Reverse DNS

dns

#1

It would be very useful if CF supported Reverse DNS hosting capability.

Basic support of the ip6.arpa and and in-addr.arpa. namespaces would mean I do not need an alternative DNS provider to just host reverse DNS. You would likely cause a significant increase in DNSSEC deployment on reverse DNS if you hosted reverse DNS zones.

As an added feature, linking forward and reverse DNS would mean that when I create a forward entry for origin.example.com, you could populate the linked reverse entry automatically (similar to how Windows DNS servers can work).

Obviously most of the UX would be meaningless for reverse DNS zones, and would be greyed out.


#2

That’s a great callout @michael Today the only use case where we support this is with our DNS Firewall product (formerly called Virtual DNS). It’s a topic I’ve brought up with our DNS product manager a couple of times and like the idea of linking the entires. I’ll pass that along to the PM for consideration.

:orange:


#3

I was going to post a thread about this until I saw this one, so I’ll reply.

I have my own /48 IPv6 range from my colocation provider which they will not host the reverse DNS for.
My range, my responsibility for the reverse zone, is their reasoning.

Currently I only run a DNS server for my reverse DNS, I would love to host it at Cloudflare.


#4

Is there an update for this use case?


#5

With the announcement on 6th August 2018, this is now supported.

The UI still lets you configure lots of things that have no meaning in in-addr.arpa and ip6.arpa zones, but you can quickly and easily set up DNSSEC on reverse zones!


#6

That’s nice, but for this to be actually useful to address the needs of LIRs this would require some kind of on-the-fly creation of responses when there is no actual record in the db, in the reverse zone as PTR and in the forward zone as A record, based on configurable rules.

For example, if my RIR would assign me a tiny IPv6 prefix, let’s say 2001:5000::/32, it is stupid and really impossible to try to create all the records in DNS, instead fallback rules would have to trigger generating the response on the fly.


#7

Is it? I’m not able to add my .in-addr.arpa zone. Getting the message:

Please ensure you are providing the root domain and not any subdomains (e.g., example.com, not subdomain.example.com) (Code: 1116)

@cscharff do you support adding arpa zones now?


#8

We do. At the moment that support is limited to just enterprise customers and requires action by their account team to validate and get it configured. I’m not sure what plans we have to open it to other plan types/ customers but given our past history of making things broadly available I imagine it’s possible we will do so.


#9

I was able to add reverse zones to my free account that I use for testing stuff on. I migrated add all my reverse v4 and v6 DNS to my Enterprise account without contacting support. The trick was using 2.0.192.in-addr.arpa. instead of 2.0.192.in-addr.arpa (note the trailing ‘.’).


#10

I think the verification still requires account team intervention but last I talked to that team they were working on that. It could be they’ve solved it… no one tells me anything. :smiley: