Check Point NG problems with EDNSCheck 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 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 170.252.72.97.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 Ethereal, 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 170.252.72.97.54859 > 216.119.106.3.53:  8978 [1au] A? 
www.chadangerer.com. (48) (DF)

15:26:18.000718 170.252.72.97.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 170.252.72.97.54859 > 216.119.106.3.53:  21909 A? 
www.chadangerer.com. (37) (DF)
15:26:20.179621 216.119.106.3.53 > 170.252.72.97.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