Reverse lookups not working when Internet connection failed.

Grant Taylor gtaylor at tnetconsulting.net
Fri Nov 4 18:02:28 UTC 2022


On 11/4/22 11:19 AM, David Carvalho via bind-users wrote:
> Thanks again.

You're welcome again.  :-)

> Probably. Am I supposed to, I have just 2 segments in this network 
> (and 2 others on another work) ?

Normally no, you're not supposed to /need/ to have a copy of an 
intermediate zone.

However, because you're using RFC 2317 Classless IN-ADDR.ARPA 
delegation, you have introduced additional complexity.  As such, you 
have an additional dependency.

I don't think that's a bad thing per se.  But it definitely is something 
to keep in mind.

> Yes! But I never heard of intermediate zone before. As far as I know, 
> my top domain forwards all "di.ubi.pt" requests to me and that works.

The intermediate zone; 66.136.193.in-addr.arpa. is for /reverse/ /DNS/. 
Your "di.ubi.pt." zone is /forward/ /DNS/.

There are actually multiple intermediate zones for both forward DNS; 
ubi.pt. and pt., and reverse DNS; 66.136.193.in-addr.arpa., 
136.193.in-addr.arpa., 193.in-addr.arpa., in-addr.arpa., and arpa.  It's 
just that the intermediate zones are hosted outside of your control. 
Both forward and reverse DNS chain down to zones that you do have 
control over hosting.

The difference in behavior between forward and reverse DNS /while/ 
/offline/ has to do with how things work technically.  Forward DNS 
simply looks for records of a given name in a given zone, both of which 
you have.  Reverse DNS on the other hand translates an IP address to a 
FQDN to look up in the DNS system.  E.g.

    a.b.c.d becomes d.c.b.a.in-addr.arpa

Your use of RFC 2317 Classless IN-ADDR.ARPA delegation complicates 
things in that,

    d.c.b.a.in-addr.arpa. becomes d.x-y.c.b.a.in-addr.arpa.

This 2317 delegation means that your client & server don't recognize 
that d.c.b.a.in-addr.arpa. maps to d.x-y.c.b.a.in-addr.arpa. /without/ 
the knowledge contained in the c.b.a.in-addr.arpa. zone.

Does that help thin the mud at all?  Or did I make things worse?



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


More information about the bind-users mailing list