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

[JINMEI Tatuya / 神明達哉]

At Sat, 22 Jan 2011 07:22:56 -0800,
Jerry Scharf <scharf at isc.org> wrote:

> What is the reason for wanting to do this? Is it something about the 
> code or something about an interpretation of the protocol?

There are several reasons (which may defer among different people who
tend to consider it)

My primary reason is that it will make the code much simpler and more
understandable as a result (of course, unless it breaks a mandatory
requirement of the protocol or causes other bad things).

A related reason is it may make the server faster, although it should
be a quite weak reason per se.

Other reason Evan mainly seemed to raise is that returning a chain may
confuse a careless resolver implementation, especially when the
authoritative server is misconfigured.  This reason isn't really
convincing for me (yet) because such a careless resolver would have a
much more serious problem and must be fixed anyway.  But according to
Evan there seems to be a real world example trouble due to returning a
chain that warrants reconsidering the authoritative server behavior.

> Why it is there is all about performance and latency for the user. If 
> both the recursive server and the auth server have to process 2 queries 
> to get the answer, it slows down both. It will also have a major impact 
> on the time it takes to satisfy the client query.
> 
> I know of at least one content providers who use short TTLs and CNAMEs 
> and would not be happy with their customers being delayed because of a 
> DNS server change.

I understand this implication, and I understand we should be careful
not to break existing practices (at least not noticeably).  That's why
I asked my questions publicly.

Regarding this point, I'd first like to note a few facts (based on the
observable behavior from my quick experiments): many deployed
resolvers of today don't accept a chain after CNAME at all, whether or
not the CNAME target is "in bailiwick" (my example case #1) or the
target is an out-of-bailiwick name (#2).  But many others accept "in
bailiwick" chains, too.  More specifically,

- BIND 9 and unbound never accept a chain after CNAME whether or not
  the target is in bailiwick.
- powerdns recursor, google public DNS and OpenDNS accept the chain
  if the target is in bailiwick; they don't accept the chain if it's
  out-of-bailiwick.

If, as often reported, BIND 9 is the vast majority in the DNS server
market, returning a chain after CNAME would be a marginal optimization
because it would be ignored by the vast majority of the deployed
servers.  But, to be fair, google public DNS and OpenDNS should have a
non negligible number of end clients, so affecting the experience of
such users may be substantial.

Another point to consider is how effective it is for such recursive
servers if the authoritative server returns a chain.  In my
understanding, a common practice of "CNAME + lower TTL" is to use a
relatively large TTL for the CNAME RR, and use lower TTL for the
target RRs.  Some real examples of big names indicate this is the case:

Google:
www.google.com.		604800	IN	CNAME	www.l.google.com.
www.l.google.com.	300	IN	A	74.125.224.49

Twitter:
www.twitter.com.	600	IN	CNAME	twitter.com.
twitter.com.		30	IN	A	128.242.240.116

Yahoo:
www.yahoo.com.		300	IN	CNAME	fp.wg1.b.yahoo.com.
(The yahoo.com zone's server doesn't return a chain, so the first
CNAME is irrelevant in the context of this discussion)
fp.wg1.b.yahoo.com.	3600	IN	CNAME	any-fp.wa1.b.yahoo.com.
any-fp.wa1.b.yahoo.com.	60	IN	A	72.30.2.43

So, even if the authoritative server returns a chain of CNAME + A and
the recursive server uses and caches the entire chain, the target
record will expire sooner and (for popular names) are fetched much
more frequently.  The optimization of returning the chain is only
meaningful only when the target happens to have expired at the time
CNAME has to be (re)fetched, which could be marginal.

Yet another point is effect of caching, especially with prefetching.
If prefetching at recursive server implementations becomes more
common, the optimization effect of returning a CNAME chain from
client's point of view will be even more marginal.

I suspect different people have different conclusions based on these
points, but, to me, they suggest that the "performance and latency"
argument is not so convincing.

---
JINMEI, Tatuya