Score:2

What is the proper formatting for a classless reverse DNS zone (RFC2317)?

in flag

Good Day,

I'm looking for some help in setting up my zone record correctly for a delegated in-addr.arpa zone (classless reverse DNS) (*names and IPs have been changed).

I have the following net-block assigned to my service, 71.26.226.88/29 and I've asked Comcast to please delegate the Reverse DNS so I can manage the PTR records. To the best of my knowledge Comcast has properly setup their side (the CNAMEs for each entry)

Now, all I have to figure out is how to get my side (BIND9) configured correctly. You can see from the dig output, something is really wrong since I keep seeing server fail messages. The DNS server is 192.168.15.10 internally, and externally is 71.26.226.90.

**I edited this post to change the domain names and IP address to their real values. It was pointed out to me that I did a poor job obfuscating these details and DNS / IP addresses are all public so it's silly to obfuscate the details.

Here is what I have:

---------------------------------------------
$ORIGIN 88/29.226.26.71.in-addr.arpa.
$TTL 86400
88/29.226.26.71.in-addr.arpa. IN SOA ns.nfvlab.net. admin.nfvlab.net. (
    2023041115
    43200
    180
    1209600
    10800
)
@               IN      NS      ns.nfvlab.net.
89      3600    IN      PTR     gateway.nfvlab.net.
90      3600    IN      PTR     mail.nfvlab.net.
91      3600    IN      PTR     91.nfvlab.net.
92      3600    IN      PTR     92.nfvlab.net.
93      3600    IN      PTR     93.nfvlab.net.
94      3600    IN      PTR     94.nfvlab.net.
---------------------------------------------
named.conf
---------------------------------------------

zone "88/29.226.26.71.in-addr.arpa" {
    type slave;
    file "/etc/zone/master/88-29.226.26.71.in-addr.arpa";
    allow-transfer {none;};
    allow-query {any;};
    masters  {
             71.26.226.90;
    };
};

---------------------------------------------
helix@Studio ~ % dig @192.168.15.10 88/29.226.26.71.in-addr.arpa PTR
---------------------------------------------

; <<>> DiG 9.10.6 <<>> @192.168.15.10 88/29.226.26.71.in-addr.arpa PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36740
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 16 61 74 20 64 65 6c 65 67 61 74 69 6f 6e 20 38 38 2f 32 39 2e 32 32 36 2e 32 36 2e 37 31 2e 69 6e 2d 61 64 64 72 2e 61 72 70 61 2e ("..at delegation 88/29.226.26.71.in-addr.arpa.")
; OPT=15: 00 17 37 31 2e 32 36 2e 32 32 36 2e 39 30 3a 35 33 20 72 63 6f 64 65 3d 53 45 52 56 46 41 49 4c 20 66 6f 72 20 38 38 2f 32 39 2e 32 32 36 2e 32 36 2e 37 31 2e 69 6e 2d 61 64 64 72 2e 61 72 70 61 20 50 54 52 ("..71.26.226.90:53 rcode=SERVFAIL for 88/29.226.26.71.in-addr.arpa PTR")
;; QUESTION SECTION:
;88/29.226.26.71.in-addr.arpa.  IN  PTR

;; Query time: 194 msec
;; SERVER: 192.168.15.10#53(192.168.15.10)
;; WHEN: Wed Apr 12 13:48:56 EDT 2023
;; MSG SIZE  rcvd: 179

---------------------------------------------

If I send a query from outside like this:

ubuntu@ip-172-37-76-122:~$ host 71.26.226.90
Host 90.226.26.71.in-addr.arpa not found: 2(SERVFAIL)

And this is the output on the Server from tcpdump while doing a query.

14:22:26.293797 IP ec2-3-228-170-37.compute-1.amazonaws.com.26341 > 192.168.15.10.domain: 54423% [1au] PTR? 89.88/29.226.26.71.in-addr.arpa. (60)
14:22:26.293861 IP 192.168.15.10.domain > ec2-3-228-170-37.compute-1.amazonaws.com.26341: 54423 ServFail 0/0/1 (60)

This is what Comcast gave me in terms of instructions:

Instruct customer to create zone (88/29.226.26.71.in-addr.arpa.) with following DNS records (template)
@ IN SOA ns.domain.net. hostmaster.nfvlab.net. 2023041101 7200 3600 604800 3600
88/29       IN      NS      ns.nfvlab.net.
89  3600    IN      PTR     89-nfvlab.net.
90  3600    IN      PTR     90-nfvlab.net.
91  3600    IN      PTR     91-nfvlab.net.
92  3600    IN      PTR     92-nfvlab.net.
93  3600    IN      PTR     93-nfvlab.net.
94  3600    IN      PTR     94-nfvlab.net.

Any help or pointers (ha ha punny) would be greatly appreciated

djdomi avatar
za flag
you need the owner of the ip to ask, if he can add the PTR
Scott Vandiver avatar
in flag
Comcast is the owner and they have delegated the /29 block to my DNS for PTR (reverse DNS)
Patrick Mevzek avatar
cn flag
Are you aware that IPv4 addresses are 4 bytes? As such, `446` can NOT be in an IPv4 address. It is worthless to assess your question after you did such bad obfuscation. Give the real names and addresses if you want real help or ask your DNS provider to help you. DNS is public, obfuscation is pointless and counter productive. Also use `dig` to troubleshoot and look at `-x` and `+trace` options. Look at RFC 2317 to understand classless in-addr.arpa delegations.
djdomi avatar
za flag
if you want to manage the PTR, bind deliver already known example in /etc/bind or named depends on the distribution. but Comcast is known for me only for home and end-user connection?
Scott Vandiver avatar
in flag
Yes you got me on the obfuscation I should not have used an IP address at 446, that was my bad. I'm not sure how that creates a problem to review the question.
Scott Vandiver avatar
in flag
It was pointed out to me (above) that I used a poor scheme for obfuscating the IP address. I have gone back and changed these to the original values and set the Domain names to their correct values. I just want to say to Patrick Mevzek, thank you for pointing out the stupid error I made when I attempted to obfuscate the IP address. Boy that was really stupid to change the .226 to a .446. Really appreciate you pointing out how stupid that was. You say I should use Dig, but it's clear in my post that I am using dig for troubleshooting, but thank you for that suggestion.
Score:2
in flag

