<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>(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...)<br>
    </p>
    <div class="moz-cite-prefix">On 9/19/23 8:15 PM, Viktor Dukhovni
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ZQpjzRDX5sGvP1ZV@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">On Tue, Sep 19, 2023 at 11:00:34PM +0100, Joe Abley wrote:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Perhaps "apart from mail", it largely is.</pre>
    </blockquote>
    It's an anachronism manufactured from neglect, failure of
    imagination, and the pervasive tendency to think locally and act
    locally.<br>
    <blockquote type="cite"
      cite="mid:ZQpjzRDX5sGvP1ZV@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">Often unhelpful, and
sometimes trending on harmful</pre>
    </blockquote>
    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.<br>
    <blockquote type="cite"
      cite="mid:ZQpjzRDX5sGvP1ZV@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap=""> [...]

The email ecosystem would benefit [...]</pre>
    </blockquote>
    <p>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.</p>
    <p>This goes far beyond email, but email is a historical application
      so it is of note that this parallel evolution has occurred.</p>
    <p>And yes traceroute, wireshark, and many other handy tools will do
      PTR lookups (oftentimes by default, unless you specify "-n").<br>
    </p>
    <blockquote type="cite"
      cite="mid:ZQpjzRDX5sGvP1ZV@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">Reverse IPs for routers do make debugging easier, not only for
strangers [...]</pre>
    </blockquote>
    <p>"...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?)</p>
    <p>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).</p>
    <p><br>
    </p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>I am open to being part of any conversation about making these
      mappings visible to strangers, because strangers is all of us.</p>
    <p>--</p>
    <p>Fred Morris<br>
      <a class="moz-txt-link-abbreviated" href="mailto:m3047@m3047.net">m3047@m3047.net</a> | <a class="moz-txt-link-abbreviated" href="mailto:consulting@m3047.net">consulting@m3047.net</a><br>
      <a class="moz-txt-link-freetext" href="https://github.com/m3047">https://github.com/m3047</a></p>
    <p>--</p>
    <p>[0]:<br>
    </p>
    <pre># dig <a class="moz-txt-link-abbreviated" href="http://www.infoblox.com">www.infoblox.com</a>
;; ->>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:
<a class="moz-txt-link-abbreviated" href="http://www.infoblox.com">www.infoblox.com</a>.       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     <a class="moz-txt-link-abbreviated" href="http://www.infoblox.com">www.infoblox.com</a>.

;; 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

</pre>
  </body>
</html>