January 2001 - Test - lists.nanog.org

Re: sorry to ruin several of your evenings...
by Tony Rall 28 Jan '01

28 Jan '01

It is not clear to me what incentive there is for someone running 8.2.2P7 to upgrade to 8.3. In particular, it does not appear (from the ISC web site or from Paul's msgs) that 8.3 fixes any security flaws in 8.2.2P7. (Yes, I understand that 9 is a desirable goal. I'm just questioning whether 8.3 is a worthwhile interim step - as opposed to staying on 8.2.2P7 awhile longer.) Tony Rall

1 0

Static IP distribution
by Kris S. Amundson 28 Jan '01

28 Jan '01

The topic of static IP address allocation came up today between a coworker and I, and we had differing ideas on how it should be done. This would be static IP's for our broadband DSL users on non-portable upstream assigned IP space. One method would be to have all our customers run a DHCP client, and those who wanted a static IP would get one reserved in the DHCP server via MAC address. The other method would be to staticaly route their host IP (or a small range) down their pvc and exclude it from the DHCP server range. Some of our arguments: Managing end user MAC addresses for static IP users would be a big hassle. Every time an end user changes a NIC, swaps a server out, buys a new computer, they would need to put a call in because their MAC had changed. Having DHCP assigned statics allows us to change DNS server IP's on the fly with minimal implications. It would also allow us to reassign new IP space without breaking everything (end user mail/dns/etc. would break). Worst case senario is an IP subnet change would occur, the user would DHCP their new "static" IP breaking any server services, but would still be able to connect to the Internet. There were other arguments about possible DHCP spoofing agains't static IP and such.

4 5

Six million ways to crash
by Sean Donelan 28 Jan '01

28 Jan '01

On Sat, 27 January 2001, Simon Lyall wrote: > Considering the small number of servers and their value I'm surprised > nobody has gone for a sustained DDOS against them all at once. This could > get pretty messy if they managed it. In nearly a century of international telecommunications, the number of deliberate attacks on the infrastructure itself is amazingly small. Historically, network engineers have been more dangerous to the infrastructure than malicious actors. The telephone system, credit card system, electric grid and so forth all have significant infrastructure vulnerabilities. > Obviously it's pretty hard to add additional servers but has the option of > splitting the current group into multiple distributed machines with the > same ip (like how these other DNS organisations are doing) been looked at? I haven't physically seen all the root servers, but the volunteers operating the servers take their task seriously. There are a lot more than 13 physical machines. Of course, Murphy is always on the prowl, and there isn't a real effective way to protect against a DDOS. If there was a way to protect your server, I think the IRC people would have already implemented it.

2 1

RE: How common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

> From: Jay R. Ashworth [mailto:jra@baylink.com] > Sent: Saturday, January 27, 2001 6:44 PM > On Sat, Jan 27, 2001 at 10:35:06AM -0800, Roeland Meyer wrote: > > > > More interestingly, how many root servers allow > recursive lookup? > > > > > > a quick looping probe shows that none of them do, nor the > gTLD servers > > > (phew!) although L.ROOT-SERVERS.NET and H.GTLD-SERVERS.NET > > > are unreachable > > > from my view. Preparing an accurate list of all TLD servers > > > glued in the > > > root zone will take a little longer. > > > > I was taking about root servers at ALL levels, not just the root. > > I believe the phrasing Roeland may be looking for is "how many *zone* > servers (ie: authoritative servers, not customer resolvers) allow > recursive lookups", no, Roeland? Well, yes.

1 0

Before everyone asks me at once - Genuity site
by Elizabeth Schwartz 27 Jan '01

27 Jan '01

This page is behind a password, yep, but you just have to fill out the mailing list info. Just make something up. (I'd make up a login myself but it's too late at night to go find where Netscape is hiding the cookie, so the site isn't letting me do a new account. I don't have access to the corporate servers from the "inside") > We've got this document on the company's public-facing web site: > > http://www.genuity.com/securitymatters/rundown004.htm -- Elizabeth Schwartz 781-262-6565 Unix System Administrator eschwart(a)genuity.net Genuity, Inc

1 0

RE: How common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

Good feed-back, thanks. > From: Sean Donelan [mailto:sean@donelan.com] > Sent: Saturday, January 27, 2001 2:34 PM > On Sat, 27 January 2001, Roeland Meyer wrote: > > <Root server> ::= Any DNS server that has final authority > for a <domain > > tier/level>; > > Wouldn't a better term be "authoritative server"? It states > what it is, > and doesn't have the semantic overload of your use of "root server." I agree, but the definitions were evolved from existing, not recreated. The problem is that there are tiers of responsibility with in the LD and there are many LDs. For example; UK has both the TLD and SLD as fixed and sells registrations in the 3LD. AU also does this, but are considering opening up the SLD for new registrations. We have two different authority layers here, not just one. Also ml.org --> dhs.com, sells 3LDs in COM, how do we talk about them, operationally? Also authority, for any LD, is different than that for a zone. Yet, both name servers will answer as authoritative. Even the software doesn't make a distinction. Further, and here is where the semantics become difficult, what do you call the final non-recursive authority vs. the authoritative recursive resolving authority (and do you want to spell that definition out 10 times per paragraph)? > Unless, of course, you are in marketing in which case you > want semantic > overload such as Microsoft's use of "Digital Nervous System" (DNS) to > create confusion. <g> ref Halloween I & II <g> But, that is yet another reason to further refine the semantics... before MSFT does! IMHO, engineers who sneer at Mktg, have no idea how much of their lives are ruled by it. > Root Server == An authoritative server for the "." (root) of > the domain > name system The problem is that we have more than one set of authoritative root servers and one set includes the other. The current semantics do not allow that at all. This is fine for the unified-root school, but the reality is that it isn't the ONLY school and denial wont make the others go away. > TLD Server == An authoritative server for a Top Level Domain, such as > the generic TLDs (COM, EDU, INT) and country > code TLDs (CA, AU, ZA) The problem is (as stated above), there are many authority layers beyond that of the TLD. Yes, some of them are getting politisized (repeat what I said about Mktg and double it). The real danger is that a schism is developing in the semantics (between Eng, Mtkg, and the politicians). This may be a pre-cursor to a schism at the root-level itself. I would dearly like NOT to see that.

