I’m looking to maybe migrate my website to a CDN like Netlify or Cloudfront, and since I’m using the bare 2nd level domain (zone apex), I can’t just use CNAME.
Looking at the documentation, the ALIAS record seems both restricted and recommended:
Restricted Types ALIAS , DNAME
These record types are used very rarely in the wild. Due to conflicts with the security guarantees we would like to give, these record types are disabled in our API. If you attempt to create such RRsets, you will receive a 400 Bad Request response. In case you have a good reason for using these record types, shoot us an email and we can discuss your case.
Caveats CNAME record
… If you are interested in aliasing the zone apex, consider using an ALIAS RRset.
What kind of “conflicts with the security guarantees” are there with ALIAS? Is it really still not available for everyone without special requests?
The problem with ALIAS is that it’s not actually a record type. Configuring an ALIAS record instructs the authoritative server to do a lookup of the ALIAS target whenever the name is queried, and return an A/AAAA record synthesized ad-hoc. This way, when the IP of the target changes, it is transparently taken into account.
The problem comes in when combining this with DNSSEC. In this case, the synthesized records need to be signed ad-hoc. That causes the following issues:
Our globally distributed secondary nameservers don’t have any private key material, so they can’t sign the response ad-hoc. (They only have pre-signed records with fixed contents that were signed by our main server. This is by intention so that we don’t need to trust foreign jurisdictions.)
One could direct all such queries to our main server for ad-hoc signing, but that would a) be very complicated, b) create a single point of failure at query time, c) significantly increase latency.
We could modify our software so that our main server configures and signs A/AAAA records statically whenever an ALIAS record is configured, distributes them to the secondaries, and updates them periodically. However, this is a non-trivial development effort. Furthermore, it is not immediately clear what DNSSEC requirements should be imposed for the lookup on the main server side. If the target is not secured with DNSSEC, then we wouldn’t know if the IPs we’re looking up to configure the A/AAAA records are authentic – but we still would be signing them. That’s very misleading, as far as DNSSEC guarantees are concerned.
We have written down some of these concerns here. The feature is currently not assigned to any milestone, so it may take a while until we support it (if at all – it is unclear whether a feasible solution exists). As usual, we are short on resources; in particular we are in short supply of work force. As deSEC is a community effort, you are very welcome to take on this issue if you see a way to contribute!
This instruction is indeed not very helpful, and we should improve the wording.
Ohhh okay. Also I just remembered that many CDNs use DNS to direct clients towards the closest server, rather than BGP anycast routing.
So it’s even more work to do this without ad-hoc signing: the central location should make multiple queries, with different EDNS Client Subnets matching the various geo regions, and store the results with associated locations, then the secondary servers should serve the results that match the location.
They only have pre-signed records with fixed contents that were signed by our main server. This is by intention so that we don’t need to trust foreign jurisdictions
A “screw security, just geo-distribute the signing keys for my domain” option would be fine, haha.
But really, it seems like “use a subdomain, deal with it” is the best way to go still.
CNAME records are not permitted at the apex (“root domain”). This is not a deSEC limitation, but a DNS limitation.
However, the new HTTPS record types has recently been specified and is supported by major browser vendors. It can redirect several kinds of service configurations, including an “alias mode” which mimics CNAME-like behavior at the apex.
First of all, thanks for the awesome service you and your team is providing.
As this post is some years old and DNS flattening (ALIAS) is a feature now multiple DNS services offer and the more problematic part, other do require it for some services (e.g. scaleway), I would just ask if you could review the current state of this. I am fully aware, that this is not RFC.
The problem with the HTTPS is, that it does not work for the HTTP-01 Challange in the ACME protocol.
My current workaround is, to create a A RECORD on desec.io then having a own crown job which verifies if the target cname of the domain has changed IP, if so, update via API
Our assessment hasn’t changed. The proper solution would be to establish an ACME challenge type using the HTTPS record. There is a GitHub issue about that over at the CA/B Forum: Issue · GitHub
The outcome there was that a specification from the IETF’s ACME Working Group would first be required.
Thanks for your precious time and the fast response. I can live with that, due the fact that I can control the change via API/Scheduled job, there may be a downtime but prefer to stay with desec than moving to cloudflare.
So let’s wait until the new ACME way shows up and then the ones who require the services also add this validation method.
