1

I've got an old master nameserver running Bind 9.2 and a newer slave running 9.8. Right now we've got a project going on where we're essentially splitting a cloud in two and we're using subzones and CNAMEs to keep our services running smoothly. However, the cranky old 9.2 server doesn't seem to want to resolve the CNAMEs to the subzone and returns REFUSED: recursion requested but not available. On the other hand the 9.8 server serves the requests just fine.

Disclaimer: I know these nameservers are horribly out of date, and even worse the one running 9.2's OS is waaaaay out of support as well, so I'm not likely to find a reputable package to upgrade it. The project immediately after this cloud split is rebuilding our DNS servers/services from scratch.

How can I get the older server to resolve these CNAMEs properly?

dig results

dig @ NS1 [Bind 9.2]

# dig foo.domain.com @ns1.domain.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> foo.domain.com @ns1.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5937
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;foo.domain.com.        IN      A

;; Query time: 116 msec
;; SERVER: 4.3.2.1#53(4.3.2.1)
;; WHEN: Fri Jul 31 16:18:36 2015
;; MSG SIZE  rcvd: 48

dig @ NS2 [Bind 9.8]

# dig foo.domain.com @ns2.domain.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> foo.domain.com @ns2.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59986
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;foo.domain.com.        IN      A

;; ANSWER SECTION:
foo.domain.com. 300 IN  CNAME   foo.sub.domain.com.
foo.sub.domain.com. 300 IN A     5.6.7.8

;; AUTHORITY SECTION:
sub.domain.com.  300     IN      NS      ns1.domain.com.
sub.domain.com.  300     IN      NS      ns2.domain.com.

;; ADDITIONAL SECTION:
ns1.domain.com.     30      IN      A       4.3.2.1
ns2.domain.com.     30      IN      A       1.2.3.4

;; Query time: 80 msec
;; SERVER: 1.2.3.4#53(1.2.3.4)
;; WHEN: Fri Jul 31 16:22:29 2015
;; MSG SIZE  rcvd: 161

Config

Below are the config files for the servers, trimmed down to the bare essentials.

NS1 [Bind 9.2]

options {
        recursion no;
        additional-from-auth no;
        additional-from-cache no;
        blackhole { bogon; };
        directory "/var/named";
        notify yes;
};
zone "domain.com" {
        type master;
        file "/var/named/domain.com.hosts";
        also-notify { 1.2.3.4; };
        notify yes;
};
zone "sub.domain.com" {
        type master;
        file "/var/named/sub.domain.com.hosts";
        also-notify { 1.2.3.4; };
        notify yes;
};

NS2 [Bind 9.8]

options {
        directory       "/var/named";
        recursion no;
        blackhole{ bogon; };
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;
};
zone "domain.com" {
        type slave;
        masters { 4.3.2.1; };
        allow-transfer { 4.3.2.1; };
        file "/var/named/slaves/domain.com.hosts";
};
zone "sub.domain.com" {
        type slave;
        masters { 4.3.2.1; };
        allow-transfer { 4.3.2.1; };
        file "/var/named/slaves/sub.domain.com.hosts";
};

domain.com.hosts

$ORIGIN .
$TTL 300        ; 5 minutes
domain.com      IN SOA  ns1.domain.com. servers.domain.com. ( ... )
    NS      ns1.domain.com.
    NS      ns2.domain.com.
$ORIGIN domain.com.
sub NS ns1.domain.com.
sub NS ns2.domain.com.
foo CNAME foo.sub

sub.domain.com.hosts

$ORIGIN .
$TTL 300        ; 5 minutes
sub.domain.com   IN SOA  ns1.domain.com. servers.domain.com. ( ... )
    NS      ns1.domain.com.
    NS      ns2.domain.com.
$ORIGIN sub.domain.com.
foo A 5.6.7.8
  • Recursion requested but not available should simply lead to only available (authoritative and already cached) data being used in answering the query. Query response type REFUSED means just that: the server is refusing to tell you anything. I don't remember off the top of my head, but double-check what the default values for allow-query{}; is in the respective versions. Global and per zone. That's most likely the culprit here. Normally you want allow-query { any; }; at least on all authoritative zones, with possibly a more restrictive setting globally. – a CVn Aug 1 '15 at 0:17
  • 1
    Your question is too obfuscated for us to be able to tell you the problem, unfortunately. A status code of REFUSED means that ns1 does not consider itself authoritative for the domain. ns2 does, and answers properly; the status code is NOERROR and the warning about recursion is normal. Run your query with +norecurse to remove the warning. We cannot tell you why the server considers itself authoritative without the unredacted config. There is obviously something wrong and it is likely in the redacted text. – Andrew B Aug 1 '15 at 2:12
  • You can try checking the logs on ns1. Make sure there is not a syntax error that is preventing the zone from loading. – Andrew B Aug 1 '15 at 2:19
  • Please do not redact the domain name in this question. If you feel you absolutely must, then at least do it properly. – MadHatter Aug 1 '15 at 6:42
