Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm experiencing symptoms similar to those of the other question. That is, peoples are complaining about a domain name being inaccessible. And then, it suddenly starts working after a while. But I doubt it's because of unreliable DNS servers. They are of my domain name registrar, which is pretty popular in my country.

Could there be some other reasons for this? It's a subdomain, like in and I make it work with wildcard DNS record. Could that possibly be a reason? Maybe some old DNS servers doesn't understand these sort of things? The other reason I can think of is some temporary issues in the internet, like some hosts can't access the other ones? Or some DNS servers filtering out records by some criterion?

UPD The setup is simple, no load balancers, no clusters, no round-robin DNS servers. And I'm talking about publicly available server. The users are the users of the internet. I'm managing both and They are in one DNS zone.

UPD Or maybe after all it's because of the domain registrar. Its servers respond with a timeout:

DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown


I suppose, not all the DNS-servers would tolerate timeouts, don't you think?

share|improve this question
Do you have any reasons why they can't access it? "DNS resolution error" is way different than say, a connection reset. – Nathan C Apr 21 '14 at 19:39
chrome says net::ERR_NAME_NOT_RESOLVED, if that's what you meant. Also, we have other site which makes requests to our domain. And in the log, the other site says "name lookup timed out". – x-yuri Apr 21 '14 at 20:00
So it's definitely DNS...specifically the local DNS the clients are using to resolve the domain name. Try running an nslookup from an affected machine. After, query a known-working server to verify it's a DNS issue (i.e, nslookup – Nathan C Apr 21 '14 at 20:01
The strange thing here is that one user said, that chrome can't resolve domain, but nslookup can. Probably because chrome has some DNS cache of its own. But then, I experienced it myself for some time and was going to check with DNS server, however stumbled upon ping saying "Ping request could not find host Please check the name and try again.", tracert saying "Unable to resolve target system name", but nslookup resolving the domain. – x-yuri Apr 21 '14 at 20:32
Is this domain internal or external? – Nathan C Apr 22 '14 at 0:26

From the comments above, this definitely sounds like a DNS issue. I could see this being caused by hosts caching records, DNS servers themselves caching records (recursively), or even if you have a load-balancer like an F5 appliance that could be doing caching. One that's bitten me more times that I care to admit, is web proxies performing caching of resolved results.

In visiting a website, you have two basic parts, the journey and the destination. The journey is the pre-connection stage and the destination is the actual connection to the server. You need to isolate the pre-connection part of the equation from the actual connection.

Once you resolve the IP address of the website, try typing in the IP address instead of the domain name in your browser. Do your ping tests and traceroutes against this IP address. Is the IP address responding? Is it continually responding over a period of time (ping -t x.x.x.x on Windows) or is it going up and down? If you can get the site with the IP and not the hostname, it's your DNS. If you can't get to it with either, you've got yourself a connectivity problem. If this is intermittent for either the domain name or the IP, you probably have a intermittent load-balancing problem (such as round-robin DNS servers, or improperly configured clustering) or you have an intermittent connectivity issue such as layer 1 or 2 issue.

Something else to add to your toolbox is a looking-glass website called which is specifically designed to help separate out a problem with your system or if it's a more global issue.

Some of this info I've provided is just shooting blindly in the dark, since this is an ongoing troubleshooting process and information is limited so far. If you can post more info as comments, I'm confident we can help get you straightened out.

share|improve this answer
The setup is simple, no load balancers, no clusters, no round-robin DNS servers. I added explicit A record for the subdomain and the issue is supposedly settling down, but I doubt it has to do with it. Anyway, it would be advantageous to have something in case it'll come back. Also, as you might guess it's somewhat problematic to get more info, because I can't reproduce it myself. I experienced it myself, but I couldn't get much of it for the time it was in effect. Nevertheless thanks for your answer, I'll inform you if I manage to get more info. – x-yuri Apr 21 '14 at 21:33

For the future, I will just add some tips from my experience:

  • to properly diagnose the problem you better have access to the DNS server
  • the relevant DNS servers are the SOA-s and caching nameservers that the users use
  • it helps to have both Unix and Windows boxes for diagnostics.
  • DHCP server plays a big part in it, if it gives DNS servers to users
  • IP conflicts can generate weird effects (and all devices on the local network are suspects)

On Unix boxes you use

dig SOA @
dig SOA

On Windows boxes you use

ipconfig.exe /displaydns >logfile.txt
ipconfig.exe /flushdns         <=WITHOUT THIS YOU GET DISTORTED REALITY 
nslookup.exe -q=soa

I did not fully understand, who is SOA (Source Of Authority) for and for your, and whether they are different from the caching DNS(-es) that your users use — if not, all three or more must be dig-ged. DHCP might give several DNS-es to your users and they might have different opinions on the records (caches).

On both unix and Windows you can create cron jobs / schedule tasks to log dig results once per minute to some logfile and then grep through it to collect some difficult-to-catch anomalies. (It helped me prove in one case that our servers indeed sometimes cannot ping each other on the local network!)

share|improve this answer
From the updated question it seems that all technical aspects of the DNS server are in the hands of your registrar and the question is specific to their implementation of the DNS server and their WEBinterface you are using to configure it. Sorry, I cannot yet comment on the question. – mkaama Apr 22 '14 at 20:12
Users being the entire internet, they can have each their own specific problems with their local caching DNS servers. E.g. the local caching DNS server in our company would not respond about some sites, but some other DNS servers (with different caching strategies and error tolerances) would answer about those sites. – mkaama Apr 22 '14 at 20:17
I wanted to clarify, I should dig: 1) SOA of, 2) SOA of if they are in different DNS zones, 3) caching DNS servers of the user (manually specified by users, or given by DHCP). If that's what you mean, I don't really understand why digging SOA of in any case. – x-yuri Apr 22 '14 at 20:18
Also, is there a way to determine from command line which DNS servers are used under windows, to automate asking users as much as possible? – x-yuri Apr 22 '14 at 20:23
If any of above 3 are broken, users will suffer. And caching means that some users can only notice some changes after 6 or 12 hours. dig-ging of course, can only show if the responses are what you expect them to be. To get a good grip on your toolchain you might want to experiment with and see if changes propagate through as expected (create some A records with bogus IP addresses). If users send you the output of ipconfig.exe /all and nslookup.exe -q=soa that will have all the information. – mkaama Apr 22 '14 at 20:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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