[dns-operations] Adding CNAME for the root domain issue

[Andrew Boling]

On Fri, Apr 29, 2016 at 1:48 PM, John R Levine <johnl at taugh.com> wrote:

> So in our last installment, it was seen that a CNAME for a "zone apex"
>> looks
>> ok (returns SOA, NS, MX, etc) but it doesn't work with subdomains (FQDNs
>> under the apex); and DNAME works for stuff under the "apex" but doesn't
>> look
>> like a zone.
>>
>
> No, that's backwards.  CNAME at the apex doesn't work because the apex has
> to have NS and SOA records, and getting them indirectly via CNAME doesn't
> count.  CNAME anywhere else works fine so long as you don't try to put
> other records at the same name, and don't expect it to redirect any name
> other than the exact one that has the CNAME.
>
>
Agreed. I also beg to differ on the response looking "okay" for an implied
zone cut; the presence of the AA flag in the header shoots that down
immediately. (not in Fred's paste, but it's a given)

Fred,

The scope of the CNAME record has always been limited to a single label, as
it was designed to alias host resources (not define equivalence in the DNS
hierarchy). An implied cut on the CNAME would not be explicit (unlike the
NS case), and it is not possible for the server defining the CNAME to know
whether it is relinquishing authority without having to reach out to
another authoritative nameserver. Nor should it be possible for the
recipient of an alias target to "appropriate" a namespace by defining NS
records at a later date. The combined implications of following this rabbit
hole range from "very bad" to "this would fail every conceivable security
review".

In short, CNAME does not provide this function, and without some EDNS
hacking the rrtype cannot be updated to provide this function in a way that
is backwards compatible. All of this is fairly evident when the behaviors
of the authoritative server are taken into consideration. It's an
unfortunate reality that most people want to look at this problem from the
recursor downward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160429/49ef352d/attachment.html>