1

I tossed this question at some smart dudes on IRC and got the answer:

options {
    additional-from-auth yes;
    additional-from-cache yes;
}

Where both were explicitly set to no in my config.

http://www.zytrax.com/books/dns/ch7/queries.html#additional-from-auth

additional-from-auth and additional-from-cache control the behaviour when zones have additional (out-of-zone) data or when following CNAME or DNAME records. These options are for used for configuring authoritative-only (non-caching) servers and are only effective if recursion no is specified in a global options clause or in a view clause. The default in both cases is yes. These statements may be used in a global options or in a view clause. The behaviour is defined by the table below:

And then the table basically boils down to:

If they're not both set to yes the type of query referenced in this question is going to be refused more or less all the time.

  • That last sentence is so blatantly wrong in the context you're presenting it that I have to downvote this. Nothing personal. All REFUSED means is that 1) the server is not configured to provide recursion to the requesting IP address, and 2) the server does not consider itself authoritative for the domain that you are requesting. The additional-from-* options have nothing to do with REFUSED. – Andrew B Aug 1 '15 at 2:06
  • @AndrewB I've amended the answer somewhat, but it's only out of context if you completely neglect reading the actual question. I'd love to have included the table, but SO markdown doesn't allow for tables. Also, the additional-from-* options clearly do have everything to do with the REFUSED response in this case as they were preventing the server from looking up additional records from a different zone. – Sammitch Aug 4 '15 at 20:34
  • I've had to delete two prior versions of this comment, sorry for the spam. My final conclusion is that your answer still has nothing to do with the problem as presented, despite your strong conviction to the contrary. See answer below. I think I was premature in retracting the downvote but it's not worth bothering at this point. Good luck! – Andrew B Aug 4 '15 at 21:36
0

It's extremely difficult to troubleshoot DNS problems with obfuscated examples and we say this frequently. (as MadHatter already pointed out) When we're confronted with a non-sequitur, we basically have to assume that there's something that you're not showing us or that you've tainted the example due to mistranslation. Your comment seems to suggest that the context of your answer should be "obvious" to anyone who reads your Q&A, but that's demonstratively bunk.

This is supposedly the content of your domain.com zone on both servers:

$ORIGIN .
$TTL 300        ; 5 minutes
domain.com      IN SOA  ns1.domain.com. servers.domain.com. ( ... )
    NS      ns1.domain.com.
    NS      ns2.domain.com.
$ORIGIN domain.com.
sub NS ns1.domain.com.
sub NS ns2.domain.com.
foo CNAME foo.sub

Yet you're telling us that the requests for foo.domain.com are returning REFUSED on one of your servers?

# dig foo.domain.com @ns1.domain.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> foo.domain.com @ns1.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5937
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;foo.domain.com.        IN      A

;; Query time: 116 msec
;; SERVER: 4.3.2.1#53(4.3.2.1)
;; WHEN: Fri Jul 31 16:18:36 2015
;; MSG SIZE  rcvd: 48

Sorry, no. That's a misconfiguration if you're presenting it accurately, as it should not be possible for the server to return that answer when that's the actual zone file loaded into memory. (assuming that it did load -- which we couldn't verify with a SOA query for obvious reasons)

REFUSED means that the server is rejecting the query outright because it's interpreting a query as a request for out of zone information. It doesn't matter what the target (right hand side) of your CNAME record is in this case; the left hand side is the only thing that matters. Even if the target is out of zone, that's fine, it just means that your server will provide the answer to the CNAME without providing the corresponding A record. (barring the case where the other zone is located on the same server, which should be the case here) That's still NOERROR though, not REFUSED. The presence of the recursion desired (rd) flag will have no influence on this behavior in an authoritative context either.

I understand that you want us to believe that your answer solves the question you presented us, but it doesn't. I can't speak to what else changed that might have fixed the issue for you, but your example configuration clearly indicates that this data should have been in-zone. The options you tweaked should have no influence on this. We can take your word that your changes have addressed the problem somewhere along the way, but this truly is a case of 1 + 1 = zucchini.

Please make sure the aa flag is present in the response from NS1, for your own sake.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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