- NANOG - lists.nanog.org

Abuse contact at Qwest IP
by just me 19 Nov '01

19 Nov '01

If anyone has a useful abuse contact at qwest ip, please mail me at mghali(a)ea.com. I've been seeing a DoS from their network for over 6 hours now, and the contacts on Jared's fine page have been less than useful. Sorry for the WOB.. matt ghali --mghali(a)snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

1 0

ISP network design of non-authoritative caches
by Sean Donelan 19 Nov '01

19 Nov '01

I appreciate the redirect, if there is a better list, but my question is directed at network operators. namedroppers is for dns protocols, dnsops is for operators of authoritative name servers. The majority of users on today's Internet will never directly query any root name server, or any other authoritative name server. Instead of a set of authoritative servers, the servers which actually deliver direct DNS service to users/hosts are non-authoritative, caching servers. There are more caching, name servers at the edge of the net than there are Akamai boxes in the world. In the late 1980's and early 1990's, when the net was much more interesting (i.e. flaky, low-bandwidth, expensive circuits) network operators carefully planning where to place caching-only name servers, and configuring end-systems to use the appropriate set of servers. A well-configured set of caching-only name servers can maintain the illusion of DNS for several hours, even during a network partition or loss of many authoritative name servers, at least for the "popular" names. They work so well, people forget they can still have problems. During the boom times, ISPs couldn't individually configure millions of DNS clients. They generally told subscribers to use two statically configured name servers, or more recently used DHCP to set them. Several national ISPs, including the one I use, with millions of subscribers, appear to still do this. We know this isn't good engineering practice, because another national ISP with millions of subscribers configured their network the same way, and experienced a multi-hour service disruption affecting most of their users a couple of years ago when an error blocked access to their two caching-only, name servers. There is lots of "best practice" information for configuring authoritative name servers (including the root and TLDs). The BOG, O'Reilly, DNSOPS, RFCs, etc. There are several "managed service" companies which will maintain authoritative name servers for you. Although most of this stuff seems obvious, network providers seem to get bitten by the same obvious things over and over again. Is there a white paper, best common practice, or book which shows the naive ISP (whether they have 10 or 10 million subscribers) how to architect their DNS system? Medium and large organizations having firewalls with internal/external DNS, which already includes local caching. This seems to be mostly a large, national ISP issue. By their nature, small ISP networks tend to have "shared fate" among all of their systems anyway.

16 24

Re: how many roots must DNS have before it's considered broken (Re: ISP network design of non-authoritative caches)
by Steven M. Bellovin 19 Nov '01

19 Nov '01

In message <5.1.0.14.2.20011119140458.0338d260(a)oak.higgs.net>, Simon Higgs writ es: > >At 05:21 AM 11/19/01 +0000, you wrote: > >>Once we start down the slippery slope of "I'm a root too", how >>many different ad hoc DNS "universes" (for lack of better >>term) must we have before we decide that things are "broken"? > >Two. That happened back in 1996 when the IANA TLD applicants began getting >their glue added to AlterNIC. Today lack of entry in the root has created a >dozen or so more alt.roots. Now people are beginning to notice the >consequences (i.e. the .US zone is now causing cache pollution outside the >legacy root since it's using the ICANN .BIZ name servers - and that .BIZ >isn't recognized by all the alt.roots). See what happens when there's more than one root? > >But it's OK. Really. There's only one root. Honest. Except for this one, >which is being run with all the usual I* blessings: > >http://www.isi.edu/otdr/ > >>Maintaining a single, authoritative root seems, IMHO, to be a >>Good Thing. Given multiple registries, namespace collisions >>would get ugly -- and, even in the absence of collisions, let us >>consider "reachability" issues. Don't confuse the question of the number of servers with the technical question of what a root is; that's determined by the content. > >That's the point. Getting the alt.root "universes" to cooperate is an >exercise similar to "cat herding", but it has to start somewhere. > Please -- if folks "co-operate" properly, there's one root. Don't confuse the question of how many roots there should be with who should decide the contents. Whether or not ICANN should be the sole decision-maker is a purely political question, and out of scope on the ICANN list. >Simon > >-- >DNS is not a sacred cow that cannot be replaced by something better. Sure -- my estimate is that that will take ~8 years: 1-2 years to design, 1-2 years of coding, testing, and interoperability testing, at 5 years for the installed base of machines to be replaced, since most machines are never upgraded. And you have to climb uphill against that installed base, and against folks who don't understand why they should populate your new database when they've already populated (and paid, both directly and in support costs), for the existing database. I'm not saying that you're wrong -- in fact, I agree that the current scheme is showing its age in many different ways -- but don't underestimate the difficulty of replacing it. (The only similar example I can think of, in terms of its impact on both end systems and the infrastructure, is IPv6 -- and we all know how much of that is deployed.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

