BIND9 as a cache-only nameserver doesn't work

Question

I installed BIND9 via apt-get on a newly installed and completely updated UBUNTU 12.04, virtualized on VirtualBox.
I want to use it as a cache-only nameserver.

named.conf contains only the following lines:

options {
    directory "/var/cache/bind";  
    dnssec-validation auto;  
    auth-nxdomain no;  
    listen-on-v6 {any;};  

    recursion yes;
    allow-recursion {localnets;};
    allow-query-cache {localnets;};
    allow-query {localnets;};
};  

zone "." {
    type hint;
    file "/etc/bind/db.root";
};

zone "localhost" {
   type master;
   file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
   type master;
   file "/etc/bind/db.127";
};

Now, if I dig anything using my nameserver, the lookup fails with connection timed out; no servers could be reached and the BIND9 log is full of DNS format error [...] non-improving referral or also FORMERR.

More specifically, the result of dig @127.0.0.1 www.amazon.com is

; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 www.amazon.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

In addition, using Wireshark I can see outgoing packets to root-servers, but I never receive a response.

But if I use dig using an external nameserver (8.8.8.8 for example), or I use it in the forwarders option of BIND9, the lookup succeed.

Why?

Questions: How do you know that bind has started or is operating? What are the contents /etc/resolv.conf? Any errors noted during startup? Any errors in the log files? — mdpc, Jan 09 '13 at 16:45
BIND has started because it listens on port 53 (TCP and UDP). `/etc/resolv.conf` contains only one line: `nameserver 127.0.0.1`. The re are NO errors at the startup. Errors in log files are those arising from queries. — JustTrying, Jan 09 '13 at 16:48
David Schwartz: sorry, but your remark makes no sense. BIND knows the root name servers (found in /etc/bind/db.root), it will query them, they will refer to TLD servers, BIND will query them and so on. — bortzmeyer, Jan 09 '13 at 20:55

score 4 · Answer 1 · edited Apr 13 '17 at 12:14

I presume you have already verified to have actual internet connectivity working tip top in your Ubuntu within VirtualBox.

If so, a frequent reason for your own recursive server to not be working is if your internet provider is blocking access to other authoritative name servers that run on the domain port. I see you have already tried making direct requests to the root servers unsuccessfully directly with dig, which would indicate that indeed some connectivity issues are in place.

In short, you can do a simple test: try running dig @8.8.8.8 +trace www.google.com to emulate how a recursive resolver would be doing name resolution.

If you get timeouts prior to ., then there's either something wrong with your connectivity or your provider blocks Google Public DNS (and very likely any other DNS, too).

If you get a timeout right after ., then your provider blocks access to the root servers (and probably all other authoritative name servers, too).

