Hmmm...

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Mon Mar 22 04:49:03 UTC 2004


BM> Since the server doesn't have recursion enabled, it won't 
BM> resolve the target of the CNAME for you, you have to do it
BM> yourself.

Actually, recursion has nothing do to with it, and the target of the alias
_has_ been given in that response.  As per RFC 2308 section 2.2, that response
comprises _two_ pieces of information answering the question posed:

1. The client-side alias from "nic.uy." to "www.nic.org.uy.".
2. An empty "NS" resource record set for "www.nic.org.uy.", the target of the
alias.

It's a type 2 response with a non-empty alias chain (in the manner that RFC
2308 section 2.2 explicitly allows for and describes the semantics of).  It's
almost certainly generated entirely from local DNS database content (following
the algorithm in RFC 1034 section 4.3.2) and has no relation to recursion.

PE> Another allegedly authoritative server omits the aa bit on the
PE> response:

BM> Seems wrong to me, but I think I may know what's confusing it.

Actually, it's right too, and it isn't either confused or odd at all.  As per
RFC 2308 section 2.2, that response comprises two pieces of information
answering the question posed:

1. The client-side alias from "nic.uy." to "www.nic.org.uy.".
2. A delegation for "org.uy.", the nearest enclosing superdomain to the target
of the alias that the content DNS server knows about.

It's a "referral" response with a non-empty alias chain (again as described in
RFC 2308 section 2.2).

The difference between the two servers is that the first has complete
information about the entire alias chain and the final target domain name
("www.nic.org.uy.") in its database, and so can follow the RFC 1034 algorithm
around and come out at step 3(a) with a complete answer; whereas the second
only has in its database delegation information about "org.uy." pointing
elsewhere and so follows the RFC 1034 algorithm around coming out at step 3(b)
with a partial answer ending in a referral.

The value of the AA bit corresponds to what is at the end of the alias chain. 
In the first case, they data at the end of the alias chain are data from the
"nic.org.uy." "zone" in the local database, and the AA bit is set to 1.  In
the second case, the data at the end of the alias chain are delegation data
for "org.uy.", deemed to be "outside" of the "uy." "zone", and the AA bit is
set to 0.

BM> Perhaps this server saw that it was being asked for a delegation
BM> record, so it decided to return a non-authoritative answer before
BM> it noticed that the answer it was returning was really a CNAME
BM> record in the parent zone rather than a delegation.

No.  The server was simply following the RFC 1034 algorithm.


More information about the bind-users mailing list