Reverse lookup zones play a significant role in DNS systems. DNS is a role that not only translates domain names into IP addresses, but also IP addresses for domain names. Some services require a round trip translation. As in the case of classic zones, it is possible to delegate such zones, but the rules of their operation make this process more difficult, especially in the case of zones in VLSM dictated networks.
Reverse lookup is closely related to networks and specifically to addressing. To explain this properly, we have to use an example:
The company operates the 172.20.0.0/16 network and the mydomain.local local domain. This means that devices that are members of this domain will receive an appropriate DNS suffix, i.e. a MYSQL server with the address 172.20.11.10 whose NETBIOS name is MYSQLSRV001 will have the FQDN MYSQLSRV001.mydomain.local. This server will attempt to register both its name (A / AAAA record) and the PTR (reverse lookup) record in the DNS server.
For this purpose the DNS server must have a reverse lookup domain appropriate for this network – in the presented example it will be 20.172.in-addr.arpa. It is easy to see the notation of such a zone is also retrospective. If the server will be able to find such a zone and updates will be allowed, it will enter its address and name in the following form:
10.11 PTR MYSQLSRV001.mydomain.local.
If we now connect our 10.11 with 20.172 (zone name) and read from the back we will get 172.20.11.20 (the address of our server). The purpose of delegating a part of the network to another server is, as a rule, using the class references. In the example above, we can delegate the 172.20.20.0/24 network to another DNS server. In the server file with the delegated zone, enter the following reference:
20.20.172 IN NS newdnsserver.local
On the other hand, on the target server, we create the correct reverse domain that stores the required records:
Unfortunately, the situation is more complicated when classless zones are delegated. And so, the zones larger than the basic one, eg 23, should be divided into zones / 24 and delegated as separate zones to the delegated server.
It is even more problematic to bypass zones smaller than / 24, for example, holding networks / 26 or / 27. Here we have to use the document RFC2317.
Splitting consists in delegating the following zone on the main server (example for 172.20.0.0/25):
0 / 220.127.116.11 IN NS delegatedserver.local
However, this is just the beginning, because every record that will be in the delegated server must also be referred to this server from the main zone; which means that in addition to the above entry, you should also add CNAME entries for EVERY device:
1 IN CNAME 1.0 / 18.104.22.168.in-addr.arpa 2 IN CNAME 2.0 / 22.214.171.124.in-addr.arpa 5 IN CNAME 5.0 / 126.96.36.199.in-addr.arpa (...)
Therefore, it is extremely important to plan the reverse zones and the IP plan when planning sub-networks and DNS services.