If your recursive resolution has no timeouts, but is missing the com. and google.com. steps, directly jumping from . to www.google.com. (or perhaps doesn't even have . to start with), then it means that your provider is redirecting all domain-port requests to their own set of recursive DNS servers, and you cannot run your own recursive name server with such internet connectivity.

If you get result almost exactly as below, with all the ., com., google.com. and www.google.com. steps, then your own local recursive resolver should work just fine, provided the installation and configuration instructions are followed.

# dig @8.8.8.8 +trace www.google.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 +trace www.google.com
; (1 server found)
;; global options: +cmd
.                       2244    IN      NS      a.root-servers.net.
.                       2244    IN      NS      b.root-servers.net.
.                       2244    IN      NS      c.root-servers.net.
.                       2244    IN      NS      d.root-servers.net.
.                       2244    IN      NS      e.root-servers.net.
.                       2244    IN      NS      f.root-servers.net.
.                       2244    IN      NS      g.root-servers.net.
.                       2244    IN      NS      h.root-servers.net.
.                       2244    IN      NS      i.root-servers.net.
.                       2244    IN      NS      j.root-servers.net.
.                       2244    IN      NS      k.root-servers.net.
.                       2244    IN      NS      l.root-servers.net.
.                       2244    IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 25 ms

com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
;; Received 504 bytes from 192.33.4.12#53(c.root-servers.net) in 15 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 168 bytes from 192.55.83.30#53(m.gtld-servers.net) in 183 ms

www.google.com.         300     IN      A       74.125.225.208
www.google.com.         300     IN      A       74.125.225.211
www.google.com.         300     IN      A       74.125.225.212
www.google.com.         300     IN      A       74.125.225.209
www.google.com.         300     IN      A       74.125.225.210
;; Received 112 bytes from 216.239.38.10#53(ns4.google.com) in 24 ms

If I run `dig @8.8.8.8 +trace www.google.com`, the output directly jumps from `.` to `www.google.com`, as you said. If I try to run, for example, `dig @8.8.8.8 +trace serverfault.com` I can see also the `com.` sections, but a lot of them has a `;; BAD (HORIZONTAL) REFERRAL` at the end. The address from which the response is received is different every time (the `;; Received 505 bytes from 192.43.172.30#53(192.43.172.30) in 1798 ms` has a different address every time), and finally I also obtain the correct response for `serverfault.com`. Is it weird? — JustTrying, Jan 14 '13 at 08:49
It strongly suggests that your network operator is doing something fishy with the DNS. Tell them about Internet neutrality. — bortzmeyer, Jan 14 '13 at 10:23
You are supposed to have different `root-` and `gtld-` servers serving your requests, so the fact that the IP-address is always different is normal. However, for the rest of your concerns, it does seem like you are getting inconsistent results: you've previously said that you can't contact the root server at all, but now it seems like your ISP redirects your requests to the root server back into their own server, but perhaps only sometimes etc. Overall, you clearly have connectivity issues unrelated to BIND9, so your connection is unlikely to run a fully-functional cache. Are you in a dorm? — cnst, Jan 14 '13 at 18:07
One other thing you can try doing, purely for educational purposes and seeing how things work, is run `dig` with the `+tcp` option. DNS usually uses the udp protocol (`+notcp`), and that's the one that would be the first one to be blocked on restricted networks. I'm using a captive network myself right now, and `dig +trace www.google.com` only has `.` and `www.google.com` (indicating redirection to ISP-controlled server), whereas `dig +trace www.google.com +tcp` has all `.`, `com.`, `google.com.` and `www.google.com.` parts as expected (indicating that only 53/udp is restricted, not 53/tcp). — cnst, Jan 14 '13 at 18:17

score 3 · Answer 2 · answered Jan 09 '13 at 20:54

3

The first thing I notice is that you have no "recursion yes;" in named.conf. BIND is not recursive by default (for some time) for security reasons. You should authorize your local network to query the resolver with recursive queries:

acl me {
            ::1/128;
            127.0.0.0/8;
};
...
    recursion yes;
    allow-recursion   { me; };
    allow-query-cache { me; };
    allow-query { me; };

It does not explain the strange error messages you find in the logs. Frankly, in ServerFault's questions, I hate vague summaries like "Now, if I dig anything using my nameserver, the lookup fails with connection timed out". Post the complete command and the complete result and we'll see.

answered Jan 09 '13 at 20:54

bortzmeyer

3,941
1
21
24

1

As usual, excellent DNS advice from Stephane. You need to explicitly enable recursion in order for BIND to answer your queries. You might find the pre-defined ACL "localnets" useful if you want to be more permissive than his address match list, which matches only localhost. Please do use an ACL of some kind, i.e. do *not* operate an open resolver. They *will* be discovered and used for DNS reflection attacks. – Michael McNally Jan 09 '13 at 21:31
I edited my post with your suggestions. And I also edited my real `named.conf`, but as you can see lookups continue to fail. – JustTrying Jan 11 '13 at 09:01

BIND9 as a cache-only nameserver doesn't work

2 Answers2