consolidating in-addr.arpa data
Fred Morris
m3047 at m3047.net
Sat Sep 16 00:47:26 UTC 2023
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
More information about the bind-users
mailing list