I have 3 dns servers that were setup before my time. They are rhel6.10, so close to end of extended support. I would like to get new ones set up, but I'm not sure what the term for the current setup is.
Basically, I have 2 externals, with a 3rd that I make changes to, that then gets reproduced on the 2 externals. I.E. I make a change on the 1 dns server, which then gets propagated to the 2 externals.
I'm sure the setup isn't overly difficult, but I am just not sure what the name of this style of setup would be. It's probably simple, I just want to make sure I have the right 1, so I don't bone everything.

Thanks

I would start with reviewing the config file(s) for the DNS server where you are making changes on. Hopefully it will shed some light.
Do you know exactly which DNS server running on these machines? Is it the DNS server that was packaged with RHEL 6 or different?

I'm about 100% positive it was Bind that was installed. Pretty sure it's a master/slave setup. I am assuming setup was based on this, as its was part of the small documentation.
https://www.unixmen.com/dns-server-i...ng-centos-6-3/

What version OS are you going toward?

Also, /usr/sbin/named -v (no sudo) will tell you the version. Version 9 config is very portable mostly paths and how configs are included is a bit different on different Linux setups.

Sticking with rhel, probably 8.
Bind version: BIND 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.11
The config itself, seems fairly straight-forward. I just hope the named.conf can copy over, it's a large file.

Do you have an extra box or VM? It should move over no problem, but you want to run it to check things like Selinux (if enforcing).
Also, if you dnssec sign zone, that is a process that is sometimes inside bind but on older versions it is outside of the bind process, with things like zone-signer or other processes.

Zones are usually the same config, they just repeat the config over and over. In fact, I usually make a perl script to generate the zone file configs. If you put things in the options file, the zones are usually four line long like:


zone "ZONE" IN {
type master;
file "/var/named/db/ZONE";
};

and the secondary zones are like:

zone "SECONDARYZONE" IN {
type slave;
masters { MASTERPIP; };
file "/var/named/unsigned/SECONDARYZONE";
};

Pretty much the same, over and over.

The master and 1 slave are VMs. The other slave is physical. That way if something with the VM host dies, not all dns is lost.

I mean, can you easily spin up another VM to deploy DNS to it and probably act as a master?

The way DNS works, what you registered to your parent is very important. If you registered just the slaves, then your master is not participating in DNS resolution. If didn't, then your master is simply a stealth master, just a record generator. Check to see how
your slaves receive updates. A stealth would need a allow-transfer clause. If the master is also in the NS records, then you don't need that.

NS records are tied to the IP that you negotiated with your parent (isp or ARIN). So if only your slaves are the IP registered, then things will work fine; in fact you can swap out the master stealth and just upgrade the zones one by one.

The way I would to it:

Spin up a whole DNS master. You can install ALL the running config and zones, but of course they won't work. Create a false subdomain like dnstest.domain.com and configure it on the new master and the slaves. You would have to replicate the firewall settings for the old master for the slaves. When things look good (updates/transfers) then swap ips of the old and new DNS systems. (Oh, sync over the current zone records from old to new BEFORE you switch!) As stated before, if the master is declared in the NS records, then you will need to swap the ips. If not, then you just have to change the source on the secondaries at your leisure.

Bringing this back up, since it's the same topic.
Running into a problem with starting named, on 1 of the slaves.

To add background, rhel 8.6. The "master" performs no dns functions other than updating the slaves.

When attempting to start: I receive this error:
/etc/named.rfc1912.zones:7: options 'allow-update' is not allowed in 'slave' zone 'domain.com'

The current dns slave allows this, so I am not sure why the new 1 does not. I'm sure it's just a config somewhere, but I haven't found where.

Try "allow-update-forwarding" instead of "allow-update". This allows a slave to do dynamic updates.

Ok, so still on this quest. I have to thank elgrandperro for that little change.

I have gotten further. I have a new slave that communicates to the old master. Now I am just getting the new master to work. It's mostly there, but I run into a couple errors.

The old master has a small script that runs.
It runs:

echo -e 'Checking DNS configuration..\n'
named-checkconf
named-checkzone

To check conf and zones, and that seems to work fine. Then it runs:

echo -e '\n'
read -p "Do you want to restart DNS service? (Y) " RESP

if [ "$RESP" = "Y" ]; then

# To generate PTR records
/etc/named/mkrdns /etc/named.conf
/sbin/service named restart
/bin/logger Named service restarted as $USER
fi

It DOES ask to restart the dns service.
The part that seems to fail is the /etc/named/mkrdns
and the named restart

So, the script was used on rhel 6, I am trying to adapt it for rhel 8.

The mkrdns initially installs in /usr/bin/mkrdns, I moved it to /etc/named to emulate the old master. Perhaps that is an issue.

Now, on the named service restart, I am not using the normal named. I am using named-chroot, which is also what the old master used.
So, my guess is I need to change 2 things. I probably need to change the /sbin/service named restart, to reflect that systemctl is used. And I probably need to change the default named service, somewhere, from named to named-chroot. I just don't know where.

I HAVE done systemctl disable named, and systemctl enable named-chroot. So, reboots should start the right service.

I really wouldn't advise moving progs you didn't write yourself. The pkg mgr puts them in a specific place that the rest of named (in this case) expects to find them and where it will update them(!).
Just edit your script to match the original instead.

Also you may or may not have preserved ownerships/permissions/selinux settings by moving it..
Luckily, there is a 'yum reinstall ..' cmd - you might want to think about using that to ensure the above are correct.
For future ref, there is also https://www.cyberciti.biz/tips/reset...ermission.html

Well, I moved it back, but the error is still the same. I checked my sebools and turned 1 on, but no change.

The error, which I neglected to list previously:
Too many }; found!

So, it doesn't like the named.conf, which is odd as mkrdns has no problem with it, on the server I am replacing.

I only removed identifying info, otherwise this is the exact named.conf used on the old master(and works), that I am trying to use on the new master.

Keep in mind, I never set up the old master, and I am learning as I go. Most of it, I have figured out. I figured out the restart named-chroot issue.
So, this might be my last hurdle.

It's difficult to tell, but you could diff this one against the known good original.
Also, it's possible the syntax error is actually in one of the included files.

You could grep for '{' and '};' and see which file has a mismatched number of occurrences.

What does named-checkconf say, by itself? It should find this error, but it doesn't traverse includes, it won't tell you which line in which file but only which include is in error.