First packet delays for around 10 seconds due to pending WSDNSD DNS lookup over TCP

Product

Security Gateways

Version

R81.10 (EOS), R81.20, R82, R82.10

Last Modified

2026-07-23

Symptoms

• Traffic captures on the Security Gateway or mirror port on the switch show an approximate 10-second delay of the syn packet.

• The $FWDIR/log/wsdnsd.elg file contains these entries, indicating that the WSDNSD process is stuck at TCP connection to the DNS server:

[wsdnsd 13921]@HOSTNAME[DATETIME] Warning:cp_timed_blocker_handler: Handler info: Library [/opt/CPshrd-R8x.xx/lib/libResolver.so], Function offset [0x2ccb0].

[wsdnsd 13921]@HOSTNAME[DATETIME] Warning:cp_timed_blocker_handler: Handler info: Nearest symbol name _Z10Sock_InputiPv, offset [0x2ccb0].

[wsdnsd 13921]@HOSTNAME[DATETIME] Warning:cp_timed_blocker_handler: A handler [0xf6569cb0] blocked for 9 seconds.

• The traffic capture through the fw monitor command when filtering the TCP port 53, shows that the syn packet of the DNS TCP query from the Security Gateway shows a 10 second delay before sending out:

Example:

[vs_0][fw_5]  [Date, Time].743300 Mgmt:o[44]: 192.x.x.x -> 10.x.x.x (TCP) len=60 id=53464
TCP: 63382 -> 53 .S.... seq=7561cecb ack=00000000
[vs_0][fw_5]  [Date, Time].222801 Mgmt:o[44]: 192.x.x.x -> 10.x.x.x (TCP) len=60 id=53464
TCP: 63382 -> 53 .S.... seq=7561cecb ack=00000000
[vs_0][fw_5]  [Date, Time].226824 Mgmt:O[44]: 192.x.x.x -> 10.x.x.x (TCP) len=60 id=53464
TCP: 10000 -> 53 .S.... seq=7561cecb ack=00000000

• Manual connectivity test # telnet dns_server_ip 53, confirms that the DNS server is reachable over TCP port 53.

Forcing DNS queries to use TCP instead of the default UDP:

# time dig -x 192.x.x.x.in-addr.arpa @dns_server_ip +tcp

• Kernel debug shows that the Security Gateway holds the first DNS TCP query packet, as well as similar delays in subsequent traffic:

fw_handle_first_packet: Unified Rulebase returned HOLD;
fw_xlate_match: Returning hold;
FW-1: fw_first_packet_xlation: NAT rulematch required HOLD - vanishing  packet;
fwxlate_nat_rulematch: nrb_rulebase_nat_get_matched_rules returned HOLD;

Cause

The WSDNSD daemon is a DNS Resolver, responsible for resolving domain objects against the DNS server configured on the system. When the DNS response for a specific host (Non-FQDN) or domain (FQDN) is too large to fit into a single UDP packet, the DNS server sets the truncated (TC) bit in the response header. When this happens, the DNS query automatically switches from UDP to TCP to retrieve the whole response.

When the WSDNSD daemon initiates a local DNS TCP query, and domain objects in the rule base include non-FQDN values, rule base lookups may delay the DNS query. Until the DNS lookup completes, the Security Gateway holds the first packet of any connection that requires DNS‑based rule base matching.

This results in an approximate 10‑second delay before the first packet of traffic is sent.

Solution

This problem was fixed. The fix is included in:

• Jumbo Hotfix Accumulator for R82.10 starting from Take 19
• Jumbo Hotfix Accumulator for R82 starting from Take 103
• Jumbo Hotfix Accumulator for R81.20 starting from Take 158

If you choose not to upgrade, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue.

A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

For faster resolution and verification, please collect CPinfo files from the Security Management Server and Security Gateways involved in the case.

Hotfix installation instructions:

Refer to sk168597 - How to install a Hotfix.

After installing the Hotfix, do this procedure:

Step1: Enable the nrb_no_async_local_dns Parameter

You can control the Security Gateway behavior with the kernel parameter

nrb_no_async_local_dns:

Configure the applicable value for this kernel parameter temporarily (in the current session only - does not survive reboot), or permanently (survives reboot).

Important In ClusterXL, you must configure all Cluster Members in the same way.

To see the current value of this kernel parameter, run:

Step 2: Create a dedicated rule to allow DNS traffic from the Security Gateway/Cluster Members to the configured DNS servers

1. In SmartConsole, navigate to the relevant policy package.
2. Create a dedicated rule, or move the existing rule to the top of the rule base (or above all network rules that contain Non-FQDN domain objects), to allow DNS traffic from the Security Gateway/Cluster Members to the configured DNS servers.

In the Services & Applications column, select the predefined DNS service.

Note - If you have a separate Application & URL Filtering ordered layer, create an identical  rule to the Network rule, to allow the DNS connection in this policy layer as well.

Step 3: Install the Access Control Policy

Relation Solutions:

• sk182103: Initial packet (SYN or 1st UDP) to a specific subnet is delayed for 6 seconds
• sk176144: "Gateway Timeout" error when attempting to access websites through Security Gateway configured as HTTP/HTTPS Proxy
• sk131852: Updatable Objects
• sk161632: Domains Tool (domains_tool)

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Article Properties

Access Level: General

Status: Approved by TAC

Date Created: 2026-02-01

Last Modified: 2026-07-23