September 1998 - Test - lists.nanog.org

Re: the GOV top-level domain
by Mathias Koerber 21 Sep '98

21 Sep '98

1 0

Re: the GOV top-level domain
by Sean Donelan 21 Sep '98

21 Sep '98

>A has not been the authoritative source for .GOV for a while. >Check G.ROOT-SERVERS.NET. Check WHOIS, it lists a.root-servers.net as a name server. Registrant: Government (US Federal) top-level domain (GOV-DOM) General Services Administration Center for Electronic Messaging Technologies 1800 F Street, NW Washington, DC 20405 Domain Name: GOV Administrative Contact, Technical Contact, Zone Contact: Borgoyne, Gary (GB260) gary.borgoyne(a)FED.GOV 202-501-6824 202-501-1337 Record last updated on 02-Oct-97. Record created on 01-Jan-85. Database last updated on 21-Sep-98 04:08:47 EDT. Domain servers in listed order: A.ROOT-SERVERS.NET 198.41.0.4 H.ROOT-SERVERS.NET 128.63.2.53 B.ROOT-SERVERS.NET 128.9.0.107 C.ROOT-SERVERS.NET 192.33.4.12 D.ROOT-SERVERS.NET 128.8.10.90 E.ROOT-SERVERS.NET 192.203.230.10 I.ROOT-SERVERS.NET 192.36.148.17 F.ROOT-SERVERS.NET 192.5.5.241 G.ROOT-SERVERS.NET 192.112.36.4 whois: whois.nic.gov web: www.nic.gov email: registrar(a)nic.gov To see this host record with registered users, repeat the command with a star ('*') before the name; or, use '%' to show JUST the registered users. The InterNIC Registration Services database contains ONLY non-military and non-US Government Domains and contacts. Other associated whois servers: American Registry for Internet Numbers - whois.arin.net European IP Address Allocations - whois.ripe.net Asia Pacific IP Address Allocations - whois.apnic.net US Military - whois.nic.mil US Government - whois.nic.gov Besides even if it wasn't also server the domain, the root-servers should still return the NS records of the servers that are servering top-level domains. See for example the DIG for the SG top level domain. # dig @198.41.0.4 sg. ns ; <<>> DiG 2.2 <<>> @198.41.0.4 sg. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 5, Auth: 0, Addit: 5 ;; QUESTIONS: ;; sg, type = NS, class = IN ;; ANSWERS: sg. 172800 NS DNSSEC1.SINGNET.COM.sg. sg. 172800 NS AUTH02.NS.UU.NET. sg. 172800 NS NS.RIPE.NET. sg. 172800 NS DS.NIC.NET.sg. sg. 172800 NS NS1.PACIFIC.NET.sg. ;; ADDITIONAL RECORDS: DNSSEC1.SINGNET.COM.sg. 172800 A 165.21.83.11 AUTH02.NS.UU.NET. 172800 A 198.6.1.82 NS.RIPE.NET. 172800 A 193.0.0.193 DS.NIC.NET.sg. 172800 A 202.42.194.205 NS1.PACIFIC.NET.sg. 172800 A 192.169.33.3 ;; Total query time: 253 msec ;; FROM: drgate.dra.com to SERVER: 198.41.0.4 ;; WHEN: Mon Sep 21 18:58:24 1998 ;; MSG SIZE sent: 20 rcvd: 237 -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

the GOV top-level domain
by Sean Donelan 21 Sep '98

21 Sep '98

