3

I've got 2 domains in my environment. One of them is an active directory domain for 'myproductionlab.local' at 10.60.0.0/16
Then I have a debian box running bind9 for a domain, 'mytestlab.local'
I have added an entry into my named.conf.local:

zone "60.10.in-addr.arpa" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};
zone "myproductionlab.local" {
        type forward;
        forwarders {
                10.60.10.5;
                10.60.10.7;
                10.60.10.9;

        };
};

the debian box is configured to have 127.0.0.1 for DNS resolution and there are no forwarders globally configured.

name resolution resolves just fine:

nslookup mymachine.myproductionlab.local  
Server:     127.0.0.1
Address:    127.0.0.1#53
Non-authoritative answer:
Name:   mymachine.myproductionlab.local
Address: 10.60.10.200

and from the query log:

client 127.0.0.1#36076 (mymachine.myproductinlab.local): query: mymachine.myproductionlab.local IN A + (127.0.0.1)

but reverse DNS isn't forwarded:

nslookup 10.60.10.200
Server:     127.0.0.1
Address:    127.0.0.1#53
** server can't find 200.10.60.10.in-addr.arpa: NXDOMAIN

and from query log:

client 127.0.0.1#40295 (200.10.60.10.in-addr.arpa): query: 200.10.60.10.in-addr.arpa IN PTR + (127.0.0.1)

I've tried a bunch of zone variations:

zone "60.10.in-addr.arpa" {
zone "10.60.10.in-addr.arpa" {
zone "200.10.60.10.in-addr.arpa" {

I've also tried to tcpdump and 0 packets are captured for nslookup 10.60.10.200 but packets are captured for the name.

when I manually specify the DNS server in nslookup it also works fine:

nslookup 10.60.10.200 10.60.10.5
Server:     10.60.10.5
Address:    10.60.10.5#53
200.10.60.10.in-addr.arpa   name = mymachine.myproductionlab.local.
7
  • I'll assume you reloaded the zone after your changes and did a namedconf check Feb 21 '17 at 2:48
  • Yes, I've reloaded each time and named-checkconf on all the configs reports no errors. Feb 21 '17 at 14:52
  • 1
    what's the output of dig -x 10.60 10.200 Feb 21 '17 at 16:13
  • 1
    Thanks Jacob, I didn't use dig to troubleshoot until you mentioned. Post the suggestion as an answer and I can accept it as correct for you Feb 21 '17 at 20:09
  • so your rdns works, just an issue with nslookup Feb 21 '17 at 20:19
1

nslookup isn't very helpful, what's the output of dig -x 10.60 10.200

which showed your default private ranges were enabled and catching your requests as authority.

remove or edit them to be more specific.

3

The output of DIG led me to discover the issue

dig -x 10.60.10.200

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 10.60.10.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26824
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;200.10.60.10.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.    86400   IN  SOA localhost. root.localhost. 1 604800     86400 2419200 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 13:46:50 CST 2017
;; MSG SIZE  rcvd: 104

10.in-addr.arpa. was defined in zones.rfc1918 which points to db.empty
In previous versions of bind zones.rfc1918 was not included by default and even still I have checked all the configs and nothing is telling bind to read that file so it must be read by default now on this version or it's configured somewhere else.

dpkg -l | grep bind
ii  bind9                                1:9.9.5.dfsg-9+deb8u6            amd64        Internet Domain Name Server
ii  bind9-host                           1:9.9.5.dfsg-9+deb8u6        amd64        Version of 'host' bundled with BIND 9.X
ii  bind9utils                           1:9.9.5.dfsg-9+deb8u6        amd64        Utilities for BIND
ii  libbind9-90                          1:9.9.5.dfsg-9+deb8u6        amd64        BIND9 Shared Library used by BIND
3

Just in case anybody hits this… For recent versions of Bind9 (at least on Debian) it is not sufficient to disable the

include "/etc/bind/zones.rfc1918";

statement because Bind9 then automatically creates them. Instead,

empty-zones-enable no;

is required in your options section (named.conf.options).

See https://deepthought.isc.org/article/AA-00800/0/Automatic-empty-zones-including-RFC-1918-prefixes.html.

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.