search and ndots support in bind utilities

Mark Andrews marka at isc.org
Fri Sep 27 01:31:44 UTC 2019


Partially qualified names are inherently unsafe.

Depending on applying the search list after trying the name as fully
qualified is just plain dangerous as it depends on a NXDOMAIN response
from a namespace not under your control to reach the service you are
after.  TLDs get added all the time.

One could kind of get away with it back when RFC 1535 was written as
there were only a handful TLDs to worry about colliding with and that
was manageable.  That time has long past.  This was the time when ndots
was invented.  Yes, this was a considered decision.

Searching with partially qualified names with non-default ndots is also
unsafe, but slightly less so.  You reach internal information / services
accidentally instead of leaking it to a external party.

Mark

> On 26 Sep 2019, at 9:20 pm, Petr Mensik <pemensik at redhat.com> wrote:
> 
> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



More information about the bind-users mailing list