Date: Mon, 4 Aug 1997 00:29:47 -0500 From: Karl Denninger <karl@Mcs.Net> To: Studded <Studded@dal.net> Cc: Karl Denninger <karl@Mcs.Net>, "freebsd-current@FreeBSD.ORG" <freebsd-current@FreeBSD.ORG>, "lists@tar.com" <lists@tar.com>, Terry Lambert <terry@lambert.org> Subject: Re: Moving to a more current BIND Message-ID: <19970804002947.58958@Jupiter.Mcs.Net> In-Reply-To: <199708040518.WAA29255@mail.san.rr.com>; from Studded on Sun, Aug 03, 1997 at 10:17:57PM -0800 References: <199708040518.WAA29255@mail.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 03, 1997 at 10:17:57PM -0800, Studded wrote: > This is exactly the kind of debate I didn't want to get into, so > I'll respond just this one time. > > On Sun, 3 Aug 1997 20:04:14 -0500, Karl Denninger wrote: > > >On Sun, Aug 03, 1997 at 04:58:42PM -0800, Studded wrote: > >> On Sun, 3 Aug 1997 15:54:54 -0700 (MST), Terry Lambert wrote: > >> > >> >On the specific issue of the most recent "bind", I have a problem. > >> > > >> >Someone has stated that their new "bind" is complaining about my > >> >use of an alias record as the name of my DNS server. > >> > >> This has always been an error, but BIND 8.1.1 is more vocal about > >> it now. TMK BIND 4.9.6 does not exhibit any differences in relation to > >> this from the BIND 4.9.4 we had in the tree. In any case, what you're > >> doing will still work, and 8.1.1 allows you to send those error messages > >> to /dev/null if you like. > >> > >> >This is a bogus thing for it to do, since it is imperitive that > >> >you be able to use a DNS rotor for DNS services, if you have > >> >equivalent servers for reasons of fault tolerance. > >> > >> Without going into too much detail that's better left for > >> bind-users@vix.com, a dns rotary is certainly not "imperative," and BIND > >> is actually pretty smart about sending its queries to the one of your name > >> servers that is in the best network position to it. > > > >A CNAME can *only* point to an "A" record. > > This is not accurate. A CNAME record can refer to another CNAME > record, although this is not related to this question. Actually, the more correct way of saying it is that a CNAME cannot be used in conjunction with other resource record types, EXCEPT to point to an "A" record. > >Using CNAMEs in NS lines is in violation of the BIND rules and will break. > > It is a violation of the spec, but it will also work. No it doesn't. We have had a number of people bitch at our tech desk about non-resolving domains over exactly this point in the last month (since we converted to BIND 8.x). Every time the target has had either a bad authority record (which will screw you just as firmly) or an NS line pointing to a CNAME. In each case where these were found to be the issue, when the authoritative nameservers fixed the misconfiguration the domain instantly became resolvable. What you describe works under very certain conditions. Expecting it to work is a really, really, really bad idea. Like don't. CNAMEs should NEVER be used for this. They are unnecessary to use for this kind of purpose anyway; there are other, perfectly legitimate ways under the RFCs to get round-robin behavior in NS lines. Among other things, you can list multiple NS lines (duh!) or multiple A records for a given hostname. In general, when we're talking about NS lines (which designate authority) the following is true: 1) The NS line must point to a resolvable name. 2) The resolvable name should be an "A" record, and *NOTHING ELSE*. 3) Multiple "A" records *ARE LEGAL*, but using CNAMEs to get the same kind of effect does NOT reliably work. 4) A name within the zone being declared is legal, but then the delegate of the zone in question must also have the glue records defined and those MUST MATCH the declarations in the zone itself. > For the details on why this is bad, see the BIND FAQ, > /usr/src/contrib/bind/doc/misc/FAQ.2of2 Question 6.6. Yep. > >Don't do it. If you do it, people using BIND 8.1.1 *CANNOT RESOLVE YOUR > >DOMAIN*. That includes, among others, us. > > You might consider double-checking your setup. It *should* work, > but that still doesn't mean it's a good idea. Nope. It doesn't. Further, if you mix delegations, and we hit the bad one, and cache the result, until that TTL is reached we won't retry (and we're not alone in this behavior). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970804002947.58958>