Great, we finally finished setting up our nameserver fulfilling all of the basic necessities our business needs and boom, all the sudden the nameserver’s network goes down, suddenly no machines are able to resolve DNS.<\/p>\n\n\n\n
Once the issue is resolved, the business owner decides it’s time to add multiple DNS servers for redundancy in case the situation happens again.<\/p>\n\n\n\n
This is where Master\/Slave DNS server configurations come in for redundancy.<\/p>\n\n\n\n
Generally what this does is we have a master server (our previous rhel92 server) which copies\/transfers\/sends record updates to our new slave servers (in our case this will be rhel92-2 with IP 192.168.0.79).<\/p>\n\n\n\n
First things first, on our -current- bind server (rhel92), we need to allow transfers to the slave.<\/p>\n\n\n\n
Open \/etc\/named.conf and in the options section, we’re going to add the ‘allow-transfer’ option with our slave server’s IP:<\/p>\n\n\n\n
# vim \/etc\/named.conf\noptions {\n....\n allow-transfer { localhost; 192.168.0.79; };\n notify yes;\n also-notify { 192.168.0.79; };\n....\n}<\/code><\/pre>\n\n\n\nThen:<\/p>\n\n\n\n
# systemctl reload named-chroot.<\/code><\/pre>\n\n\n\nWhat do these options do?<\/p>\n\n\n\n
\n- allow-transfer<\/strong> defines a match list e.g. IP address(es) that are allowed to transfer (copy) the zone information to\/from the server (master or slave for the zone). <\/li>\n\n\n\n
- also-notify<\/strong> tells our master to send notifications for record updates to the specified IP addresses (our slave)<\/li>\n<\/ul>\n\n\n\n
Doing this allows us to make changes on the master and have them automatically propagate to any slaves without having to manually copy over each modified zone file to each slave.<\/p>\n\n\n\n
Now let’s go ahead and set up rhel92-2 with the same \/etc\/resolv.conf settings as our first server, and set its hostname:<\/p>\n\n\n\n
rhel92-2:<\/p>\n\n\n\n
# hostname rhel92-2.fakedomain.dev<\/code><\/pre>\n\n\n\nOn all of our clients, we need to add this new second DNS server:<\/p>\n\n\n\n
rhel89, rhel88:<\/p>\n\n\n\n
# echo 'nameserver 192.168.0.79' >> \/etc\/resolv.dnsmasq<\/code><\/pre>\n\n\n\nBack on rhel92-2, basically what we’ve done is copied the \/etc\/named.conf over from our ‘master’ server.<\/p>\n\n\n\n
Now we need to change it to do a few things:<\/p>\n\n\n\n
1. Listen on the correct IP address and allow receiving notifications from master. We also want to make sure our received transferred records save in plain-text format.<\/p>\n\n\n\n
# vim \/etc\/named.conf\n....\n listen-on port 53 { 127.0.0.1;192.168.0.79; };\n allow-notify { localhost; 192.168.0.66; };\n masterfile-format text;\n....<\/code><\/pre>\n\n\n\n2. On our slave server we need to edit our forward and reverse zones so that they retrieve records from the master instead of us having to create them:<\/p>\n\n\n\n
# vim \/etc\/named.conf\n....\nzone \"fakedomain.dev\" {\n type slave;\n file \"slaves\/fakedomain.dev.zone\";\n masters { 192.168.0.66; };\n};\n\nzone \"0.168.192.in-addr.arpa\" {\n type slave;\n file \"slaves\/0.168.192.in-addr.arpa.zone\";\n masters { 192.168.0.66; };\n};\n....<\/code><\/pre>\n\n\n\nOnce again reload:<\/p>\n\n\n\n
# systemctl reload named-chroot<\/code><\/pre>\n\n\n\nAnd like magic, our secondary slave server can be queried for any of the same records as our master from any of our servers:<\/p>\n\n\n\n
[root@rhel88 ~]# nslookup webapp\nServer: 127.0.0.1\nAddress: 127.0.0.1#53\n\nNon-authoritative answer:\nName: webapp.fakedomain.dev\nAddress: 192.168.0.63\n\n[root@rhel88 ~]# nslookup webapp 192.168.0.66\nServer: 192.168.0.66\nAddress: 192.168.0.66#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.63\n\n[root@rhel88 ~]# nslookup webapp 192.168.0.79\nServer: 192.168.0.79\nAddress: 192.168.0.79#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.63<\/code><\/pre>\n\n\n\nPLOT TWIST: <\/strong>Now let’s say the business ownder decides to change the IP of the webapp server to 192.168.0.64. <\/p>\n\n\n\nLet’s go change it on the master:<\/p>\n\n\n\n
Now let’s say you decide to change the IP of the webapp server to 192.168.0.64. Let’s go change it on the master:<\/p>\n\n\n\n
rhel92:<\/p>\n\n\n\n
# vim \/var\/named\/fakedomain.dev.zone\n.........\n$TTL 8h\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n 2022070601 ; serial number\n 1d ; refresh period\n 3h ; retry period\n 3d ; expire time\n 3h ) ; minimum TTL\n\n IN NS ns1.fakedomain.dev.\n\nns1 IN A 192.168.0.66\nrhel92 IN A 192.168.0.66\nrhel89 IN A 192.168.0.63\nrhel88 IN A 192.168.0.67\nwebapp IN A 192.168.0.64\n.........<\/code><\/pre>\n\n\n\n# vim \/var\/named\/0.168.192.in-addr.arpa.zone\n.........\n$TTL 8h\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n 2022070601 ; serial number\n 1d ; refresh period\n 3h ; retry period\n 3d ; expire time\n 3h ) ; minimum TTL\n\n IN NS ns1.fakedomain.dev.\n\n66 IN PTR ns1.fakedomain.dev.\n66 IN PTR rhel92.fakedomain.dev.\n63 IN PTR rhel89.fakedomain.dev.\n64 IN PTR webapp.fakedomain.dev.\n67 IN PTR rhel88.fakedomain.dev.\n.........<\/code><\/pre>\n\n\n\nReload:<\/p>\n\n\n\n
# systemctl reload named-chroot<\/code><\/pre>\n\n\n\nCheck from another server:<\/p>\n\n\n\n
[root@rhel88 ~]# nslookup webapp 192.168.0.66\nServer: 192.168.0.66\nAddress: 192.168.0.66#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.64<\/code><\/pre>\n\n\n\nNow check the slave:<\/p>\n\n\n\n
[root@rhel88 ~]# nslookup webapp 192.168.0.79\nServer: 192.168.0.79\nAddress: 192.168.0.79#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.63<\/code><\/pre>\n\n\n\nUH-OH! There’s a problem here! Our slave still has the old IP. How do we fix this?<\/p>\n\n\n\n
GENERALLY After the TTL expires for the zone (ours is configured for 8 hours) it auto-refreshes. But we need this fixed for production. How do we force the transfer?<\/p>\n\n\n\n
\n- If you really need to force a zone transfer to a slave immediately, you’ll have to delete the backup zone data file and restart — not reload — the name server.<\/li>\n<\/ul>\n\n\n\n
However, to correct the situation for the future, once you realize that you ‘done goofed’ and found that 8 hours is way too long for your TTL, first go edit the TTL on the master server zone files. Since we want our example to refresh very fast, we’re going to set it to 60 (1 minute), but something like 3600 (1 hr) is typical:<\/p>\n\n\n\n
# vim \/var\/named\/fakedomain.dev.zone\n$TTL 60\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n 2022070601 ; serial number\n 60 ; refresh period\n 60 ; retry period\n 60 ; expire time\n 60 ) ; minimum TTL<\/code><\/pre>\n\n\n\n# vim \/var\/named\/0.168.192.in-addr.arpa.zone\n$TTL 60\n@ IN SOA ns1.fakedomain.dev. fakedomain.dev. (\n 2022070601 ; serial number\n 60 ; refresh period\n 60 ; retry period\n 60 ; expire time\n 60 ) ; minimum TTL<\/code><\/pre>\n\n\n\n# systemctl reload named-chroot<\/code><\/pre>\n\n\n\nNow, as mentioned to fix our blooper we’ll have to delete the zone files from our slave server:<\/p>\n\n\n\n
rhel92-2:<\/p>\n\n\n\n
rm -Rf \/var\/named\/slaves\nrm -Rf \/var\/named\/chroot\/var\/named\/slaves<\/code><\/pre>\n\n\n\n# systemctl restart named-chroot<\/code><\/pre>\n\n\n\nFinally, both servers should return the same value from our other non-dns servers:<\/p>\n\n\n\n
[root@rhel88 ~]# nslookup webapp 192.168.0.79\nServer: 192.168.0.79\nAddress: 192.168.0.79#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.64\n\n[root@rhel88 ~]# nslookup webapp 192.168.0.66\nServer: 192.168.0.66\nAddress: 192.168.0.66#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.64<\/code><\/pre>\n\n\n\nAnd if we change it again on the primary rhel92:<\/p>\n\n\n\n
\/var\/named\/fakedomain.dev.zone<\/p>\n\n\n\n
webapp IN A 192.168.0.65<\/code><\/pre>\n\n\n\n\/var\/named\/0.168.192.in-addr.arpa.zone<\/p>\n\n\n\n
65 IN PTR webapp.fakedomain.dev.<\/code><\/pre>\n\n\n\n# systemctl reload named-chroot<\/code><\/pre>\n\n\n\nThen wait a short time (roughly 60 seconds), the TTL should auto-update the changes on our slave now:<\/p>\n\n\n\n
[root@rhel88 ~]# nslookup webapp 192.168.0.79\nServer: 192.168.0.79\nAddress: 192.168.0.79#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.65\n\n[root@rhel88 ~]# nslookup webapp 192.168.0.66\nServer: 192.168.0.66\nAddress: 192.168.0.66#53\n\nName: webapp.fakedomain.dev\nAddress: 192.168.0.65<\/code><\/pre>\n\n\n\nHurray! \\o\/<\/p>\n\n\n\n
<\/p>\n","protected":false},"featured_media":0,"parent":101,"menu_order":1,"comment_status":"open","ping_status":"closed","template":"","doc_tag":[],"_links":{"self":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/185"}],"collection":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/types\/docs"}],"replies":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=185"}],"version-history":[{"count":2,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/185\/revisions"}],"predecessor-version":[{"id":194,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/185\/revisions\/194"}],"up":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/101"}],"next":[{"title":"Using RNDC commands and forcing transfer receiving from a slave nameserver side","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-connection-interruptions\/using-rndc-commands-and-forcing-transfer-receiving-from-a-slave-nameserver-side","href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/188"}],"prev":[{"title":"The Basic Necessities","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-connection-interruptions\/configuring-bind-as-a-caching-dns-server","href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/180"}],"wp:attachment":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=185"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fdoc_tag&post=185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}