2

I'm trying to configure reverse DNS for a sub Class C block. My ISP has delegated 128/25.2.0.192.in-addr.arpa.

I've spent a good few hours reading everything I can find on classless reverse map delegation, but I can't seem to get this working properly in test.

When running dig on the BIND box and requesting 129.128/25.2.0.192.in-addr.arpa, BIND seems to be reporting as authoritative for the 128/25.2.0.192.in-addr.arpa zone, but isn't replying with a PTR record for server1.example.com as I would expect. I'm sure I must be missing something but I seem to be blind to it.

Below, 2.0.192.rev is my zone file, named.conf the zone part of the BIND config and finally the output from dig.

I'd like to confirm that this is the correct approach, if I'm making a mistake, or if there's a better way to do this please?

---------------------------------------------------------------------
2.0.192.rev
---------------------------------------------------------------------
$TTL 4h
$ORIGIN 128/25.2.0.192.in-addr.arpa.
@               IN  SOA  ns1.example.com. hostmaster.example.com. (
                              1144449999 ; serial number
                              3h         ; refresh
                              15m        ; update retry
                              3w         ; expiry
                              3h      ; nx = nxdomain ttl
                              )
                IN  NS          ns1.example.com.
                IN  NS          ns2.example.com.


129             IN  PTR         server1.example.com.
130             IN  PTR         server2.example.com.

---------------------------------------------------------------------
named.conf
---------------------------------------------------------------------
zone "128/25.2.0.192.in-addr.arpa" {
        type master;
        file "2.0.192.rev";
};

---------------------------------------------------------------------
dig @localhost 129.128/25.2.0.192.in-addr.arpa
---------------------------------------------------------------------

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost 129.128/25.2.0.192.in-addr.arpa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38179
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;129.128/25.2.0.192.in-addr.arpa. IN        A

;; AUTHORITY SECTION:
128/25.2.0.192.in-addr.arpa. 10800 IN SOA   ns1.example.com. hostmaster.example.com. 1144449999 10800 900 1814400 10800

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jan 28 20:11:39 GMT 2016
;; MSG SIZE  rcvd: 128

1 Answer 1

4

It looks like you set things up right, but that the problem is with how you tried to test it.

;; QUESTION SECTION:
;129.128/25.2.0.192.in-addr.arpa. IN        A

Your query is for A, not PTR. Because of this you get a result saying that there is no such record (but not NXDOMAIN as the requested name does exist).

Ie, dig @localhost 129.128/25.2.0.192.in-addr.arpa PTR ought to work.


It's also worth noting that the exact naming of a zone for a RFC2317-style reverse delegation can vary as the zone name for the sub-/24 network is chosen at the discretion of the parent zone owner.
If your ISP specified 128/25.2.0.192.in-addr.arpa. that should obviously be the relevant name for you but in general it may be good to verify by querying the nameservers for the parent zone.

1
  • 1
    You sir are a legend. I had been querying the A record rather than the PTR. I've checked the format of the zone name with the ISP, and it does match. I've just not tried testing via their nameservers as my nameserver isn't operational yet. Querying using the correct dig option does work though so I now have the confidence to go live. Thank you!
    – leftcase
    Jan 28, 2016 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .