search and ndots support in bind utilities

Petr Mensik pemensik at redhat.com
Thu Sep 26 11:20:10 UTC 2019


Hello,

I got bug report [1] about different behavior of nslookup in 9.11
version compared to old 9.9 version. At first I thought this issue
should be closed right away. But when I digged into changes in BIND, I
could not find any reason for given change. It seems to me the effect
was not desired. Or not well documented.

What changed since 9.10? In 9.9, bind utilities behaved the same way as
internal glibc implementation. When there is dots >= ndots in searched
name, absolute name is tried first. If it does not exist, domains from
search clause are appended and searched as well. Current nslookup
behavior is to use ONLY absolute name when dots >= ndots. While I
personally consider it better practice, some people still expect
original behavior.

What is worse, it makes it inconsistent with evaulation by the system
(glibc) dns resolver. This way, host some.service can give different
results than getent hosts some.service with search openstacklocal.

I would like to find evidence or at least opinions, whether this
change[2] was intentional and/or what was the reason for it. It seems
either bind utils should revert to use search domains after absolute
name or system resolver should be fixed to behave the same way as bind
utils. But either change requires decision what is the correct way and
how it should behave.

In case my description of the problem is unclear, let's have an example:

$ nslookup -debug -domain="vm" rhel6.8
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find rhel6.8: NXDOMAIN

But on BIND 9.9 or with [2] reverted, it gets:
$ ./nslookup -debug -domain="vm" rhel6.8
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	rhel6.8.vm
Address: 192.168.122.109

Is it bug or feature?

Glibc has the same behavior even on new enough versions.
Both glibc-2.28-72.el8 and glibc-2.30.9000-7.fc32 can resolve name with
dot inside which host or nslookup cannot resolve. I am aware referenced
BIND version is quite archaic.

Best regards,
Petr

1. https://bugzilla.redhat.com/show_bug.cgi?id=1743572
2.
https://gitlab.isc.org/isc-projects/bind9/commit/8afea636ab0c07399aa3e2410b2cfbd41099df98
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com  PGP: 65C6C973


More information about the bind-users mailing list