You might asking yourself, what the heck is DNS Flag Day anyways? Before you go Google it yourself, let me break it down for you. On or around February 1st, 2019 major DNS service providers are going to start enforcing EDNS. Which DNS service providers you ask?
…and what is EDNS? Extension Mechanisms for DNS (EDNS aka EDNS0) essentially allows for larger packet sizes, 512 bytes being this traditional size for DNS. By increasing it to 4096*, EDNS allows for the ability to inject client IP information which is ideal for CDNs (cough cough CloudFlare) or to support DNSSEC. DNSSEC (Domain Name System Security Extension) was designed to protect applications (and caching resolvers serving those applications) from using forged or manipulated DNS data, such as that created by DNS cache poisoning.
*Size matters in this case.
Many NGFWs may block traffic as they are expecting the packet to be 512 bytes and may drop. You may need to add an additional firewall rule to permit DNS packet that are =< 4096 bytes.
Sadly this spec has been around since 1999, so now the giants have drawn the line in the sand, support it as of 02/01/2019 or not, we don’t care. If you don’t, this is how it will look for your customer, users, and/or contractors that rely on 3rd party DNS services:
I think we can all agree that doing this on a Friday is a terrible idea. Want to piss off people who work in IT? Don’t socialize a change that could impact many people and make sure that the people who can troubleshoot it and fix it, work through the weekend. They love that kinda stuff. About as much as they like when their puppy eats a shoe lace and they have to pull it out of their butthole.
But Brian, some of the companies you listed above are not public DNS providers, why are they there? Mostly because I am lazy and didn’t want to create multi graphics 😉 The following open source DNS softwares will also enforce EDNS by default:
| ORGANZATION | VERSION | RELEASE DATE |
|---|---|---|
| ISC | Bind 9.14 | End of January 2019 |
| CZ NIC | Knot Resolver 3.3.0 | Imminent |
| NLNET Labs | 1.8.4, 1.9.0 or newer | Sometime after February 1st, 2019 |
| PowerDNS | 4.2 | Imminent |
So are you ready? If you are looking for a quick method to test your domain(s) to see if they are EDNS compliant, the main supporters have stood up website for you. Click the image below and test your domain:
Need a little more substance?
Testing is simple, just replace zone with your domain and @server with the FQDN or IP address of the authoritative DNS server for your domain.
dig +norec +noedns soa zone @server
dig +norec +edns=0 soa zone @server
dig +norec +edns=100 +noednsneg soa zone @server
dig +norec +ednsopt=100 soa zone @server
dig +norec +ednsflags=0x80 soa zone @server
dig +norec +dnssec soa zone @server
dig +norec +dnssec +bufsize=512 +ignore dnskey zone @server
dig +norec +edns=100 +noednsneg +ednsopt=100 soa zone @serverProTip 101: Finding your authoritative DNS server(s).
#replace briandeitch.com with your domain
dig -t ns briandeitch.com
Expected results (compliant)
Plain DNS
dig +norec +noedns soa zone @server
expect: SOA
expect: NOERRORPlain EDNS
Plain EDNS
dig +norec +edns=0 soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0EDNS Unknown Version
dig +norec +edns=100 +noednsneg soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
See RFC6891, 6.1.3. OPT Record TTL Field UseEDNS Unknown Option
dig +norec +ednsopt=100 soa zone @server [1]expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: that the option will not be present in response
See RFC6891, 6.1.2 Wire FormatEDNS Unknown Flag
dig +norec +ednsflags=0x80 soa zone @server [1]expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: Z bits to be clear in response
See RFC6891, 6.1.4 FlagsEDNS DO=1 (DNSSEC)
dig +norec +dnssec soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: DO flag in response if RRSIG is present in response
See RFC3225EDNS Truncated Response
dig +norec +dnssec +bufsize=512 +ignore dnskey zone @server
expect: NOERROR
expect: OPT record with version set to 0
See RFC6891, 7. Transport ConsiderationsEDNS Unknown Version with Unknown Option
dig +norec +edns=100 +noednsneg +ednsopt=100 soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
expect: that the option will not be present in response
See RFC6891Additional considerations, conditions, and/or considerations.
- Only EDNS version 0 is defined.
- EDNS option 100 is not defined.
- The only EDNS flag defined in DNSSEC OK (DO).
When EDNS version 1 is defined we expect to see: OPT record with version set to 0 or 1.
When sending an EDNS version other than zero, you expect to see BADVERS or a EDNS version greater than or equal to the version you send in the response. If the version is less than the version you send and the status is NOERROR, NXDOMAIN, or YXDOMAIN, the server is non-compliant.[1] +ednsopt and +ednsflags require BIND 9.11.0 or later. BIND 9.11.0 can be found on the ISC.ORG web site.
While I am not a huge fan of disruptive changes, it almost has to be done. The ability to geolocate is a nice feature but I am far more excited for a bigger adoption of DNSSEC. It almost always takes a few tech giants to get the ball rolling before overall adoption kicks in: TLS 1.2 (..soon to be TLS 1.3), Chip and PIN for credit cards, and HTTPS everywhere, and the Windows Phone…jk.
Regards,
BD