0

For the last couple of days, I have been trying to connect my Bind9 server to my AD's DNS as a secondary zone, to no avail. This is all done on VMware, with pfSense connecting the two (yes port 53 tcp/udp is also open there)

The problem seems to be that when trying to get a zone transferred from the master, the packets will be dropped, though there are no firewalls that should be rejecting them.

I can ping all of them with no problem, and I can also transfer the zone via nslookup from a normal windows client.

Looking at Wireshark and tcpdump -i any port 53 when connecting the Bind server to the ADDNS server, gives me this:

https://i.imgur.com/soToiCM.png

Yes it does look like a firewall is blocking the queries, but trust me it can't be. I tried to disable all firewalls and also added both services and port numbers to pass.

You can also see that the Windows server gave me an timeout error, though it has started to give me "The server with this IP is not authoritative for the zone" This error comes no matter where I try to apply it (For zone transfer, NS record, connect to server, etc.)

And looking at the named status, it gives me this me a ton of issues, mostly regarding non authoritative responses :

managed-keys-zone: loaded serial 97
zone 0.in-addr.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone localhost.localdomain/IN: loaded serial 0
all zones loaded
running
zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0)

-

managed-keys-zone: loaded serial 97
zone 0.in-addr.arpa/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone localhost.localdomain/IN: loaded serial 0
all zones loaded
running
zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0)
error (host unreachable) resolving 'dlv.isc.org/DNSKEY/IN': 192.5.5.241#53
error (host unreachable) resolving './DNSKEY/IN': 192.5.5.241#53
error (host unreachable) resolving 'dlv.isc.org/DNSKEY/IN': 198.97.190.53#53
error (host unreachable) resolving './NS/IN': 192.5.5.241#53

- This is after setting a CNAME record in ADDNS for the server. Though I have no DNSSEC set up.

-

managed-keys-zone: journal file is out of date: removing journal file
managed-keys-zone: loaded serial 101
zone 0.in-addr.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone localhost.localdomain/IN: loaded serial 0
all zones loaded
running
zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0)
received control channel command 'stop'
shutting down: flushing changes
stopping command channel on 127.0.0.1#953
stopping command channel on ::1#953
no longer listening on 127.0.0.1#53
no longer listening on 192.168.64.128#53
exiting
managed-keys-zone: loaded serial 101
zone 0.in-addr.arpa/IN: loaded serial 0
zone localhost.localdomain/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone localhost/IN: loaded serial 0
all zones loaded
running
zone centns.bliss.lan/IN: refresh: NODATA response from master 192.168.64.64#53 (source 0.0.0.0#0)
zone centns.bliss.lan/IN: refresh: NODATA response from master 192.168.64.64#53 (source 0.0.0.0#0)

- So the problems seems simple, it is seen as a authoritative server, even though I state it as a slave?

Here is my named.conf

[root@centns ~]# cat /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
        listen-on port 53       { 192.168.64.128; 127.0.0.1; };
        filter-aaaa-on-v4       yes;
        directory               "/var/named/";
        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";
//      auth-nxdomain           no;
//      allow-query             { 192.168.64.0/24; };
//      allow-transfer          { 127.0.0.1; 192.168.64.64; };
//      allow-notify            { 127.0.0.1; 192.168.64.64; };
//      allow-recursion         { 127.0.0.1; 192.168.64.64; };
        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion no;


        dnssec-enable no;
        dnssec-validation auto;
        dnssec-lookaside auto;
        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

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

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };


};
zone "centns.bliss.lan" IN
        {
        type            slave;
        file            "centNS.bliss.lan";
        masters         { 192.168.64.64; };
        allow-query     { 192.168.64.0/24; };
        allow-transfer  { 192.168.64.0/24; };
//      allow-recursion { 192.168.64.0/24; };
        };
                /*
zone "64.168.192.in-addr.arpa" IN
        {
        type slave;
        file "rev.centNS.bliss.lan";
        masters { 192.168.64.64; };
        notify yes;
        };
                */
zone "." IN {
        type hint;
        file "named.ca";
};

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

As you can see from all the commented lines, that I have tried a couple of things now.

I have tried:

*Disabling firewall on both Windows and CentOS

*Setting a A and CNAME record in the AD DNS for my CentNS server

*Making sure that Windows has BIND enabled

If you need more information, please ask, I really want this to work.

migrated from unix.stackexchange.com Aug 16 '18 at 16:16

This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.

  • Fair. I just thought it might have something to do with the bind conf, which is why I posted here instead. I also tried without firewalls (as said), but still no dice. – DamnPeggy Aug 16 '18 at 13:10
0

For creating a slave of the Windows DNS, in the Windows side, you need to authorize zone transfers.

Roughly, depending on the Windows version, that path is "Server Manager->DNS->DNS Manager->Properties->Zone Transfers". Select "allow zone transfers" and "only to the following servers" and add your BIND IP addresses.

As for your BIND configuration, you need also to allow names starting with _, as Windows DNS uses them. So in the options section, you add:

check-names master ignore;

Beware also of you DLV DNSSEC configuration, you are getting the error (host unreachable) because the DLV has been obsolete for years and the project killed since 2015.

So comment or delete the line bindkeys-file "/etc/named.iscdlv.key";

  • I have allowed transfer to the server, windows just gives me "The server with this IP address is not authoritative for the zone" I also before had the check-names master ignore; Though that line still didn't make any difference. Same with commenting out the bindkeys-file – DamnPeggy Aug 16 '18 at 12:46
0

Your image shows "Host administratively prohibited", so there must be a firewall somewhere.

it is seen as a authoritative server, even though I state it as a slave?

A slave server is also authoritative.

  • Where do you reckon it could be coming from then? Cause I added dns a a service, as well as the ports 53/tcp and 53/udp to my zone in firewalld. Also configured the same rules on Windows firewall and pfSense – DamnPeggy Aug 17 '18 at 6:14
  • Also is there anything in the named.conf that would make it not authoritative or am I missing something? – DamnPeggy Aug 17 '18 at 6:16
  • The source address of the ICMP packets is displayed in the image. Find the host with that address, and find out why it rejects the packets. – RalfFriedl Aug 18 '18 at 11:26

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.