DNS_PROBE_FINISHED_NXDOMAIN

Hello everyone,

for some time now a strange thing has happened to me for the watchguard forum site, when I try to login on the forum the "DNS_PROBE_FINISHED_NXDOMAIN" page appears after 1 second the page is automatically reloaded and everything is ok.

the nice thing that it does only on the forum site .... it happens to you too, I have active dnswatch

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @toscanatlc
    What website is in your address bar when you get that error?

    -James Carson
    WatchGuard Customer Support

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @toscanatlc
    I'll look into this and see if I can get it to reproduce.

    If the issue continues, I'd suggest opening a support case for it -- that'll allow us to get more details and help should that happen.

    -James Carson
    WatchGuard Customer Support

  • James,

    if it can help, sometimes when i disconnect from the esc forum this:

    Sorry, but we're having trouble signing you in.
    We track these errors automatically, but if the problem persists feel free to contact us. In the meantime, please try again.
    Correlation ID: 8b18d805-c26c-4b7a-abd4-7d3e57897653
    Timestamp: 2021-09-28 18: 46: 37Z
    AADB2C: An exception has occurred.

  • Hello,
    today i downgraded my firebox to previous version 12.7 (build 640389) and the DNS problem seems to be gone ....

  • for those scrupulous, or as we say in Italy "I'm like St. Thomas if I don't see I don't think", I updated the mil M370 to 12.7.1 and the problem was immediately resolved, no configuration changed or modification made, only upgrade

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @toscanatlc
    If a downgrade then upgrading back to 12.7.1 fixed it, it's likely something got cached. If for some reason this occurs again, I'd suggest a support case so we can get logs from the device and determine how that might be happening (if that is what happened.)

    Thanks for reporting back what you did to get it working. I'll keep an eye out for similar issues.

    -James Carson
    WatchGuard Customer Support

  • Hi James, I apologize for a typo, with version 12.7 everything ok but after I redid upgarde to 12.7.1 the problem is BACK IMMEDIATELY, I opened a ticket about it, I expect support around Monday 4/10, there I will let you know

  • nothing to do, even the technical support has not found any problems on the DNS, I do not know where to turn my head, the only thing left to do is to downgrade the cluster to 12.7 but I would like to avoid .. sic sic

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @toscanatlc Can you please give me your case number?
    I can go take a peek and see if I can get the tech to escalate it.

    -James Carson
    WatchGuard Customer Support

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @toscanatlc
    I was able to search around and find your case.

    In this case, it looks like you've completely disabled any DNS service on the firewall and are getting an NXDOMAIN response from your DNS server.

    If the NXDOMAIN response (as in the server is making a response saying it can't find the host) downgrading the cluster isn't going to change that response.

    The easiest way to verify that this is how your external DNS server is responding is by taking a packet capture. You can do this by using Firebox System manager.

    -Open WatchGuard System Manager, and log in. Right click on your firewall and go to Firebox System Manager.
    -Click Tools -> Diagnostic Tasks.
    -Choose TCP Dump from the drop down menu.
    -Choose advanced options.
    -Use the argument "-nei eth0 port 53" (without the quotes, change eth0 to the port your external interface is on if it's a port other than 0.)
    -Click to stream the file to a location, and specify where you'd like to save.
    -Click run task.
    -Allow the error to occur.
    -Click stop task.

    If the upstream DNS server is in fact replying with NXDOMAIN, we should be able to see that in the capture (using a display program like wireshark.)

    If the DNS server is not providing an IP for that website intermittently, you'll need to look into that with the DNS provider, or consider changing DNS services. Keep in mind that DNS is a global service, so if the server that authoritative for that domain is not properly providing a record, it'll cause problems throughout the entire DNS system.

    -James Carson
    WatchGuard Customer Support

  • Hi James, first of all thanks for your interest, I did as you told me, the problem occurred after 4/5 searches on the adidas.com site, last night I changed our DNS to 9.9.9.9 (I remind you that DNSWatch is disabled), from the tcpdump analyzed with wireshark I notice a strange thing, there are requests to 34.251.171.117 which if I'm not mistaken is the DNS of DNSWatch and this is strange, I am attaching the portion of the dump where the error is:

    165 75.197.088 34.251.171.117 185.xxx.xxx.xxx DNS 96 Standard query response 0xb743 To edgedl.me.gvt1.com A 34.104.35.123
    166 75.731.571 185.xxx.xxx.xxx 34.251.171.117 DNS 75 Standard query 0xe602 A www.adidas.it
    167 75.900.168 34.251.171.117 185.xxx.xxx.xxx DNS 216 Standard query response 0xe602 A www.adidas.it CNAME www.adidas.com_v2.edgekey.net CNAME e40636.a.akamaiedge.net A 23.216.154.219 A 23.216 .154.240 A 23.216.154.232 A 23.216.154.224
    168 77.128.440 185.xxx.xxx.xxx 34.251.171.117 DNS 79 Standard query 0x77 from To assets.adidas.com
    169 77.128.618 185.xxx.xxx.xxx 34.251.171.117 DNS 87 Standard query 0x8465 To adl-foundation.adidas.com
    170 77.128.869 185.xxx.xxx.xxx 34.251.171.117 DNS 85 Standard query 0x4f39 To brand.assets.adidas.com
    171 77.214.317 34.251.171.117 185.xxx.xxx.xxx DNS 190 Standard query response 0x8465 To adl-foundation.adidas.com CNAME adl-foundation.adidas.com.edgekey.net CNAME e1777.dsca.akamaiedge.net A 95.101 .87.80
    172 77.217.914 185.xxx.xxx.xxx 34.251.171.117 DNS 81 Standard query 0xb0ec A engine.monetate.net
    173 77.224.520 34.251.171.117 185.xxx.xxx.xxx DNS 223 Standard query response 0x77 from To assets.adidas.com CNAME assetmanagerpim.san.cloudinary.com CNAME s1-san.cloudinary.com.edgekey.net CNAME e4531.dsca .akamaiedge.net A 184.27.96.132
    174 77.228.254 185.xxx.xxx.xxx 34.251.171.117 DNS 76 Standard query 0xa25d To f.monetate.net
    175 77.305.487 34.251.171.117 185.xxx.xxx.xxx DNS 158 Standard query response 0xa25d To f.monetate.net CNAME f.monetate-prod.zone A 99.80.96.190 A 52.214.104.135 A 52.213.34.91
    176 77.308.430 185.xxx.xxx.xxx 34.251.171.117 DNS 77 Standard query 0xa43e To sb.monetate.net
    177 77.353.393 34.251.171.117 185.xxx.xxx.xxx DNS 172 Standard query response 0xb0ec A engine.monetate.net CNAME engine.monetate.net.edgekey.net CNAME e4361.b.akamaiedge.net A 104.87.108.185
    178 77.356.655 185.xxx.xxx.xxx 34.251.171.117 DNS 77 Standard query 0x306e A se.monetate.net
    179 77.431.021 34.251.171.117 185.xxx.xxx.xxx DNS 163 Standard query response 0xa43e To sb.monetate.net CNAME http2.monetate.edgekey.net CNAME e4361.b.akamaiedge.net A 104.87.108.185
    180 77.433.527 185.xxx.xxx.xxx 34.251.171.117 DNS 77 Standard query 0x277c A tags.tiqcdn.com
    181 77.435.267 34.251.171.117 185.xxx.xxx.xxx DNS 163 Standard query response 0x306e A se.monetate.net CNAME http2.monetate.edgekey.net CNAME e4361.b.akamaiedge.net A 104.87.108.185
    182 77.437.691 185.xxx.xxx.xxx 34.251.171.117 DNS 75 Standard query 0x56c8 A www.res-x.com
    183 77.511.037 34.251.171.117 185.xxx.xxx.xxx DNS 167 Standard query response 0x277c A tags.tiqcdn.com CNAME tags.tiqcdn.com.edgekey.net CNAME e8091.a.akamaiedge.net A 184.27.98.33
    184 77.519.942 34.251.171.117 185.xxx.xxx.xxx DNS 91 Standard query response 0x56c8 A www.res-x.com A 69.43.132.198
    185 78.147.852 185.xxx.xxx.xxx 9.9.9.9 DNS 91 Standard query 0x72a2 A eu.web.repauth.watchguard.com
    186 78.147.912 185.xxx.xxx.xxx 149.112.112.112 DNS 91 Standard query 0x72a2 A eu.web.repauth.watchguard.com
    187 78.183.469 149.112.112.112 185.xxx.xxx.xxx DNS 123 Standard query response 0x72a2 A eu.web.repauth.watchguard.com A 34.250.146.177 A 34.248.145.13
    188 78.183.515 9.9.9.9 185.xxx.xxx.xxx DNS 123 Standard query response 0x72a2 A eu.web.repauth.watchguard.com A 34.250.146.177 A 34.248.145.13

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @toscanatlc
    The DNS servers on the firewall only govern what DNS servers the firewall uses, and in the event of it being a DHCP server, what DNS servers it provides to the client(s). If there are clients that still have a DHCP lease from when that was the setting or that manually have it populated (for example, if they're using DNSWatch Go) they may still be looking up.

    In this case, the DNS queries all appear to be getting responses -- did you encounter the issue during this time?

    -James Carson
    WatchGuard Customer Support

  • Hi James,

    I can confirm that after the last update 12.7.2 the problem was still in place, after disabling DNSWartch the problem seems to have disappeared, for what I think the problem lies in DNSWatch.

    this for what concerns the initial post, the problem on my M370 for Watchguard domains "DNS_PROBE_FINISHED_NXDOMAIN"

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @drnet
    If you don't have a support ticket in place, I'd suggest opening one -- there's a very limited amount of troubleshooting that can be done over the forums.

    -James Carson
    WatchGuard Customer Support

  • Restart DNS Client Server.
    If you’re running Windows you can try restarting the DNS client services which resolves and caches DNS domain names.

    Simply open up Command Prompt by pressing the Windows logo key and R. Then type “services.msc” and hit Enter.

    Scroll down to “DNS Client,” right click on it, and select “Restart.

    If the restart option is greyed out for you (as it was for us), an alternative way to do it is via the command prompt.

    Open up Command Prompt by pressing the Windows logo key and R. Then type “cmd” and hit Enter.

    Then enter the following commands:
    net stop dnscache
    net start dnscache
    Depending on the version of Windows you’re running you might get an error saying:
    The requested pause, continue, or stop is not valid for this service.
    This is most likely because you need to run CMD as a network service to issue the command. If you’re running into this error, we suggest trying the other alternatives below first.

  • Hello,

    yes they are all tests that I have already done, even from different PCs, as already described after the update to 12.7.2 and the deactivation of DNSWatch everything works ok, as I reactivate DNSWatch the problem comes back to the surface for what concerns only and exclusively the "watchguard" domain.

    during the day I do other tests and I tell you, thanks bye

  • Hello,
    if i disable the dnscache service on the pc (windows 10) the problem seems to disappear, i don't really understand. if you noticed in the changelog of 12.7.2 a fix is mentioned that seems related to my problem:

    "An issue that caused DNSWatch to refuse requests is resolved. [FBX-22069]"

  • With the Windows DNS cache enabled, you can see the cache contents in a text file with a command such as this:
    ipconfig /displaydns > c:\temp\dnscache.txt

    Perhaps that will help understand the issue.

  • Hi Bruce,

    yes sure, already done, I also ipconfgi / flushdns to empty everything mam then double check what is inside the cache, it is empty but the problem persists.

  • as a matter of fact, if I bypass the firewall and connect directly to my router the problem does not exist.

    did you see the fix I wrote earlier on version 12.7.2?

  • Yes.
    However, there is no detail about what the fix really fixes.
    And there is nothing for this fix number in the Known Issues list on the support site which might give more info.

    I don't use DNS Watch because doing so causes any DNS policies in ones config to not be processed - and I have some DNS proxy policies that I want to have in use.
    This I can't see this issue.

  • when I opened the ticket to technical support they told me to update to 12.7.2 because my problem was probably related to this BUG, it seems strange to me that no one else has this problem, even in the other office we have this problem arandom on many domains , for now the only thing to do is wait, I did everything, I even reset my router, tonight maybe I try to downgrade the firmware.

    Thanks Bruce, bye

  • I can confirm that since upgrading to 12.7.2 I have had constant issues with "DNS_PROBE_FINISHED_NXDOMAIN"

    This is usually occuring with website sub domains.
    eg.

    Sub.domainname.com.au

  • thanks for the confirmation I thought I was the only one, also etu use DNSWatch?

    I thought I was the only one ..

Sign In or Register to comment.