search domains do not apply to dotted names

[martinpitt]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

232, master

Used distribution

Ubuntu 17.04

I got a downstream report about resolved's handling of search domains: glibc in no way restricts application of search domains to "single" (undotted) labels, it always applies the search domains. It has an ndots options below which it forces appending a search domain, but that does not mean that it skips search expansion for queries with more than ndots dots.

E. g. if you have Domains=example.com then a lookup of for.bar ought to try and query foo.bar.example.com.

I wrote a test case that reproduces this bug.

My first naïve approach was to just change dns_scope_name_needs_search_domain() to always return true instead of return dns_name_is_single_label(name);. This makes search expansion work, but then breaks queries which already provide a fully qualified host name. I tried to fix that in dns_query_add_candidate() but it seems its current approach is a bit too simplistic.

[poettering]

This is an explicit design decision, following the logic of LLMNR and suchlike, that single-label names follow different rules than multi-label names. By strictly saying that they are different we remove ambiguity regarding resolving: if something has a dot, it's an fqdn, if not it's to be seen in a local scope, and queried via llmnr or via search domains. This makes things very clear for both the resolver and as well as for the user: there's no ambiguity what happens when he types a hostname into his web browser: if he types in anything with more than one label, the user knows it ends up on the internet, and hence returns a global resource's address. If he types in something with only one label, then he knows it is resolved within local scope, meaning either via LLMNR or via DHCP supplied, LAN-specific search domains, or via some other means.

Honouring searching domains for multi-label names is simply a big security problem I think, as today the most famous websites all are usually accessed via a two-label name (like for example github: if you look in the URL bar, it is a two-label name). If the user never knows whether "spiegel.de" ends up in the local search domain logic or not then that's a primary security problem, and can be exploited remotely (simply by providing search domains via DHCP and then providing a link). Potentially routing traffic for all such multi-label domains through a search domain is highly problematic.

Resolving multi-label names via the search list is also kinda incompatible with DNSSEC as that's supposed to validate the name the user types the way it was type in.

I think this bahaviour is also in line with the general trend how the internet bodies see that, for example the fight against "dotless domains" (google for it...), i.e. servers that are reachable via single-label domains via DNS. It's kinda the other side of the medal: make sure the Internet DNS servers never resolve addresses under single-label names, even if clients ask for it. All that work is to make it very clear that single-label names go one way, and multi-label domains another way, and that there should not be ambiguities inbetween.

Also note that glibc requires manual reconfiguration to actually honour this, and I am pretty sure almost nobody will do that.

All that together makes very reluctant to do anything about this. This appears very much a legacy concept that does not have a place in an Internet where DNSSEC is the norm, and local networks where LLMNR is typical. Yes, we are breaking some setups which relied on that, but quite frankly given that these are highly localized setups only (as you cannot serve such a DNS configuration via DHCP for example), I am very sure this is an egg that is worth breaking to make an omelette.

Sorry if this is disappointing!

[martinpitt]

Not disappointing to me personally actually, my gut feeling actually agrees. It's just a rather obvious behaviour change compared to glibc's resolver, so I wanted to at least report it. So I guess we can/should close this?

[poettering]

Yupp. Thank you for your understanding!

[VGerris]

Hi,
I embrace any move to a more secure internet and deigns facilitating that.
What I have a problem with is that for regular desktop users, DNS resolving simply BREAKS.
Unfortunately I do not know enough about all the components involved, but currently the mean problems come from dnsmasq, NetworkManager and systemd-resolvd.

This thread seems like 2 guys making a design decision that breaks many peoples every day system.
What I am most pissed off about, is that the bugs reported for Ubuntu by users experiencing issues, are simply marked as closed by @martinpitt which I thing is WRONG!

Do these things break on Windows and MacOS? NO!
Do you want Ubuntu users to switch because of it? I personally don't and I am sure Canonical doesn't either. I wonder if this is an issue in Fedora? Is it broken there too?

I am specifically talking about these two bugs now:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636375

