Skip to content

Instantly share code, notes, and snippets.

@aeden
Created January 8, 2014 23:41
Show Gist options
  • Save aeden/9634e40f349bb4937374 to your computer and use it in GitHub Desktop.
Save aeden/9634e40f349bb4937374 to your computer and use it in GitHub Desktop.

DNS records get cached, as we have seen above. So if your DNS record is cached for IP address 1.2.3.4 and the service provider changes the record to 5.6.7.8, you will send traffic for your mapped apex domain to the wrong address until the record expires in all caching resolvers.

This is true for any cached request, not just an ALIAS. As a matter of fact, the way we implement the ALIAS record is to always attempt the lookup through an upstream caching resolver, so we are effectively behaving the same way a client sending the request directly to the caching resolver would.

You also potentially break geoIP optimisations because suddenly you request the IP address from the nameserver of your DNS provider, not from your actual location. This may even get you in trouble with location restricted services (think Unblock-Us, just not in an intended way).

With Anycast the results of geocaching can potentially be mitigated because the request will be resolved at an Anycast server near the client. As you add more PoPs and improve the advertised routes, the likelihood of problems occurring are even lower.

CNAME-like functionality on the zone apex has no formal specification and a very small backing in the industry that can only be called experimental at this stage. While we fully support experimental new approaches for many things, DNS and our customers connectivity for their domains is not one of them. We believe that DNS needs to be rock solid and reliable no matter what.

Yes, there is no formal specification. We have been operating ALIAS records for the last 2 years and it has been effective at solving our customers problems. In fact, stability of DNS is affected much more significantly through elements that are standardized, like ANY requests, EDNS0 and DNSSEC.

The right way of doing it is to accept that a root domain mapped onto another service either needs an IP address to point to or an HTTP redirect to a 'www' subdomain that can be pointed to your destination via CNAME. As long as there is no official DNS industry standard, embrace your 'www' subdomain and do not use aforementioned ALIAS-type records.

URL forwarding is not a standardized type of record either, and must synthesize the IP address of one or more forwarders (although it can do so without any sort of DNS lookup).

There are other things to consider as well. When you set up a CNAME you cannot use any other records on that name. For example, you run into the same problem if you have a subdomain that requires both resolution to an external hostname as well as records for mail delivery.

It breaks the internet!

We've been breaking the Internet for 2 years then, and we'll continue breaking it as long as our customers need a solution to their problems. Eventually we would love for an RFC to be published that solves this problem. The standardized solution doesn't need to be the ALIAS record, but a solution is necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment