Handle LLMNR only by nss-resolve

[pemensik]

Is your feature request related to a problem? Please describe.
Yes, described in #23494. LLMNR eats also queries to single label names, which are not wanted to be resolved by LLMNR. It should not

Describe the solution you'd like
I want to use LLMNR only from getaddrinfo() calls and similar. I think that is also equivalent to how Windows machines use it, because they do not redirect DNS to local service. They just provide equivalent to glibc nss plugins except dns.

Unlike Ubuntu, Fedora enabled also nss resolve plugin in /etc/nsswitch.conf. Therefore it has a way to make clear distinction, when it uses just general get me addresses for a host name xy and get me dns response for query to local stub. Take advantage of it and serve LLMNR only for queries received from resolve plugin, but not for queries received over DNS socket on port domain.

If I have search example.net in /etc/resolv.conf, then I want all single label queries to try host.example.net via DNS. I don't want resolution passed to LLMNR and end there if not found. It would work itself just like before f33, when systemd-resolved started to be installed by default. nss-dns would ensure search is applied according to resolv.conf.

Describe alternatives you've considered
Disabling LLMNR always and for all. We have mdns for multicast resolution. Create a separate nss-llmnr similar to nss-mdns. Local LLMNR on DNS stub should not serve ever LLMNR responses on 127.0.0.53 stub or 127.0.0.54 stub.

The systemd version you checked that didn't have the feature you are asking for

systemd-251.1-2.fc37.x86_64

[pemensik]

I also think resolved stub should use options no-tld-query in stub-resolv.conf when LLMNR is enabled. Then it should forward queries only received via resolve plugin. If query arrive to domain port, forward and resolve it as normal query. With this flag, dns nss plugin would not forward any single label query to domain port of resolved.

[pemensik]

Doing it this way would fix issues like reported on #23737

[pemensik]

I have found current systemd-resolved implementation even violates LLMNR RFC: https://www.rfc-editor.org/rfc/rfc4795#section-5.4, last sentence very clearly says LLMNR must not be done in reaction to DNS query. But it is.

[pemensik]

This breaks simple queries, which are supposed to work. Examples why it is breaking stuff:

• dig -t ns com.
• dig -t ds org.

Both return NXDOMAIN. I am quite sure domains .com and .org exists. You are reading a page on one of them.

[justinfenn]

I think the behavior with those examples is faulty regardless of LLMNR status. Things like com. and org. are not single-label names, they are fully-qualified domain names.

[pemensik]

Well, technically com. name is two label, consisting of com and final root domain. com itself is single label. Yes, I am aware they are top level domain, which exists in DNS. Single label name does not contradict it is fully qualified domain name. Current behaviour is in direct violation of RFC 8020. I know they are just fine domains, but systemd team considered the issue were solved by #23494. I am quite unsatisfied with such "solution".

I admit I were surprised a lot, when tested behaviour of nslookup -type=ns org on my Windows 11 machine. It does not work the same way as on resolved. It says non-existent domain.

Which does not mean that is okay. That is why I have proposed MR #28263, disabling that in following release. It is going to be removed anyway.

[pemensik]

Filled Fedora bug for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=2220973

[q2dg]

