-
Print
-
DarkLight
-
PDF
How to verify a clean network path for DNS resolution by recursive servers
Article Summary
Share feedback
Thanks for sharing your feedback!
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