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

[Peter Koch]

>From the peanut gallery ...

> Evan raised an issue about how our authoritative server (b10-auth)
> should handle CNAMEs: http://bind10.isc.org/ticket/504#comment:12
> I think it's a discussion topic for wider audiences and I'd like to
> solicit opinions here.
> 
> There may be many details to be discussed, but I'd roughly form the
> discussion points three-fold as follows:
> 
> 1. Should b10-auth return the target RR(set) after a CNAME if both
>    CNAME and the target are in the same zone?  An example of this case
>    is that the server has an authority for example.com. and has
>      foo.example.com. CNAME bar.example.com.
>      bar.example.com. A 192.0.2.1

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.  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.

> 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.  Again, the DNSSEC case is different.

> 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.

-Peter