DNS Flag Day is February 1st, 2019! It’s approaching fast and folks are finally starting to take it seriously. So what is DNS Flag Day, and how does DNS Flag Day affect the BIG-IP DNS (previously known as GTM or Global Traffic Manager)? Glad you asked! The goal of this post is to explain DNS Flag Day’s impact on your F5 BIG-IP DNS in a way that cuts through the noise and arms you with some concise information – so you can keep your name resolution functioning and your boss off your back. 😉
What is DNS Flag Day?
DNS Flag Day is February 1st, 2019 and it marks the day that major open source resolver vendors will release updates that implement stricter EDNS handling. The “stricter handling” means most of the software that runs DNS for the Internet will make no attempt to disable EDNS when they receive a query timeout. That means all servers that don’t respond correctly to EDNS queries will be treated as DEAD – i.e. your sites will be unavailable to a lot of users if you don’t get this fixed.
What is EDNS and why do we need it?
To understand EDNS and why we need it, we need to understand where DNS came from and its limitations. DNS is the mechanism that resolves websites to IP addresses, it was developed quite a long time ago in the early 80s. Though there have been enhancements over the years, there are some core flaws with how the flags, return codes, size of packets, and labels function – greatly restricting how we can make more intelligent name resolution decisions.
One of the biggest pushes for EDNS is the current limitation of DNS and the use of of geolocation data – EDNS solves this. Currently if you want to resolve a name to an IP based on the users location and you’re not using EDNS you’re limited to the local DNS server making the request on behalf of the user. In other words, when you type in WorldTechIT.com in your browser the DNS server you use asks the authoritative DNS servers which IP WorldTech IT.com resolves to, those authoritative DNS servers see your local DNS IP, not your machine’s IP. I’m sure you can see the limitations with this – Local DNS servers are not always “local” and can live from an IP range that’s not anywhere close to your proximity. A lot of DNS servers also load balance requests to DNS servers from different subnets – this poses persistence issues.
Preparing for DNS Flag day with the F5 BIG-IP GTM aka F5 DNS
Okay so now you get it, and you’re asking: If I have the the F5 BIG-IP DNS (a.k.a. GTM), do I have to worry about DNS Flag Day? You sure do, and here’s how to prepare for it. Disclaimer: This is general guidance, we take no responsibility for any issues you cause in your environment following this advice. Always consult with a BIG-IP expert when tackling something this important to your business.
Depending on your environment the second option can have some serious implications – be very careful if you are using these features and disable them, you may cause more issues disabling these features. Again, check if you’re hitting a false positive, you may not actually have an issue that would impact resolution.
As always WorldTech IT is available to ensure you’re prepared for DNS Flag Day and any other F5 DNS, security, authentication, and load balancing initiative you have – please feel free to contact us for F5 DNS Flag Day help (or any other F5 needs).
|Product||Branch||Versions known to be EDNS RFC non-compliant||EDNS RFC-compliant fixes introduced in||EDNS RFC non-compliant features|
|BIG-IP (DNS, GTM)||14.x||14.0.0 - 14.1.0||126.96.36.199||GSLB/Local BIND*
FPGA Hardware accelerated Cache
|13.x||13.0.0 - 188.8.131.52||None|
|12.x||12.1.0 - 184.108.40.206||12.1.4|
|11.x||11.5.1 - 220.127.116.11||18.104.22.168|
|BIG-IP (AAM, AFM, Analytics, APM, ASM, Edge Gateway, FPS, Link Controller, LTM, PEM, WebAccelerator)||14.x||None||Not applicable||None|
|Enterprise Manager||3.x||None||Not applicable||None|
|BIG-IQ Centralized Management||6.x||None||Not applicable||None|
|F5 iWorkflow||2.x||None||Not applicable||None|
|Traffix SDC||5.x||None||Not applicable||None|
*Global Server Load Balancing (GSLB) and Local BIND, along with the other listed methods of DNS response, are EDNS RFC non-compliant in versions prior to BIG-IP 11.5.4 HF2, 11.6.1 HF1, and 12.0.0. This is corrected in those specific versions in ID 463202. GSLB and Local Bind in BIG-IP 13.x – 14.x are EDNS RFC compliant. For versions that contain the fix for ID 463202 an EDNS RFC-compliant responder is needed (for example Local BIND) until the fixes introduced in BIG-IP 11.5.8, 22.214.171.124, and 12.1.4. For more information, refer to K17086: The BIG-IP system drops non-zero versions of EDNS0 requests.
There are some instances where you may receive false positives when using DNS caching or FPGA Hardware accelerated cache on a compliant version. Note – DNS Express or BIND should not generate any false positive:
- Implementations configured with a resolver cache with root hints nosoa results are expected because the genreport tool makes non-recursive queries. Additionally, since the DNS cache does not answer queries authoritatively, noaa results are also expected.
- Testing a wide IP will produce nosoa in the test results. A Start of Authority record (SOA) is not owned by the wide IP record itself, but may be owned by the second level domain on the local BIND.
- Check out F5’s DNS Flag Day article and skip to the section “Understanding test results for known EDNS RFC-compliant versions” to better understand the test results for known BIG-IP EDNS RFC compliant versions 12.1.4, 126.96.36.199, and 11.5.8 configured with DNS caching & FPGA Hardware accelerated cache. I’m not sure if 188.8.131.52 yields these false positives as F5 did not include it in their testing, I would have to test myself – feel free to get at it and let me know :).
- The RD bit set in the test results for EDNS does not impact DNS Flag Day compliance. However, this anomaly was noted during compliance testing. This issue is tracked by ID 752216-6. For more information, refer to K33587043: DNS queries without the RD bit set may receive responses with the RD bit set.
- Receiving timeout and noopt results while testing an FPGA hardware-accelerated cache are not expected. For more information, refer to K25351434: The DNS FPGA hardware-accelerated cache may drop DNS queries that contain EDNS OPT records.