Reverse lookups not working when Internet connection failed.

[Grant Taylor]

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>