News Flash: Your DNS might be broken, and you don’t even know it. But wait? How could I not know my DNS is broken? Well, the answer lies in the history of the DNS standards and what has become the cobbling together of features within authoritative and recursive DNS server software. It all started going south about 19 years ago with the introduction of Extension Mechanisms for DNS (EDNS(0)). The standards for EDNS(0) were solidified in 2013 in RFC 6891 but have been evolving ever since.
So what’s the big deal? What does EDNS(0) do for me? EDNS(0) allows DNS features like DNSSEC, Client Subnet and other “extensions” to be built into the DNS protocol. It also allows DNS to respond with records larger than 512 bytes. The problem facing the Internet has to do with the way in which some
DNS servers respond to requests when asked if they support specific EDNS(0) features. The standard calls for those servers that DO NOT support the requested feature to simply ignore the request flag and return a normal DNS response. A broken DNS server will either not respond to the request at all or in the worst cases simply crash.
The result is obviously no DNS response to any requests from recursive servers. Most recursive servers see the first failed request containing EDNS(0) data time out and retry WITHOUT including the EDNS(0) information. This is a workaround and results in terribly slow DNS resolution – responses can take upwards 5-10 seconds depending upon timeout settings on the recursive resolver. The work around is not pretty and terrible for Internet performance. Recursive resolvers that employ these workarounds are also subject to exploitation, so there's all the more incentive for recursive providers to tighten the code.
Enter the mighty power of a conglomerate of recursive DNS resolver providers – you know, the big guys like Google, Cloudflare, NLNET Labs (Unbound), ISC (BIND), Facebook, Quad9, PowerDNS, Cisco and others. These providers of the most widely used recursive DNS resolvers have announced that they will no longer be supporting these “EDNS(0) error workarounds” and will be cleaning up their code in such a way that domains using authoritative name servers that DO NOT correctly respond to DNS queries with EDNS(0) data will not be resolved. The date that has been set for this change is February 1
st, 2019.
The result of this “line in the sand” means that all domains hosted on these poorly coded DNS servers will fail to resolve correctly across all the recursive resolvers built by and run by the consortium. So your SPF, DKIM, DMARC, most TXT and PTR records will fail. This will be a very bad day for anyone who doesn’t take time to address this issue BEFORE February 1
st, 2019.
Now that I have your attention, what can you do to make sure you avoid any of this craziness? Simple! Just do the following:
- Make a list of all the domains that you own
- Go to https://dnsflagday.net
- Go to the Domain owners section and test each domain – you will see an “additional info” link under the results
- Record the results
For each domain that fails, you should examine the nameservers and see if there is a pattern across any of the failed domains. There likely will be as if one domain hosted by a given name server fails, ALL domains hosted by that name server will fail. To fix the issue, you will need to contact that provider and review your findings. It will be incumbent upon the provider to either upgrade their DNS server software to a version that responds correctly or contact the developer of that software and request a fix. The software does not need to support EDNS(0) extensions but must respond correctly when asked according to
EDNS standard section 7. If your provider cannot get their DNS server software updated to pass the tests, you should move your domains to a provider who can provide service that passes these critical tests.
You should also make sure that your provider supports DNS queries over UDP and TCP as BOTH are now required and firewalls need to be configured accordingly both by the DNS provider and by clients.
By taking a bit of time now to test and verify your domains, your DNS Flag Day will be just another routine day.
About the Author: Jim Nitterauer, CISSP is currently a Senior Security Specialist at AppRiver, LLC. His team is responsible for global network deployments and manages the SecureSurf global DNS infrastructure and SecureTide global SPAM & Virus filtering infrastructure as well as all internal applications and helps manage security operations for the entire company. He is also well-versed in ethical hacking and penetration testing techniques and has been involved in technology for more than 20 years.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
