<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 29, 2016 at 1:48 PM, John R Levine <span dir="ltr"><<a href="mailto:johnl@taugh.com" target="_blank">johnl@taugh.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So in our last installment, it was seen that a CNAME for a "zone apex" looks<br>
ok (returns SOA, NS, MX, etc) but it doesn't work with subdomains (FQDNs<br>
under the apex); and DNAME works for stuff under the "apex" but doesn't look<br>
like a zone.<br>
</blockquote>
<br></span>
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.<span><br>
<br></span></blockquote><div><br></div><div>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)</div><div><br></div><div>Fred,</div><div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div></div></div></div>