February 2002 - Test - lists.nanog.org

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 07 Feb '02

07 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 07 Feb '02

07 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

testing sprint (fwd)
by David Lesher 06 Feb '02

06 Feb '02

> The question is, does sprint.net have the balls to terminate Sprint long > distance for spamming? During the height of the 84 MFJ negotiations, then C&P Tel. disconnected the ATT lobbying office for non-payment. (It made the Wall Street Journal.) -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Hyperflow load balancer.
by Daniel F. Chief Security Engineer - 06 Feb '02

06 Feb '02

I have been looking around for documentation on these this and cannot find any. Its a Hyperflow 2 made by Holontech. thats about all I know i can get to a user like shell but cannot figure out how to reset the password. does anyone know how to reclaim or reset the root/admin pass on these things. We got them second hand no docs no passwords. and have to make them work :) TIA -- Chief Security Engineer | Daniel Fairchild danielf(a)supportteam.net Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.

1 0