DNS Flag Day happened on Feb 1st, 2019, and it’s a big deal. On this day, many DNS software and service providers including Cloudflare, Google, and Facebook have agreed to remove non-compliant DNS implementations from their software or services.
But why is this happening? Because the DNS is slow and inefficient with non-compliant DNS implementations established from a long time ago.
Setting CNAME on an APEX domain is the perfect example.
RFC (request for comments) prohibit setting CNAME on APEX domain. For instance, example.com is a DNS zone, its apex domain is example.com. Setting CNAME on example.com is non-compliant and it will cause problems on MX records, CAA and more.
However, many CDN users want to accelerate their APEX domain with CDN, thus implementing CNAME on APEX record became a thing for many DNS providers. This whole situation was caused by a mismatch between business demand versus compliance.
I’m using CDN, what this means to me?
CDN is a common performance solution for many businesses, and many have their CDN CNAME running on APEX domain. Since CNAME on APEX is now limited due to the DNS Flag Day, many businesses are affected by this. Theoretically speaking, Alias record (replacement for APEX CNAME according to the RFC) is the solution to this, but unfortunately this is not the case.
The way an Alias record works is every time a request hits the name servers to either an A or AAAA record type, the custom handler is invoked and attempts to resolve the Alias into its appropriate IPv4 or IPv6 address. It does this by asking a resolver to resolve the domain. Most of the CDN providers are running a DNS resolver locally for this purpose.
Since CDN’s GSLB is a geo-location based DNS answer, it replies to the closest CDN node based on requestor IP geolocation. But local DNS resolver is the one who actually initiates the request to GSLB, so GSLB will only reply to the local DNS resolver geolocation instead of the actual users, which may cause sub-optimal CDN performance.
Available solutions on the table
The solution is dead simple. Simply redirect the APEX domain to www, or you can continue with the non-compliant CNAME for APEX, but this can cause additional request redirection.
The real solution to this is to go back to the drawing board and rethink the whole Alias implementation method, such as taking advantage of the EDNS Client Subnet. This way, the Client Subnet’s value should be able to carry from auth DNS to local DNS resolver and eventually receive by CDN’s GSLB.
At Mlytics, we’re also planning to develop our own managed DNS service with Multi CDN provisioning via CNAME and NS to eliminate this issue. Stay tuned!
