[bind10-dev] should b10-auth return CNAME chain?

Peter Koch pk at DENIC.DE
Sun Feb 6 12:08:30 UTC 2011


On Mon, Jan 24, 2011 at 03:16:37PM -0800, JINMEI Tatuya / ?$B?@L at C#:H wrote:

> > I think it should, because it is what the protocol spec seems to suggest
> > even if authoritative servers are authoritative only today and weren't back
> > then.
> 
> Do you mean Section 4.3.2 3-a of RFC 1034?
> 
>             If the data at the node is a CNAME, and QTYPE doesn't
>             match CNAME, copy the CNAME RR into the answer section
>             of the response, change QNAME to the canonical name in
>             the CNAME RR, and go back to step 1.
> 
> (and perhaps 3.6.2, too?)

yes, absolutely; bearing in mind that terminlogy and role separation weren't
as strict at the time.

> > How would prudent resolvers treat the A RR when the owner of the A RR is
> > _not_ below the QNAME?  I believe this would only make sense if the resolver
> > can be expected to actually use the information, which is probably not the
> > case for the example above.
> 
> Right, and according to my experiments most (if not all) deployed
> recursive servers ignore the target record in this case as I reported
> in my second message of this thread.

I have no hard evidence in either direction but i tend to think that first,
some resolvers seem to overreact and second DNSSEC will change teh scenario
slightly.  Assume that there are many more resolver instances than auth server
instances and assume that access to a target in the same zone or a descendant,
if immediately available, is cheap compared to a full response - requery
cycle, how much overall latency can be saved?  A small step or an auth server,
but...

> as you noted yourself, it may not matter much in the end; DNSKEY may
> have a much larger TTL, in which case the entire chain is more likely
> to be validated without additional fetch.

Indeed, only looking at an empty cache does not well reflect reality.

-Peter



More information about the bind10-dev mailing list