search

StackExchange / dnscontrol

Infrastructure as code for DNS!
https://dnscontrol.org/
MIT License
3.07k stars 389 forks source link

Better validation of CNAME record mutual exclusion #30

Closed captncraig closed 7 years ago

captncraig commented 7 years ago

Writing this down so I don't forget about it. Low priority.

Per all the rfcs, CNAME records should be the ONLY record for any given label. No other records of any type should be created with the same name as a CNAME.

We have had confusion with various providers accepting them inconsistently, or giving unhelpful errors if you try.

We may want to do a pre-pass to make sure CNAMES are the only records for their names and give a clear warning (or fail hard) if you try to.

Apex CNAMES are technically valid, but require extra care as well. Technically you should not have any other records at all if you use one. Perhaps we should not allow them at all? Or require some extra validation to make one? With Gcloud, for example, we would need to remove ALL records (including the NS records) for google to even accept an apex CNAME. This kinda requires special code just for this case. Is it one we even care to support, or should we explicitly disallow it?

tlimoncelli commented 7 years ago

Let's break this down into 2 issues:

  1. If there is a CNAME, there can not be another record for that label (even another cname). "dnscontrol preview" should validate this (and error out).

  2. Apex CNAMEs are technically permitted but we should not permit them. (cloudflare has a special trick to simulate CNAMEs at the apex... they send an "A" record with the right IP address. We don't support that because it would prevent us from switching DNS providers. If someone wants to add it to the open source version, we'll consider it when/if that happens .)

aeden commented 7 years ago

Apex CNAMEs are technically permitted but we should not permit them

Apex CNAMEs are not actually permitted. On the other hand, ALIAS record as we and AWS call it, or ANAME as DME calls it, or CNAME flattening as Cloudflare calls it, is permissible since it is a virtual record that is converted to A and AAAA records at request time (or at regular intervals).

tlimoncelli commented 7 years ago

I was unclear. I meant Apex CNAMEs should be permitted in the DNSControl language, but the providers should turn them into ALIAS/ANAME/CNAME (with flattening), as appropriate.

A problem arises that if you have a provider that doesn't have some kind of Apex CNAME kluge then you've painted yourself into a corner. (i.e. you've prevented yourself from converting to a provider). That's ok as long as users are aware of the risk. We could make them aware by logging a warning any time an Apex CNAME is used (but warning are ignored, etc.) or require a different function (instead of CNAME(), maybe ApexCNAME()).

I favor it being a special function name because it requires conscious effort and can be detected by reading the file. Having CNAME() detect the situation and automatically do the right thing is more fancy but leads to surprises. One of the design principles of the DSL is that the audience is novices who should not be surprised by odd edge-cases of DNS (of which there are many).

captncraig commented 7 years ago

Yes, ALIAS support would be nice, but out of scope for this issue. Apex cnames should be dissallowed in our DSL I still believe. Will open a new issue to discuss the possibility of adding ALIAS record type.

captncraig commented 7 years ago

We can move further discussion an ALIAS/aNAME type to #50.