[dns-operations] cloudflare-dns.com doesn't have reverse DNS

[Fred Morris]

(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
m3047 at m3047.net | consulting at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230920/3f0eddd3/attachment.html>