systemd-resolved (237) incorrect configuration after dhcp #8851
Comments
|
OK I have more data now. There is most definitely a bug here. Some background. DNS records in play are in the home domain: On a offending machine: Works Doesn't Work Also Doesn't work Note: It clearly knows it's a cname. We also know that the search domain is set. That was way up at the top. But it's obvious resolved is not doing a search properly. |
|
Frankly this bug is holding back a number of upgrades on my networks at home and in the office. I simply can not trust the dns results. Which opens up a huge issue around security. I am currently working on a simplified process to neuter resolved and install dnsmasq as a replacement local resolver. Which I can then add to my automation scripts. |
|
However another way to get around systemd-resolvd borkness is to: |
upuv
changed the title
|
Do you have ".local" in a unicast DNS domain, did I get this right? Since RFC 6762 ".local" is assigned to MulticastDNS usage (also see https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml), hence resolved won't consider it for classic DNS lookups by default. This is a security precaution: multicast DNS names have an inherent local focus, and we should not permit them to leak onto the public internet (i.e. classic DNS with its global focus) by default. That said, resolved is fine with looking up ".local" in unicast DNS domains, for compatibility with networks that have been set up that way a long time ago. But it's opt-in. To enable this make sure to declare ".local" and search or routing domain on the same interface where you configure your DNS server. If you configure your DNS server directly in /etc/resolv.conf then it's sufficient to add "search local" to it, to make that happen. Alternatively, edit /etc/systemd/resolved.conf, and set Domains= to "~local" which is to configure the domain for routing queries, but not for suffix searching. Anyway, I don't think there's any real bug here. The current behaviour is in-line with today's IETF recommendation and IANA assignments. Yes, old DNS implementations didn't work that way, but that's mostly because they predate these definitions. And yes, it's unfortunate that MulticastDNS conflicts conceptually with other uses of the .local domain, but it is the way it is... I hope this makes some sense. I'll leave this bug open, and turn into into a documentation issue. We should make this behaviour clearer in the systemd-resolved man page i guess, since this comes up regularly. |
|
There is no local in the DNS domain. local is NOT part of domain structure at all. I only used the word local to describe that the network is my physically local as in lan. So please ignore the use of the word local above as it clearly is causing confusion. The domain in the above is .home . And the resolve.conf does have It is clearly not searching the home domain dns. In the above we clearly see that home is the search domain. Also note this can be replicated on a fresh install of ubuntu 18.04. Absolutely no changes other than the usual apt update apt upgrade after install. I have replicated this behaviour above with a Intel NUC, Virtual box VM ( Bridged network ) and a Dell workstation. On all of those devices when I install Ubuntu Server 16.04 everything works perfectly. The documentation clearly states that if the Domains= is left blank the search domain of /etc/resolv.conf is used. Again in the above it is clear that the search domain of home is clearly set. The default configuration of resolved is that Domains=blank. The resolved.conf file. From everything I have explored the above behaviour as shown by test output is incorrect and does not match documentation. Therefore I still feel this is a bug. |
|
Also note: That when I do switch the link from stub-resolv.conf to resolv.conf things work. stub-resolv.conf resolv.conf Thus it is clear that resolved is not working as intended. It is not using the search directive. |
|
It should also be noted that when I explicitly set the Domains= in resolved.conf to home searching still fails. This does set the interface configuration however. But no actual change to behaviour. Again note the DNS is fine. It's rock solid. All other devices and OS's that are non-systemd-resolved work out of the box perfectly. The DHCP service on the DNS host is working fine. All devices require no additional configuration in order to properly resolve home domain names both a cname records. It's clear that the systemd host shown above is getting the correct DHCP information as the /run/systemd/resolve/resolv.conf file is properly configured with data that came from DHCP. |
|
@upuv your issue seems to exhibit the same DNS symptoms as bug: 1766969 on launchpad. But other than this issue, I can't find another on github/systemd/issues that's similar to: 1766969. |
Thanks! Helped immediately. |
|
I also get SERVFAIL when trying to resolve my private local DNS domain. Is there a way to fix this on the server side, as in, anything I can change on my DHCP/DNS to get local hosts on my LAN to resolve? Or is changing the Domains= line the only work around for now? |
|
hmm, so, if i get this right, then the issue here is specific to CNAME handling in the DNS stub server of resolved. when the client does a lookup for an A RR and there's a CNAME RR defined, we won't propagate that properly. That's of course a real bug. |
OK, so this is where things are broken: It appears your zone file is simple incorrectly set up. Your CNAME record redirects |
|
This appears to be caused by a local zone file issue, hence dropping the milestone. |
poettering
added
the
needs-reporter-feedback ❓
Inspired by the discussions in systemd#8851, even though the issue appears to be entirely unrelated to the .local domain in the end.
|
That is an example of how it doesn't work. Any cname will not work also local searches do not work with systemd-resolved. And again this works for every other OS resolver that I have tested.
So just to be 100% here.
The only resolve that works is As per dnsmasq configuration: Dig command of all host combinations above.Here is the debug output of those very same dig commands.I'd have to write a script or something to generate a zone file. And that sorta defeats the evidence gathering process. |
|
hmm, so, are you saying that you have addresses and CNAMES assigned to "dotless" domains? resolved won't resolve those via classic DNS, following these IAB recommendations: dotless domains are resolved via LLMNR or search domains, but CNAMES won't be allowed to redirect to LLMNR or search domains, since that would allow outside DNS servers to reference private names and we can't allow that. But I am really puzzled by all this, I really don't follow what your set up is like. First you used the ".local" domain (which is reserved via RFC for a different purpose), now you appear to use dotless domains (aka "single-label" domains, aka "TLDs") for A/CNAME records. In the middle it was about CNAME redirection and search domains. I am seriously confused about all of this. |
|
I have never used .local anywhere. I only used the word "local" to refer figuratively to the local physical network. Again ".local" HAS NEVER BEEN A DOMAIN in this networks configuration. |
|
But dotless domains are still in the standard. They are only considered harmful in discussion papers. However the spec still allows them. Until the spec depreciates them it is still standard. PS This discussion paper has not progressed at all since 2013. |
|
well, you should be able to define "." as routing domain, so that single-label domains are resolved via classic DNS. But we try to make things secure and somewhat up-to-date with today's intended use of DNS, hence we won't do A/AAAA/PTR lookups on single-label names on DNS normally. I mean, besides the fact that everyone recommends against having domains set up like this, this also creates security issues (as dotless domains are usually assumed to be in local context and shouldn't leak onto the internet) and ambiguity issues (as you invade TLD territory like this, and they keep adding new TLDs every other week or so these days, so you might sooner or later run into conflicts with maybe an official TLD being created called ".logging"... Anyway, consider adding Domains=~. to /etc/systemd/resolved.conf. That will result in a routing domain being defined that any domain ending in the top level domain (i.e. all domains) will be routed to classic DNS. But of course, routing all single-label domains to classic DNS is on you then, and the security and ambigituity issues this creates. |
|
Domains=~. Does not resolve the issue. Tested. As an aside this really needs much much better documentation. As this is the only implementation of a resolver that does not resolve dotless domains. You are effectively breaking from the standard. I would also suggest that this is covered in the debug output of resolved as well. As it stands now it simply looks like it stops working. I will validate this by migrating this network to a "dotted domain". For now I'm willing to have this thread moved to closed. But again the debug output of systemd-resolved needs to highlight this divergence from standard definitions. If further testing on a "dotted domain" reveals the same behaviour I will raise a NEW issue. |
Inspired by the discussions in #8851, even though the issue appears to be entirely unrelated to the .local domain in the end.
poettering
removed
the
needs-reporter-feedback ❓
|
If Domains=~. doesn't work, we should really make it work though, leaving the bug open hence. And yes, it could also use some documentation. |
|
I noticed today that modifying Domains= with my networks search domains does not work after a fresh reboot. I have to manually Why can't it correctly just use the search domains provided by DHCP like it is supposed to? |
|
As @laxdragon said, restarting |
|
Same issues here... still open>? |
They probably were reported by your router as your provider's DNS servers. At least that's what my additional 2 ipv6 addresses were, and I verified it by a reverse lookup :) |
|
It seems that the setup that is reported as broken has single-label tlds that are supposed to resolve for A records. We don't support this by default, but it can now be optionally allowed after 3b5bd7d. Please reopen if either a) that interpretation was incorrect, or b) it doesn't work with that option enabled, or c) it still doesn't work after removing use of single-label names. |
Submission type
systemd 234 & 237
Used distribution
ubuntu server 17.10 BUG
ubuntu server 18.04 BUG
ubuntu server 16.04 SUCCESS ( Used to validate it was a local host bug. )
In case of bug report: Unexpected behaviour you saw
When trying to resolve names in the local dns that are cnames a failure occurs. In that nothing is resolved. Even though most operating systems can resolve it just fin
In case of bug report: Steps to reproduce the problem
a record a.local = 192.128.0.20
cname c.local => a.local
dig a.local
dig c.local
From the output it's clear that 17.10 and 18.04 resolve incorrectly for c.local.
It should be noted that windows, android, IOS, my TV all resolve correctly. Only the ubuntu server installations with systemd are failing.
The text was updated successfully, but these errors were encountered: