In article <mailman.1165.1259775639.14796.bind-us...@lists.isc.org>, Joseph S D Yao <j...@tux.org> wrote:
> On Wed, Dec 02, 2009 at 12:47:08PM +0000, Sam Wilson wrote: > > In article <mailman.1153.1259725836.14796.bind-us...@lists.isc.org>, > > Joseph S D Yao <j...@tux.org> wrote: > [incorrectly] > > > No. > ... > > Not true. CNAME chains - CNAMEs pointing to other CNAMEs - are > > inefficient and discouraged but the DNS spec is built to ensure that > > they work. Check out www.google.com sometime (or www.google.co.uk) and > > wonder at how many people would be annoyed if they didn't. > > > CNAME chains have nothing to do with this. THIS is perfectly legal: > > a CNAME b > b CNAME c > c CNAME d > d CNAME extra-ordinary > > although, as mentioned, inefficient. My bad - I read your initial statement as banning names with CNAME records from the RHS of other RRs, not from the LHS, and I was offering a counterexample. > THIS is not legal: > > a CNAME b > a CNAME c > a A 1.1.1.1 To be pedantic, the first alone is legal, but once that exists neither of the second nor third is legal. > ... > > > Why not do this? > > > > > > subdomain.b A 7.8.9.10 > > > subdomain.b NS ns1.subdomain.b > > > ns1.subdomain.b A 7.9.11.13 > > > > If b was itself delegated the CNAME would be problematical again. > ... > > > And if all the name servers crashed, then the domain would be unserved. > Why introduce unnecessary hypotheticals? ;-) Because you introduced a delegation for a and I wanted to head off the idea that you could delegate b and then point a to it as a CNAME. You'd need to use DNAME in that situation. > And, as pointed out in another post, the CNAME does not appear to be > problematic in this case, even were it to exist. Indeed. Sam _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users