0

This is my first post on this site so be gentle. I am not too clued up with DNS so that might be my first problem but i am pretty sure i covered as much as i know.

So i installed Bind9 on centos 7 and created all the configs for the master etc and its working like a charm. I can resolve the records that i have created when i put a static DNS of my masterdns on my local machine.

Server info: Masterdns.vnq.local: 192.168.2.210 slavedns.vnq.local: 192.168.2.11

So what i was thinking is to replicate the files/records to a slave server in case the masterdns goes down for some reason. So i used this link to setup my master and slave servers. When i test the slave and enter the static in my local machine and try to ping/resolve the dns name it doesn't happen, below is the configs and i will try to explain (best of my knowledge) what i tried.

I will start with the error i am getting or what i have so far and below that i will post all relevant configs.

So when i want to check if the reverse config on the SLAVEDNS is resolving properly it gives me the below output. (Note that the forward file on slave gets the "OK") and also the information replicates from master to slave perfectly but doesnt resolve on slave. What i have tried is to double check all info especially the reverse lookup arpa in the named.conf files for both as i believe it lies there somehwere but i might be completely wrong.

[root@slavedns slaves]# named-checkzone vnq.local /var/named/slaves/vnq.r ev /var/named/slaves/vnq.rev:3: ignoring out-of-zone data (2.168.192.in-addr .arpa) /var/named/slaves/vnq.rev:14: ignoring out-of-zone data (165.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:15: ignoring out-of-zone data (166.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:16: ignoring out-of-zone data (167.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:17: ignoring out-of-zone data (170.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:18: ignoring out-of-zone data (171.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:19: ignoring out-of-zone data (210.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:20: ignoring out-of-zone data (211.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:21: ignoring out-of-zone data (214.2.168.192.in -addr.arpa) /var/named/slaves/vnq.rev:22: ignoring out-of-zone data (masterdns.2.168. 192.in-addr.arpa) /var/named/slaves/vnq.rev:23: ignoring out-of-zone data (ovirt.2.168.192. in-addr.arpa) /var/named/slaves/vnq.rev:24: ignoring out-of-zone data (ovirthost1.2.168 .192.in-addr.arpa) /var/named/slaves/vnq.rev:25: ignoring out-of-zone data (ovirthost2.2.168 .192.in-addr.arpa) /var/named/slaves/vnq.rev:26: ignoring out-of-zone data (ovirthost3.2.168 .192.in-addr.arpa) /var/named/slaves/vnq.rev:27: ignoring out-of-zone data (remote.2.168.192 .in-addr.arpa) /var/named/slaves/vnq.rev:28: ignoring out-of-zone data (slavedns.2.168.1 92.in-addr.arpa) /var/named/slaves/vnq.rev:29: ignoring out-of-zone data (storage.2.168.19 2.in-addr.arpa) zone vnq.local/IN: has 0 SOA records zone vnq.local/IN: has no NS records zone vnq.local/IN: not loaded due to errors.

BELOW IS THE CONTENTS OF THE VNQ.REV FILE.

     $ORIGIN .
