I'm running an authoritative server with recursion disabled for hosts not in my network on BIND 9.11.3. When querying for domains not under the server's authority from a host outside my network, I get no answer and a list of root servers in the authority section. I understand why this happens, and I'm wondering if it's possible to disable the authority section entirely. Is there an option similar to minimal-responses that will not return any authority data when recursion is not available?

Example dig:

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> @NS google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6847
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5ed7760df1d65f05baba487c5b75a318b3065456b81ca133 (good)
;; QUESTION SECTION:
;google.com.                        IN      A

;; AUTHORITY SECTION:
.                   518400  IN      NS      D.ROOT-SERVERS.NET.
.                   518400  IN      NS      F.ROOT-SERVERS.NET.
.                   518400  IN      NS      B.ROOT-SERVERS.NET.
.                   518400  IN      NS      L.ROOT-SERVERS.NET.
.                   518400  IN      NS      I.ROOT-SERVERS.NET.
.                   518400  IN      NS      A.ROOT-SERVERS.NET.
.                   518400  IN      NS      E.ROOT-SERVERS.NET.
.                   518400  IN      NS      C.ROOT-SERVERS.NET.
.                   518400  IN      NS      M.ROOT-SERVERS.NET.
.                   518400  IN      NS      H.ROOT-SERVERS.NET.
.                   518400  IN      NS      K.ROOT-SERVERS.NET.
.                   518400  IN      NS      G.ROOT-SERVERS.NET.
.                   518400  IN      NS      J.ROOT-SERVERS.NET.

;; Query time: 36 msec

My options look like this:

options {
        listen-on { any; };
        directory "/var/cache/bind";
        allow-recursion { acls; };

        rate-limit {
                responses-per-second 10;
                exempt-clients { acls; };
                window 5;
        };

        allow-query-cache { any; };
        allow-query { any; };
        allow-update { none; };
        dnssec-enable no;
        dnssec-validation no;
        minimal-responses yes;
        forwarders {
                208.67.222.222;
                208.67.220.220;
        };
};
up vote 7 down vote accepted

I did some quick testing, and believe your problem is related to the following line:

    allow-query-cache { any; };

Your configuration is disallowing recursion to the public, but still allowing cache access. Normally a remote client would receive an rcode of REFUSED when recursion is not enabled, but since access to the cache has been explicitly allowed, the client is receiving the most specific answer that is possible from a cache that does not contain that response.

The DNS professional in me would recommend disabling recursion+caching on an authoritative server in all circumstances where there is not an explicit need. If you are convinced that you need to retain this functionality, then it would be best to apply the same ACL to both. (or simply remove allow-query-cache altogether, since it defaults to the value of allow-recursion)

  • That would make sense. Thanks much! – asmth00 Aug 16 at 18:45

I wouldn't consider what you describe normal behavior for BIND9 (it certainly doesn't behave like that with the default config), however I'm pretty sure I understand what causes it.

Your authoritative server also has recursion enabled (not necessarily a good idea) but locked down (better), however you are specifically allowing everyone access to already cached results.

If you remove allow-query-cache { any; };, it should answer REFUSED (as expected).

  • 1
    Within a minute of each other. Nice! – Andrew B Aug 16 at 17:50
  • Thanks as well. :) – asmth00 Aug 16 at 18:46

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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