> Source: [sk184096](https://support.checkpoint.com/results/sk/sk184096) # sk184096 - First packet delays for around 10 seconds due to pending WSDNSD DNS lookup over TCP | Property | Value | |----------|-------| | Solution ID | sk184096 | | Date Created | 2026-02-01 | | Last Modified | 2026-07-23 | | Technical Level | General | | Products | Security Gateway | | Versions | R82.10, R82, R81.20, R81.10 (EOS) | ## 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`, also works as expected. * 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](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82.10/Default.htm) starting from Take 19 * [Jumbo Hotfix Accumulator for R82](https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/Default.htm) starting from Take 103 * [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 158 If you choose not to upgrade, Check Point can supply a **Hotfix** . [Contact Check Point Support](https://www.checkpoint.com/support-services/.contact-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](http://supportcontent.checkpoint.com/solutions?id=sk92739) from the Security Management Server and Security Gateways involved in the case. **Hotfix installation instructions:** Refer to [sk168597 - How to install a Hotfix](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk168597).

**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`: |------------------------------|---------------------------------------------------| | Kernel Parameter Value | Security Gateway Behavior | | `nrb_no_async_local_dns = 0` | Feature is disabled by default | | `nrb_no_async_local_dns = 1` | Bypass first-packet hold of local DNS connection. | 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. |--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Deployment | Temporary Configuration | Permanent Configuration | | Security Gateway, ClusterXL | In Gaia Clish, or in the Expert mode: `fw ctl set int nrb_no_async_local_dns ` | In Gaia Clish, or in the Expert mode: `fw ctl set -f int nrb_no_async_local_dns ` | | Security Group in ElasticXL, Security Group in Maestro, Security Group on Scalable Chassis | In Gaia gClish: `fw ctl set int nrb_no_async_local_dns ` In the Expert mode: `g_fw ctl set int nrb_no_async_local_dns ` | In Gaia gClish: `fw ctl set -f int nrb_no_async_local_dns ` In the Expert mode: `g_update_conf_file $FWDIR/modules/fwkern.conf nrb_no_async_local_dns=` | To **see** the current value of this kernel parameter, run: |--------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------| | Deployment | Command | | Security Gateway, ClusterXL | In Gaia Clish, or in the Expert mode: `fw ctl get int nrb_no_async_local_dns` | | Security Group in ElasticXL, Security Group in Maestro, Security Group on Scalable Chassis | In Gaia gClish: `fw ctl get int nrb_no_async_local_dns` In the Expert mode: `g_fw ctl get int nrb_no_async_local_dns` |

**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. ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk184096/dns_rule202512031705291.jpg) **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](https://support.checkpoint.com/results/sk/sk182103) [sk176144: "Gateway Timeout" error when attempting to access websites through Security Gateway configured as HTTP/HTTPS Proxy](https://support.checkpoint.com/results/sk/sk176144) [sk131852: Updatable Objects](https://support.checkpoint.com/results/sk/sk131852) [sk161632: Domains Tool (domains_tool)](https://support.checkpoint.com/results/sk/sk161632)
--- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content