- NANOG - lists.nanog.org

The Great RADB Clean-Up
by Christerfer R. Frazier 08 Feb '02

08 Feb '02

Effective April 2, 2002, Merit Network, Inc. will begin the process of removing RADB maintainer objects that have not been renewed and paid for 2002. This message is to inform the community about our clean-up process so that RADB users can take measures to minimize any operational impact. All maintainers scheduled for removal will be posted before March 15, 2002 at http://www.radb.net/docs/deletelist.html. Currently, about 2,100 maintainers with 52,000 total objects are unpaid and scheduled for removal beginning April 2 unless payment is made. Of the total 2,100 maintainers, 1,100 have associated valid objects in the RADB. These 1,100 maintainers, in turn, have 22,000 associated valid objects that are currently being routed in the Internet. For example, eleven of the top twenty maintainers (in terms of number of total objects) have not yet been renewed and are scheduled for removal. We are currently making a targeted effort to remind the owners of maintainers with valid objects about the deadline. About 1,000 "stale" maintainers with either invalid objects or no objects at all will be removed as part of the clean-up. All maintainer IDs scheduled for removal will be posted on the RADB Clean-up web page at http://www.radb.net/docs/deletelist.html before March 15, 2002. As of today, only some of the maintainers have been posted. At the same URL, you will also find a tool to check for a specific maintainer and associated objects (if any) targeted for removal. If you are filtering routes based on the RADB, we urge you to stay abreast of this information. We will be providing regular updates via the NANOG list and on the web page. The RADB service fee for January 1, 2002 through December 31, 2002 is $250 per maintainer object. The RADB service agreement must be renewed annually. Merit's policy, as specified in the agreement, is to remove maintainers that have not been renewed and paid. As a non-profit organization, Merit does not pursue profit as a goal. The $250 maintainer fee is strictly a cost recovery mechanism that helps support the ongoing 24x7 operations of the RADB. Costs that Merit must cover through maintainer fees include contracting for 24x7 NOC monitoring; server maintenance and connectivity; help-desk support; second-level 24x7 on-call engineering; and maintenance of the IRRd database server software that powers the RADB. We welcome your input on the RADB clean-up. The Merit RADB team will be on hand to discuss questions and concerns about the database clean-up during the Route Registry BOF at NANOG24 on Monday, 9:00-10:30 PM. We hope you'll join us! URLS: To view or query the list of maintainer IDs scheduled for removal: http://www.radb.net/docs/deletelist.html To review the RADB maintainer object agreement: http://www.radb.net/docs/agreement.html To renew RADB service and pay for your maintainer object: https://www.merit.edu/cgi-bin/radb/pay/alive For general information: http://www.radb.net For Merit RADB, Chris Frazier

1 0

"Tier 1 Backbones" which don't filter IP packets? --SUMMARY
by Ehud Gavron 08 Feb '02

08 Feb '02

On January 27th, while pimping the latest NANOG Traceroute at ftp://ftp.login.com/pub/software/traceroute/beta I asked about providers that don't administratively prohibit LSRR and SSRR packets. Response was overwhelming, and I've finally gone through all the responses. Requests for summary were overwhelming, and I've BCCd all of those who requested that, but thought I'd CC the list since there's such interest. Thanks for all the feedback, especially those who took the time to provide official responses from the various corporations... and I'm sorry I couldn't respond to everyone individually. Ehud LSRR and SSRR SUMMARY: Some providers REQUIRE it for peering. Lots of providers ALLOW it from customers and peers. Only one was verified to deny LSRR/SSRR and admit to it. There is a good work in progress page at http://www.gweep.net/~crimson/networks/lsrr.html REQUIRE: (alpha order) Genuity [verified] RCN [from URL above] ViaNet [from URL above] Verio [verified] WiscNet [from URL above] ALLOW: Cable & Wireless Sprintlink Global Crossing Hurricane Networks E.Spire Worldcom AT&T DO NOT ALLOW AND ADMIT TO IT: Time Warner Telecom [verified] -end-

1 0

RE: route-views.oregon-ix.net
by Peter Rohrman 08 Feb '02

08 Feb '02

No problem my friend. Pete -----Original Message----- From: David Meyer [mailto:dmm@sprint.net] Sent: Friday, February 08, 2002 11:09 AM To: Peter Rohrman Cc: 'nanog(a)nanog.org' Subject: Re: route-views.oregon-ix.net There was some problem with it. I wasn't on site but Joel handled it. Thanks for the report. Dave On Thu, Feb 07, 2002 at 10:11:13AM -0500, Peter Rohrman wrote: >> >> I cant get to route-views.oregon-ix.net. Is this route server >> decommissioned or is this just an outage? >> >> Pete >> >> ************************************************************************** >> Peter Rohrman One Executive Dr. >> Network Engineer Fort Lee, NJ 07024 >> Everest Broadband Networks (201) 905-8491 >> **************************************************************************

2 1

route-views.oregon-ix.net
by Peter Rohrman 08 Feb '02

08 Feb '02

I cant get to route-views.oregon-ix.net. Is this route server decommissioned or is this just an outage? Pete ************************************************************************** Peter Rohrman One Executive Dr. Network Engineer Fort Lee, NJ 07024 Everest Broadband Networks (201) 905-8491 **************************************************************************

3 2

COM/NET/ORG/EDU Registry Informational Message
by Brad Verd 08 Feb '02

08 Feb '02

