I looked at your project. I starred it. :-) With no intended irony, I say
that your project appears much more ambitious than mine: I base that on
the work you put into "fixing", for lack of a better word, the DNS
(walking delegations, etc.).
On Mon, 14 Feb 2022, Mark Delany wrote:
https://github.com/m3047/rear_view_rpz
I do not completely understand what's going on here, but it *looks* like you're
populating
the local cache with reverse entries for remote addresses and that those
reverse entries
are synthesized from A/AAAA queries discovered via dnstap.
Yes, practically speaking. Technically I am populating a zone, however
technically this zone is not a properly delegated reverse lookup zone but
intended to be utilized as an RPZ... but not as a "ban hammer", but rather
as a source of information.
[...]
Interesting but quite a different problem from the one I'm trying to solve
which is to
make it trivially easy to auto-serve reverse answers and automagically satisfy
reverse,
forward, reverse comparisons for your own networks.
[...own networks] as seen by others.
I think our (more or less) declared project objectives make it clear the
problems we're trying to solve:
* meeting the requirements of many remote services which insist on
matching forward and reverse names
versus
* PTR responses enhanced with local knowledge
There are a gamut of opinions about reverse DNS PTR records, and probably
just as many opinions about how we should reclaim it and why. I certainly
see Conway's organizational principles in play in the role of PTR records
as a shear layer.
They're full (the DNS is full) of patterns and antipatterns. One fractal
rabbit hole example: [0]
My myth of the origin of PTR records is that "in the beginning.." there
was felt to be a need for the operators of systems tribe as opposed to the
administrators of systems to tell us things about those systems, but that
the administrators found that it was a Good Thing and it's been this way
ever since. [1]
PTR records have always been a way to answer questions for somebody,
although I dare say if you wildcarded an entire block of addresses as
PTR mail.example.com no spam filter would notice.
It's no longer IMO primarily useful for the system operators... as in the
operators of those systems. As the operator of a communicating system I
feel like I'm next in line to decide what's useful to me. The toolmakers
agree with me: traceroute, arp, iptables all default to doing reverse
lookups (-n to turn it off): people desperately, subconscously, with the
fibre and satellites of their being, want it to be so, to be useful.
No moral to the story, just that there's a story to PTR records.
--
Fred Morris
--
[0] The DNS protocol allows multiple rvalues per type per oname. This
works ok for e.g. A/AAAA, is disallowed for CNAME, and is... I'm not sure
what it is for PTR records. If an app is using hostnames in ACLs, it means
you need to list them all. (Rabbit hole: the app could query the name and
use the address for access control, or it could do a reverse lookup of the
address and compare it to the name, which do you choose?) In fact, this is
just a bad idea and nobody on the Internet would do it without DNSSEC
(right?), but other (better? more YOLO?) directory services implicitly
trust names and system administrators invariably (in the Rilke sense)
"fail right" to the Internet and guess what happens? Jasbug.
[1] At this point it has been codified by the administrative tribe in the
"security by obscurity" principle that reverse lookups shouldn't reveal
useful information... possibly the original sin of (Kelly Shortridge's)
DevSecObs?
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
