(From what I can tell Joe sent his reply to me and cc'ed the list, and only his direct reply arrived here and it ended up mangled because I do infrastructure filtering. Not being certain how the threading works I was going to respond to my own original post but Victor's followon adds context, so here goes...)
On 9/19/23 8:15 PM, Viktor Dukhovni wrote: > On Tue, Sep 19, 2023 at 11:00:34PM +0100, Joe Abley wrote: > >> Apart from mail and some degree of debugging courtesy, what >> operational reasons exist to put effort into reverse DNS in 2023? Are >> there any? Or is the whole reverse tree just a weird anachronism? > Perhaps "apart from mail", it largely is. It's an anachronism manufactured from neglect, failure of imagination, and the pervasive tendency to think locally and act locally. > Often unhelpful, and > sometimes trending on harmful Yes; and given the trend in North America / Western Europe towards centralization (remarked upon here in the past) and the virtualization which accrues to it, perhaps unavoidable without some rethinking. It may also be more pronounced with IPv4 than 6, I haven't taken a deep dive on that. > [...] > > The email ecosystem would benefit [...] Here we see the beginnings of the undercurrent, where arguably the email ecosystem itself considers that it benefits from PTR records in some fashion. PTR records at least historically are maintained by different delegees than direct ICANN franchisees (by this I mean there's no money in delegating the domains) and so the deliberativeness of maintaining congruence between a PTR record and an MX record augurs some likelihood that the operator is not asleep at the switch; and the presence of PTR records for dynamically allocated addresses complicates the pragmatic but nominally off-label use of the congruence for this purpose. This goes far beyond email, but email is a historical application so it is of note that this parallel evolution has occurred. And yes traceroute, wireshark, and many other handy tools will do PTR lookups (oftentimes by default, unless you specify "-n"). > Reverse IPs for routers do make debugging easier, not only for > strangers [...] "...strangers": and that's a tell. Another tell is that CF's infra DNS servers all apparently have reverse DNS, but mozilla.cloudflare-dns.com doesn't. I've probably stared at this for far too long, but it reeks of security by obscurity (it might not even be CF who requested this anonymity). (I haven't done extensive research into mozilla.cloudflare-dns.com: does Mozilla really use the name, or the addresses it points to? I do know that *.cloudflare-dns.com isn't wildcarded for A records. I suppose this is the ask I didn't think of earlier: does anybody know?) Any entity which can crowdsource DNS traffic can build a passive DNS database which illuminates these relationships and so those organizations, their "friends", and anyone who can pay for it has access to the mappings. Who is harmed by lack of access is operators of small networks, and especially (what I'm passionate about) the defenders of those networks (who may want to evaluate not only their peers, but the reliability of the infrastructure those peers are hosted on). In fact though, if you're the operator of a small / industrial / medical facility network (and your external traffic is primarily directed at external servers, not the other way around) all it takes to synthesize relevant[0] PTR records is a little python and BIND (as a caching resolver) compiled with Dnstap. (I only support BIND in my free public offerings, but based on feedback I infer it works with Unbound as well.) I have a slide deck covering all of this. I've taken it a step further and utilizing Redis and DNS together I have what amounts to a federated / distributed SIEM and a menagerie of mostly command line tools for querying it. I have an irreverent white paper and a rough cut two minute video covering all of this. I am open to being part of any conversation about making these mappings visible to strangers, because strangers is all of us. -- Fred Morris m3...@m3047.net | consult...@m3047.net https://github.com/m3047 -- [0]: # dig www.infoblox.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23483 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;www.infoblox.com. IN A ;; ANSWER SECTION: www.infoblox.com. 3600 IN CNAME agcdn.pantheon.map.fastly.net. agcdn.pantheon.map.fastly.net. 30 IN A 146.75.118.253 # dig @10.0.0.220 -x 146.75.118.253 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18348 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;253.118.75.146.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 146.in-addr.arpa. 10770 IN SOA z.arin.net. dns-ops.arin.net. 2017036699 1800 900 691200 10800 # dig @10.0.0.230 -x 146.75.118.253 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45275 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: ;253.118.75.146.in-addr.arpa. IN PTR ;; ANSWER SECTION: 253.118.75.146.in-addr.arpa. 5 IN PTR www.infoblox.com. ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; ADDITIONAL SECTION: REARVIEW.M3047.NET. 1 IN SOA DEV.NULL. M3047.M3047.NET. 3309584 30 15 86400 600
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
