Re: search and ndots support in bind utilities

[Petr Mensik]

Thank you Paul,

this document is far better than I hoped for. I have to improve my
googling skills it seems. This is brilliant.

On 9/30/19 5:35 PM, Paul Ebersman wrote:
> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document, explaining
> pemensik> what are possible dangers. How to use it safe way or how to
> pemensik> avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   
> 
> It goes into detail on why search/suffix lists are a bad idea.
> 

-- 
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

Re: search and ndots support in bind utilities

[m3047]

One more thing: what about disabling search lists? Can't I make a rule 
that "all FQDNs must be specified with a trailing dot (as documented to 
stop the use of search lists)"?


You'd better test that thoroughly. Firefox still doesn't get the TLS host 
header right, and Apache doesn't toss its breakfast anymore, but it ain't 
pretty. Try https://apache.org./ if you don't believe me...




Good luck, and a good tomorrow...

--

Fred Morris




___
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

Re: search and ndots support in bind utilities

[Paul Kosinski via bind-users]

Following https://www.icann.org/en/system/files/files/sac-064-en.pdf,
it sounds like modest groups of Internet users (such as informal clubs)
that don't have their own official domain (like "iment.com") are out of
luck if they would like to have local subdomains -- unless they want to
use the quite misleading reserved TLD "test", that is.

It's really too bad that the committee that expanded the space of TLDs
weren't as farsighted as those who allocated the IPv4 addresses to
include non-routable ones for local (intra-LAN) use.

P.S. Note that the domain implied by the PTR lookup result of such a
group's external IP address, although unique, is usually not suitable.
Most can change without notice due to DHCP, and they also tend to be
something unworkable, like "c-66-31-152-1.hsd1.ma.comcast.net.".


On Mon, 30 Sep 2019 09:35:57 -0600
Paul Ebersman  wrote:

> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document,
> pemensik> explaining what are possible dangers. How to use it safe
> pemensik> way or how to avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   
> 
> It goes into detail on why search/suffix lists are a bad idea.
___
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

Re: search and ndots support in bind utilities

[m3047]

The following is not specific to BIND, but concerns the operating 
environment for DNS software. Ebersman in a later post links to a document 
which foreshadows what I'm about to discuss.


On Mon, 30 Sep 2019, Petr Mensik wrote:

[...]
I am aware search is a no-no in DNS community.


That's barely the "other 10%" of it. It reaches as far as cooked Google 
servers (Stucke's still amusing talk from Black Hat some years ago) and 
comes down to a simple: "whose name do you trust?"


I know from experience with the data that in some $VENDOR's streaming 
NXDOMAIN telemetry feed, on any given day, depending which way the wind is 
blowing, that .belkin will be one of the top 10 TLDs. Luckily Cisco bought 
.cisco, so you can see for yourself if your Passive DNS data provider is 
any good by looking for A queries which resolved to 127.0.53.53.


Why does so much DNS traffic show up inadvertently stemmed with .cisco and 
.belkin? Rhetorically speaking, of course.


The DNS is just one naming service which is queried in attempts to resolve 
resource names into actual instances. Others include hosts, LDAP, NIS, you 
get the idea. If you go down the "no search lists" path, then that means 
everywhere, not just the DNS. (This may also be part of the reason for 
inconsistent behavior; earlier this year I personally saw DNS lookups 
suddenly become case sensitive on SuSE Leap when using getaddrinfo().)


What about Active Directory? If your domain can't resolve inside of 
Windows, does it fall back to the DNS?


Resources doesn't include just web sites, CRLs, adverts, tracking beacons. 
It includes database servers, etcd and other resolution / configuration 
services, drives containing executables to, you know, execute...


It doesn't stop with best practices according to the DNS community. Plenty 
of developers will think they know best for their particular situation, so 
you will see them trying various things that will oftentimes result in 
stemming and trying things from your search list. (Guilty as charged, 
during the SuSE episode I coded an option to force the use of dnspython 
for name resolution.)



Prohibitions like "no search lists" do next to nothing. Clever programmers 
will use whatever domain you specify for your hosts as something to 
deconstruct and use for stemming. An (enforced) search list might be 
preferable!


Look at your DNS traffic, particularly NXDOMAIN. (I'd look for stuff 
resolving in typoed / bit flipped domains too.)


Add a domain you own but do not use as the final fallback in your search 
list, and monitor all DNS traffic going to it.


Even resolving stuff may not stop it from leaking (stop resolution 
attempts), because the developer may not trust your answer. I wouldn't do 
that, of course. ;-) But clearly people obsessed with "happy eyeballs" 
don't share my sensibilities.



Good luck, and a good tomorrow...

--

Fred Morris

___
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

Re: search and ndots support in bind utilities

[Paul Ebersman]

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

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

See ICANN SSAC doc 64:

  

It goes into detail on why search/suffix lists are a bad idea.
___
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

Re: 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  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
>>
>> 

Re: search and ndots support in bind utilities

[Mark Andrews]

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  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

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

___
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

search and ndots support in bind utilities

[Petr Mensik]

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