Rotary.org DNS Resolution - Server Failure

Question

A user reported to me that they are unable to access rotary.org. This is a fairly major international site, so it seemed a bit strange. I replicated the issue on my machine in different browsers. Rotary.org 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: dc1.zzz.edu Address: 192.168.2.4

> rotary.org
Server:  dc1.zzz.edu
Address:  192.168.2.4

*** dc1.zzz.edu can't find rotary.org: Server failed

When it does work:

nslookup
Default Server:  dc1.zzz.edu
Address:  192.168.2.4

> rotary.org
Server:  dc1.zzz.edu
Address:  192.168.2.4

Non-authoritative answer:
Name:    rotary.org
Address:  209.107.78.20

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

This issue appears to be only for rotary.org - 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 rotary.org pass some funky DNS?

Answer 1

Indeed, I find nothing wrong with rotary.org, 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 rotary.org.

(Online tests like http://www.zonecheck.fr/ 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 rotary.org
auth1.ns.gin.ntt.net.
    129.250.35.229: OK: 2013062800 (166 ms)
    2001:418:3ff:4::11: OK: 2013062800 (159 ms)
auth2.ns.gin.ntt.net.
    2001:1868:104::101: OK: 2013062800 (201 ms)
    69.36.249.35: OK: 2013062800 (184 ms)
auth3.ns.gin.ntt.net.
    129.250.31.21: OK: 2013062800 (131 ms)
    2001:418:0:700b::201: OK: 2013062800 (140 ms)
auth4.ns.gin.ntt.net.
    2001:728:0:7000::201: OK: 2013062800 (53 ms)
    213.130.47.21: OK: 2013062800 (41 ms)
auth5.ns.gin.ntt.net.
    2001:218:2000:3005::201: OK: 2013062800 (297 ms)
    61.213.162.88: OK: 2013062800 (314 ms)

And with dig:

% dig @auth1.ns.gin.ntt.net. A rotary.org

; <<>> DiG 9.9.2-P2 <<>> @auth1.ns.gin.ntt.net. A rotary.org
; (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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rotary.org.            IN  A

;; ANSWER SECTION:
rotary.org.     7200    IN  A   209.107.78.20

;; AUTHORITY SECTION:
rotary.org.     7200    IN  NS  auth2.ns.gin.ntt.net.
rotary.org.     7200    IN  NS  auth5.ns.gin.ntt.net.
rotary.org.     7200    IN  NS  auth3.ns.gin.ntt.net.
rotary.org.     7200    IN  NS  auth1.ns.gin.ntt.net.
rotary.org.     7200    IN  NS  auth4.ns.gin.ntt.net.

;; 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.