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

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Sat Jan 22 05:50:04 UTC 2011


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
   and the question is when the server is queried for foo.example.com./A
   whether it should include bar.example.com./A in the answer section.

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)
   The question is when the server is queried for foo.example.com./A
   whether it should include bar.example.org./A in the answer section.

3. If the zone of the target RR is signed, should it affect the serve
   behavior?

BIND 9 returns the A RR in both cases 1 and 2, and returns it whether
or not the target zone is signed.  As far as I know, NSD behaves that
way, too.

We are now thinking about taking a different approach: don't return
any chain after CNAME and always have the resolver follow it
explicitly.  Do it at least the target zone isn't signed, and probably
keep the same behavior even for signed zones.

I have some more detailed points about this topic, but I'll stop here
for now so that this message won't be too long.  For now, I'd like to
know whether this generally sounds like a good or bad idea, and
especially if there's a case where this behavior breaks an existing
(recursive) resolver.  From my quick experiments, it should work with
BIND 9, unbound, pdns recursor.

---
JINMEI, Tatuya



More information about the bind10-dev mailing list