Is it just me, or are other people having trouble with the GOV domain today. The a.root-server.net doesn't seem to be returning the NS records for the GOV domain. I'm not a 'dig' expert, so what am I doing wrong? Here is a normal DIG response for the COM top-level domain # dig @198.41.0.4 com. ns ; <<>> DiG 2.2 <<>> @198.41.0.4 com. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; Ques: 1, Ans: 11, Auth: 0, Addit: 11 ;; QUESTIONS: ;; com, type = NS, class = IN ;; ANSWERS: com. 518400 NS C.ROOT-SERVERS.NET. com. 518400 NS D.ROOT-SERVERS.NET. com. 518400 NS E.ROOT-SERVERS.NET. com. 518400 NS I.ROOT-SERVERS.NET. com. 518400 NS F.ROOT-SERVERS.NET. com. 518400 NS G.ROOT-SERVERS.NET. com. 518400 NS J.GTLD-SERVERS.NET. com. 518400 NS K.GTLD-SERVERS.NET. com. 518400 NS A.ROOT-SERVERS.NET. com. 518400 NS H.ROOT-SERVERS.NET. com. 518400 NS B.ROOT-SERVERS.NET. ;; ADDITIONAL RECORDS: C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 J.GTLD-SERVERS.NET. 518400 A 198.41.0.21 K.GTLD-SERVERS.NET. 518400 A 195.8.99.11 A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ;; Total query time: 261 msec ;; FROM: drgate.dra.com to SERVER: 198.41.0.4 ;; WHEN: Mon Sep 21 18:19:02 1998 ;; MSG SIZE sent: 21 rcvd: 402 Here is a DIG response for the GOV top-level domain, notice it just returns an SOA record for the a.root-servers.net, no NS records. # dig @198.41.0.4 gov. ns ; <<>> DiG 2.2 <<>> @198.41.0.4 gov. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; gov, type = NS, class = IN ;; AUTHORITY RECORDS: . 86400 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1998092000 ; serial 1800 ; refresh (30 mins) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; Total query time: 269 msec ;; FROM: drgate.dra.com to SERVER: 198.41.0.4 ;; WHEN: Mon Sep 21 18:18:50 1998 ;; MSG SIZE sent: 21 rcvd: 94 Here is a DIG response for a non-existant top-level domain, same type of response as for the GOV domain. # dig @198.41.0.4 kasdgkasdgk. ns ; <<>> DiG 2.2 <<>> @198.41.0.4 kasdgkasdgk. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; kasdgkasdgk, type = NS, class = IN ;; AUTHORITY RECORDS: . 86400 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1998092000 ; serial 1800 ; refresh (30 mins) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; Total query time: 273 msec ;; FROM: drgate.dra.com to SERVER: 198.41.0.4 ;; WHEN: Mon Sep 21 18:23:23 1998 ;; MSG SIZE sent: 29 rcvd: 102 -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: IXC Fibre cut IL,OH
by Dean Anderson 21 Sep '98

21 Sep '98

How about some paper cups and a ball of string? (only to be deployed after the backhoe has been killed... ;-) --Dean At 06:53 AM 9/21/98 -0700, bmanning(a)vacation.karoshi.com wrote: >> >> So, the requirement should not only be 24 hour NOC, but GSM phone with >> other provider? >> >> --Dean > >Nope, get a sat-phone, some wood & wet blankets, semephore flags, a mirror and >brush up on you Moris code. .. (after reading up on tsunami threats for >the So.Cal. area over the weekend :) > >--bill > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Anyone having problems with nic.near.net
by Douglas M. Todd 21 Sep '98

21 Sep '98

at BBN? ==DMT> ======================================================================= Douglas M. Todd, Jr. Sapient Corporation One Memorial Dr. Cambridge, MA 02142 Tel: 617.679.6974 Fax: 617.621.1300 Email: dtodd(a)sapient.com http: www.sapient.com vsign: www.format-c.com/vsign.sig pgp: www.format-c.com/pgpsig #include <std_disclaim.h>

1 0

Re: More on video
by Dean Anderson 21 Sep '98

21 Sep '98

At 06:17 PM 9/18/98 -0700, Sean M. Doran wrote: > >Sandra Gittlen wrote: > >| In addition to the sheer size of the file, one issue is how to >| maintain a user's link for up to four hours. The Internet was >| not designed for such stateful connections. > >Stateful connections? > >Do you mean "long-lasting bulk-transfers"? No, I think she means modem connections. Lots of cheap modems on poor quality lines won't stay up that long reliably. Many people perceive the internet through an unreliable modem connection. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

