Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

A user reported to me that they are unable to access This is a fairly major international site, so it seemed a bit strange. I replicated the issue on my machine in different browsers. results in a page not found error.

Our environment is two Windows Server 2008 R2 DCs running DNS for the campus. They are each configured to use root hints, with no DNS forwarders in use. The systems are solid, and for other parts of the internet, they seem to resolve DNS queries like a champ. All campus computers are set to use these DCs as DNS servers, and except for the DCs, workstations cannot make outside DNS requests (blocked by firewall).

This problem comes and goes. In the past, I have flushed the DNS cache on both servers as a temporary fix. When the issue is happening, performing an nslookup results in something like the following (simulated, since the issue isn't present right now): nslookup Default Server: Address:


*** can't find Server failed

When it does work:

Default Server:


Non-authoritative answer:

Flushing the DNS cache on the server resolves this - usually - instantly. intoDNS DNS report shows that most things on their end are normal: EXCEPT that they provide no glue between their name servers.

This issue appears to be only for - no other users have reported issues. I'm fine clearing the cache when there is an issue, but I'd also like to understand what could be causing this. Could this issue be on our end, or does pass some funky DNS?

share|improve this question
IntoDNS is a quite poor service, with several spurious errors. The one about missing glue is specially stupid, since the name servers of are not even in the same TLD as the domain they server. See for a comparative analysis. – bortzmeyer Jun 29 '13 at 11:28
up vote 1 down vote accepted

Indeed, I find nothing wrong with, except may be a lack of diversity (all name servers in one AS). The only way forward I can think about is, next time it breaks, run some tests from your network. For instance, dig and traceroute to all the name servers of

(Online tests like tests from a differenat vantage point. If it is a network issue between NTT and you, they may miss it.)

An example with a simple tool:

% check-soa -i OK: 2013062800 (166 ms)
    2001:418:3ff:4::11: OK: 2013062800 (159 ms)
    2001:1868:104::101: OK: 2013062800 (201 ms) OK: 2013062800 (184 ms) OK: 2013062800 (131 ms)
    2001:418:0:700b::201: OK: 2013062800 (140 ms)
    2001:728:0:7000::201: OK: 2013062800 (53 ms) OK: 2013062800 (41 ms)
    2001:218:2000:3005::201: OK: 2013062800 (297 ms) OK: 2013062800 (314 ms)

And with dig:

% dig A

; <<>> DiG 9.9.2-P2 <<>> A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48120
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags: do; udp: 4096
;            IN  A

;; ANSWER SECTION:     7200    IN  A

;; AUTHORITY SECTION:     7200    IN  NS     7200    IN  NS     7200    IN  NS     7200    IN  NS     7200    IN  NS

;; Query time: 166 msec
;; SERVER: 2001:418:3ff:4::11#53(2001:418:3ff:4::11)
;; WHEN: Sat Jun 29 13:34:53 2013
;; MSG SIZE  rcvd: 169

In both examples, tests are ran from your network so show what your users will see.

share|improve this answer
Great tools to have! Thanks Bortzmeyer. I'll keep a lookout for this happening again and check from our network out, as well as from an external service to determine where the issue may lie. Thanks! – SteadH Jun 29 '13 at 17:19

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.