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 wtit.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.
[tagline_box backgroundcolor=”#e8e8e8″ shadow=”no” shadowopacity=”0.1″ border=”1px” bordercolor=”” highlightposition=”top” content_alignment=”left” link=”” linktarget=”_self” modal=”” button_size=”” button_shape=”” button_type=”” buttoncolor=”” button=”” title=”” description=”” margin_top=”15″ margin_bottom=”” animation_type=”0″ animation_direction=”down” animation_speed=”0.1″ class=”” id=””]
- Use the table below to verify the F5 BIG-IP TMOS® version you’re using and confirm whether it’s EDNS RFC compliant or non-compliant.
- Use the EDNS compliance tester and verify if you pass or fail, you should get a green “All Ok” if you pass. If you pass you’re all good for now, just be careful when moving to different versions of code, making firewall changes, and how you implement caching features called out in the table – you may become non compliant or create false positive that you will need to be able to explain.
- If you are on a compliant version but getting some non-compliant results it may be because you’re using caching and hitting some false positive caused by the testing tool limitations. See the false positive section below.
- If you don’t get a green “All Ok” make sure you have a TCP listener configured in addition to your existing UDP listener and test again.
- If you fail again, contact your firewall administrator and ensure they are:
- Allowing TCP 53 to your listeners
- Not limiting the DNS packet sizes
- Not dropping EDNS requests
- Use the EDNS compliance tester and verify if you pass or trigger any non-compliance issues.
- If you are still non-compliant you have two choices:
- Upgrade to a compliant version
- Verify whether you are using DNS Express® Express, DNS Cache, or FPGA Hardware accelerated Cache and disable them – Not recommended – use WITH CAUTION.
[/tagline_box]
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) | 15.x | None | 15.0.0 | None |
14.x | 14.0.0 - 14.1.0 | 14.1.0.1 | GSLB/Local BIND* DNS Express DNS Cache FPGA Hardware accelerated Cache |
|
14.0.0.4 | ||||
13.x | 13.0.0 - 13.1.1.3 | 13.1.1.4 | ||
12.x | 12.1.0 - 12.1.3.7 | 12.1.4 | ||
11.x | 11.5.1 - 11.6.3.3 | 11.6.3.4 | ||
11.5.8 | ||||
14.x | 14.0.0 - 14.1.0.1 | None | FPGA hardware accelerated cache¹ | |
13.x | 13.0.0 - 13.1.1.4 | None | ||
12.x | 12.1.0 - 12.1.4 | None | ||
11.x | None | Not applicable | ||
BIG-IP (AAM, AFM, Analytics, APM, ASM, Edge Gateway, FPS, Link Controller, LTM, PEM, WebAccelerator) | 14.x | None | Not applicable | None |
13.x | None | Not applicable | ||
12.x | None | Not applicable | ||
11.x | None² | Not applicable | ||
Enterprise Manager | 3.x | None | Not applicable | None |
BIG-IQ Centralized Management | 6.x | None | Not applicable | None |
5.x | None | Not applicable | ||
F5 iWorkflow | 2.x | None | Not applicable | None |
Traffix SDC | 5.x | None | Not applicable | None |
4.x | None | Not applicable |
*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, 11.6.3.4, and 12.1.4. For more information, refer to K17086: The BIG-IP system drops non-zero versions of EDNS0 requests.
False Positives
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, 11.6.3.4, and 11.5.8 configured with DNS caching & FPGA Hardware accelerated cache. I’m not sure if 14.0.0.4 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 :).
Known Issues
- 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.
Leave a Reply