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
BIND
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:
15:26:13.989203
192.168.1.100.54859 > 216.119.106.2.53: 60974 [1au] A? www.chadangerer.com. (48) (DF)
Note the "[1au]". From the tcpdump
man page:
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:
Additional
records
<Root>: type OPT, class unknown
Name: <Root>
Type: EDNS0 option
UDP payload size: 2048
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x0
Data length: 0
Data
BIND attempts to resolve the DNS A two more times with the EDNS0 option:
15:26:15.990202
192.168.1.100.54859 > 216.119.106.3.53: 8978 [1au] A? www.chadangerer.com. (48) (DF)
15:26:18.000718
192.168.1.100.54859 > 216.119.106.2.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.
15:26:20.010329
192.168.1.100.54859 > 216.119.106.3.53: 21909 A?
www.chadangerer.com. (37) (DF)
15:26:20.179621
216.119.106.3.53 > 192.168.1.100.54859: 21909* 1/0/0 A
65.110.86.239 (53)
The solution to the problem was to disable "SmartDefense" for DNS
UDP packets.
More information:
http://lists.virus.org/fw1-0305/msg00433.html
Back to brandonhutchinson.com.
Last modified: 02/17/2004