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