5 ms·

"works" They closed this super-critical bug despite not fixing it, claiming they're making the right decision in their implementation when they in fact misread

"works" They closed this super-critical bug despite not fixing it, claiming they're making the right decision in their implementation when they in fact misread the spec https://github.com/systemd/systemd/issues/2514 https://github.com/systemd/systemd/issues/2514 Yeah, that's right, with resolved you cannot connect to other machines on your local network by specifying their simple names, because it blackholes those requests, and there's nothing you can do about it.

drdaeman 4y ago
> with resolved you cannot connect to other machines on your local network by specifying their simple names Huh? You most certainly can. I mean, somehow "ssh koyomi" works here on my network, no matter if machine I run this on uses system-resolved or unbound or something else. My DHCP server supplies options 119 and 135 and that's all that's necessary to make it work. What you can't is to have a CNAME with a bare hostname i.e. make "foo.example.org" magically resolve to "foo.local" when you're on that particular LAN with "search local" (and $deity knows what if you're not). To be honest, I'm not even sure what's the point of this setup, unless you do split-horizon (but then why not respond with "foo.local." proper?)
- strictfp 4y ago
  Do you have a proper domain name for your local network (+ search domain)? I'm talking about the case where you don't, or have a '.local' domain; https://askubuntu.com/a/918161 https://askubuntu.com/a/918161
  - nulbyte 4y ago
    The .local name is intended for multicast name resolution. RFC6762 says implementations may coalesce results with unicast DNS lookups, but it's not required. The only thing required is that anything ending in .local must he looked up via mDNS. So including .local in the search list doesn't seem likely to make your query reach DNS on an mDNS capable stub resolver. Meanwhile, RFC4795 says that LLMNR senders should not send queries for single-label domains to DNS and that no search list should be applied to such. So querying a single-label domain does not seem likely to reach DNS on an LLMNR capable stub resolver. My advice to one who wants to use DNS to resolve hostnames on the local network: Avoid using a domain reserved for mDNS domain and use another one.
    - strictfp 4y ago
      The thing is that a simple name doesn't work either, so 'server1' doesn't work, 'server1.local' doesn't work. 'server1.example.com' works, and I think 'server1.lan' also works, but I'm not sure about that last one.
  - drdaeman 4y ago
    Oh, now I get it. Sorry, it was not obvious from the bug you've linked above - there it talked about a CNAME record referencing a bare hostname from a "proper" (non-mDNS) domain name, a fairly weird use case I don't quite get. Yes, I do have a "proper" domain name for my LAN and my .local is for mDNS (although I don't think I've ever used it with short names, always foo.local explicit; and I use mDNS very infrequently) - guess which is why I haven't ever seen this behavior. Thank you for clarifying.
tasuki 4y ago
This issue also hit me! It was easy enough to set up `dnsmasq` and use that instead of `systemd-resolved`. And yes, I'm a little upset about it being broken by default and having to hunt down the issue, which did take quite a bit of time.
SahAssar 4y ago
I skimmed the bug report, and wrote up a reply, but then realized that all of this is meaningless to the actual question: If your beef is with resolved, and resolved can be replaced with your resolver of choice, what is your point against systemd as an init?

drdaeman 4y ago

> with resolved you cannot connect to other machines on your local network by specifying their simple names Huh? You most certainly can. I mean, somehow "ssh koyomi" works here on my network, no matter if machine I run this on uses system-resolved or unbound or something else. My DHCP server supplies options 119 and 135 and that's all that's necessary to make it work. What you can't is to have a CNAME with a bare hostname i.e. make "foo.example.org" magically resolve to "foo.local" when you're on that particular LAN with "search local" (and $deity knows what if you're not). To be honest, I'm not even sure what's the point of this setup, unless you do split-horizon (but then why not respond with "foo.local." proper?)

strictfp 4y ago
Do you have a proper domain name for your local network (+ search domain)? I'm talking about the case where you don't, or have a '.local' domain; https://askubuntu.com/a/918161 https://askubuntu.com/a/918161
- nulbyte 4y ago
  The .local name is intended for multicast name resolution. RFC6762 says implementations may coalesce results with unicast DNS lookups, but it's not required. The only thing required is that anything ending in .local must he looked up via mDNS. So including .local in the search list doesn't seem likely to make your query reach DNS on an mDNS capable stub resolver. Meanwhile, RFC4795 says that LLMNR senders should not send queries for single-label domains to DNS and that no search list should be applied to such. So querying a single-label domain does not seem likely to reach DNS on an LLMNR capable stub resolver. My advice to one who wants to use DNS to resolve hostnames on the local network: Avoid using a domain reserved for mDNS domain and use another one.
  - strictfp 4y ago
    The thing is that a simple name doesn't work either, so 'server1' doesn't work, 'server1.local' doesn't work. 'server1.example.com' works, and I think 'server1.lan' also works, but I'm not sure about that last one.
- drdaeman 4y ago
  Oh, now I get it. Sorry, it was not obvious from the bug you've linked above - there it talked about a CNAME record referencing a bare hostname from a "proper" (non-mDNS) domain name, a fairly weird use case I don't quite get. Yes, I do have a "proper" domain name for my LAN and my .local is for mDNS (although I don't think I've ever used it with short names, always foo.local explicit; and I use mDNS very infrequently) - guess which is why I haven't ever seen this behavior. Thank you for clarifying.

tasuki 4y ago

This issue also hit me! It was easy enough to set up `dnsmasq` and use that instead of `systemd-resolved`. And yes, I'm a little upset about it being broken by default and having to hunt down the issue, which did take quite a bit of time.

SahAssar 4y ago

I skimmed the bug report, and wrote up a reply, but then realized that all of this is meaningless to the actual question: If your beef is with resolved, and resolved can be replaced with your resolver of choice, what is your point against systemd as an init?