Check Point NG problems with EDNS
We recently ran into problems with Check Point NG FP3 and extremely
slow DNS resolution. Recursive DNS queries that normally took less than
a second to resolve took over 20 seconds. Our name server is running
9.2.3, although this problem may affect other name servers using EDNS.
The problem was that Check Point NG was configured with "SmartDefense"
for DNS UDP packets, effectively blocking any DNS UDP request with a
UDP payload greater than 512 bytes. With BIND 9.2.3, DNS queries are
larger than 512 bytes, as they contain an "EDNS0 option."
Here is a packet capture for a DNS A record query for www.chadangerer.com:
192.168.1.100.54859 > 18.104.22.168.53: 60974 [1au] A? www.chadangerer.com. (48) (DF)
Note the "[1au]". From the tcpdump
A few anomalies are checked and
may result in extra fields
enclosed in square brackets:
If a query contains an answer, authority records or additional records section, ancount, nscount, or arcount are printed as `[na]', `[nn]' or `[nau]' where n is the appropriate count.
In this case, the DNS query contained one additional record. Capturing
the packets in raw format (tcpdump -w)
and loading the data into Wireshark, we see that the additional record
is an "EDNS0 option" with a UDP payload size of 2048:
<Root>: type OPT, class unknown
Type: EDNS0 option
UDP payload size: 2048
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Data length: 0
BIND attempts to resolve the DNS A two more times with the EDNS0 option:
192.168.1.100.54859 > 22.214.171.124.53: 8978 [1au] A? www.chadangerer.com. (48) (DF)
192.168.1.100.54859 > 126.96.36.199.53: 20148 [1au] A? www.chadangerer.com. (48) (DF)
Finally, BIND sends the DNS A record request without the EDNS0 option.
The DNS reply is immediately returned.
192.168.1.100.54859 > 188.8.131.52.53: 21909 A?
www.chadangerer.com. (37) (DF)
184.108.40.206.53 > 192.168.1.100.54859: 21909* 1/0/0 A
The solution to the problem was to disable "SmartDefense" for DNS
Back to brandonhutchinson.com.
Last modified: 02/17/2004