Re: URGENT: ns.internic.net blown
It just recently happened to two of our networks as well (last week). I don't remember being warned about this, yet it has happened to several providers so far. Len On Mar 5, 10:03am, David Bergum wrote:
Subject: URGENT: ns.internic.net blown Per,
have you recently reassigned 194.0.0.0 via swip? There was a swip bug that blew away the total registration record for a CIDR block when the zero net was reassigned. I have suffered the consequence of this with two of my cidr blocks. With one it took over 3 weeks for them to fix. Not good....
Dave.
-- A Minnesota Regional Network -----/|\-----------------------------------------------+ - / | \ Dave Bergum <bergum@MR.Net> | - /__|__\ 511 11th Av S, Box 212 Gab: (612)342-2895 | - j---'---/ Minneapolis, MN Fax: (612)344-1716 | -~~~~~~~~~~ 55415-1536 Beep: (612)637-6791 | -------------------------------------------------------+ -- End of excerpt from David Bergum
-- BBN/BARRNET ..The PREMIER West Coast Network Provider.. info@barrnet.net Work: len@barrnet.net http://www.barrnet.net 415-528-7111 (sales/info) Personal: len@netsys.com http://www.netsys.com 415-528-7205 (office)
On Mar 5, 10:34, Len Rose wrote:
It just recently happened to two of our networks as well (last week). I don't remember being warned about this, yet it has happened to several providers so far.
It's a little worse than that in this case; 194 isn't a provider block, it's one of the two superblocks in Europe, delegated to the RIPE NCC (the other one is 193). The bogus info is actually in the zone files themselves, according to Lars-Johan Liman at KTH in Sweden (they run nic.nordu.net, one of the root servers). This means that all root servers will be infected -- I just checked three, and yep, sure enough. Those root operators reading this, please consider fixing the zone file; the correct data is 194.IN-ADDR.ARPA. 518400 NS sunic.sunet.se. 194.IN-ADDR.ARPA. 518400 NS munnari.oz.au. 194.IN-ADDR.ARPA. 518400 NS sparky.arl.mil. 194.IN-ADDR.ARPA. 518400 NS ns.ripe.net. 194.IN-ADDR.ARPA. 518400 NS ns.eu.net. 194.IN-ADDR.ARPA. 518400 NS ns.uu.net. 194.IN-ADDR.ARPA. 518400 NS layon.inria.fr. munnari.oz.au. 86400 A 128.250.22.2 munnari.oz.au. 86400 A 128.250.1.21 sparky.arl.mil. 52142 A 192.5.23.200 sparky.arl.mil. 52142 A 128.63.48.85 ns.ripe.net. 86400 A 193.0.0.193 ns.eu.net. 86400 A 192.16.202.11 ns.uu.net. 7200 A 137.39.1.3 layon.inria.fr. 172800 A 192.93.2.4 sunic.sunet.se. 86400 A 192.36.148.18 sunic.sunet.se. 86400 A 192.36.125.2 -- bilse, EUnet NOC +31 20 592 5110; 24hr +31 20 592 5165 (emergencies only) EUnet Comm. Svcs. +31 20 623 3803; fax +31 20 622 4657 http://www.EU.net
It's a little worse than that in this case; 194 isn't a provider block, it's one of the two superblocks in Europe, delegated to the RIPE NCC (the other one is 193).
The bogus info is actually in the zone files themselves, according to Lars-Johan Liman at KTH in Sweden (they run nic.nordu.net, one of the root servers). This means that all root servers will be infected -- I just checked three, and yep, sure enough.
Those root operators reading this, please consider fixing the zone file; the correct data is
194.IN-ADDR.ARPA. 518400 NS sunic.sunet.se. 194.IN-ADDR.ARPA. 518400 NS munnari.oz.au. 194.IN-ADDR.ARPA. 518400 NS sparky.arl.mil. 194.IN-ADDR.ARPA. 518400 NS ns.ripe.net. 194.IN-ADDR.ARPA. 518400 NS ns.eu.net. 194.IN-ADDR.ARPA. 518400 NS ns.uu.net. 194.IN-ADDR.ARPA. 518400 NS layon.inria.fr.
i've fixed this on ns.isc.org, though i'm not sure what good it will do unless all the roots do it.
participants (3)
-
len＠barrnet.net -
Paul A Vixie -
Per Gregers Bilse