Reverse lookups not working when Internet connection failed.

[Grant Taylor]

On 11/4/22 10:07 AM, David Carvalho via bind-users wrote:
> My reverse zone file

What is the origin of your zone file?  0-28.66.136.193.in-addr.arpa.?

> 1.0-28.66.136.193.in-addr.arpa.         IN      A       193.136.66.1

You seem to be using RFC 2317 Classless IN-ADDR.ARPA delegation.

As such, your reverse DNS is /dependent/ upon the parent zone; 
66.136.193.in-addr.arpa., where the Classless IN-ADDR.ARPA delegation 
CNAME records exist.  E.g.

    1.66.136.193.in-addr.arpa.   IN   CNAME 
1.0-28.66.136.193.in-addr.arpa.

It is likely this -- almost certainly -- external dependency was missing 
while your Internet connections was down that prevented your systems 
from being able to resolve reverse DNS.

Two options come to mind:

1)  Create a bogus 66.136.193.in-addr.arpa. zone locally to host the 
2317 CNAMEs.  --  This will likely have some side effects that need to 
be mitigated.
2)  Leverage Response Policy Zone(s) to try to influence the lookup as 
others suggested.  E.g. cause 1.66.136.193.in-addr.arpa. to become 
1.0-28.66.136.193.in-addr.arpa. locally.  --  I'd have to read about how 
to do this.

Aside:  I see no need for 1.0-28.66.136.193.in-addr.arpa. to have an A 
record.  But I don't see any problem with having it either.

> 1.0-28.66.136.193.in-addr.arpa.         IN      A       193.136.66.1
> 
> ; Reverse mapping
> 
> 1       IN      PTR     dns.di.ubi.pt.
> ...

These are the types of PTR records that I would expect to see in a 
reverse DNS context.



-- 
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/ff89ef69/attachment.bin>