Reverse lookups not working when Internet connection failed.
Grant Taylor
gtaylor at tnetconsulting.net
Sat Nov 5 00:43:14 UTC 2022
On 11/4/22 12:09 PM, Cuttler, Brian R (HEALTH) via bind-users wrote:
> My pointer zones are more like
>
> Zone "28.66.136.193.in-addr.arpa.", I've never had that leading "0-"
>
> Is that typical? What does it do?
I invite you to go skim RFC 2317 -- Classless IN-ADDR.ARPA Delegation.
TL;DR: 2317 is a way to delegate /part/ /of/ a single class of IPs.
N.B. "class" is akin to the dot boundary in dotted quad IPv4.
This is important because DNS (sub)domains are delegated on the dot
boundary.
The idea is to turn 1.2.0.192.in-addr.arpa., which normally has the PTR
record, into a CNAME to an RNAME that is in a /different/ /domain/.
This is done explicitly so that the /different/ /domain/ can be
delegated to someone so that they can manage their own reverse DNS PTR
records. E.g.:
$ORIGIN 2.0.192.in-addr.arpa.
;...
; 0-3 are directly in the 2.0.192.in-addr.arpa. zone file.
0 IN PTR test0.example.net.
1 IN PTR test1.example.net.
2 IN PTR test2.example.net.
3 IN PTR test3.example.net.
; 4-7 are aliased to records in the 4-30.2.0.192.in-addr.arpa. zone.
4 IN CNAME 4.4-30.2.0.192.in-addr.arpa.
5 IN CNAME 5.4-30.2.0.192.in-addr.arpa.
6 IN CNAME 6.4-30.2.0.192.in-addr.arpa.
7 IN CNAME 7.4-30.2.0.192.in-addr.arpa.
; 8-15 are aliased to records in the 8-29.2.0.192.in-addr.arpa. zone.
8 IN CNAME 8.8-29.2.0.192.in-addr.arpa.
9 IN CNAME 9.8-29.2.0.192.in-addr.arpa.
...
14 IN CNAME 14.8-29.2.0.192.in-addr.arpa.
15 IN CNAME 15.8-29.2.0.192.in-addr.arpa.
; delegate the 4-30.2.0.192.in-addr.arpa. zone to Customer1.
4-30 IN NS ns1.customer1.example.
IN NS ns2.customer1.example.
; delegate the 8-29.2.0.192.in-addr.arpa. zone to Customer2.
8-29 IN NS nsA.customer2.example.
IN NS nsB.customer2.example.
Notice how the PTR records for 0-3 are found directly in the
2.0.192.in-addr.arpa. zone.
Notice how the PTR records for 4-7 and 8-15 are aliased to records in a
sub-domain.
Notice how the 4-30 and 8-29 sub-domains of the 2.0.192.in-addr.arpa.
zone are delegated to different entities.
RFC 2317 delegates (NS records for (sub)domain) control over the PTR
records to other DNS administrators via CNAME records in the parent zone.
N.B. the 0-28 in the OP's examples and my 4-30 & 8-29, are using the RFC
2317 /convention/ of delegating to the <network>-<netmask length> as the
sub-domain to use. -- I maintain that this is a convention and is not
required. -- RNAME records could just as easily have been delegated to
16.example.com and the example.com zone could have had the following record:
16 IN PTR test0x10.example.com
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221104/d916a554/attachment.bin>
More information about the bind-users
mailing list