5

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?

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
rgb255_255_255
  • 317
  • 1
  • 6

2 Answers2

6

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.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • 1
    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` – Barmar Oct 30 '21 at 18:20
  • @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. – joeqwerty Oct 30 '21 at 18:39
  • `** server can't find 4.2.0.192.in-addr.arpa: NXDOMAIN` – Barmar Oct 30 '21 at 18:47
  • It looks like this address block isn't delegated. – Barmar Oct 30 '21 at 18:47
  • 1
    That's a sample ip address for use in documentation. Use your ip address. - https://datatracker.ietf.org/doc/html/rfc5737 – joeqwerty Oct 30 '21 at 19:02
2

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.)

Pranav Sharma
  • 136
  • 4
  • 2
    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. – rgb255_255_255 Oct 30 '21 at 05:17