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

[Matthew Pounsett]

Moving this from bind-users to dns-operations.


On 27 April 2016 at 09:00, Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:

> In article <mailman.633.1461768150.73610.bind-users at lists.isc.org>,
>  "Baird, Josh" <jbaird at follett.com> wrote:
>
> > Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?
> >
> > [1]
> >
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/
>
> <delurk>
> Does anyone else find themselves mentally yelling "apex!" whenever they
> read the word "root" in that document?
> </delurk>
>
> 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".

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.

"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 example.com 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."


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.

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.

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.

(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.)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160427/13cb4607/attachment.html>