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

15:26:13.989203 >  60974 [1au] A? (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

BIND attempts to resolve the DNS A two more times with the EDNS0 option:

15:26:15.990202 >  8978 [1au] A? (48) (DF)

15:26:18.000718 >  20148 [1au] A? (48) (DF)

Finally, BIND sends the DNS A record request without the EDNS0 option. The DNS reply is immediately returned.

15:26:20.010329 >  21909 A? (37) (DF)
15:26:20.179621 >  21909* 1/0/0 A (53)

The solution to the problem was to disable "SmartDefense" for DNS UDP packets.

More information:

Back to

Last modified: 02/17/2004