How to verify a clean network path for DNS resolution by recursive servers
- 14 Feb 2019
- 1 Minute to read
-
Contributors
-
Print
-
DarkLight
-
PDF
How to verify a clean network path for DNS resolution by recursive servers
- Updated on 14 Feb 2019
- 1 Minute to read
-
Contributors
-
Print
-
DarkLight
-
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