- Test - lists.nanog.org

Re: Internic does it again
by Matthew James Gering 30 Jul '97

30 Jul '97

>Because of the pending IPO, the InterNIC is in a 90 day quiet period. Even >if they have hired a PR person/group/agency, that entity couldn't really do >their job until after the IPO. I believe that this is an SEC regulation. Bullshit. We are all customers of InterNIC, they are providing service under contract with us. They have a right, and we have a right to demand that they keep us informed on any issues that may affect that services. This is a vendor/client issue, not a vendor/public issue. If they are forced to email their customer base directly instead of posting on appropriate forums during that 90 days then fine, but it is definitely something that should and needs to be done. Matt

1 0

Re: [nsp] known networks for broadcast ping attacks
by Jeffrey S. Curtis 30 Jul '97

30 Jul '97

Jay R. Ashworth writes: }Ought IP stack implementations not to refuse to reply to ECHO_REQUEST }packets with destination address which are broadcast addresses? Why? It's a useful tool. }Ok, yes, I know that CIDR makes this harder, but knowing which nets }fall on non-octet boundaries is non-obvious, too, and this particular }attack wasn't trying... It's not hard - a host knows its own subnet mask and therefore can calculate its broadcast address trivially (my IP address logical-AND my subnet mask, plus all ones in the zero-portion of the mask). }.255 is _always_ a broadcast address, no? Wrong - consider what happens on nets whose subnet mask is less than 24 bits long (I have many such nets). 10.1.1.255 is a unicast host address if the mask is /23, or /22, or... Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

2 1

Re: [nsp] known networks for broadcast ping attacks
by shields＠crosslink.net 30 Jul '97

30 Jul '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > Ought IP stack implementations not to refuse to reply to ECHO_REQUEST > packets with destination address which are broadcast addresses? Apparently some management packages search out hosts using broadcast pings. Not the best decision IMO. This was discussed a couple of days ago on bugtraq and I posted a Linux patch to cause it not to answer broadcast pings. *** How do you configure your router for that? no ip directed-broadcast. -- Shields, CrossLink.

1 0

TLD .ES screw up
by Miguel A. Sanz. RedIRIS/CSIC 30 Jul '97

30 Jul '97

