<div dir="ltr"><div><br></div><div>Moving this from bind-users to dns-operations.</div><br><div class="gmail_extra"><br><div class="gmail_quote">On 27 April 2016 at 09:00, Sam Wilson <span dir="ltr"><<a href="mailto:Sam.Wilson@ed.ac.uk" target="_blank">Sam.Wilson@ed.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">In article <<a href="mailto:mailman.633.1461768150.73610.bind-users@lists.isc.org">mailman.633.1461768150.73610.bind-users@lists.isc.org</a>>,<br>
 "Baird, Josh" <<a href="mailto:jbaird@follett.com">jbaird@follett.com</a>> wrote:<br>
<br>
> Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?<br>
><br>
> [1]<br>
> <a href="https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/" rel="noreferrer" target="_blank">https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/</a><br>
<br>
</span><delurk><br>
Does anyone else find themselves mentally yelling "apex!" whenever they<br>
read the word "root" in that document?<br>
</delurk><br><br></blockquote><div>There are a huge number of problems with that document's use of terms, and the way it presents  its information.  Those problems only begin with using "root" in place of "apex".</div><div><br></div><div>The document also presents the whole CNAME at apex problem as if it's really fine to do, and only breaks down because a few people don't support it properly. </div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div>"Technically, the root [APEX!] could be a CNAME but the RFCs state that once a record has a CNAME it can't have any other entries associated with it: that's a problem for a root [APEX!] record like <a href="http://example.com">example.com</a> because it will often have an MX record (so email gets delivered), an NS record (to find out which nameserver handles the zone) and an SOA record."</div></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div>Actually, no.  "Technically", it cannot be a CNAME, because the technical specification says it can't.   And the reason it says it can't is because having a CNAME and any other data is ambiguous.  This paragraph presents it as if the rule is just arbitrary, and has no real justification.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It goes on to explain one of the cases where CNAME at apex breaks down (the MS Exchange issue) but frames it as if it's sortof Microsoft's fault that doesn't work, if only they hadn't been following the specification so closely.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The other "corner cases" it hand-waves around include nice things like potential DoS of entire domains with CNAMEs at their apex.  For example, three queries to Google DNS will cause Google to start returning SERVFAIL for future queries of that domain, if the auth server actually responds with a CNAME at the apex of the zone. (I will leave which queries as an exercise for the reader).  The DoS only lasts for the TTL of the CNAME, but it can be reset at will by the attacker.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(To be clear, I don't consider that to be a bug or security flaw in Google Public DNS, but simply an example of the unintended consequences of trying to use an ambiguous, illegal configuration.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">What Cloudflare is doing with their CNAME flattening service is quite good, but that document is a terrible marketing representation of what is an excellent technical implementation if a kludge we all have to live with.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>