0

I've been running my own name servers (bind9) for many years in Linux boxes, and I have several in my office served by Verizon FiOS. This morning I discovered that I could no longer resolve anything in the google.com domain. Other domain lookups continued to work. I verified that my root server tables are current.

Unable to identify a misconfiguration, and noticing the problem did not exist with a name server in a VPS on a Linode, I tried a work-around. That VPS is on a layer 2 VPN with my office network, so I switched my default route on some of the affected office systems such that all traffic to the Internet went through the VPS. After this switch, name service is OK, resolving google.com.

See demo below. Note that 192.168.10.87 is one of my internal routers that does NAT to the Version FiOS interface. 192.168.10.78 is functioning as a router on the VPN at a remote site, effectively providing a tunnel for my named processes (and everything else unfortunately) to get to the Internet after I change the default route. The behavior is consistent on three separate computers.

I have some half-baked theories about what is going on, but I can't decide how to diagnose this further.

root@flipper:~# host google.com
;; connection timed out; no servers could be reached
root@flipper:~# host yahoo.com
yahoo.com has address 206.190.36.45
yahoo.com has address 98.138.253.109
yahoo.com has address 98.139.183.24
yahoo.com has IPv6 address 2001:4998:44:204::a7
yahoo.com has IPv6 address 2001:4998:c:a06::2:4008
yahoo.com has IPv6 address 2001:4998:58:c02::a9
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
root@flipper:~# ip ro del default via 192.168.10.87
root@flipper:~# ip ro add default via 192.168.10.78
root@flipper:~# host google.com
google.com has address 216.58.219.206
google.com has IPv6 address 2607:f8b0:4006:80e::200e
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
root@flipper:~# cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
|improve this question
  • Welcome to NE, we hope you will both contribute to and learn from this community. Unfortunately, questions by end users of a network not within their control or of a service provider network are considered off topic by this community. Please see What topics can I ask about here? for more details. Further, while you have described your problem, you really haven't asked any question(s) for anyone to provide any sort of answer. – YLearn♦ Jul 2 '15 at 19:26
  • Well, actually, it is all one network, but I take your point. The implicit question was about how I might diagnose a problem and alter the configuration of the portion of the network under my control in order to achieve satisfactory operation. You're right; I did not ask that question, but instead expected it to be inferred. It's moot anyway. If you want me to delete the post, i'll do so. It's moot anyway. In any case, is there an appropriate forum for this question as you recognize it? – Bill Michaelson Jul 5 '15 at 21:23
0

I'm having a similar problem running DJBDNS on several Centos 6 systems. I ended up redirecting all lookups for the following domains out to the Fios dns cache server at 71.150.0.12 and now the names resolve.

googleapis.com google.com googlemail.com googleusercontent.com gstatic.com

Prior to the redirection, all of the lookups done by the caching server were either getting no responses or server failures but manual lookups using dig would resolve. Used tshark to monitor the packet flow to see this.

I don't know if the following domain is related but it had the same behavior.

llnwd.net

Based on the fact that we're using different software, I think the problem must be external but I have no idea what is causing it.

update: just had to add youtube.com ytimg.com ggpht.com and google-analytics.com

|improve this answer
  • That's similar to what I was seeing. I am in central NJ, BTW. Problem resolved spontaneously. Thanks for the response. – Bill Michaelson Jul 2 '15 at 16:23
  • Oh my - look at the reverse name resolution here... root@flipper:~# ping google.com PING google.com (63.117.14.119) 56(84) bytes of data. 64 bytes from 119.14.117.63.piscataway.google-ggc.verizon.com (63.117.14.119): icmp_seq=1 ttl=60 time=9.12 ms Maybe it was Verizon providing Google service at the edge that was gone. – Bill Michaelson Jul 2 '15 at 16:29
0

The problem has resolved itself. Bottom line is that DNS queries from my recursive servers for names associated with Google did not resolve for at least a couple of hours, but only when originating from my FiOS line. I guess there was a broken route to a required DNS server via Verizon. I did not bother to packet trace or traceroute, nor was there anything informative in syslog. It's working now, and I suppose the cause will remain a mystery.

|improve this answer

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