2

We have a small network, with a main server (hosting our own website and functioning as a name server) and some web hosting servers. Since yesterday we have an issue with a domain of a client of ours that we host on our network.

The webserver is set up correctly, the name server as well (and both work fine for other domains), but the domain is unreachable because the hostname lookup fails. Chrome says the hostname could not be resolved, some DNS check tools say that the domain could not be found or even simply just crash.

When I run the dig directgeslaagd.com command, I get an authority section only, saying com 600 IN SOA a.gtld-... which is for the TLD. When I run the dig @ns1.webwhales.nl directgeslaagd.com command, I get the right results (directgeslaagd.com. 86400 IN A 149.210.185.13). This happens from both inside and outside our server network. So, my conclusion is that my name server works correctly, right?

When I adjust the hosts file of my windows PC and load this domain from 149.210.185.13 directly, the website works, conclusion is that also the webserver works correctly. When I lookup the WHOIS data, all name servers and data are correctly. Yesterday I updated the name server details through our registrar, but that did not help.

Do you know what might be the problem here? I have never seen something like this before. The domains used here are the actual domains, so you can see for yourself.

2

Got an answer from my registrar. It turns out that ICANN sends a verification email when the domain holder's email address changes. They do this for all their TLDs for a couple of months now. They give you one to two weeks to click on the link in that email, or your domain will be blocked.

When this is the case, the Registrar Status in the WHOIS data should be clientHold. Ironically this email often disappears in the receiver's spam box. Would be nice if they send an alert to the tech contact (or at least another email address registered with that domain) first.

Hope this will help other people out.

  • Very, very strange that there was no angry red status indicator of this in in your control panel. – Andrew B Mar 1 '15 at 16:39
  • Indeed, they created a brand new control panel, will request them to develop this feature. – redelschaap Mar 1 '15 at 16:41
  • Yeah, that's pretty bad. Others definitely call your attention to this within the main interface. – Andrew B Mar 1 '15 at 16:42
1

It's best to think of WHOIS as a "best effort" information tool for humans. The information it provides is not always current or accurate, and in either case it is not something that DNS ever consults.

dig +trace +additional example.com is your friend; it helps you visualize problems and will show you things that WHOIS never will. This starts a trace at the root nameservers and follows the nameserver delegations.

In your particular case, this is as far as the trace gets:

com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1425204658 1800 900 604800 86400
;; Received 112 bytes from 192.33.14.30#53(192.33.14.30) in 11 ms

This should be ringing a bell: this is very similar to what you were seeing with your earlier dig. (an authority section for com. and its SOA record) The problem is that the TLD nameservers for com. are not serving a delegation to other nameservers.

This is where the information from WHOIS finally becomes useful: directgeslaagd.com. hasn't expired (valid through December 2016), and supposedly there are three nameservers configured...but that isn't a valid reflection of what the TLD nameservers are actually serving when they get the query.

The problem is somewhere between your registrar's web interface and the TLD nameservers. Try to find something inside of the registrar's web interface that might provide a hint as to why this is going on. Short of that, you will need to take this up with your registrar directly as they are the only ones who can provide you a direct answer as to what the problem is.

  • Thanks for your answer. Glad to hear it's (probably) not in my server. Their web interface shows that everything is configured fine, so I'll send them a message right away. – redelschaap Mar 1 '15 at 10:27
  • I did take a look at all three servers and they are all responding authoritatively with matching SOA records, so that's a good sign at least. Make sure you configured IP addresses for those three nameservers within your registrar config. It's unlikely, but this could be something weird your registrar does when no glue records are defined. – Andrew B Mar 1 '15 at 10:33
  • The other two name servers are from my registrar. When using an own name server, you can use two more of theirs as a backup. They watch my name server, update them selves with DNS records and take care of the glue records. This works for all domains we host, and this one started acting weird last night. – redelschaap Mar 1 '15 at 10:42
  • Btw, you say that WHOIS data is not always current and accurate, but doesn't come that data from the same source as where the TLD servers get their data? Or would my registrar has to send signals to multiple services? Not that I changed anything until this occurred... – redelschaap Mar 1 '15 at 10:47
  • The glue records I was discussing are defined at the registrar level, not by your nameservers. They're IP addresses that get served by the com. nameservers in the ADDITIONAL section of the referral to your nameservers. RE: WHOIS, it's just a database of text fields. Ideally it should be current, but you have no control over how long updates to it lag behind updates made to the TLD nameservers. (or whether the data got pushed to the TLDs at all) This is far from the first time I have seen WHOIS data that does not match what is in DNS. – Andrew B Mar 1 '15 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.