Rev DNS for ISP

Website, Application, Performance DNS & Network
1

What is the name of the domain?

abanet.org

What is the error number?

rev lookup fails

What is the error message?

NXDOMAIN

What is the issue you’re encountering

Our ISP pulls the rev dns records from us - we don’t own that IP range

What steps have you taken to resolve the issue?

We are switching DNS to Cloudflare and they do not allow us to configure and publish the rev-dns for IPs we do not own. The old method was CoreSite pulled the DNS rec from us and published them. going to ns1.abanet.org and getting the info from zone 228.99.38.in-addr.arpa .

What feature, service or problem is this related to?

DNS records

What are the steps to reproduce the issue?

Added NS as an A rec -csdns01.abanet.org - but when I run a query I get REFUSED. running the same nslookup against ns2chi.americanbar.org I get an answer ( both resolve to the same IP ).
The end goal is to enable our ISP to pull the re-dns from us, in the past we simply ( and still do ) host 228.99.38.in-addr.arpa on that server, going forward that is an option but I am open to other methods.

2

No, if you do not have control over the IP addresses, and thereby the arpa zone, then you cannot perform the validation to add the arpa zone directly to Cloudflare.

However, looking at your set up, this isn’t the way you’re doing it.

The method so far has been for the IP space holder to CNAME the arpa address to a destination address, in the format of {IP_ADDRESS}.abanet.org.

For an IP address, such as e.g. 38.99.228.183, the corresponding host in the arpa zone (e.g. 183.228.99.38.in-addr.arpa) has simply been CNAME’d towards 38.99.228.183.abanet.org.

This is known as “Classless IN-ADDR.ARPA delegation”, which has been outlined in RFC2317.

As a result of using the “Classless IN-ADDR.ARPA delegation”, and with that specific CNAME, you will now need to create the corresponding PTR record in Cloudflare, with the name “38.99.228.183”, or the FQDN “38.99.228.183.abanet.org”.

Both variants will end up with displaying the name “38.99.228.183” in the Dashboard.

PTR records exist in Cloudflare for some of your IP addresses with this set up, but not all of them.

Several of the ones that do have PTR records, are also having multiple PTR records, which isn’t recommended, such as e.g. 38.99.228.188, that have 5 different PTR records.

“Classless IN-ADDR.ARPA delegation” will use one DNS record per IP address, in Cloudflare, and depending on your Cloudflare plan, you may be quite limited in how many PTR records you’re able to set up this way.

That said, -

How exactly are you testing this?

And on which exact IP address(es) are you seeing these results?

3 Likes
3

DarkDeviL - tyvm for the reply - I will digest and confirm.
It appears that one ISP pulls from a rev zone, and one uses the PTRs .
I will test further and confirm.

testing with nslookup
dnsext07 # nslookup 192.34.22.144 1.1.1.1
144.22.34.192.in-addr.arpa canonical name = 144.128-159.22.34.192.in-addr.arpa.
144.128-159.22.34.192.in-addr.arpa name = ns2chi.americanbar.org.
144.128-159.22.34.192.in-addr.arpa name = smtpprod02.americanbar.org.
144.128-159.22.34.192.in-addr.arpa name = smtpprod02.abanet.org.
144.128-159.22.34.192.in-addr.arpa name = csdns01.abanet.org.

Authoritative answers can be found from:

dnsext07 # nslookup 38.99.228.188 1.1.1.1
188.228.99.38.in-addr.arpa canonical name = 38.99.228.188.abanet.org.
38.99.228.188.abanet.org name = dns02.abanet.org.
38.99.228.188.abanet.org name = dnsext07.abanet.org.
38.99.228.188.abanet.org name = noreply.abanet.org.
38.99.228.188.abanet.org name = smtp1.abanet.org.
38.99.228.188.abanet.org name = tt.abanet.org.

Authoritative answers can be found from:

dnsext07 #

4

Both of the two IP subnets you’re sharing, are using the before-mentioned “Classless IN-ADDR.ARPA delegation” way, to forward it’s queries to somewhere else.

However, they are doing it in two different ways:

The 192.34.22.128/27 (192.34.22.128 - 192.34.22.159) subnet is forwarding it’s queries, to another arpa host name below it’s own zone.

The way it is done on this specific subnet, the arpa host name can be set up in a completely different zone, that is not directly depending on the abanet.org zone.

Add zone name “128-159.22.34.192.in-addr.arpa” to Cloudflare.

Set up your PTR records for 192.34.22.144 in Cloudflare, with the name “144”, or the FQDN “144.128-159.22.34.192.in-addr.arpa”.

Ask your ISP for the 192.34.22.128/27 subnet, to re-delegate the 128-159.22.34.192.in-addr.arpa zone, to Cloudflare, by removing ns2chi.americanbar.org and ns3chi.americanbar.org, and adding the two Cloudflare name servers you’re being provided with, while adding that zone, instead.

This way, you can have the 192.34.22.128/27 subnet as a separate zone (“128-159.22.34.192.in-addr.arpa”) in Cloudflare, and will no longer be depending on your own two name servers, ns2chi.americanbar.org and ns3chi.americanbar.org any more, for this specific IP subnet.

As mentioned above, the way your ISP has set up 38.99.228.160/27 is slightly different than the other subnet.

Instead of CNAME’ing “183.228.99.38.in-addr.arpa” to another arpa host name below it’s own zone, such as e.g. to “183.160-192.228.99.38.in-addr.arpa”, which would have allowed you to create “160-192.228.99.38.in-addr.arpa” in Cloudflare, then the set up here has been done so you need to use your own Forward DNS (abanet.org), to create your PTR records in.

In it’s current set up, you cannot separate the 38.99.228.160/27 subnet, from your Forward DNS (abanet.org) zone.

Unlike 192.34.22.128/27, the 38.99.228.160/27 subnet is NOT depending on your own name servers in it’s current set up.

Personally, I would recommend getting the 38.99.228.160/27 subnet adjusted, so it would be set up in the same kind of way, as 192.34.22.128/27 is, which would also allow you to delegate it to Cloudflare, as a separate zone, that won’t be depending on the abanet.org zone.

Both set ups are valid set ups though.

4 Likes
5

DarkDeviL - thank you for the thorough explanation, setting up the zone a Cloudflare will make moving the main zone ( americanbar.org ) much easier - AND - when we get a new CoreSite block (192.34.128.x/27) we should be able to set up that zone ahead of time making the cutover easier.
I will try again to get ComCast (38.99.228.x/27) to do the same re-delegation.

2 Likes