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
I tossed this question at some smart dudes on IRC and got the answer:
Where both were explicitly set to
no
in my config.http://www.zytrax.com/books/dns/ch7/queries.html#additional-from-auth
And then the table basically boils down to:
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:Yet you're telling us that the requests for
foo.domain.com
are returningREFUSED
on one of your servers?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 yourCNAME
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 theCNAME
without providing the correspondingA
record. (barring the case where the other zone is located on the same server, which should be the case here) That's stillNOERROR
though, notREFUSED
. 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.