How to verify a clean network path for DNS resolution by recursive servers
  • 14 Feb 2019
  • 1 Minute to read
  • Contributors
  • Dark
    Light
  • PDF

How to verify a clean network path for DNS resolution by recursive servers

  • Dark
    Light
  • PDF

Article Summary

This article only applies to BIND versions prior to 9.10
BIND 9.10 and more recent versions use a different EDNS probing algorithm that doesn't work with the current set of existing rs.dns-oarc.net records. ISC does not currently know of any similar set of records that works with the more recent EDNS probing algorithms.

Here is how you verify that you have a clean network path that will handle DNS correctly, including EDNS and DNSSEC.

Do this dig on all hosts that are running recursive resolvers:

dig +short rs.dns-oarc.net txt

The output should look something like this:

rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent EDNS buffer size 4096"
"192.168.1.1 DNS reply size limit is at least 4023 bytes"

You should ensure that your whole network infrastructure between your DNS servers and the Internet:

  • Supports IETF RFC 4035 (Protocol Modifications for the DNS Security Extensions).
  • Supports EDNS0 (IETF RFC 2671).
  • Allows IP fragments.
  • Allows UDP packets up to 4096 bytes for every hop between the DNS server and the Internet.
  • Permits port 53 traffic in both directions, both TCP & UDP.
  • Does not block ICMP to/from the DNS servers.

If you are using a DNS proxy, it must conform to IETF RFC 5625 (DNS proxy implementation guidelines):

  • Resolvers must handle resource records (RRs) of unknown type transparently.
  • All requests and responses must be proxied, regardless of the  values of the QTYPE and QCLASS fields.
  • All responses must be proxied, regardless of the TYPE and CLASS fields of any resource record therein.
References