DFW context profile FQDN rule not working for certain URLs

Products

• VMware NSX Networking

Issue/Introduction

Impacted version: NSX-T 4.1

• The DFW context profile FQDN rules are not working for the URLs that do not have IPv6 records associated with them.

We can take www.mgmt.cloud.vmware.com as an example:

• If we do nslookup for the URL, we will get only IPv4 address records and no IPv6 records.
• It is observed in the dfwpktlogs.log, the vdpi entry doesn't get created for the concerned URL and further rules get processed while the L7 rule state is pending for the DNS snooping rule:

2023-08-31T06:34:56.234Z 3ebc5651 INET L7 Rule pending PASS 3052 OUT 71 UDP 172.16.10.51/39359->192.168.110.10/53 >>>> pending for L7 verdict (DNS snooping rule)

DNS resolution for IPv4 addresses happen, but the entry doesn't get created in vdpi; we never see APP_DNS entry in the logs and the traffic gets rejected taking a hit at implicit deny (if configured):
2023-08-31T06:34:56.262Z 3ebc5651 INET match REJECT 3054 OUT 60 TCP 172.16.10.51/44766->18.239.199.74/443 S
2023-08-31T06:34:56.263Z 3ebc5651 INET match REJECT 3054 OUT 60 TCP 172.16.10.51/38964->18.239.199.6/443 S
2023-08-31T06:34:56.263Z 3ebc5651 INET match REJECT 3054 OUT 60 TCP 172.16.10.51/51166->18.239.199.126/443 S
2023-08-31T06:34:56.264Z 3ebc5651 INET match REJECT 3054 OUT 60 TCP 172.16.10.51/33182->18.239.199.71/443 S >>>> further rules took hit and rejected the traffic
2023-08-31T06:35:20.815Z 3ebc5651 INET TERM PASS 3052 OUT UDP 172.16.10.51/37994->192.168.110.10/53 4/4 284/576
2023-08-31T06:35:25.816Z 3ebc5651 INET TERM PASS 3052 OUT UDP 172.16.10.51/39359->192.168.110.10/53 4/4 284/576 >>>>> verdict comes from L7 rule, but the traffic has already got rejected

• If we do nslookup prior to initiating the traffic, the FQDN entry gets created and the traffic starts working fine till the time the TTL expires for the FQDN, which can be verified with vsipioctl getfqdnentries -f <dfw-nic-filter>

Cause:
There were some code changes done in version 4.1, due to which the DNS snooping rule keeps on looking for both IPv4 and IPv6 resolutions for the FQDN and thus the verdict doesn't come out, and in the meantime, further rules get processed while DNS snooping rule stays in pending state.

Environment

VMware NSX-T Data Center 4.x
VMware NSX-T Data Center

Resolution

• If we know the IP addresses of the FQDN and if they are static, the same can be allowed via a separate rule as a temporary workaround
• This behavior has been addressed and fixed in 4.1.2 version of NSX-T.