November 2001 - Test - lists.nanog.org

REQ: Dark Fiber/MAN Providers @ Arlington, VA
by Gordon Ewasiuk 19 Nov '01

19 Nov '01

Hi All: I'm looking for dark fiber or MAN providers servicing the Arlington, VA area. Specifically, a provider that can connect two sites on North Glebe Road. Please reply off-list. Will post results if there is interest. -Gordon -------------------------------------------------- Gordon Ewasiuk, Certifed Sun Fanatic, Winstar VHC The REAL office number is here-----> 703.893.4901 Read the story about the #1 Unix Platform http://www.sun.com/software/cover/2001-1106 -------------------------------------------------

1 0

ICANN off the map
by Patrick Greenwell 19 Nov '01

19 Nov '01

Far be it from me to introduce operational content into the mix of the usual suspects referring to anyone that doesn't adhere to their worldview as ranting or being sociopaths, however there doesn't seem to be any announcements for ICANNs address space at the moment as near as I can tell from polling the various route servers, rendering them unreachable.

9 15

RE: generosity
by Jonathan Disher 19 Nov '01

19 Nov '01

Well, even though Exodus saw fit to pump us 22,000 additional prefixes (starting three or four weeks ago, and still ongoing), they -have- filtered out this one. But then, when I've got 124,753 prefixes, what's one or two more amongst friends.... *shrug* RAM's cheap, I 'spose. -j -- --Jonathan Disher --Sr. Systems and Network Engineer --Internet Pictures Corporation, San Ramon, CA --[v] (925) 242-4088 | [p] (877) 446-9311 | [e] jonathan.disher(a)ipix.com > -----Original Message----- > From: Matt Levine [mailto:matt@deliver3.com] > Sent: Monday, November 19, 2001 4:17 PM > To: Randy Bush; nanog(a)nanog.org > Subject: RE: generosity > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm seeing a 0.0.0.0/0 announcement coming from abovenet > (6461 17025), but only 1 of our upstreams is un-clever enough > not to be filtering it. > > > > - -- > Matt Levine > @Home: matt(a)deliver3.com > @Work: matt(a)eldosales.com > ICQ : 17080004 > PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF > "The Trouble with doing anything right the first time is that > nobody appreciates how difficult it was." > > - -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On > Behalf Of Randy Bush > Sent: Monday, November 19, 2001 7:04 PM > To: nanog(a)nanog.org > Subject: generosity > > > > they have no noc listed in jared's page, at least not that i can find > > route-views.oregon-ix.net>sh ip bg 0.0.0.0 > BGP routing table entry for 0.0.0.0/0, version 11124471 > Paths: (1 available, best #1) > Advertised to non peer-group peers: > 64.166.72.140 > 13 > 192.12.65.1 from 192.12.65.1 (192.12.65.1) > Origin IGP, localpref 100, valid, external, best > > and it's been there for some days > > randy > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> > > iQA/AwUBO/mg4sp0j1NsDQTPEQL0fQCbB1FDDVOATVlpnipDyekC5iYJqUAAn1Tz > +IRRnvy+L5/6qVFGRT6hTMon > =zgLV > -----END PGP SIGNATURE----- >

1 0

generosity
by Randy Bush 19 Nov '01

19 Nov '01

they have no noc listed in jared's page, at least not that i can find route-views.oregon-ix.net>sh ip bg 0.0.0.0 BGP routing table entry for 0.0.0.0/0, version 11124471 Paths: (1 available, best #1) Advertised to non peer-group peers: 64.166.72.140 13 192.12.65.1 from 192.12.65.1 (192.12.65.1) Origin IGP, localpref 100, valid, external, best and it's been there for some days randy

2 1

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