3 2

RE: How common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

Then, how do you intelligently talk about the other entities I bring up? BTW, I didn't invent some of this. The semantic need exists and because of resistance to further definition, folks are making their own semantics to fill the vacume. You really ought to look at what MSFT uses for DDNS semantics, it is a nightmare. The reason that they came up with their own, is because there were no pre-existing semantics that would cover the concepts. MHSC, ORSC, and I suspect uDNS, had to do the same thing. One resultant is, that we have conflicting semantics. ref: what I said about routing around the problem. Denial is not a river in Egypt and won't make the problem go away. > -----Original Message----- > From: Havard.Eidnes(a)runit.sintef.no > [mailto:Havard.Eidnes@runit.sintef.no] > Sent: Saturday, January 27, 2001 2:29 PM > To: rmeyer(a)mhsc.com > Cc: bmanning(a)vacation.karoshi.com; joshua(a)roughtrade.net; > nanog(a)merit.edu > Subject: Re: How common is lack of DNS server diversity? > > > > > <Root server> ::= Any DNS server that has final authority for a > > <domain tier/level>; > > That's what's commonly referred to as an "authoritative name > server" for the zone in question. > > I'll side with Bill M: a "root DNS name server" serves the root > zone, aka. ".". > > Regards, > > - Håvard >

3 2

RE: How common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

> > More interestingly, how many root servers allow recursive lookup? > > a quick looping probe shows that none of them do, nor the gTLD servers > (phew!) although L.ROOT-SERVERS.NET and H.GTLD-SERVERS.NET > are unreachable > from my view. Preparing an accurate list of all TLD servers > glued in the > root zone will take a little longer. I was taking about root servers at ALL levels, not just the root.

3 2

RE: How common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

> From: Adam McKenna [mailto:adam@flounder.net] > Sent: Saturday, January 27, 2001 2:35 PM > On Sat, Jan 27, 2001 at 02:34:58PM -0800, Roeland Meyer wrote: > > > > > Roeland, do you make this shit up as you go along, or what? > > > > Nope, these are agreed upon concepts, just not from the IETF. > > Agreed-upon by whom? The voices in your head? You obviously don't understand the difference between "concept" and "definition". www.open-rsc.org www.dnso.net www.icann.org www.dnso.org BTW, that makes two, personal insults are to be directed at null(a)root-service.net from now on.

5 4

RE: How (un)common is lack of DNS server diversity?
by Roeland Meyer 27 Jan '01

27 Jan '01

> From: woods(a)weird.com [mailto:woods@weird.com] > Sent: Saturday, January 27, 2001 3:38 PM > [ On Saturday, January 27, 2001 at 14:40:39 ( -0800), Roeland > Meyer wrote: ] > > Subject: RE: How common is lack of DNS server diversity? > > > > Then, how do you intelligently talk about the other > entities I bring up? > > An "authoritative nameserver" is, well, an authoritative nameserver. > Nothing more, nothing less. If it's registered (in the > parent zone, or > the root cache/hints file in the case of a top level zone) > but it's not > actually answering authoritatively (but it is answering) then it's > considered to be "lame". Actually, in /bind/contrib, there are programs to chase down and email hostmaster of lame servers. They are considered not-acceptable. BIND also err-logs these, explicitly. > Everything else describes the relationship of the zone to the root > (eg. "top level domain", "second level domain", etc.). > People who want to ascribe some meaning to who's responsible > for shared > top (or sometimes second) level zones talk about "global top level > domains" and "country code top level domains" or maybe "second level > country code domains", though none of these descriptions are > technically > meaningful in any way whatsoever -- they simply ascribe administrative > descriptions to ordinary top level (or maybe second level) > domain names. > > What more could you possibly need!?!?!?!? That's overly simplistic. Put a recursive SLD server up and see how fast the cache gets munged. > The only confusing terms that have been used repeatedly everywhere and > by most everyone at one time or another are "primary" and "secondary" > nameservers (especially when they give the impression that > there's only > one "secondary" nameserver). The new BIND documentation suggests the > much better terms "master" and "slave". There's only one > master, and it > might not even be registered or visible (though BIND's named will > complain if the master listed in the SOA isn't also listed as > one of the > NS records). There can be many slaves, and not all of them need to be > registered or visible either. Both the master and all of the slaves > will always answer authoritatively (at least to anyone who can reach > them and who they permit to query them). Either way if they're listed > in publicly visible NS records, either in their parent zone, or within > the zone, they'd damn well better answer authoritatively! Agreed. > This is not rocket science -- it's very very very simple > stuff! Anyone comfortable with keeping lists of things and understanding > hierarchical relationships between those lists can do DNS in their sleep once they > learn a half dozen very simple rules. I can almost agree. But the existance proof against this point is the ICANN. > I believe the reason that Internet DNS is in such a sorry state is > literally because it is so boringly simple yet particular > about the tiny > details that only an accountant-type personality would care about. We > need more accountants to do the DNS! :-) Interesting that you bring up accountancy, there is a fair amount of $$$ invloved here.

1 0