0

Right. So I have set up this bind9 server to act as a local DNS server. Everything worked okay up until recently it refuses to resolve domain names like
http://www.google.com.au/
http://www.wikipedia.org/
If I do a dig +trace www.wikipedia.org, I get:

steven@raspberry ~ $ dig +trace www.wikipedia.org

; <<>> DiG 9.9.5-9+deb8u4-Raspbian <<>> +trace www.wikipedia.org
;; global options: +cmd
.                       859     IN      NS      j.root-servers.net.
.                       859     IN      NS      e.root-servers.net.
.                       859     IN      NS      c.root-servers.net.
.                       859     IN      NS      h.root-servers.net.
.                       859     IN      NS      b.root-servers.net.
.                       859     IN      NS      d.root-servers.net.
.                       859     IN      NS      i.root-servers.net.
.                       859     IN      NS      k.root-servers.net.
.                       859     IN      NS      l.root-servers.net.
.                       859     IN      NS      a.root-servers.net.
.                       859     IN      NS      m.root-servers.net.
.                       859     IN      NS      g.root-servers.net.
.                       859     IN      NS      f.root-servers.net.
.                       16451   IN      RRSIG   NS 8 0 518400 20151230170000 20151220160000 62530 . nyrnZ0BopqY5P3GSLOcohUrEU6EkLIc0RfT+dxiDoIPwN93dve1vObA/ 5mDSrp1NRErsEWUqEPkboEWJrkK61c0DZ5Hjf7RiAfIpssY71doFA1G3 zlUomC03AzhpdFTIyW9YY3ZNam8PJfqprIj0i1l9OxDw7q9oUrEicNb5 2ak=
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 35 ms

org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    86400   IN      DS      9795 7 2 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5
org.                    86400   IN      DS      9795 7 1 364DFAB3DAF254CAB477B5675B10766DDAA24982
org.                    86400   IN      RRSIG   DS 8 1 86400 20151230170000 20151220160000 62530 . i81kyNDNJdMC9jgJqTpSVrOr50bX095ZFRzUJobLUIw86wae4V6NVDBk uNYlLENVak15g9eVIcl/TeA2QVF60qNJ7y26H1+S2HrXLH6P03dGfqt9 qLqEdhubYOxKPgOJyNkFzyj88spFYEergV1hbE2dXXe09FJuwUkoTbcf DqE=
dig: couldn't get address for 'a0.org.afilias-nst.info': no more

What should I do? Please help!

Schteeb
  • 3
  • 1

1 Answers1

1

+trace can be misleading with how it resolves NS records and it does not chase glue. If you add +additional you'll see the corresponding IP addresses, but +trace doesn't actually use that data. It's trying to resolve a0.org.afilias-nst.info by contacting your default nameserver (127.0.0.1), which is unable to provide the information.

If changing /etc/resolv.conf to 8.8.8.8 allows +trace to function correctly, the problem is somewhere in your nameserver configuration and you need to analyze the messages logged by the daemon. If it doesn't, your device is unable to communicate on port 53 outbound to the public internet. Fix that first.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • I experienced this exact failure, and at least in my case, it was caused by one of my local nameservers accidentally having an forwarders directive that pointed at a Time Capsule that was in turn asking one of my two local nameservers to resolve names, so in some cases it was basically looping between the two nameservers, each of which forwarded the request to the other until the request timed out. I suspect that bad forwarders directives are a frequent cause of this misbehavior. – dgatwood Jan 23 '17 at 05:50
  • Another common cause on multihomed systems is sending the request out the wrong source interface. You can fix that with the query-source directive, but be sure to *not* specify a port number. Another (hopefully rare) cause is old stateful/DPI firewalls that can't handle large DNS packets. Disabling edns (for IPv4 and IPv6) can fix that possible cause. – dgatwood Jan 23 '17 at 05:51
  • Finally, this could be caused by a broken named.ca file, though that typically wouldn't cause a failure so far down the trace, but rather would cause it to be unable to reach any root servers. – dgatwood Jan 23 '17 at 05:52