Feature Idea: Directly create PTR records from IPAM IP addresses

[ObjectiveWriter]

Versions

NetBox Version: NetBox Community v4.1.7
NetBox DNS Version: 1.1.6
Python Version: 3.12.5

Unclear Documentation on how to configure reverse zones.

After following the documentation, it is unclear how to correctly configure a reverse zone within the plugin. FQDN/DNS Names from IPAM Records do not get converted to reverse zone entries when running rebuild_dnssync.

To Reproduce

1. Setup Netbox
2. Add a prefix (ie: 10.0.0.0/22) set as reserved
3. Add a child-prefix (ie: 10.0.0.0/24) set as active
4. Add a child-child-prefix (ie: 10.0.0.0/29) set as active.
5. Add an IPv4 Address 10.0.0.1 within the /29.
6. Add a DNS/Hostname in the IP-Address edit section. (ie: testrouter.example.com)
7. Install the netbox dns plugin
8. edit the prefix 10.0.0.0/24 add it to the default view.
9. create a nameservers (ns1.example.com / ns2.example.com)
10. create a reverse zone for the the child-prefix ie: 0.0.10.in-addr.arpa as part of the default view.
11. run rebuild_dnssync
12. check reverse zone: no entry
13. debug step 1: edit ip-address manually change hostname to testrouter99.example.com
14. check reverse zone: no entry
15. run rebuild_dnssync
16. check reverse zone: no entry

Expected result

Reading the instructions suggests that rebuild_dnssync fetches the fqdn/hostname from the ip-address entry in netbox. then creates an entry in the reverse zone. This does not appear to be the case.

Actual result

Nothing happens.

Updating DNS records for IP Address 10.10.10.1/24, VRF None
  Zones: []

additional notes

Adding the "optional fields" as suggested in the docs does not improve this.

[peteeckel]

@ObjectiveWriter thanks for raising this.

The IPAM DNSsync feature does not directly create PTR records at all, it creates address (A/AAAA) records in forward zones. If a matching reverse zone is found, the PTR records are generated accordingly.

I will update the documentation to clarify that.

[peteeckel]

In your example you'll just need to add the zone example.com in the default view.

[ObjectiveWriter]

This would be "unexpected" behavior. Because this means it cannot be used to automate reverse zone creation, if we do not also at the same time carry a forward zone.

Meaning:

A tenant gets a reverse dns/fqdn entry for an ip-address associated with their service. The corresponding "forward" entry is in their own external DNS zone. (not mapped in netbox) as the netbox operator has no control over the zone. (Or any small to medium sized DC, would have 100's of "client zones" they have no control over.)

In this case (wich i suspect will be quite common) it becomes impossible to use the dns plugin to manage PTR records.

Solution:

• Create A record in Forward zone if FQDN Exists
• Create PTR in Reverse zone if FQDN Exists

Instead of going only create a PTR if there is a matching A.

On Update

• Update Forward Zone (if exists)
• Update Reverse Zone (if exists)

[peteeckel]

It is not unexpected as it is documented exactly that way.

I see your use case, and I think it would be a possible addition to enable direct PTR creation from IPAM DNSsync, but it's just not the way it's implemented today. I fully agree that it's possible and that it makes sense, but it's definitely not a bug but an FR.

[peteeckel]

By the way, doing this is by no means trivial ... there are several situations that need to be considered:

• A new forward zone gets created that matches the DNS name of an IPAM IP address
• The reverse zone gets renamed and no longer matches the IPAM IP address
• The reverse zone gets renamed and still matches the IPAM IP address, but with a longer/shorter prefix
• A new reverse zone with a longer prefix is created and part of the PTR records need to migrate to it (and vice verse when it's deleted)
• etc.pp.

All these cases need to be handled correctly (they are with forward zones in the play, but all of this functionality would need to be recreated for "pure" reverse zones, and tests need to be written for all these cases. So my estimate for the effort of implementing this is between two and four weeks. Of course, PRs are welcome :-)

The documentation update will close this issue, but as it's an interesting point I will convert it to a discussion so we can collect some other users' opinions and ideas as well.

[ObjectiveWriter]

Amazing! If you ever find yourself near Vienna let me know....I'll buy you a beer.

I currently dont really see how the implementation would differ for "pure" reverse zones compared to ones that just get orchestrated if there is a forward zone matching. Its arguably the same logic as before, just the event gets triggered directly instead of after another event has occurred.

But maybe i am misunderstanding the logic here.

[peteeckel]

Amazing! If you ever find yourself near Vienna let me know....I'll buy you a beer.

Are you planning to visit FOSDEM 2025? I'll be there :-)

[ObjectiveWriter]

Sadly no. Other projects getting in the way.

[peteeckel]

By the way, as a workaround you can create the required forward zones and define an active custom state for them so they don't get rolled out automatically.

[ObjectiveWriter]

That's "just" a few hundred zones. I think i will hold off on this for the moment.