Score:5

How to confirm who is responsible for serving reverse DNS (PTR) requests an IP block?

gb flag

Before anyone answers "ask your ISP" or "ask your hosting provider", please read in full.

Scenario:

  • I own a domain name mydomain.example, and a publically routed IP block (say 192.0.2.0/28)
  • The NS records (GLUE) for this domain are configured at my registrar - ns1.mydomain.example and ns2.mydomain.example which point to my servers (self-hosted DNS servers)
  • Reverse DNS for my publically routed IP block are served by the same servers This is so I can update the reverse dns entries for my IPs at my leisure on my equipment.

Problem: I went to migrate DNS hosting for my domain (mydomain.example) from my own servers to cloudflare, deciding it isn't worth the hassle to DIY-host it. I have done this several times before with identical setups and experienced no ill effects.

However, when the NS records updated to cloudflare's, I found my reverse DNS completely stopped working.

Question: What / who determines who is answering the queries for the reverse DNS for my IP block? It was my understanding that typically, forward DNS and reverse DNS are done independently of each other so I wasn't expecting the migration of the forward lookup name servers from the self-hosted infrastructure -> cloudflare to torch reverse DNS lookup.

It was my understanding that the entity that answers your forward dns (cloudflare) is independent of the one answering your reverse DNS (e.g. your hosting provider, ISP etc). But, how can I confirm who is really responsible for this - like I would for my forward DNS? I can do a % dig +short mydomain.example NS to confirm which servers are responsible for forward DNS queries, what is the procedure to figure out who is responsible for the reverse DNS of an IP address(es) that I am using?

Score:6
cv flag

If your ip address were 192.0.2.4 and you were using nslookup you'd run the following:

set q=ns

4.2.0.192.in-addr.arpa

This would show you the name servers responsible for the ip address block in which your ip address exists.

mx flag
NS records don't generally exist for individual IPs. It should be just `2.0.192.in-addr.arpa`. Or use `dig +trace -x 192.0.2.4`
joeqwerty avatar
cv flag
@Barmar Have you used nslookup in the manner I described? If not, give it a try. Use "set debug" to see the detailed information for the query.
mx flag
`** server can't find 4.2.0.192.in-addr.arpa: NXDOMAIN`
mx flag
It looks like this address block isn't delegated.
joeqwerty avatar
cv flag
That's a sample ip address for use in documentation. Use your ip address. - https://datatracker.ietf.org/doc/html/rfc5737
Score:2
jp flag

Solution to your issue:

In this case, I don't think the issue is with your PTR records, but rather with the way Cloudflare's Reverse Proxy system works. If your domain is using Cloudflare's proxy, then it's not actually pointing at your server anymore.

The solution is to turn off Cloudflare's proxying for the domains/subdomains where mail servers are located.

Answer to your question:

The DNS and rDNS queries do occur separately, but the DNS query occurs first in order to determine which IP to query for rDNS/PTR. In this instance, Cloudflare is essentially replacing your IP in the DNS response with their own, which is what's causing the issue.

For example, if you have mydomain.example, and your Cloudflare DNS settings are an A record pointing to 192.0.2.1 with Proxy enabled, then the domain is actually pointing to Cloudflare's servers, which are then forwarding traffic to yours. However, this means that the PTR lookup is going to query Cloudflare's servers rather than yours, which will report no record present:

❯ dig proxied.mydomain.example # Remote mail server queries a proxied domain's A record.
;; QUESTION SECTION:
;proxied.mydomain.example.          IN  A
;; ANSWER SECTION:
proxied.mydomain.example.       300 IN  A   104.21.30.252  # Cloudflare Server
proxied.mydomain.example.       300 IN  A   172.67.174.61  # Cloudflare Server
❯ dig -x 104.21.30.252 # Remote mail server checks PTR/rDNS of both IPs (This is from a real Cloudflare IP)
;; QUESTION SECTION:
;252.30.21.104.in-addr.arpa.    IN  PTR
;; AUTHORITY SECTION:
21.104.in-addr.arpa.    3600    IN  SOA cruz.ns.cloudflare.com. dns.cloudflare.com. 2034580120 10000 2400 604800 3600 
# Server returns no PTR record, because it's Cloudflare's server being queried.

If you disable Cloudflare's proxying for the mail server DNS record, it looks more like this:

❯ dig unproxied.mydomain.example # Remote mail server queries a non-proxied domain's A record.
;; QUESTION SECTION:
;unproxied.mydomain.example.            IN  A
;; ANSWER SECTION:
unproxied.mydomain.example.     300 IN  A   192.0.2.1 # DNS server returns your server's IP.
❯ dig -x 192.0.2.1 # Mail server queries YOUR server for PTR.
;; QUESTION SECTION:
;117.8.209.209.in-addr.arpa.    IN  PTR
;; ANSWER SECTION:
117.8.209.209.in-addr.arpa. 86400 IN    PTR unproxied.mydomain.example.
# PTR returns the correct value.

(Please note that I've skipped the MX/SPF/DKIM/DMARC lookups in this response, because as far as I'm aware Cloudflare doesn't mess with those unless you point your record to a proxied A/AAAA/CNAME record.)

rgb255_255_255 avatar
gb flag
Hey, thanks for the response but this is not my issue, because PTR record lookups are done on the IP itself, not the cloudflare proxy IP. Also, I am not using cloudflare proxying for anything, at this time I was only using it to host my DNS records.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.