I have an internal network (in a cloud) of 172.16.0.0/20 and several servers. The server on which bind9 runs has the ip 172.16.25.227 and another server (on which different other services) run has an ip of 172.16.30.90. As you can see, the third octets differ.
I have set up bind9 and configured the forward zone file - forward lookups are working just as expected. However, when trying to configure the corresponding reverse zone file, I run into problems.
Configuring the reverse zone starts with reversing your ip - meaning 172.16.0.0 becomes 16.172.in-addr.arpa. Then you configure the file (to which the reverse zone file points) that contains the reverse zone entries. If the third octet was fixed, I would just put the value of the fourth octet at the beginning of each line for any given entry. However, since this is not the case, I have no idea how to approach this. I tried 25.227 and 227.25 but none worked. When I called it a day and decided to give it another shot a day later I noticed that bind9 would no longer start - it would fail to launch. When I checked the logs, I found the issue preventing it from launching:
/etc/bind/named.conf.local:15: zone '31.172.in-addr.arpa': already exists previous definition: /etc/bind/zones.rfc1918:18
From my understanding this file contains entries for the private ip address ranges and its point is to make sure that a DNS server does not send queries for one of these zones into the internet (where they get ignored anyways). However, I am now wondering whether it is actually doable to have a network of 172.16.0.0 with a subnet mask of 20. I noticed that thezones.rfc1918 file just points to db.empty - so I have thought about changing the pointer of that specific entry from db.empty to point to db.172 (the file I created for the reverse lookups) but wanted to ask whether this is a.) possible and b.) good practice.