DNS Flag Day 2020: Improving Internet DNS Security

Although the DNS protocol is not secured by default, it is mainly used on IP networks as the key element to convert application names to technical addresses. Following the 2019 DNS Flag Day, which targeted protocol compliance on EDNS, the 2020 version will focus on operational and security problems caused by Internet Protocol packet fragmentation. Fortunately, EfficientIP customers will not suffer any issues, as our DNS servers already support the 2020 Flag Day recommendations, complying with standards and RFC.

DNS and IP fragmentation

IP fragmentation is normal. As soon as a message transported in the payload of an IP conversation is bigger than the maximum message size an IP frame can transport, the IP layer will cut the message into multiple parts and transport each in a separate IP frame. Since DNS can be transported on top of the UDP transport protocol (in IP frame) and queries or answers may be too long to fit into a single frame, some DNS information will require multiple IP fragmented frames. In TCP, there should not be fragmentation because the transport protocol negotiates maximum frame size and is designed to transport big messages. The impact of IP fragmentation on the DNS service (when transported by UDP) mainly concerns security – it has been demonstrated that DNS cache poisoning is able to be performed with UDP/IP fragmented messages.

What is the plan for 2020?

For 2020, DNS service providers are being asked to use TCP transport either all the time or whenever a UDP query or answer will be fragmented. UDP is not able to negotiate the maximum message size but DNS is able to exchange this information in an EDNS option. Two simple steps are required: 1) Set the EDNS buffer size to a value compatible with the maximum size of an IP frame on your network (e.g. 1232 bytes) 2) If the message to be transported is bigger than this limit, switch to DNS over TCP.

If you use mainly TCP for the transportation of your DNS requests/answers, you can use a much larger buffer in the EDNS option (e.g. 4096 bytes). You will then be on the right track to secure the last mile of your DNS transaction with DoT (DNS over TLS).

What to do now to prepare for Flag Day?

Firstly, it is important to note that there will be no impact of not performing any of the following actions. If you want to be fully compliant, start with the actions on your authoritative servers, especially if you are expecting large response packets (e.g. a lot of A records for the same FQDN). Performing the actions on the recursive server depends on whether you trust the internal network and clients (as enterprises generally do) or not (as is the case for ISPs). For enterprises it is not mandatory, fragmentation can happen without any issue.

If you manage an authoritative server

• Enable DNS over TCP
• Answer on port TCP 53
• Check security path (e.g. firewalling rules protecting your DNS server)
• Set EDNS buffer size to less than 1232 bytes for UDP traffic

If you manage resolver and recursive servers

• Enable DNS over TCP
• Set the EDNS buffer size at a value corresponding to your network environment (1232 bytes)
• Enable UDP fallback to TCP in the configuration

Test your configuration and environment

1. Get the name servers associated with your domain:

   $ dig efficientip.com NS
   ;; ANSWER SECTION:
   efficientip.com.        3600    IN      NS      ns-212.awsdns-26.com.
   efficientip.com.        3600    IN      NS      ns-1000.awsdns-61.net.
   efficientip.com.        3600    IN      NS      ns-1360.awsdns-42.org.
   efficientip.com.        3600    IN      NS      ns-1660.awsdns-15.co.uk.
   

2. Check TCP on authoritative servers:

   $ dig +tcp www.efficientip.com @ns-1360.awsdns-42.org.
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64544
   

3. Check TCP on recursive server:

   $ dig +tcp www.efficientip.com
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31930
   

4. Check you can get large record with your recursive server:

   $ dig +bufsize=512 test.knot-resolver.cz. TXT
   ;; Truncated, retrying in TCP mode.
   

5. Check DNS reply size:

   $ dig +short rs.dns-oarc.net TXT
   rst.x4090.rs.dns-oarc.net.
   rst.x4058.x4090.rs.dns-oarc.net.
   rst.x1212.x4058.x4090.rs.dns-oarc.net.
   "2001:19f0:6800:10a7:5400:ff:fe1b:34dd DNS reply size limit is at least 4090"
   "2001:19f0:6800:10a7:5400:ff:fe1b:34dd sent EDNS buffer size 4096"
   

in the answer message:

• DNS reply size limit is at least 4090 => if size is around 4000, everything is OK
• DNS reply with size around 1400 (“2a04:e4c0:10::75 DNS reply size limit is at least 1394”), something dropping fragment (e.g. firewall)
• Lacks EDNS, defaults to 512, guess what?

Further Reading

• DNS-OARC reply size test
• ISC DNS flag day 2020
• DNS flag day 2020