How about we think about how we facilitate the old behavior with the new design?
Besides that, I am not sure what is causing the issue in the first case, but restarting systemd-resolvd fixes issues temporarily, so there is certainly something very wrong in the configuration there.
That may not be subject of discussion here, unless it is a systemd-resolvd issue.

Let's bundle our efforts to have actual end products like Operatings system in a certain bundle WORK. If that means disabling systemd-resolvd, fine, lets's do it by default. Otherwise, let us think about the proper way of dealing with an between situation of a hopefully more safe future internet.

[Saviq]

Not sure if this would be acceptable, but one possibility would be to allow adding a trailing dot to the query, which would make it go through search domains?

It would get rid of the ambiguity, even if a http://name.home./ URL could potentially look weird.

So single-label and trailing-dot queries would go through search domains (and only through search domains), no others would.

FWIW, single-label names with a trailing dot do resolve today with libnss-resolve:

$ ping name.
PING name.home.domain.tld (10.1.0.1) 56(84) bytes of data.
[...]

If this is not acceptable, then the above itself should probably be a bug.

An argument for the original behaviour is that it allowed for reaching easily (and explicitly) across subdomains, when you had home.domain.tld and work.domain.tld configured and could reach name and other_name.work (but not other_name) when your search domains would be home.domain.tld and domain.tld.

[yrro]

I'd actually expect names ending in a dot to not go through search domains, since they are fully qualified (the DNS equivalent of an absolute path in the filesystem).

https://tools.ietf.org/html/rfc1034#page-8

[poettering]

Yes, the trailing dot is usually indication that the name is final and should not be subject to search domain extension

[skimj]

FYI, RFC3397 DHCP Domain Search Option section 4 (Security Considerations) item [2] specifically recommends:

that resolvers resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the local domain name (or searchlist if specified) appended.

[erikhugintech]

Adding a comment to this:

"Honouring searching domains for multi-label names is simply a big security problem"

That may be so, in some setups, under certain conditions. It is however the responsibility of the system administrator to manage this correctly for his setup.

You're not only removing this ability from the default setup of several distros, you're also removing the ability for a system administrator to explicitly choose the functionality he needs. I see no reason at all why you should override the RFC, and break default setups , because you personally believe it could be a problem in certain constructed scenarios.

To illustrate more clearly what I think you're doing - exaggerated, i know, but it's just an illustration. Would you react if a developer decided that all passwords must be 16 chars in the default PAM setup of a distro? What if the developer then also decided that you cannot change this config, because it's more secure - if you want PAM, your passwords must be 16 chars?

I have a practical use for hosts like "proxy.ops", "nginx1.web", "syslog.ops". Now, for my setups I'll of course just replace systemd-resolved with another resolution mechanism across all hosts. That's a waste of time, and yet more deviation from default install that must be maintained, due to a "we-know-best" decision that sounds more like something Apple or MS would impose on users.

[ghost]

I have a practical use for hosts like "proxy.ops", "nginx1.web", "syslog.ops". Now, for my setups I'll of course just replace systemd-resolved with another resolution mechanism across all hosts. That's a waste of time, and yet more deviation from default install that must be maintained, due to a "we-know-best" decision that sounds more like something Apple or MS would impose on users.

Okay. I'm going to register nginx1.web soon (as you should know it becomes a top level domain)..

Whats going to happen then?

that resolvers resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the local domain name (or searchlist if specified) appended.

Oops.

Sorry, but @poettering is completely right here. If something is broken like that it's better to remove it (even if it breaks other setups relying on broken standards) than to keep it as dirty as it is.

[toughkrua]

This is an explicit design decision, following the logic of LLMNR and suchlike, that single-label names follow different rules than multi-label names. By strictly saying that they are different we remove ambiguity regarding resolving: if something has a dot, it's an fqdn, if not it's to be seen in a local scope, and queried via llmnr or via search domains. This makes things very clear for both the resolver and as well as for the user: there's no ambiguity what happens when he types a hostname into his web browser: if he types in anything with more than one label, the user knows it ends up on the internet, and hence returns a global resource's address. If he types in something with only one label, then he knows it is resolved within local scope, meaning either via LLMNR or via DHCP supplied, LAN-specific search domains, or via some other means.