Well, LLMNR seems deprecated (https://techcommunity.microsoft.com/t5/networking-blog/aligning-on-mdns-ramping-down-netbios-name-resolution-and-llmnr/ba-p/3290816) so I'd not spend many efforts in it

[pemensik]

PR #31621 has changed sent types to LLMNR only to selected types. That includes A, AAAA, PTR and CNAME. While it improves significantly DNSSEC validation, it will still disallow names to local hostnames without dot present at local DNS server, such as router. name provided by every Mikrotik router, which will become broken.

In a document linked from ResolveUnicastSingleLabel= in man resolved.conf, it is said:

(b) The search list expander can require two or more
interior dots in a generated domain name before it
tries using the name in a query to non-local
domain servers, such as the root.

The use of SHOULD for (b) is a recommendation against doing DNS queries for dotless domains. RFC 2119 [RFC2119] explains the meaning of SHOULD as follows: ...

What have been misunderstood is that non-local domain servers are any domain servers. But that is not true. If the local network DHCP provides us list of servers, we have no way to know whether they serve local content. But they are local in most cases, such as in our corporate network. They will be local in most of networks, especially if they use private IPv4 ranges. Even if they don't, they can be considered local. The only case we may assume they are likely not local, is when public servers like Google's 8.8.8.8 or 1.1.1.1 is used. But that is difficult to auto-detect, it should be specified by the user explicitly. It should be auto-enabled for fallback servers, which are very likely non-local, public DNS resolvers.

What clearly were not specified by IAB statement, that single label queries should be sent to LLMNR only. I failed to find such recommendation.

[poettering]

What have been misunderstood is that non-local domain servers are any domain servers. But that is not true. If the local network DHCP provides us list of servers, we have no way to know whether they serve local content. But they are local in most cases, such as in our corporate network. They will be local in most of networks, especially if they use private IPv4 ranges. Even if they don't, they can be considered local. The only case we may assume they are likely not local, is when public servers like Google's 8.8.8.8 or 1.1.1.1 is used. But that is difficult to auto-detect, it should be specified by the user explicitly.

I understand you work in an entreprisey RHEL world where you have a mindset of having an "entreprise zone". But systemd is supposed to work in the real world, where you cannot rely on your network segment being trusted and giving you a trusted DNS.

Hence we have this rule: single label (and .local) names have local scope, and multi-label names have internet scope. And we don't leak the single label lookups onto the Internet. And I think that actually works pretty well, the disagreements on this policy mostly come from a certain group of DNS truthers, who don't like whatever we do, whatever we tried.

[pemensik]

I understand you work in an entreprisey RHEL world where you have a mindset of having an "entreprise zone". But systemd is supposed to work in the real world, where you cannot rely on your network segment being trusted and giving you a trusted DNS.

Strange. I have dnsmasq backed router at home. It auto-registers name for every machine doing DHCP. I do not live only on corporate networks. I am a software engineer, I manage only my home network. Have limited experience in community network also. This is true for home networks and also larger company driven networks. Any unicast DNS server provided by DHCP is more trusted than multicast service. Multicast protocols are great for nice to have services, but their reliability is much lower. And they add visible timeouts, which are not desired, like in #28166.

Hence we have this rule: single label (and .local) names have local scope, and multi-label names have internet scope. And we don't leak the single label lookups onto the Internet.

I have showed multiple proofs this approach is wrong. LLMNR is a dead protocol with no future. Even then, not even Microsoft Windows implemented it the way you did. Then do not leak lookups onto the Internet. If my local router provides its own address, in the same private range as my own local address, then that is not leaking it to the Internet! Not leaking queries it is job, because only there are all information, which names are used and which are not.

If you have overridden DNS servers offered by the network (for example because I do not trust them), then very likely yours are public on the internet. That might be the only case, when filtering makes sense. But if DNS protocol is used by dig tool, then llmnr is not desired. Whatever qtype or qname is requested.

And I think that actually works pretty well, the disagreements on this policy mostly come from a certain group of DNS truthers, ...

No, it does not. There are multiple issues regarding LLMNR. But you do not listen. They know it should work different way but you do not want to hear that. It gets into their way often but you insist it works pretty well.

who don't like whatever we do, whatever we tried.

Try visiting https://chat.dns-oarc.net and ask professionals, how it should behave. Listen to them. Try to understand RFCs and what was meant by them. Not everything is obvious or written in detail. Those people know much better than me small details, how they should work and why. After just 7 years working on DNS I am still learning from them, but you can meet people who wrote some of those RFCs or have double my experience. If unsure, ask them. They are kind people. I haven't seen you there.

What I have seen multiple times is issue were closed, when only partially solved what reporter has requested. The best example were #4621. It might help asking the reporter, if proposed fix does actually fix what they wanted. If they don't know, that is okay.

[rpigott]

I don't think it's true that every client that speaks dns to us on the stub cares that we only speak dns in return. E.g. libraries like c-ares are commonly used in C to get a better asynchronous resolver interface. Go has it's own resolver implementation that mimics the libc resolver. These clients can benefit from resolved's implementation of mdns/llmnr if enabled on the host, and this minimizes unexpected differences in answers between clients requesting the same name. If it were strictly enforced that queries to the stub were answered only with unicast dns, this would break curl somehost.local, for example.

[pemensik]

The important difference is mdns resolution has own domain .local, which makes it cleanly separated. It is known when mdns is supposed to be used. The way as llmnr is implemented on Windows is it works only for applications using internal API. If go apps use DNS servers directly, it would not work there also. So it would be expected.

And I have checked curl test command. No, it uses only getaddrinfo() call to get its IP, so it would not be affected. wget test the same. No dns queries send to it. The same is with majority of commands I know. Except special DNS specific commands, which get unexpected results, because mixing different protocols. If resolved would listen also on llmnr port, be my guest. If llmnr worked just as a fallback, it might not break it so. But dns applications should get dns responses, if there was any. Especially when positive answer exists.

Yes, you are true not every client does it on purpose. If the application could opt-in to llmnr usage also over DNS protocol, then okay. But that is not the case. I have not seen any strong evidence LLMNR is desired and it would be a problem to turn it on explicitly.