consolidating in-addr.arpa data

[Fred Morris]

You can't resolve differences in both directions automatically without 
inevitable conflicts, similar to merging code changes. That said, RPZ for 
fun and profit...

On Fri, 15 Sep 2023, John Thurston wrote:
> A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and PTR 
> in whatever.10.in-addr.arpa. MS DNS is happy to publish those.
>
> But the DNS system running on BIND also has a whatever.10.in-addr.arpa zone.
>
> So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query both 
> DNS systems in turn. If I get NXDOMAIN from both, then I can say the PTR 
> doesn't exist.
>
> On each system, I'd like to be able to take the 10.in-addr.arpa data from the 
> other, compute the differences, and incorporate them locally. Then I'll be 
> able to query either system, and accept an NXDOMAIN with confidence.

Something in an RPZ will take precedence over what's in the delegated 
zone. RPZs are zones like any other zone and can be AXFR / IXFRed.

The choice of MS DNS taking precendence might be the obvious choice, but 
the namespace in the RPZ won't be the same (e.g. 
1.0.0.10.in-addr.arpa.rpz.example.com): it won't be "naked". So that won't 
work off the shelf (I know of no option to automagically rewrite the 
delegating zone).

However, if you made BIND a secondary for the MS DNS PTR zone then it 
should serve it; and you could put BIND-specific edits in an RPZ. Then the 
BIND-specific values would take precedence over what's in the MS DNS zone, 
at least as seen when BIND is queried.

Rear View RPZ (https://github.com/m3047/rear_view_rpz/) watches (BIND) 
Dnstap telemetry for A/AAAA queries and uses it to update PTR records in 
an RPZ, as an example.

--

Fred Morris