We hate to have to deal with this in public lists, but there seems to be the only way InterNIC reacts to problems these days :-( Top level domain .es was screw up by InterNIC in yesterday's root zone update. They've added an unauthorized NS without our request, knowledge or consent. We've been trying to get InterNIC to solve the problem ASAP (as it is affecting access to nearly 200.000 hosts under .es) sending messages to action(a)internic.net, hostmaster(a)internic.net and a couple of their management staff (see below) without success. We even were ingenuous enough to try to get some techical knowledgeable person on the phone but... first we got redirected to the IANA phone number!, second try (after convincing the operator that InterNIC is also in charge the root zone not only the .com .net .org domains) we had our contact data taken with the promise of a phone back by a technician which hasn't happened yet. So my questions now: Does any one know a direct way to reach the InterNIC technical staff to solve this kind of urgent problems? Shouldn't there be a specific set up of procedures, forms and communication channels between the managers of the root zone and the TLD managers? Any help will be appreciated. Miguel A. Sanz ES-NIC __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN Network Manager ____________ Spanish Academic & Research Network ________________________ --- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> Date: Wed, 30 Jul 1997 15:05:45 +0200 (MET DST) From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> To: "David H. Holtzman" <dholtz(a)internic.net> Subject: (Fwd) EMERGENCY TLD .ES Cc: hostmaster(a)nic.es Please take quick action on this and report back! We will wait a couple more hours before escalating this to IANA and TLD list. Regards, Miguel A. Sanz ES-NIC --- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> Date: Wed, 30 Jul 1997 11:49:59 +0200 (MET DST) From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> To: hostmaster(a)internic.net Subject: EMERGENCY TLD .ES Cc: cert(a)rediris.es, Mark Kosters <markk(a)internic.net>, hostmaster(a)nic.es Dear hostmaster, I am the technical contact of the top level domain for Spain (".es"). Much to our surprise we discover yesterday that a new unauthorized NS was popping up in everybody's caches for the ".es" zone. At first we thought that a cache infection attack (the kind of Alternic's against InterNIC) was taking place and spread the word that everybody in the country upgrade to the recent versions of BIND. However, some places running BIND-4.9.6 and 8.1.1 were also infected!!! We the went to check InterNIC's database and ... the problem is there!!! InterNIC has made a change in the delegation of the ".es" zone without our request, knowledge or consent. Instead of the authorized nameservers which are: SUN.REDIRIS.ES 130.206.1.2 CHICO.REDIRIS.ES 130.206.1.3 PRADES.CESCA.ES 192.94.163.152 NS.EUNET.ES 193.127.1.11 SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 NS.EU.NET 192.16.202.11 RS0.INTERNIC.NET 198.41.0.5 NS.UU.NET 137.39.1.3 MUNNARI.OZ.AU 128.250.1.21 128.250.22.2 You have now: SUN.REDIRIS.ES 130.206.1.2 CHICO.REDIRIS.ES 130.206.1.3 PRADES.CESCA.ES 192.94.163.152 LINUX2.DYCSA.ES 195.53.97.1 SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 NS.EU.NET 192.16.202.11 RS0.INTERNIC.NET 198.41.0.5 NS.UU.NET 137.39.1.3 For unkown reasons an unauthorized change has been made to the root zone and the InterNIC database. You have placed a bogus NS LINUX2.DYCSA.ES instead of the legal one: NS.EUNET.ES !!! Please CORRECT this as soon as possible and restart the root server. We would also like that you open an investigation about this case to know if this has been caused by some InterNIC's internal error or by an intentional ill will request made by someone. Please keep as inform about your actions to correct this error and of the results of your internal investigation. Regards, Miguel A. Sanz (MAS122) ES-NIC __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN Network Manager ____________ Spanish Academic & Research Network ________________________ ---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> ---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es>

7 6

Re: Out of Office AutoReply: how to protect name servers against cache corruption
by Systems Engineer 30 Jul '97

30 Jul '97

I believe this was for the rest of the list :) Schwartz, Steven wrote: > To All: > > I am out of the office until August 4th. In my absence, if your > matter > is urrgent please call or e-mail or Steven Leibrock x9496, in the > GSINet group. > > Thanks.... steve -- --- --- --- --- --- --- --- --- --- Steven Nash ph: (516)248-8400ext25 Systems Engineer / Network Security fax: (516)248-8897 Lightning Internet Services LLC email: snash(a)lightning.net http://www.lightning.net --- --- --- --- --- --- --- --- ---

1 0

Re: TLD .ES screw up
by Miguel A. Sanz. RedIRIS/CSIC 30 Jul '97

30 Jul '97

On Jul 30, 20:52, Paul A Vixie wrote: > Subject: Re: TLD .ES screw up > I want to correct a misapprehension. InterNIC does not make changes to > the root zone. The root zone is in the province of the IANA, and only > IANA can explain why this change was made or get it fixed for you. NSI > is just a publication facility for the root zone, they don't edit it. >-- End of excerpt from Paul A Vixie I think you're wrong. Last time we had to change .es delegation one and a half years ago, we had to sent a normal template to hostmaster(a)internic.net But InterNIC also make changes to hosts where domains are delegated which seem to be the cause of this problem. Someone made a wrong "host template" request for one of the secondaries of .es (ns.eunet.es) changing its name and IP address, which had the effect of changing the delegation of the .es zone. For what I understand, InterNIC is admiting hosts templates for domains which are not under .com .org .net, etc. (the TLDs under his management) and placing glue records for them in the DNS. Am I right? If this is such, I don't think this is correct. If someone wants a domain under .com to be delegated in a server under .es they shouldn't place glue records for this nameserver (the same way we don't place glue records for nameservers of .es domains delegated into .com NSs). The only glue records they should have for NSs under .es are the ones in which the TLD .es is being delegated and those should be admited only if included in the TLD delegation (or change of delegation) request. Miguel A. Sanz

2 1

Re: how to protect name servers against cache corruption
by Paul A Vixie 30 Jul '97

30 Jul '97

someone asked me a question in private e-mail that deserves a public answer. > 1) How exactly did Eugene Kashperuff propogate this "RR poisoning" across > the Internet? From NANOG's previous mailings I can deduce that it was along > the lines of dig @victim -t ns www.alternic.net. Where www.alternic.net had > duff A records. yes. > 2) What were/are the symptoms of this attack? www.internic.net resolving to > www.alternic.net? yes. > 3) If it was that easy to do, why hasn't it happened again? because that particular attack only works if you are willing to get caught. since eugene did this as a publicity stunt (which, i understand, has now begun to backfire on him since his victims didn't interpret it that way), he _needed_ to be caught. > 3a) What measures were taken (other than discussion of DNSSEC, or lack of > it) to 'cure' affected servers? upgrade to bind-4.9.6 or bind-8.1.1. > 4) How can I check for cache corruption? "dig @0 www.netsol.com a" and "dig @cache00.ns.uu.net www.netsol.com a" and check for differences. > Apologies if any of the above sound moronic or ill-informed; extracting > facts from reams of "what is a backhoe" mail list is a painfully slow task. > Time for some filters I think... no apologia needed. public explainations of this attack have been poor, even and especially by me. i'm grateful for the opportunity to improve on that.

3 2

Re: Big increase in DNS service ?!?!
by John J. Buxbaum 30 Jul '97

30 Jul '97

I saw the samething last week. Any ideas? -----Original Message----- From: Francois Beauregard <FBorg(a)fbli.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Subject: Big increase in DNS service ?!?! >Wow... I just checked the root servers for the list of head servers from >a.root-servers.net... > >Anyone knows why all servers are repeated twice... > >>From NSLookup I got... > >(root) > origin = A.ROOT-SERVERS.NET > mail addr = hostmaster.INTERNIC.NET > serial = 1997072900 > refresh = 10800 (3 hours) > retry = 900 (15 mins) > expire = 604800 (7 days) > minimum ttl = 86400 (1 day) >(root) nameserver = J.ROOT-SERVERS.NET >(root) nameserver = K.ROOT-SERVERS.NET >(root) nameserver = L.ROOT-SERVERS.NET >(root) nameserver = M.ROOT-SERVERS.NET >(root) nameserver = A.ROOT-SERVERS.NET >(root) nameserver = H.ROOT-SERVERS.NET >(root) nameserver = B.ROOT-SERVERS.NET >(root) nameserver = C.ROOT-SERVERS.NET >(root) nameserver = D.ROOT-SERVERS.NET >(root) nameserver = E.ROOT-SERVERS.NET >(root) nameserver = I.ROOT-SERVERS.NET >(root) nameserver = F.ROOT-SERVERS.NET >(root) nameserver = G.ROOT-SERVERS.NET >(root) nameserver = J.ROOT-SERVERS.NET >(root) nameserver = K.ROOT-SERVERS.NET >(root) nameserver = L.ROOT-SERVERS.NET >(root) nameserver = M.ROOT-SERVERS.NET >(root) nameserver = A.ROOT-SERVERS.NET >(root) nameserver = H.ROOT-SERVERS.NET >(root) nameserver = B.ROOT-SERVERS.NET >(root) nameserver = C.ROOT-SERVERS.NET >(root) nameserver = D.ROOT-SERVERS.NET >(root) nameserver = E.ROOT-SERVERS.NET >(root) nameserver = I.ROOT-SERVERS.NET >(root) nameserver = F.ROOT-SERVERS.NET >(root) nameserver = G.ROOT-SERVERS.NET >J.ROOT-SERVERS.NET internet address = 198.41.0.10 >K.ROOT-SERVERS.NET internet address = 193.0.14.129 >L.ROOT-SERVERS.NET internet address = 198.32.64.12 > >Because of the size limit of the packets, I receive only 3 IP from the >query to a root server and I get the following response when starting DNS... > >"NOTICE : check_root: 1 root servers after query to root server < min." > >Not pretty... Is this a screwup again or are they getting "spoofed" ??? > > > >Sincerely > >---------------------------------- >Francois Beauregard >FBorg(a)fbli.com >FBLI.COM >We love feedbacks and live by them > >Sales : Sales(a)fbli.com 1 (888) FBLI.COM >Tech support : Support(a)fbli.com 1 (514) 349-0455 >Internet Web : http://www.fbli.com >ICQ : 1907537 > >Montreal, Canada >---------------------------------- >

1 0

Re: how to protect name servers against cache corruption
by James R. Cutler 30 Jul '97

30 Jul '97

Ben, You have stated that there exist potential security fixes for bind which do not require DNSSEC. Please serve your internet community by providing the necessary code to Mr. Vixie. Thank you. - James R. Cutler EDS Mail Stop 4165 800 Tower Drive, Troy, MI 48007-7012 Phone: 248-265-7514 FAX: 248-265-7514 EDS Internal Web: <http://www.iscg.eds.com/cutler/> World Wide Web: <http://www.ltu.edu/midecus/dechtm/cutler/cutler.htm>

1 0

Re: ANS etc.
by Douglas Jardine 30 Jul '97

30 Jul '97

First, thanks for the replies. >> [4] Some recent threads on NANOG discussed physical layer issues like >> SONET, SDH, circuit layout etc. Could somebody point me to >> technical papers / articles / books which describe fiber and >> copper technology in detail. > >Ask in comp.dcom.telecom.tech. > Judging from the answers to this question, I gather I didn't phrase the question correctly. What I am looking for some is practical literature on fiber and copper technology - stuff which network operators and designers need and use. I would have guessed there would be an equivalent to say what the Stevens Books are to TCP/IP. Or have most people on this list learnt their skill by experience only? -dj ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1