Honouring searching domains for multi-label names is simply a big security problem I think, as today the most famous websites all are usually accessed via a two-label name (like for example github: if you look in the URL bar, it is a two-label name). If the user never knows whether "spiegel.de" ends up in the local search domain logic or not then that's a primary security problem, and can be exploited remotely (simply by providing search domains via DHCP and then providing a link). Potentially routing traffic for all such multi-label domains through a search domain is highly problematic.

Resolving multi-label names via the search list is also kinda incompatible with DNSSEC as that's supposed to validate the name the user types the way it was type in.

I think this bahaviour is also in line with the general trend how the internet bodies see that, for example the fight against "dotless domains" (google for it...), i.e. servers that are reachable via single-label domains via DNS. It's kinda the other side of the medal: make sure the Internet DNS servers never resolve addresses under single-label names, even if clients ask for it. All that work is to make it very clear that single-label names go one way, and multi-label domains another way, and that there should not be ambiguities inbetween.

Also note that glibc requires manual reconfiguration to actually honour this, and I am pretty sure almost nobody will do that.

All that together makes very reluctant to do anything about this. This appears very much a legacy concept that does not have a place in an Internet where DNSSEC is the norm, and local networks where LLMNR is typical. Yes, we are breaking some setups which relied on that, but quite frankly given that these are highly localized setups only (as you cannot serve such a DNS configuration via DHCP for example), I am very sure this is an egg that is worth breaking to make an omelette.

Sorry if this is disappointing!

This is a very disappointing! If i have big company with wide departments structure, i cannot implement normal understandable politic for names. For purpose wich you talk about, people was come up with the difference between the two type (n/fqdn) by pointing dot at the end of name. This is a very right comfortable decision. Why reinvent wheel or act as Windows developers, especially since glibc support this.

[Roy-Orbison]

It seems like a better choice would be to make dotted labels resolvable with search domains by a configuration option, and have it deprecated from the outset. The documentation for that option could cite these security concerns. Using it could emit a warning to the resolved's log on every service start so it can't be said you're not informing sysadmins. This would provide an upgrade path for networks that currently rely on the feature.

Patching the security hole by default is great, breaking systems without warning is not.

[yuwata]

It seems like a better choice would be to make dotted labels resolvable with search domains by a configuration option, and have it deprecated from the outset.

I do not follow this issue. So, I am not sure, but ResolveUnicastSingleLabel= may help this? The setting is introduced in v246. See #16059.

[Roy-Orbison]

@yuwata I think that option is so that a query like systemd-resolve single-label. is allowed to be sent to a (private) DNS server, rather than only being resolvable on that machine, or causing an error if no search domains are available to append.

[Chaz6]

As a system administrator I would like to be able to enforce the following behaviour:-

• Domains must be fully qualified to be resolved as-is. (i.e. a.b.c.example.com.)
• All other domains (i.e. unqualified) will only be matched against the system dns search domsins. For example, if the search domains contains 1.example.com 2.example.com then a query for a.b.c.example.com would search a.b.c.example.com.1.example.com then a.b.c.example.com.2.example.com but never a.b.c.example.com.

Alas in reality this is nigh-on impossible because pretty much all software and configurations provide domains as unqualified.

[bivanbi]

By strictly saying that they are different we remove ambiguity regarding resolving: if something has a dot, it's an fqdn, if not it's to be seen in a local scope, and queried via llmnr or via search domains. This makes things very clear for both the resolver and as well as for the user: there's no ambiguity what happens when he types a hostname into his web browser: if he types in anything with more than one label, the user knows it ends up on the internet, and hence returns a global resource's address. If he types in something with only one label, then he knows it is resolved within local scope, meaning either via LLMNR or via DHCP supplied, LAN-specific search domains, or via some other means.

I am a user and I disagree. Also the discussion above clearly shows that there is no such consensus amongst users. I suggest to stick to what RFC says.