cnames...

[Kevin Darcy]

Erik,
      I'm going to brutally summarize this discussion thread, since in my opinion it's off-topic to bind-users. (It belongs on namedroppers, as I have repeatedly pointed out).

Your basic proposal appears to be (correct me if I'm wrong):


     NS and SOA are "special" types because they are typically used only between nameservers, not something that a normal client would query. Given this, they should be exempted from CNAME chaining, and therefore can be exempted from the "CNAME and other data" rule as well, i.e. it should be legal for a CNAME to co-exist with SOA and/or NS records. This would put an end finally to the persistent confusion over the "CNAME and other data" rule as applied to names of registered domains.


I can foresee at least 3 general objections to this:

1) It complicates name resolution in the case where a query comes into a recursive nameserver, and all it has cached is a CNAME which matches QNAME, but nothing for the target of the alias. Currently, the decision of what to do next is simple: recurse to the authoritative nameservers for the *target*'s zone. Under your proposal, however, the nameserver needs to look at the query type first. If it's an NS or SOA query, then it should recurse to the nameservers for QNAME's zone, otherwise it recurses to the nameservers for the CNAME target's zone. Is the benefit to be gained here worth the cost of adding *yet*another*conditional* to the critical path of the DNS resolution algorithm?

2) It violates "the principle of least surprise". Take the following example: foo.com, a name which owns NS records, is an alias for bar.com, where bar.com owns *different* NS records and an A record. Doing a "dig foo.com a" yields the A record which is ultimately contained in the bar.com zone. Doing a "dig foo.com ns", however, yields the foo.com zone's NS records, since, under your proposal, the CNAME isn't chained for an NS query. An application or human which/who doesn't notice the indirection in the first query might be incorrectly led to believe that the A RRset and the NS RRset originated from the same zone -- a reasonable conclusion, since the QNAME was the same for both queries. Yet they are
from *different* zones, and thus the human or application could be easily led astray, possibly with disastrous results.

3) It arbitrarily reduces the overall usefulness of the aliasing mechanism. Why *shouldn't* I be able to point aliases at names which own SOA and/or NS records and have them chain properly when I do SOA and/or NS queries? Maybe I have domains many levels deep and I want "friendly" aliases to those domains at some higher level (which are more likely to be in my search path), so that I can say just "dig foo ns" instead of "dig foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns". CNAMEs are supposed to provide a *general* aliasing mechanism, but here you are carving out exceptions for record types you consider "special". Where does that line get drawn? Every record type is "special" in its own
way. Do we head down that slippery slope and eventually get rid of CNAMEs altogether (as DJB proposes)? I think that would be a great loss.

                                                                 - Kevin