[bind10-dev] should b10-auth return CNAME chain?
JINMEI Tatuya / 神明達哉
jinmei at isc.org
Mon Jan 24 23:16:37 UTC 2011
At Mon, 24 Jan 2011 10:47:44 +0100,
Peter Koch <pk at DENIC.DE> 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
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?)
CNAME RRs cause special action in DNS software. When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class. If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.
> However, without DNSSEC it isn't clear that both originate from within
> the same zone (bar.example.com could be a delegation point) but then why
> would that matter? Credibility rules are usually based on the domain
> hierarchy, not zone boundaries.
Right, I shouldn't have used the term "same (or different) zone".
More accurately, it's about whether the target (canonical) name is a
subdomain of CNAME's zone origin (aka "in bailiwick" case).
> > 2. Same question as 1, but the target is in a different zone and the
> > server has authority for both zones. Example: The server has
> > authority for example.com and example.org, and has
> > foo.example.com. CNAME bar.example.org. (in example.com)
> > bar.example.org. A 192.0.2.1 (in example.org)
> 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.
> > 3. If the zone of the target RR is signed, should it affect the serve
> > behavior?
> At least in case (2) it makes a difference since the resolver can validate
> the response instead of applying credibility heuristics. However, assuming
> an empty cache, it would have to collect (and validate) the DNSKEY for the
> target zone anyway, but then this information (infrastructure RRs) can be made
> cachable more efficiently than CNAME/A RRs with potentially low TTLs.
> Another consideration could be response size, especially when there's a
> longer CNAME chain with multiple signatures. It is truncation vs. simple
> continuing queries.
These are excellent observations. I've not considered the implication
of the additional step to collect the DNSKEY of the target zone. 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.
Internet Systems Consortium, Inc.
More information about the bind10-dev