To All, VeriSign GRS will be making several changes to the COM, NET, ORG and EDU zone files. Their format will be modified to reduce the overall file size by removing unnecessary text and extraneous records. Currently the excess information causes an increase in the time required to generate and distribute these files. In the interest of making timely updates and meeting ICANN requirements for file distribution, the following changes will be made: 1. Modify Zone File Format to Reduce Size Using certain directives and shortcuts to replace recurring values will significantly reduce the size of these zone files: - Records will contain unqualified, or relative, domain names whenever possible. The particular zone files origin will be specified with a $ORIGIN directive and should be appended to unqualified domain names per RFC 1035, section 5.1. - The $TTL directive will be used set the default time to live for subsequent records in the zone file per RFC 2308, section 4. Individual records will no longer contain an explicit TTL. - The IN class will be specified in the SOA record but omitted in all subsequent records, since a records class defaults to the previously specified class. See RFC 1035, section 5.1 for more information. These format changes are currently scheduled to be implemented late Q2 2. Eliminate Orphan A Records The current zone generation process publishes A (address) records (also called glue records) regardless of whether the name server is referenced by any NS (name server) records. Put another way, an A record is published even if no zone delegations reference it. These A records are called orphans, and their presence in the COM/NET/ORG zones is undesirable for both administrative and technical reasons The inclusion of these orphan A records can cause problems for administrators of lower-level name servers. Even if the lower-level servers are configured properly, orphan A records in the COM/NET/ORG zones can interfere with normal resolution of lower-level zones and make maintenance (especially changes) difficult and confusing. If the lower-level name servers are configured improperly, the presence of orphan A records may be the only reason that resolution is currently working correctly. Therefore, it is important that all administrators of COM/NET/ORG subzones have the correct information in their zones prior to the removal of orphan A records from the COM/NET/ORG zones. Verisigns proposed resolution for achieving this is as follows: Step 1 (by late February): A report will be generated weekly for each registrar indicating the orphan A records owned by that registrar. VeriSign GRS will also include instructions describing the steps that should be taken to ensure that lower-level name servers are properly configured so that removal of the orphan A records will not cause failures in resolution. Step 2 (by late February): A list of all orphan A records will be posted to the VeriSign GRS web site and will be updated weekly. This list will allow registrants to determine if they might be affected by the elimination of orphan A records from the COM/NET/ORG zones and provide instruction on resolving these issues Step 3 (Currently scheduled for late Q2): Approximately a week before the modification to the zone generation process to remove orphan A records is implemented, another email will be sent out as a reminder with the exact date that the change will occur. Regards, Brad -------------------------------------- Brad Verd Resolution Systems Operations Manager Verisign Global Registry Services Email - bverd(a)verisign.com ---------------------------------------

2 1

testing sprint
by Eric A. Hall 08 Feb '02

08 Feb '02

The question is, does sprint.net have the balls to terminate Sprint long distance for spamming? http://tracking.networkpromotion.com/Tracking/etags.html?LinkID=5202 -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

4 3

Round Robin DNS
by Ken Yeo 07 Feb '02

07 Feb '02

I would like to get your comments on pros and cons on using round robin DNS to load balance web servers that are located in geographical disperse locations? What current technologies you are using to run disaster recovery? Says we have site A and site B, if site caught a fire, all web browser will be redirected to site B web server only. We are planning to use round robin DNS with BGP to achieve this, is there a better way to do this? Thanks. Suan Jong Yeo Network Engineer Aurum Technology ken.yeo(a)aurumtechnology.com

3 2

Re: Querying Large Number of Whois Records?
by Spencer.Wood＠dot.state.oh.us 07 Feb '02

07 Feb '02

We are wanting a way to go though our web servers logs, and try to get a idea of where our traffic is coming from...... We have a script that works really great, but we have to put a pause in it to keep from overloading ARIN... Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.387.0710/Fax: 815.361.0714/Pager: 866.591.9954 ************************************************************* Doug Barton <DougB(a)DougBarton.net> Sent by: doug(a)yahoo-inc.com 02/07/2002 12:06 AM To: Spencer.Wood(a)dot.state.oh.us cc: nanog(a)merit.edu Subject: Re: Querying Large Number of Whois Records? Spencer.Wood(a)dot.state.oh.us wrote: > Anyway, we are looking for a way to query a large number of Whois > Records. For what purpose? Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!?

3 2

Querying Large Number of Whois Records?
by Spencer.Wood＠dot.state.oh.us 07 Feb '02

07 Feb '02

I'm sure that someone has already been asked by someone on this list, so please forget the duplicate request.... Anyway, we are looking for a way to query a large number of Whois Records. We have a perl script that does a really great job of this (Feed it IP Address's, it give you back whois records), but, ARIN's Whois server appears to be configured that after 50 or so queries in quick succession, it will kill our connection (Which actually makes sense because of the potential load we or other people might put on it). So, I was wondering, is there any good method of queuing large number of Whois Records, or possibly setting up a caching whois server? Any comments/suggestions would be greatly appreciated! Thanks! Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.387.0710/Fax: 815.361.0714/Pager: 866.591.9954 *************************************************************

3 3

apuc.. reponses on reverse DNS
by Rich 07 Feb '02

07 Feb '02

When running a reverse-DNS lookup on a few IP addresses in Korea or Japan, I was getting either "apuc10", "apuc20", or "apuc21" reposes back. I'm not sure what these mean. If anyone had some detail or could point me in the right direction I'd most appreciate it. Thanks in advance, Rich

2 1