Thank you for including your actual IP-addresses and domains.

I've asked Comcast to please delegate the Reverse DNS so I can manage the PTR records. To the best of my knowledge Comcast has properly setup their side (the CNAMEs for each entry)

To be honest, I am be surprised if any ISP would actually offer that, even for (small) business customers. I get the impression when ISP's provide support for setting up custom PTR records at all, they typically will do so by setting the desired PTR records in their own zone, rather than via RFC 2317 IN-ADDR.ARPA delegation.
That allows them to do some due diligence and ensure that the desired hostname for the PTR record also exists as a forward record that points to correct the IP-address for example.

But apparently Comcast is the exception.

dig +trace -x 71.26.226.90

...

90.226.26.71.in-addr.arpa. 3600 IN  CNAME   90.88/29.226.26.71.in-addr.arpa.
88/29.226.26.71.in-addr.arpa. 7200 IN   NS  ns.nfvlab.net.

They have delegated the reverse DNS records for 71.26.226.89-94 to your nameserver.


Additionally there is the issue that your Bind is not configured correctly and responds with an SERVFAIL error.

The reason for that would appear in here in your named.conf:

zone "88/29.226.26.71.in-addr.arpa" {
    type slave;
    file "/etc/zone/master/88-29.226.26.71.in-addr.arpa";
    allow-transfer {none;};
    allow-query {any;};
    masters  {
             71.26.226.90;
    };
};

I would expect that your server is actually the master, not a slave.

Assuming that /etc/zone/master/88-29.226.26.71.in-addr.arpa contains the zone data that should probably be something more like:

zone "88/29.226.26.71.in-addr.arpa" {
    type master;
    file "/etc/zone/master/88-29.226.26.71.in-addr.arpa";  
};

The zone file "/etc/zone/master/88-29.226.26.71.in-addr.arpa" should then indeed look something like:

$ORIGIN 88/29.226.26.71.in-addr.arpa.
$TTL 86400
88/29.226.26.71.in-addr.arpa. IN SOA ns.nfvlab.net. admin.nfvlab.net. (
    2023041115
    43200
    180
    1209600
    10800
)
@               IN      NS      ns.nfvlab.net.
89      3600    IN      PTR     gateway.nfvlab.net.
90      3600    IN      PTR     mail.nfvlab.net.
91      3600    IN      PTR     host-91.nfvlab.net.
92      3600    IN      PTR     host-92.nfvlab.net.
93      3600    IN      PTR     host-93.nfvlab.net.
94      3600    IN      PTR     host-94.nfvlab.net.

and to see if your server responds correctly to a reverse lookup for your IP-address 71.26.226.90 you should then test with the CNAME Comcast will be setting up for you and use
dig @71.26.226.90 90.88/29.226.26.71.in-addr.arpa. PTR

Scott Vandiver avatar
in flag
Thank You to HBruijn, I really appreciate the response...
Scott Vandiver avatar
in flag
This is what Comcast just sent me that they have on their side: 88/29.226.26.71.in-addr.arpa. NS. ns.nfvlab.net 89.226.26.71.in-addr.arpa. 3600 CNAME 89.88/29.226.26.71.in-addr.arpa. 90.226.26.71.in-addr.arpa. 3600 CNAME 90.88/29.226.26.71.in-addr.arpa. 91.226.26.71.in-addr.arpa. 3600 CNAME 91.88/29.226.26.71.in-addr.arpa. 92.226.26.71.in-addr.arpa. 3600 CNAME 92.88/29.226.26.71.in-addr.arpa.
Scott Vandiver avatar
in flag
93.226.26.71.in-addr.arpa. 3600 CNAME 93.88/29.226.26.71.in-addr.arpa. 94.226.26.71.in-addr.arpa. 3600 CNAME 94.88/29.226.26.71.in-addr.arpa.
Scott Vandiver avatar
in flag
Wow that formatting didn't stay at all... I tried to format my comment properly to show what Comcast has sent me to say what they have setup on their side. They state the entire setup is automated and they do this not often but somewhat regularly.
Scott Vandiver avatar
in flag
One other issue I just noticed, the dig that was performed by HBruijn was on the he wrong IP dig -x 71.226.26.90 instead of :dig -x 71.26.226.90, this is probably why the incorrect response came back from Comcast's name servers.
HBruijn avatar
in flag
Indeed; comments don't allow for much formatting :) - But with your correct IP-address range it looks like the the RFC 2317 IN-ADDR.ARPA delegation has been set up correctly by Comcast - I'll edit my question to reflect that.
Scott Vandiver avatar
in flag
I have tried moving my DNS to AWS (Route53) to see if I could build the zones there and get it working then replicate that success. However, it's still showing the same status: SERVFAIL. Nothing I've tried so far has had any impact on the server not answering that final PTR request.
I sit in a Tesla and translated this thread with Ai:

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.