Congestion peering C&W<->@home
by German Martinez 19 Nov '01

19 Nov '01

Hi, Have somebody notice some congestion between C&W and @home, >12 acr2-loopback.NewYork.cw.net (206.24.194.62) 153 ms 128 ms 149 ms > 13 * cable-and-wireless-peering.NewYork.cw.net (206.24.193.242) 346 ms > 349 ms -------> peering congested. > 14 c1-pos4-0.cmdnnj1.home.net (24.7.65.229) 353 ms 340 ms * Is the same congestion all the time, it doesn't matter what time of the day. Any response, off/online will be highly appreciated. Thank you German ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * THE DILBERT FUTURE * * Thriving on Stupidity in the 21st Century * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Internet capacity will increase indefinitely to keep up with the egos of the people using it"

3 2

problem with dotregistrar.com
by dan kelley 19 Nov '01

19 Nov '01

hi- i'm in the unfortunate position of being stuck with dotregistrar.com as the registrar for a domain. i've had a bunch of problems with them in the 11+ months that the domain has been parked there, but none as bad as this: they refuse to transfer my domain to another registrar, have blocked that transfer consistently over the past 5 months, and i'm running out of time before the domain registration expires. dotregistrar appears to be a subsidiary of iholdings.com; unfortunately they're about as responsive as dotregistrar - i've called them a bunch of times, left 2 messages, but never heard anything back. my question is this: do i have any recourse to fix this situation, or can a poorly-run registrar such as this one basically force me to pay them to renew the domain? i tried to use ICANN's registrar problems reporting, but that appears to be unreachable (not sure if this relates to the ICANN problems discussed earlier). thanks- dan

1 0

Re: ISP network design of non-authoritative caches
by Paul A Vixie 19 Nov '01

19 Nov '01

> The world isn't black and white, Paul, and attempting to paint is to -- > particularly on this topic -- doesn's support your reputation. rfc1034 and rfc1035 are entirely black-or-white on these matters. that you want to run your own root-like zone is understandable. that you would allow it to be queried outside of your rfc1918 scope is entirely beyond rationality. > And saying "well, those people don't interest me" ain't real productive > either. i'm not interested, but i am certainly entertained.

3 2

The good old days, or was it (DNS reliablity)
by Sean Donelan 19 Nov '01

19 Nov '01

