[dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

David Miller dmiller at tiggee.com
Fri Apr 4 14:40:09 UTC 2014

On 04/04/2014 06:23 AM, Anthony Eden wrote:
> While CloudFlare did not give any credit to previous work done (which
> sort of pisses me off, but whatever), they are essentially implementing
> the same thing that Amazon did with their ALIAS implementation, the same
> thing that we did with the DNSimple ALIAS implementation, and the same
> thing that DNSMadeEasy did with ANAME records. It's simply synthesizing
> A records based on a DNS resolution of the hostname that the customer
> entered. We also synthesize AAAA records at DNSimple if the query type
> warrants it.

Everything old is new again.

I have this brand new earth shattering idea to suspend a seat on a frame
between two wheels, attach a sprocket to the rear wheel, and by means of
a chain between the rear sprocket and a rotating pedal assembly allow a
user to sit on and propel the device forwards.  I call it a
biwheelmobile. :-)

> The use case is to support multiple records on a node where you would
> have previously used a CNAME. The most obvious case is on the zone apex,
> but it's also useful on subdomains where you want to define MX or TXT
> records. In the era of platforms as a service, where they want to be
> able to provide a host name where the IP address may change on a fairly
> regular basis.

^^ This.

> Yes, this is probably not compatible with DNSSEC, I actually haven't
> tried to reason through what will happen in that case since we don't
> support DNSSEC at DNSimple.

It can be compatible with DNSSEC, depending on your implementation.

> I've been thinking about writing an RFC for this, but I've never
> actually done it, and it will take some time to do, however I think
> defining how an ALIAS record will synthesize its response is probably
> something we need at this point. It will also need to describe how TTLs
> are respected, how A vs AAAA vs CNAME questions are treated and what
> failure rules might be expected.

Let me know if decide to write this up and you want input on our (DNS
Made Easy) implementation.  I suspect that our implementation is
different from yours.


> Sincerely,
> Anthony Eden
> On Fri, Apr 4, 2014 at 11:23 AM, Marco Davids (SIDN)
> <marco.davids at sidn.nl <mailto:marco.davids at sidn.nl>> wrote:
>     On 04-04-14 11:20, Stephane Bortzmeyer wrote:
>     >
>     >
>     http://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root
>     >
>     > Funny idea
>     Indeed.
>     Until you want to use DNSSEC.
>     --
>     Marco
>     _______________________________________________
>     dns-operations mailing list
>     dns-operations at lists.dns-oarc.net
>     <mailto:dns-operations at lists.dns-oarc.net>
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>     dns-jobs <https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>     dns-jobs> mailing list
>     https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> -- 
> DNSimple.com
> http://dnsimple.com/
> Twitter: @dnsimple
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140404/d3303581/attachment.sig>

More information about the dns-operations mailing list