FQDN objects not resolving

p4_greg · January 6

We seem to have discovered an issue with the method used to resolve DNS hostnames on the USGs, affecting both uOS and previous ZLD based firewalls.

Over the last couple of months we are running into issues with certain FQDN objects that will not properly resolve to an IP. Doing a bit of research, it seems some internet DNS servers are beginning to implement RFC8482 which does not allow DNS queries with QTYPE=ANY, which is the query type sent by the zywalls. Sometimes the queries succeed, but increasingly they are failing, I assume because DNS providers are slowly rolling this out on a percentage of traffic so we can discover/fix this type of issues.

Using the nslookup tool in the Diagnostics menu of the firewall, the affects of this RFC being enforced can be observed. If I force the firewall to do an A record query instead of an ANY query, the hostname successfully resolves and populates the cache, allowing the FQDN object to then function properly.

Will Zyxel adjust the default query type to 'A' on the uOS/ZLD firewalls via firmware update to prevent these issues and comply with this RFC?

More info on RFC8482: https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any/

Some screenshots illustrating the issue we are seeing:

Failed query using firewall's default query type:

Successful query using extension option forcing QTYPE=A

Zyxel_Barry · January 6

Hi @p4_greg,

Thank you for reporting this detailed issue regarding FQDN object resolution on USG FLEX H series firewalls, affecting both uOS and previous ZLD-based devices, due to the implementation of RFC8482.

We understand that the current default DNS query type (ANY) is causing resolution failures with DNS servers that enforce RFC8482, and that forcing an 'A' record query through the nslookup tool resolves the issue.

Zyxel is aware of evolving DNS standards and is continuously working to ensure compatibility and optimal performance across our product lines. While I cannot provide an immediate commitment regarding a specific firmware update timeline for adjusting the default FQDN query type to 'A', your detailed feedback, including the RFC reference and screenshots, is invaluable and has been forwarded to our development team for review.

To further assist with troubleshooting and to help us gather more context on your specific environment, please provide the following information:

Firmware Version: The exact firmware version running on your USG FLEX H Series device.
Network Topology: A diagram or description of your network setup.
Affected FQDNs: Examples of FQDNs that are consistently failing to resolve.

If your device is managed by Nebula, please enable Zyxel Support Access via Help > Support Request in the Nebula Control Center and provide your Organization and Site name. This will allow our support team to directly inspect your cloud environment configuration, significantly speeding up the troubleshooting process.

p4_greg · January 6

Firmware: all current versions

Network topology: WAN→USG→LAN 🙃

Affected FQDN:

-any domain who's DNS provider is cloudflare(and probably other DNS providers I haven't found yet)

-wikipedia.com is a well known domain who's DNS provider enforces RFC8482

-lookup zyxel.com using 'query server' 1.1.1.1 on Network Tool page of USG, it will fail with NOTIMP

-all query with QTYPE=ANY against cloudflare public dns service 1.1.1.1 will fail with NOTIMP error

PeterUK · January 6

In testing with ZLD non wildcard FQDN do use A record lookups when the rule is in use I see it lookup the TTL goes to 0 then at some point does a A record lookup

On FLEX H there is a bug for non wildcard FQDN where when the rule is in use with like policy rule for like ee.co.uk the FLEX H does not do a lookup vs how ZLD and the Cache on the uOS is updated only when DNS happens for ee.co.uk like a wildcard FQDN does.

It is the Diagnostics tool that defaults to any record

Zyxel_Melen · January 6

Hi @p4_greg

Thank you for bringing this issue to our attention with such detailed technical analysis and supporting evidence. We fully understand the concern regarding FQDN object resolution failures due to the increasing adoption of RFC8482 by DNS providers.

Your findings clearly demonstrate how the current default QTYPE=ANY query method conflicts with RFC8482 compliance, particularly affecting domains using Cloudflare DNS and other providers enforcing this standard. We recognize that this is becoming a more widespread issue as DNS providers continue their gradual rollout of RFC8482 enforcement.

We will escalate this technical feedback to our product development team for evaluation and consideration in future firmware releases. Our initial focus will be on the USG FLEX H series as the priority platform for this enhancement.

I also created the idea post for our product team to monitor the comments and votes, which helps them to evaluate this idea.

https://community.zyxel.com/en/discussion/31963/change-default-nslookup-query-type-for-zyxel-firewall

p4_greg · January 6

https://community.zyxel.com/en/discussion/comment/82569#Comment_82569

Thanks for the response @PeterUK - I'm always impressed how you seem to have already found all the bugs, I think Zyxel owes you a paycheck!

You are on to something...it has been the H-series where we experienced issues with FQDN objects used in firewall rules....more uOS 'quirks'

In my case which prompted this post, this bug you mentioned was compounded by the 'test' function on the FQDN object sending an ANY request to cloudflare, who is enforcing RFC8482. So the test function was not pulling the IP into the cache/FQDN object until an 'A' lookup was done, then it got the IP. I never did a packet capture to see exactly what was (or not) happening, also just assumed the FQDN/firewall issue would affect ZLD since it's built-in tests also send ANY queries.

What you are saying does make sense, I guess when running nslookup tool on the 100H with the '-t A' option to force an 'A' lookup, it must have populated the cache and allowed the FQDN object to function.

In addition to fixing the fqdn object update issue, Zyxel should also adjust the test functions to do an 'A' lookup instead of ANY by default...

p4_greg · January 6

https://community.zyxel.com/en/discussion/comment/82584#Comment_82584

Hi Melen, thanks for your comment.

It seems there are 2 issues at play here:

-The FQDN object update bug on the Flex H, mentioned above by PeterUK

-The test functions on the USG sending ANY query by default, causing the FQDN object to not populate the IP after creating it and using the 'Test' function to test it, which occurs when the DNS provider is enforcing RFC8482.

Is Zyxel aware of the update bug mentioned by PeterUK? Is there a solution planned for this issue?

PeterUK · January 6

I have listed the bug here

FQDN stopped update IP lookup — Zyxel Community

To test if your have this issue make a FQDN like ee.co.uk and make a rule like LAN to WAN with destination that FQDN but do not go to ee.co.uk the FLEX H should within about 3 minutes do a lookup when you view that FQDN from FLEX H UI.

FQDN objects not resolving

All Replies

Categories

Security Help Center