Does anyone have any archives between 1985 and 1991? We've stumbled a lot to reach where we are. Of course, one reason the net survives is parnoid people worry about this stuff. 1985 DARPA/DCA implements RFC 920, 921 (USC-ISI/SRI-NIC) 15 Mar 1985 Symbolics.COM registered (first DNS name, excluding .ARPA transition names) [????archives????] 1 May 1991 DDN NIC contract transfered from SRI International to GSI 26 Mar 1992 Bogus "." contamination moevax.edu.tw (and many more for several years) 1 Jun 1992 Caching-only name server (BIND) hangs when forwarders unreachable 1993 Slow connections/packet loss to NIC.DDN.MIL result in many different distribution problems (also CIX/ANS peering battles). Report consistent 50%+ packet loss to NIC.DDN.MIL root name server. Apr 1993 NS.INTERNIC.NET added to hints file NSI/GSI Internet connection upgraded from 56K to T1 21 Apr 1993 DNS/UDP packet size limit exceeded 31 Aug 1993 Bellovin suggests using pseudo-host root.net to pack server list 3 Apr 1994 AOS.BRL.MIL renamed AOS.ARL.ARMY.MIL (server name mismatch) 19 Apr 1994 Sprint employee registers the domain name MCI.NET (first namejacking?) 9 May 1994 KAVA.NISC.SRI.COM removed as a root name server 9 Jun 1994 NS.ISI.EDU added as a root name server 18 Jul 1994 Bogus in-addr.arpa SOA/NS disrupts networks 28 Aug 1994 Malformed PTR entry in in-addr.arpa zone disrupts most root name servers 2 Sep 1994 NS.ISC.ORG added as a root name server 7 Oct 1994 C.NYSER.NET changed to C.PSI.NET 17 Oct 1994 Bogus NS records for COM zone polluting servers 15 Feb 1995 Recursion turned off on the last root name server with it enabled 4 Aug 1995 root-servers.net introduced into root zone ns.nasa.gov changed ip addresses ns.isc.org uses net 39 experiment address 1 Sep 1995 ns.internic.net changed to a.root-servers.net (last root-servers.net change) 13 Sep 1995 Leaked: NSI begins fee-based DNS registration Sep 18 1995 16 Nov 1995 f.root-servers.net address change at the end of net 39 experiment May 1996 Guardian announced to protect names and server information 23 Jul 1996 g.root-servers.net root zone expired, bogus responses 22 Aug 1996 Bind/malformed record problems ".com<tab>com" (believed to be malicious) 8 Nov 1996 Bogus address for ns.uu.net (secondary name server for many other domains) 22 Jan 1997 root only root name servers J and K added 14 Feb 1997 h.root-servers.net lost COM zone 28 Feb 1997 root only root name servers L and M added 12 Apr 1997 h.root-servers.net lost COM zone (again) 19 May 1997 k.root-servers.net moved to London LINX managed by RIPE/CC (first non-US root) 26 Jun 1997 i.root-servers.net lost COM zone 13 Jul 1997 Alternic corrupts DNS caches redirecting www.internic.net traffic 17 Jul 1997 Error during the generation of COM and NET zones at NSI truncates information 22 Aug 1997 m.root-servers.net moved to Japan managed by WIDE Project 11 Nov 1998 [fjk].gtld-servers.net giving NXDOMAIN response to queries for COM zone f.root-servers.net lame due to ISP problems at NSI 2 Jul 1999 NSI web site redirected to CORE with glue record 23 Aug 2000 Timing bug causes missing NS records for COM zone on a.root-servers.net

1 0

Re: Here's internet stability...
by Marshall Eubanks 18 Nov '01

18 Nov '01

> > >Anyone reach ICANN? It's as dead as a doornail here (even Los Nettos can't >find it): > They are gone from here from BGP show ip bgp 192.0.34.65 % Network not in table The 192.0.34.0 block disappeared from our monitoring logs between Nov_18_14:07:00_EST_2001 and Nov_18_18:07:00_EST_2001. There are still prefixes from 20144 available : *> 192.0.36.0 *> 198.32.64.0 Regards Marshall Eubanks >[simon@fred simon]$ traceroute www.icann.org > 4 isi-mdrey-retA-p05.metawire.com (204.80.114.65) 12.700 ms * 8.051 ms > 5 lngw2-c5.ln.net (206.117.24.1) 223.206 ms 203.364 ms 180.878 ms > 6 * * * > 7 * * * > ># IP address Host name Round trip time >5 24.165.128.69 SRP4-0.LSANCA1-GSR2.we.mediaone.net 35 ms >6 24.130.0.125 POS10-0-0.LSANCA1-RTR1.we.mediaone.net34 ms >7 No response >8 No response > > > >Best Regards, > >Simon > >-- >### > > Marshall Eubanks tme(a)21rst-century.com

1 0

OT: totalnic.net?
by Mike Lewinski 18 Nov '01

18 Nov '01

Anyone know what's up with Registrar services from totalnic.net (AU)? We had a client register a domain with them a couple days ago. That new domain was working yesterday, but has since disappeared from the gtld root servers. The domain totalnic.net is itself missing from gtld roots (whois shows their own domain is paid through 2010). So, if a given Registrar were suffering a complete loss of connectivity, would that affect their entries at the gtld roots? Or is this more likely a result of some type of dispute/unpaid bills with ICANN? TIA, Mike

3 2

Here's internet stability...
by Simon Higgs 18 Nov '01

18 Nov '01

Anyone reach ICANN? It's as dead as a doornail here (even Los Nettos can't find it): [simon@fred simon]$ traceroute www.icann.org 4 isi-mdrey-retA-p05.metawire.com (204.80.114.65) 12.700 ms * 8.051 ms 5 lngw2-c5.ln.net (206.117.24.1) 223.206 ms 203.364 ms 180.878 ms 6 * * * 7 * * * # IP address Host name Round trip time 5 24.165.128.69 SRP4-0.LSANCA1-GSR2.we.mediaone.net 35 ms 6 24.130.0.125 POS10-0-0.LSANCA1-RTR1.we.mediaone.net34 ms 7 No response 8 No response Best Regards, Simon -- ###

1 0