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 <pemen...@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: pemen...@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@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users