BGP 4, auth error question.
by Harold Willison 21 Sep '98

21 Sep '98

Greetings. I am in the process of turning up bgp with a customer and have run into the following problem. The customer is using a Cisco router with ios 11.1.20. Im using a GRF400. The session wont establish and this is what the log is showing: Sep 18 15:50:59 Sep 18 15:50:59 BGP RECV 209.239.69.1+32617 -> 206.84.235.254+179 Sep 18 15:50:59 BGP RECV message type 1 (Open) length 37 Sep 18 15:50:59 BGP RECV version 4 as 11042 holdtime 180 id 209.239.64.254 authcode 8 Sep 18 15:50:59 BGP RECV Auth data (8 bytes): 02 06 01 04 00 01 00 01 Sep 18 15:50:59 Sep 18 15:50:59 bgp_get_open: peer 209.239.69.1+32617 (proto): unknown athentication code 8 used Sep 18 15:50:59 Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617 Sep 18 15:50:59 BGP SEND message type 1 (Open) length 29 Sep 18 15:50:59 BGP SEND version 4 as 4200 holdtime 180 id 206.84.235.254 authcode 0 Sep 18 15:50:59 Sep 18 15:50:59 Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617 Sep 18 15:50:59 BGP SEND message type 3 (Notification) length 21 Sep 18 15:50:59 BGP SEND Notification code 2 (Open Message Error) subcode 4 (unsupported authentication code) Sep 18 15:50:59 Sep 18 15:50:59 NOTIFICATION sent to 209.239.69.1+32617 (proto): code 2 (Open Message Error) subcode 4 (unsupported authentication code) data it appears that the cisco is sending us an authcode that we don't recognize. Is there a way to prevent the cisco from sending the authcode 8 or change the authcode to something more civilized, like authcode 0. The customer is willing to change their IOS version if necessary but it is not the preferred resolution. Any suggestions on how I could get this to work? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Senior Network Engineer 313-730-5151 * | noc(a)agis.net 313-730-1130 x-5649 | | harold(a)agis.net 24 hours a day, 7 days a week | | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

7 8

NANOG 14
by Pam Ciesla 21 Sep '98

21 Sep '98

The attendee list is now available on the NANOG webpage http://www.nanog.org. Please note this is not an automatic update, but done by human. If you are not on the list but should be or if there are any corrections please contact me. Also note that if you plan on attending NANOG 14 the hotel block ends 10/8. Atlanta Marriott Marquis 404-521-0000. Be sure to mention NANOG. ---------------------------------------------------------------------- Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 -----------------------------------------------------------------------

1 0

Re: How to loadshare over many E1 links
by Simon Leinen 21 Sep '98

21 Sep '98

>>>>> "js" == Jesper Skriver <jesper(a)skriver.dk> writes: > How would you loadshare over many (>6) parallel E1 links. [...] > I've been thinking om something similar to the Larscom inverse MUX > (http://www.larscom.com/t3ft3/t3_megae.htm) but this one only support > 4 E1's, then I can use multiple i-mux's and loadshare over the 8M links > they provide, but it seems like a poor solution. We use Larscom Orion 4000s for 6 transatlantic E1 links. The E1 cards have eight ports, with HSSI connections to the routers (75xx). You can look at the actual throughput under http://www.switch.ch/lan/stat/linkusa.html Hope this helps, -- Simon Leinen simon(a)babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Who is General Failure & why's he reading my disk?

2 1

NOTICE: Sep 21 Document Release Procedures
by Sean Donelan 20 Sep '98

20 Sep '98

If any network operator cares, here are the procedures for Monday's release of the video and documents. http://www.house.gov/radiotv/release.htm -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO

1 0