- NANOG - lists.nanog.org

Re: sorry to ruin several of your evenings...
by jrg＠blodwen.demon.co.uk 28 Jan '01

28 Jan '01

"Tony Rall" <trall(a)almaden.ibm.com> writes: > 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. If you look at a source diff between 8.2.2-P7 and 8.2.3, you might be scared at some of the little things that were fixed. (There's a lot of stuff added, too, as one might expect of a release and it is obviously possible that there are problems introduced within those areas too.) I can't comment about the big changes - I don't know the code well enough - but there are a number of changes like this: - if (SPRINTF((tmp, fmt, src[0], src[1], src[2], src[3])) > size) { + if (SPRINTF((tmp, fmt, src[0], src[1], src[2], src[3])) >= size) { and - if (size < sizeof "255.") + if (size <= sizeof "255.") that make me willing to upgrade (presupposing they went the right way!) My favourite inconsequential but useful change, which someone else in this thread referred to, has to be: - "No default TTL set using SOA minimum instead"); + "No default TTL ($TTL <value>) set, using SOA minimum instead"); James.

1 0

RE: sorry to ruin several of your evenings...
by Roeland Meyer 28 Jan '01

28 Jan '01

> From: Paul Vixie [mailto:vixie@mfnx.net] > Sent: Saturday, January 27, 2001 9:55 PM > asr(a)latency.net (Adam Rothschild) writes: > > > Not to disrespect Mr. Vixie, or detract from the operational content > > of the original post, but I'd like to recommend another solution to > > these recently reported security holes in BIND: install djbdns > > <http://www.djbdns.org/>. > > No disrespect taken. The README for 8.2.3 says: > > Note that BIND 8 is in "end-of-life", having been > replaced by BIND 9. > See http://www.isc.org/ for more details. > > And indeed, BIND 9 has been in preparation for several years, > has been in an > extended test release phase for the last 6 or 8 months, and > with the release > of 9.1.0 a few weeks ago, is a far better choice than BIND > 8.2.3 for most > systems. It's also compatible with BIND 8's configuration > file syntax. Thank you Paul, the web-site wasn't clear on that. Therefor, I haven't even looked at it much.

2 1

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

28 Jan '01

<Root server> ::= Any DNS server that has final authority for a <domain tier/level>; <domain tier/level> ::= root, TLD, SLD, 3LD, ... nLD (0LD, 1LD, 2LD, ... ,nLD). This is not to be confused with root level servers that have specific authority for dot, at the root level (0LD). One thing missing from the RFC specs for authoritative name servers, which Kashpureff demonstrated so nicely, cache poisoning is possible at ALL levels. Ergo, I thought that it was determined as best practice that; Name Servers that were offered up, as references, should be root for that level. That is, they should be non-recursive. This includes all NS references in all zone files. What should occur is that an org setup zone level roots and then use separate resolving servers for client access to the DNS. This is a two-tier structure with the primary tier being non-resursive. Ergo, within a <domain tier> there are operational tiers for root services and resolving services, per zone authority. RFC2870 only discusses this at the 0LD and only touches it lightly at other LDs. Another thing missing is a further definition of <authoritative>. Some of us have been working with the following; <Authoritative servers> ::= <zone authority>|<domain level authority>|<authoritative resolvers> <zone authority> ::= Final authority for a zone, non recursive. <domain level authority> ::= Final authority for a DL, non recursive (ie a.root-servers.net, gtld-servers.net, etc). <authoritative resolvers> ::= recursive servers, intended for use by clients, that claim authority for their specific zones. These include stub-resolvers. BTW, I consider RFC2870 antiquated, because it presupposes an architecture which may be outmoded or becoming outmoded rapidly. Load balancing and clustering technology makes RFC2870 an unnecessary waste of resources and can even get you into trouble. Yes, some of this is from work done on the ORSC roots. Yes, one of the largest problems we have had to overcome, at ORSC, IFWP, and ICANN/DNSO discussions, were semantic problems caused by overly simplistic and generic semantics. This in some part, explains why MSFT had to develop their own semantics, the current semantics are inadequate. As we all should know, semantics constrains design concepts. However, in such a case, designers will create their own semantics to route around the problem. This happened at MSFT, ORSC, and other places that didn't join/agree/submit to namedroppers. -- ROELAND M.J. MEYER Information Technology Architect Morgan Hill Software Company, Inc. TEL: +001 925 373 3954 FAX: +001 925 373 9781 http://www.mhsc.com mailto: rmeyer(a)mhsc.com > -----Original Message----- > From: bmanning(a)vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Saturday, January 27, 2001 12:51 PM > To: rmeyer(a)mhsc.com > Cc: joshua(a)roughtrade.net; rmeyer(a)mhsc.com; nanog(a)merit.edu > Subject: Re: How common is lack of DNS server diversity? > > > > > > > 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. > > > > Perhaps you are using the term "root servers" in a different > manner than I am used to. For me: > > "Root Server" = a DNS server for the zone "." in the Internet. > > What do you mean by "root servers at ALL levels, not > just the root." > That construction just does not parse. > > --bill >

5 6

Re: sorry to ruin several of your evenings...
by Paul Vixie 28 Jan '01

28 Jan '01

asr(a)latency.net (Adam Rothschild) writes: > Not to disrespect Mr. Vixie, or detract from the operational content > of the original post, but I'd like to recommend another solution to > these recently reported security holes in BIND: install djbdns > <http://www.djbdns.org/>. No disrespect taken. The README for 8.2.3 says: Note that BIND 8 is in "end-of-life", having been replaced by BIND 9. See http://www.isc.org/ for more details. And indeed, BIND 9 has been in preparation for several years, has been in an extended test release phase for the last 6 or 8 months, and with the release of 9.1.0 a few weeks ago, is a far better choice than BIND 8.2.3 for most systems. It's also compatible with BIND 8's configuration file syntax. BIND 9's server shares not a single line of code with BIND 8's. So if genetic diversity is what's worrying anybody, please check out BIND 9.1.0. But if you just want the BIND 8 you already have (except, without certain security flaws) then BIND 8.2.3 is just what you need.

5 5

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 28 Jan '01

28 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 28 Jan '01

28 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 28 Jan '01

28 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