Iptables

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
: type OPT, class unknown
Name:
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