0

Edited on 2017-10-25. Original question was misleading.

We have a website running on the subdomain http://admin.gigantisch.nl/. Ever since the gigantisch.nl domain changed IP addresses, we have been having trouble accessing the admin subdomain on various devices and networks. Experiments and diagnostic tools seem to indicate that this is a DNS issue.

We had been able to access the site successfully multiple times in the past days, but this seems due to cached DNS records on our various devices (including routers). It might also be due to cached records by both our ISP's DNS servers and Google's public DNS servers.

When run through the online diagnostics tool: http://dnsviz.net/d/admin.gigantisch.nl/dnssec/, it indicates there is an issue with the NSEC3 record. I have no idea what this record is, or how to manage it. Our domain registrar's DNS zone editor panel has nothing regarding NSEC records.

Something that makes all this more baffling, is that another of our websites running on the subdomain: http://backoffice.gigantisch.nl/, has none of these issues.

 
ORIGINAL QUESTION:

Here in this office, we have a site on the subdomain of our main website we can access through our wifi connections, but not through our wired network. I can also access it on my phone using cellular data.

The address of the site is: http://admin.gigantisch.nl/

The entire domain recently changed IP addresses, so it's likely there is some sort of DNS problem here. When verified with Google's DNS tool (https://dns.google.com/query?name=admin.gigantisch.nl&type=CNAME&dnssec=true), it states under "comment": "DNSSEC validation failure. Please check http://dnsviz.net/d/admin.gigantisch.nl/dnssec/."
That tool, gives us the following errors:

"NSEC3 proving non-existence of admin.gigantisch.nl/A: The NSEC3 RR covers the wildcard itself (*.gigantisch.nl), indicating that it doesn't exist.
NSEC3 proving non-existence of admin.gigantisch.nl/A: The NSEC3 RR covers the wildcard itself (*.gigantisch.nl), indicating that it doesn't exist."

Which at least indicates there is a DNS problem, I guess?

What's also strange, we have none of these problems with our other site, http://backoffice.gigantisch.nl. The DNSViz tool doesn't point out any error or warning for this subdomain either.

I was thinking maybe the old DNS records for the gigantisch.nl domain were cached by the wired router, but I gave it a soft reboot without avail.

The DNS servers for both the wired network as the wireless network appear to be set to Google's servers, 8.8.8.8 and 8.8.4.4.

There is a DNS A record setup for *.gigantisch.nl, but for neither of the subdomains.

Also, when I run Windows 10's Network Diagnostics on my client, I get: "Your DNS server might be unavailable". I don't seem to be experiencing any other connection issues though, so this might be unrelated to the problem at hand.

Ideas?

Edit: When I setup my local connection to use my ISP's default DNS servers, 62.179.104.196 and 213.46.228.196, I can access http://admin.gigantisch.nl/ without issue. When I setup the router to use those DNS servers however, I again can't access it, i.e., Chrome gives me the error ERR_NAME_RESOLUTION_FAILED.

Edit 2: The devices on the wireless network I tried, seemed to have cached the old DNS resolution of the (sub)domain name. Loading it on one of the positively tested mobile devices in an incognito tab on Chrome for example, yields: "this site can't be reached", accompanied by DNS_PROBE_FINISHED_NXDOMAIN. (By contast, Chrome on a Windows client on the wired network gives: ERR_NAME_RESOLUTION_FAILED.)

Protector one
  • 126
  • 1
  • 7
  • Have you checked if from both the network if same IP Address is returned for the said sub-domain? You can do it with `nslookup` or just use`ping`. – Diamond Oct 18 '17 at 13:47
  • @Diamant: nslookup admin.gigantisch.nl seems to give me the ip adress of the used DNS server. Which is indeed different for the wired and wireless connection. Is this useful information? – Protector one Oct 18 '17 at 14:05
  • this at least answers why you are unable to access the website. Now clearly it is a dns issue at your wired network. And I guess it is using cached value. You can try to clear dns cache from a windows pc using `ipconfig /flushdns` from command prompt. Details here: https://www.technipages.com/flush-and-reset-the-dns-resolver-cache-using-ipconfig. Alsc clear your browser cache and see. – Diamond Oct 18 '17 at 14:22
  • @Diamant: Won't `flushdns` just flush the DNS cache on the client machine? I figure I need to flush the cache on the router somehow. – Protector one Oct 19 '17 at 08:14

3 Answers3

1

  • Have you signed the zone again after the modification?

  • Have you waited for the TTL for caches to expire?

The current error tells that there is a NSEC3 record that proves non-existence of the hostname:

Description: NSEC3 record(s) proving the non-existence (NXDOMAIN) of admin.gigantisch.nl NSEC3: E8KJKO07GL57FJK7N58R9HEFDCO38OG8.gigantisch.nl. IN NSEC3 1 0 1 ab HM79JAC9O3DEMLPKUBMF4IUEV63450TB CNAME RRSIG

The NSEC3 RR covers the wildcard itself (*.gigantisch.nl), indicating that it doesn't exist.

Rebooting the router doesn't clear caches on Google Public DNS (8.8.8.8 and 8.8.4.4). It's not a local problem but a problem that exists on any recursive name server that implements the DNSSEC verification until fixed on the authoritative servers and expired on any cache in between.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • Is "signing zones" an option typically offered by domain registrars? I've never heard of it. The IP address changed roughly two weeks ago, but I have no idea how long a TTL cache remains valid. Why is the non-existence of the hostname an issue when it isn't an issue for another hostname? – Protector one Oct 19 '17 at 08:19
1

Surely your local wired network is having a problem with DNS and most probably its the router that is having issue. Apparently the routers functionality as dns forwarder/cache server is either corrupt or not working at all.

A quick solution to try would be to change the routers dhcp option for dns server from google dns to the ISPs nameservers so that each client gets the working dns server ip automatically. Each client will need to renew their dhcp lease for the change to take effect.

If you want to troubleshoot the router, and if you have all the necessary info, then try factory resetting it and then reconfigure and see. If it is still having the same problem, then you will have no choice but to talk to your service provider.

Diamond
  • 9,001
  • 3
  • 24
  • 38
  • I hadn't realized I need to renew the lease on all the clients after changing the DNS server settings on the router. That's definitely something I'll try. – Protector one Oct 19 '17 at 08:16
1

Contact the support of your registrar. Something called a rectify-zone needs to be executed by them, after which the problem disappears.

According to our registrar, this rectify-zone-thing should be automatically executed from their end, every time a change is made to the DNS records. It typically can't be executed from the registrar's admin panel. Apparently, this entire problem stemmed from a hiccup at their end that resulted in the rectify-zone not being executed.

Protector one
  • 126
  • 1
  • 7