Wildcard FQDN does seem to work with adding to alias for policies

We recently added another ISP for our office and instead of pushing that IP out to every box for the new IP, we were going to add an A record and push out a wildcard FQDN to the allowed for MGMT and WebUI from there. It seems though if we add *.example.com this will not work until we resolve internally on the Firebox side the A record we're trying to access. But if we do the actual A record itself, it works without issue (a.example.com) for instance.

Tested across at least 7 different Fireboxes, varying in models and firmware versions. Anyone have any ideas on this? Would really not like to have to add 6 FQDNs to the aliases when one wildcard would cover this all.

If we need to run a DNS lookup response locally before these will work, can anyone say how long this would be cached before we would have to do it again?

  • Please note, all the Fireboxes tested had External DNS server for it's DNS resolution as not all the Fireboxes have local DNS to use.


  • edited July 2020

    From the docs:

    Domain Name Resolution

    When you define a domain name in your configuration, your Firebox performs forward DNS resolution for the specified domain and stores the IP address mappings. For wildcard domains such as *.example.com, the device performs forward DNS resolution on example.com and www.example.com.

    To resolve the subdomains implied by *.example.com, the Firebox analyzes DNS replies that match your domain name configuration. As DNS traffic passes through the Firebox, the Firebox stores the IP address mapping responses to relevant queries. Only A and CNAME records are used. Any other records are ignored.


    Not sure about how long, but there is this info in the docs, which suggests a long time:

    The total number of domain names you can configure in Policies, Alias members, Blocked Sites, Blocked Site Exceptions, Geolocation Exceptions, and Quota Exceptions, depends on the Fireware version and your device model.

    Fireware 12.4 and higher:

    Firebox M200, M270, M300, M370, M400, M440, M470, M500, M570, M670, M4600, M5600, T55, T55-W, T70, FireboxV, and Firebox Cloud: Up to 2048 domain names
    All other devices: Up to 1024 domain names

    Fireware 12.3.1 and lower:

    All devices: Up to 1024 domain names

    Each domain can map up to 255 IP addresses. Older IP addresses are dropped when the maximum is reached.

  • Yeah I read that in the docs, that's the only reason I tested resolving it via internal traffic to confirm that it was a caching issue. Still doesn't explain how it doesn't matter if I use the actual A record it works though (a.example.com). Maybe I'm not reading the docs correctly. I've also put in a support request to see if they could shed some light on the why and for how long because I wouldn't want to have to re-cache the mappings every time we do an update on the firebox (or it loses power for an extended period of time).

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Let us know what support says.

    For FQDN, you can see what the firewall currently has cached in the FQDN table by typing on the CLI:
    diagnose fqdn "/fqdnd/cache/dump"
    (it's a weird command, the quotes in the middle are part of the command. Copy/paste that whole line.)

    You can SSH to the firewall by using a SSH client, and changing the port to 4118. Log in with status, and your status passphrase.

    -James Carson
    WatchGuard Customer Support

  • I see the same behavior and it is equally annoying!

    Gregg Hill

  • So it seems I may have been mis-understanding the article.

    WG Support response pretty much the same but makes sense to me:

    • When you add an FQDN, the Firebox performs forward DNS resolution for the specified domain and stores the IP address mappings.

    • When you add a wildcard FQDN eg. *.example.com, the Firebox only performs forward DNS resolution for example.com and www.example.com. For the other addresses, the Firebox analyses DNS requests that pass through the Firebox and adds the results to its FQDN cache.

    • The length of time that the Firebox caches the result is determined by the TTL (Time To Live) value provided by the DNS Server.

    So to answer your question, yes the Firebox would need to see the DNS lookup for the address in order to match it to the alias and therefore the policy.

    So it makes sense if it's only looking up www.xxxx.com and xxxx.com unless local requests are cached outbound for lookups. That is pretty annoying but not a huge deal I suppose I'll just have to add all the A records manually.

  • It gets to be a big deal when a previously-working wildcard domain suddenly starts failing. I have to either do a lookup from the Firebox or add the FQDN instead, or in addition to, the wildcard.

    Is there a way to dump the output of the command you noted? Using PuTTY, it does not have a buffer big enough to catch it all.

    Gregg Hill

  • Never mind! In PuTTY, click on Window, then it's right in the middle. I was clicking on all the sub-items and not the section titles.

    Gregg Hill

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Greggmh123
    Turn the scrollback up.


    It's also in the support file from the firewall under \support\firewall\fqdnd_cache_dump.txt

    -James Carson
    WatchGuard Customer Support

  • James, judging by our message time stamps, I found the solution as you were typing! I had 716 cached DNS lookups.

    Gregg Hill

Sign In to comment.