Bind 9.9 upgrade and RFC 1918 Errors

[Chris Wilson]

Hello Everyone,

 

I just recently upgraded one of our servers to bind 9.9, and I'm having some
issues. 

 

We have a legacy software application running that likes to see both
forward/reverse dns, however since the upgrade reverse dns is no longer
working. We have this server working with DHCPD to automatically update zone
records. 

 

When I try to query the server I get:

 

[root at server1 cswilson]# nslookup 192.160.1.149

Server:         127.0.0.1

Address:        127.0.0.1#53

 

** server can't find 149.1.160.192.in-addr.arpa.: NXDOMAIN

 

And in the log:

Mar 14 04:35:06 server1 named[2128]: client 127.0.0.1#44884
(2.1.168.192.in-addr.arpa): RFC 1918 response from Internet for
2.1.168.192.in-addr.arpa

Mar 14 04:35:06 server1 named[2128]: client 127.0.0.1#37262
(2.1.168.192.in-addr.arpa): RFC 1918 response from Internet for
2.1.168.192.in-addr.arpa 

 

(I have also noticed the above errors occur when doing forward lookups from
hosts on 192.168.1.x)

 

I have read up a bit on configuring 9.9 to work and be compliant with new
practices, however all I have done seems to fail. This server is located
behind a private network and does not serve any clients on the internet or
otherwise. I am probably overlooking something, but none the less after
quite a few hours of frustration I thought I would reach out for some help
and guidance as I want to make sure things stay compliant and people stay
happy ;). If anyone sees anything out of place besides the local reverse
zone as well, feel free to let me know. 

 

Any insight would be greatly appreciated!!!! Thanks a bunch in advance. 

 

Best Regards,

 

Chris W.  

 

 

I am posting my configuration just in case:

 

named.conf:

 

key DHCP_UPDATER {

        algorithm HMAC-MD5.SIG-ALG.REG.INT;

        secret "tJLR2IOnrk15bqfJ5kSCgw==";

        };

acl recurseallow { 192.168.1.0/24; 127.0.0.1; };

options {

        check-names master ignore;

        check-names slave ignore;

        check-names response ignore;

        listen-on port 53 { 127.0.0.1; 192.168.1.2; };

        listen-on-v6 { none; };

        directory       "/var/named";

        disable-empty-zone "168.192.in-addr.arpa";

        dump-file       "/var/named/data/cache_dump.db";

        statistics-file "/var/named/data/named_stats.txt";

        memstatistics-file "/var/named/data/named_mem_stats.txt";

        allow-query     { any; };

        allow-query-cache     { any; };

        dnssec-enable yes;

        dnssec-validation yes;

        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";

        session-keyfile "/run/named/session.key";

        allow-recursion { recurseallow; };

        recursion yes;

};

 

logging {

        channel default_debug {

                file "data/named.run";

                severity dynamic;

        };

};

 

zone "." IN {

        type hint;

        file "named.ca";

};

 

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

 

zone "horizon.local" {

        type master;

        file "/var/named/horizon.local.hosts";

        allow-update { key DHCP_UPDATER; };

        };

zone "0.1.168.192.in-addr.arpa" {

        type master;

        file "/var/named/192.168.1.0.rev";

        allow-update { key DHCP_UPDATER; };

        };

key rndc-key {

        algorithm hmac-md5;

        secret "wZNgqFie+NPZ+dT6lT0EIw==";

        };

controls {

        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };

        };

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180314/c54b763c/attachment.html>