rfc1034 & bind 8.3.4 providing referrals as final answer to recursive clients
Barry Margolin
barmar at alum.mit.edu
Sun Sep 5 04:36:46 UTC 2004
In article <che0fo$1qs2$1 at sf1.isc.org>,
Ladislav Vobr <lvobr at ies.etisalat.ae> wrote:
> 2. Why authoritative only Bind 8.3.4 provides referral in the answer
> section, and glue A records as well
In BIND 4 and BIND 8, if the server has the records that you query for,
it puts them in the Answer section; it treats delegation and glue
records like cached records. BIND 9 fixed this; delegation or glue
records are always put in the Authority or Additional sections.
> the caching server (bind, which will contact such a authoritative-only
> server containing only referrals will not follow up to the final
> authoritative servers with the zone in case of fake3.ladislav.name.ae,
> the final authoritative servers don't have to exist at all, since they
> will never be queried to verify with. And this referral records will be
> provided as a final answer by the caching servers to all recursive clients.
I believe that BIND 9 caching name servers *will* follow up to the final
authoritative servers. They recognize that this is necessary because
the response from the parent server is marked non-authoritative.
>
> As per the rfc1034
>
> --snip--
> - The simplest mode for the client is recursive, since in this
> mode the name server acts in the role of a resolver and
> returns either an error or the answer, but never referrals.
> This service is optional in a name server, and the name server
> may also choose to restrict the clients which can use
> recursive mode.
> --snip--
>
> Can you see the conflict?
That's why it was changed in BIND 9. What's your point?
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
More information about the bind-users
mailing list