search and ndots support in bind utilities

[Petr Mensik]

Hi Mark,

I am aware search is a no-no in DNS community. However, is there any
public documentation to this change? Is there RFC recommending not to
use search or how it should be used, related to today's top level domains?

While I agree it is dangerous, there are still people using it. I think
we should point them at some document, explaining what are possible
dangers. How to use it safe way or how to avoid using it at all.

Most important thing is IMO, all libraries in current system should
behave the same way. When I run dig x.y, then ping x.y, I expect it is
always the same target. When search is used now (on Fedora or RHEL), it
might return DIFFERENT target IP. I think this is much more confusing.

Dig protects you, but applications using getaddrinfo() are still
searching both absolute, then relative name if absolute name does not
exist. I think it makes problem MORE dangerous, since your manual
checking using DNS tools does not show requests. But then real
applications using system resolver are more vulnerable. You have
manually verified it is ok using tools, but it is not from applications.
The problem is still there, but HIDDEN from administrator.

Obvious recommendation is to not use search at all. That would work
always the same on any version. I think until glibc resolver is fixed,
tools should behave still the same way. I would like to push change to
glibc resolver, but it seems I am missing good enough arguments.

Regards,
Petr

On 9/27/19 3:31 AM, Mark Andrews wrote:
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com  PGP: 65C6C973