rfc1034 & bind 8.3.4 providing referrals as final answer to recursive clients

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Mon Sep 6 03:42:25 UTC 2004


LV> Can you see the conflict?

There is no conflict.  But I do see the well-known BIND 8 
duplicate-resource-record-generation bug:

	LV> ;; ANSWER SECTION:
	LV> fake3.ladislav.name.ae.  3H IN A  10.3.3.3
	LV> ;; ADDITIONAL SECTION:
	LV> fake3.ladislav.name.ae.  3H IN A  10.3.3.3

I also see your misunderstanding of the fact that delegation is not 
exclusive in the DNS.  Answers about "fake3.ladislav.name.ae." can be 
legitimately supplied by any one of no less than five sets of content 
DNS servers:

	1. the "." content DNS servers
	2. the "ae." content DNS servers
	3. the "name.ae." content DNS servers
	4. the "ladislav.name.ae." content DNS servers
	5. the "fake3.ladislav.name.ae." content DNS servers

You asked a "name.ae." content DNS server about 
"fake3.ladislav.name.ae.".  Since it knew the answer, because it has 
data for that name in its database, it told that answer to you.  It 
also, helpfully, even though it was not actually required to, supplied 
you with the delegation information for "ladislav.name.ae.", so that you 
would know a "better" set of content DNS servers to query when it came 
to your next lookup.

LV> the final authoritative servers don't have to exist at all,
LV> since they will never be queried to verify with.

They will be queried the next time that one wants to look up another, 
different, datum for "fake3.ladislav.name.ae.".


More information about the bind-users mailing list