[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.
-DMM
> 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