A Couple of Questions on Reverse PTR Records

[sproggit]

I'm in the process of attempting to add some reverse-lookup functionality to my local Zone... and I'm seeing some odd results likely the result of misunderstanding on my part. I'd be very grateful for anyone able to offer any advice on the following.

First Question - Reverse Zone Creation...
The network containing my local zone addresses is 172.16.0.0 - running as a flat Class B network [or so I thought]. In other words, I'm using a subnet mask of 255.255.0.0, or /16 for my local addresses... Initially, after a quick bit of Google-Fu, I found this thread

https://www.reddit.com/r/technitium/comments/1n0la3d/add_hostnames_to_static_ips/

and given my network range I tried to manually add a Zone on my Primary DNS, using 0.0.16.172.in-addr.arpa ... I then tried to add PTR records to that zone - which Technitium lets me do... but when I went back to my Dashboard and looked at the "Top Clients" table, they were still showing just IP addresses, not my local domain names.

So I went back to my existing Zone, chose the A record for a highly active host and selected "Edit". I then activated the two radio-button options, "Update reverse (PTR) record" and "Create reverse zone for PTR record" and clicked "Save". This time, when I went back to my Dashboard and looked at "Top Clients", I can now see the FQDN for each of the top 10 active hosts - which is exactly what I wanted... But something else and unexpected has happened... When I select the "Zones" tab, I now find that I have multiple new Primary Zones created by my changes ... such as 1.16.172.in-addr.arpa, 101.16.172.in-addr.arpa and 104.16-172.in-addr.arpa.

The first part of my first question is: given that I'm trying to operate a flat Class B network here, why has the "Create reverse zone for PTR record" option in the A Record details created a whole set of Zones? Obviously I've done something wrong here, but if I follow through what has happened, should I not expect to see a Primary [reverse lookup] Zone of "16.172.in-addr.arpa" and then, within that, a set of PTR records with the Name field set to e,g, "104.1", "103.1 and "1.1"?

The second part of my first question, closely related to the above is: how should I go about trying to tidy this up?

Second Question - Replication
I have a pair of Technitium Servers and for conventional name-to-IP resolution, the replication between them is working perfectly... I had a look to see if there are any special steps I should take in order to set up replication to a secondary server and I can't find anything in the documentation.
If this were simply a conventional "primary domain", then I would build a Secondary Server instance on my other Technitium host, go back to the Primary Server and add an NS record for the Secondary Server, then go to Zone Options and configure things so that the Primary would accept replication connections from the Secondary - and that would have things up and running just fine.

But there are no guidance notes for replicating a Reverse Lookup Zone anywhere... Does this mean that the same principles apply:-

1. Go to the second Technitium Host and add a "Secondary" zone using the same Zone name as all these newly-created "ip-addr.arpa" Zones that have appeared on my Primary...
2. Go to the Primary Host and add a Name Server (NS) record for the Secondary Server for each of these new Zones...
3. Edit the Zone Options on the Primary to accept replication requests for each of the new Zones from the Secondary Server
4. Go to the Secondary Server, navigate to each of these new Zones in turn and hit "Refresh" to initiate the transfer

If it helps... I think my biggest concern right know is the appearance of all the new "ip-addr.arpa" Zones on my Primary instance. It doesn't feel right and so I think I should probably try and sort that before I attempt replication.

But any advice on either of these questions would be very much appreciated.

Thanks in advance.

[ShreyasZare]

Thanks for asking.

given my network range I tried to manually add a Zone on my Primary DNS, using 0.0.16.172.in-addr.arpa

The zone name should have been 16.172.in-addr.arpa instead and the PTR records in there should have the rest of the two numbers in the name field.

When you use the option to add/update PTR record when adding/updating A/AAAA records, the DNS server will try to find out any existing reverse zone to add PTR records to. But since you had 0.0.16.172.in-addr.arpa zone instead of 16.172.in-addr.arpa, it did not match and thus the DNS server created a reverse zone for /24 subnet for the PTR records.

Second Question - Replication

The reverse zones are nothing special and work the same way. So, you have to configure secondary zones for them the exact same way. I would recommend that you setup Catalog zone so that you can easily provision secondary zones by just adding the primary zone as the member of catalog zone. You can read more about it in this blog post.

[sproggit]

Thanks so much, Shreyas, for taking the time to reply.
It's easy enough for me to remove the 5 reverse-lookup zones that I accidentally created yesterday, then start over.

Thanks also for the tip and link to Catalog Zones... This is not something I had encountered before your mention of the feature here, so before I make any more attempts I will read that carefully. I'm fortunate in that because my needs are relatively minimal - a SOHO network basically... I have a "Production" environment and a "Test" environment [I am using Raspberry Pi's for most of my infrastructure resources and these are cheap enough for me to buy extra to have a test setup] so I should be able to test that in isolation without breaking the Production environment...

Just one clarification question on your comments. You wrote, "The zone name should have been 16.172.in-addr.arpa instead and the PTR records in there should have the rest of the two numbers in the name field."

Last night I was reading some documentation on this on the CloudFlare web site and if I understood that correctly, even though when I set the Domain Name for reverse lookup it would begin "16.172", [which is reversed], when I come to create the Name field for the PTR records in that Zone, the numbers should be "the right way round".
So in other words my Production pair of Technitium Servers are "Tom" and "Jerry" ... and Tom's IP address is 172.16.100.1, I would have the Zone name you suggest above, but the PTR record for Tom would be "100.1" and NOT "1.100". I am only reversing the Network Address, not the Host Address. At least, that is what I understood from what I read last night...

[ShreyasZare]

So in other words my Production pair of Technitium Servers are "Tom" and "Jerry" ... and Tom's IP address is 172.16.100.1, I would have the Zone name you suggest above, but the PTR record for Tom would be "100.1" and NOT "1.100". I am only reversing the Network Address, not the Host Address. At least, that is what I understood from what I read last night...

For a host 172.16.100.1, the zone here would be 16.172.in-addr.arpa (since you want a /16 zone) and the record name would be 1.100. This is since the reverse lookup will use the domain name 1.100.16.172.in-addr.arpa to query for the PTR record.

[sproggit]

Thank you!

[ShreyasZare]

You're welcome!