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