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