Unbound reverse PTR records

[lsbbs]

When I create multiple A records for the same IP address like

name1.example.domain. A 123.123.123.123
name2.example.domain. A 123.123.123.123

For each name also a PTR record is created.

123.123.123.123.in-addr.arpa PTR name1.example.domain.
123.123.123.123.in-addr.arpa PTR name2.example.domain.

There should be only one reverse record for each IP.
A checkbox if a PTR record should be created would be fine solution for this.

OPNsense 21.7.7-amd64 with unbound 1.13.2

[OPNsense-bot]

Thank you for creating an issue.
Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

[Starkstromkonsument]

@lsbbs Is this a duplicate of #4420 ?

[lsbbs]

Yes, somehow.

[x390]

Would be nice to see ntopng show the correct address instead of some random alias.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[x390]

@fichtner Is this a intended function?

[maciekb]

I strongly support that it should be possible to manually indicate whether a PTR record should be generated for a given override record. The problem is quite trivial, but annoying. Many web services rely on reverse name recognition. The first example that comes to mind is Zenarmor (Sensei), which presents inconsistent data in its reports in the current situation. Multiple PTR records for the same IP address cause the name to be retrieved randomly, causing the reports to show several hosts as the source despite the data coming from a single IP address.
In addition, I noticed that Unbound in OPNsense generates just as many IN A records as both PTR records for the local network gateway IP address. This is a problem if we have vlans, for example, and are trying to access the router by name. If the resolver gets an IP address in response from a vlan address that we don't have access to from the source network, then access is obviously not possible.

[swhite2]

@maciekb While I agree that manual PTR records as a separate type would be ideal; scope, migration and impact all limit the viability of pushing this in the short term. For now I'm proposing #5925 in order to mitigate the issues discussed here. Let me know what you think.

[maciekb]

@swhite2 I understand that a more detailed control may require rebuilding more of the internal logic and adapting the user interface to it. It seems to me that the proposed restriction on the generation of PTR records is a reasonable solution for the moment.
Thank you very much for understanding the problem and offering a solution.