[dns-operations] You live in a dump, Quoyle!

[Fred Morris]

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?