$TTL 86400      ; 1 day
2.168.192.in-addr.arpa  IN SOA  masterdns.vnq.local. root.vnq.local. (
                                2011071001 ; serial
                                3600       ; refresh (1 hour)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      masterdns.vnq.local.
                        NS      slavedns.vnq.local.
                        PTR     vnq.local.
$ORIGIN 2.168.192.in-addr.arpa.
165                     PTR     ovirt.vnq.local
166                     PTR     ovirthost1.vnq.local
167                     PTR     ovirthost2.vnq.local
170                     PTR     storage.vnq.local
171                     PTR     remote.vnq.local
210                     PTR     masterdns.vnq.local
211                     PTR     slavedns.vnq.local
214                     PTR     ovirthost3.vnq.local
masterdns               A       192.168.2.210
ovirt                   A       192.168.2.165
ovirthost1              A       192.168.2.166
ovirthost2              A       192.168.2.167
ovirthost3              A       192.168.2.214
remote                  A       192.168.2.171
slavedns                A       192.168.2.211
storage                 A       192.168.2.170

Here is the vnq.fwd file

$ORIGIN .
$TTL 86400      ; 1 day
vnq.local               IN SOA  masterdns.vnq.local. root.vnq.local. (
                                2011071001 ; serial
                                3600       ; refresh (1 hour)
                                1800       ; retry (30 minutes)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      masterdns.vnq.local.
                        NS      slavedns.vnq.local.
                        A       192.168.2.210
                        A       192.168.2.211
                        A       192.168.2.165
                        A       192.168.2.166
                        A       192.168.2.167
                        A       192.168.2.214
                        A       192.168.2.170
                        A       192.168.2.171
$ORIGIN vnq.local.
masterdns               A       192.168.2.210
ovirt                   A       192.168.2.165
ovirthost1              A       192.168.2.166
ovirthost2              A       192.168.2.167
ovirthost3              A       192.168.2.214
remote                  A       192.168.2.171
slavedns                A       192.168.2.211
storage                 A       192.168.2.170

SLAVEDNS 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 { 127.0.0.1; 192.168.2.211; };
        listen-on-v6 port 53 { ::1; };
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { localhost; 192.168.2.0/24; };


};
zone "vnq.local" IN {
type slave;
file "slaves/vnq.fwd";
masterfile-format text;
masters { 192.168.2.210; };
};
zone "2.168.192.in-addr.arpa" IN {
type slave;
file "slaves/vnq.rev";
masterfile-format text;
masters { 192.168.2.210; };
};

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

Below is the master named.conf info

[root@masterdns var]# vi /etc/named.conf
         - 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 yes;

        dnssec-enable yes;
        dnssec-validation yes;

        /* 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 "." IN {
        type hint;
        file "named.ca";
};

zone "vnq.local" IN {
type master;
file "forward.vnq";
allow-update { none; };
};
zone "2.168.192.in-addr.arpa" IN {
type master;
file "reverse.vnq";
allow-update { none; };
};

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

So like i said masterdns working great. when i do the same command on the masterdns server it received for the reverse and forward files the "ok".

see below forward and reverse files for MASTERDNS

Forward.vnq file

$TTL 86400
@   IN  SOA     masterdns.vnq.local. root.vnq.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          masterdns.vnq.local.
@       IN  NS          slavedns.vnq.local.
@       IN  A           192.168.2.210
@       IN  A           192.168.2.211
@       IN  A           192.168.2.165
@       IN  A           192.168.2.166
@       IN  A           192.168.2.167
@       IN  A           192.168.2.214
@       IN  A           192.168.2.170
@       IN  A           192.168.2.171
masterdns       IN  A   192.168.2.210
slavedns        IN  A   192.168.2.211
ovirt           IN  A   192.168.2.165
ovirthost1      IN  A   192.168.2.166
ovirthost2      IN  A   192.168.2.167
ovirthost3      IN  A   192.168.2.214
storage         IN  A   192.168.2.170
remote          IN  A   192.168.2.171

Reverse.vnq fiel

$TTL 86400
@   IN  SOA     masterdns.vnq.local. root.vnq.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@       IN  NS          masterdns.vnq.local.
@       IN  NS          slavedns.vnq.local.
@       IN  PTR         vnq.local.
masterdns       IN  A   192.168.2.210
slavedns        IN  A   192.168.2.211
ovirt           IN  A   192.168.2.165
ovirthost1      IN  A   192.168.2.166
ovirthost2      IN  A   192.168.2.167
ovirthost3      IN  A   192.168.2.214
storage         IN  A   192.168.2.170
remote          IN  A   192.168.2.171
210     IN  PTR         masterdns.vnq.local
211     IN  PTR         slavedns.vnq.local
165     IN  PTR         ovirt.vnq.local
166     IN  PTR         ovirthost1.vnq.local
167     IN  PTR         ovirthost2.vnq.local
214     IN  PTR         ovirthost3.vnq.local
170     IN  PTR         storage.vnq.local
171     IN  PTR         remote.vnq.local
  • You can't have A records in your reverse zonefile, this is not how the DNS works and this is why you have warning about ignored data when you run named-checkzone. – Patrick Mevzek Jul 14 at 5:08
  • @PatrickMevzek I mean, you certainly can have them. It's just a really odd thing to have names such as masterdns.2.168.192.in-addr.arpa with address records, but it's not like it's not possible or doesn't work. – Håkan Lindqvist Jul 15 at 13:24
  • @HåkanLindqvist You can put many kind of records in the DNS... but if applications do not use then, what it is useful for then? Which applications do A requests in in-addr.arpa? I will be curious to know them... CNAME are useful for classless delegations, but A/AAAA no idea, except for nameservers of course, but this is certainly not the case of the user here, which is confused as putting forward and reverse in the same file... Which can be accepted as syntactically valid but won't have the effect the OP wish it has. – Patrick Mevzek Jul 15 at 14:49
  • @PatrickMevzek I don't object that it's a weird thing to do, however it does work just fine with basically any application that accepts hostnames to connect to as input (eg a browser or whatnot) if you give it a name like that (eg masterdns.2.168.192.in-addr.arpa). I don't know why you would want to do it, though, and I agree completely that it's almost certainly a sign that someone has messed up. That however, is wildly different from "you can't, that's not how DNS works and this is why you have warning about ignored data". – Håkan Lindqvist Jul 15 at 15:09
  • @HåkanLindqvist again, even if it technically works fine do you really think that it will achieve the user's intent here? I certainly doubt so. DNS experts can debate it at will, but I think we have to point the OP to the good direction, which is: forward and reverse data HAS to live in separate zones, per design, hence the zonefile provided will not work in the sense that it will not do what the OP intents to do. My first comment erred maybe too much on the strict side but I prefer to give a strong indication to the OP that his construct is wrong. When he masters the DNS, he can change it. – Patrick Mevzek Jul 15 at 15:12
0

Your named-checkzone command line is incorrect for the file you are testing.

You ran:

named-checkzone vnq.local /var/named/slaves/vnq.rev 

But looking at your named.conf as well as the contents of this zone file, it appears the name of that zone is 2.168.192.in-addr.arpa (not vnq.local as indicated on the command line).

If you adjust your command line, the test itself should work:

named-checkzone 2.168.192.in-addr.arpa /var/named/slaves/vnq.rev

An alternative that I find quite convenient is:

named-checkconf -zj

(This loads the named.conf and validates the configuration as well as the zone files referenced in the configuration.)

Now, of course, after you correct the command you use to test the zone file, there may also be real issues with your zone file, but at least then the test will guide you towards the real problems rather than bogus stuff that are purely a result of inconsistent parameters to the validation tool.

Just looking at the contents of the question, here are some problematic things that I immediately spotted:

  • You probably want trailing dots at the end of the values for the PTR records (ie, in your example I assume you wanted the value to be ovirt.vnq.local, not ovirt.vnq.local.2.168.192.in-addr.arpa, which it currently is).
  • The TLD local is reserved for use with mDNS, it should not appear in DNS. You should probably consider using your own namespace instead.
  • The address records in the reverse zone are rather unorthodox. Unless you plan to look up names like masterdns.2.168.192.in-addr.arpa, I would assume that having these records is purely a mistake.
  • It's quite odd that you seem to be directly working with the zone file and the data in it on the slave side. You should not need to do this; when the master works properly the slave should transfer the zone data and write it to the specified file without any manual intervention. (However, it looks like you would need to add allow-transfer on the master side.)
0

Yeah so basically the command i was running was incorrect and thanks for pointing that out and after running the command i got the "ok" which got me thinking why it wasnt working... So i disabled the firewalld on the server and sure enough the slave is working. This is a local DNS only that i am making just to use and play around with.

So basically the command output got me stressed a bit and because of my "limited" knowledge on building a dns server from scratch i thought my config was messed up somewhere..

Thanks for all the answers and comments!

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.