resolved: proxy upstream local requests to our stub with DO bit set#31621
resolved: proxy upstream local requests to our stub with DO bit set#31621bluca merged 9 commits intosystemd:mainfrom
Conversation
This new flag allows resolving single label names via public DNS. By default this is turned off, and this option allows excepting a lookup for this.
When we use proxy mode when propagating DNS queries to upstream DNS servers, let's use the relaxed single label rules. This has the benefit that tools such "delv" work on the proxy stub 127.0.0.54.
So far we disabled DNSSEC if local clients asked for it via DO flag if DNSSEC=no is set. Let's instead switch to proxy mode in this case, and thus treat client requested DO mode as a way to force proxy mode. This means DNSSEC=no just controls whether resolved will do validation for regular looups, but it has no effect anymore on lookups from clients that indicated they want to do their own DNSSEC anyway. Fixes: systemd#19227 systemd#23737 systemd#25105
dig question with DNSSEC on will now be proxied upstream, i.e. to the test knot server. This leads to different results, but the result isn't tha tinteresting since we don't want to test knot, but resolved. Hence comment this test. There seems to be something wrong with the test though, as the upstream server refused recursion, but if so it is not suitable as an upstream server really, as resolved can only be client to a recursive resolver.
So far we only looked at the domain name when routing requests to specific scopes. With this we'll also take the DNS RR type into account. This takes benefit of the fact that lookups for RRs such as SOA or NS or the various DNSSEC RR types never really make sense to be routed to LLMNR or mDNS, since they don't have concepts there. This hence refuses to route requests for those RR types to the LLMNR/mDNS scopes, which hence means they'll likely be routed to classic DNS instead. This should improve behaviour of tools that assumes it speaks to classic DNS only via 127.0.0.53, since it will now usually do that.
Te variables indicate what kind of RRs we are looking for, but the name so far suggests it was about what we already found. Let's rename the variables to make the purpose clearer.
If you query for an MX RR of a host listed in /etc/hosts, let's return an empty reply rather than NXDOMAIN, i.e. indicate that the name exists but has no MX RR assigned, thus making ourselves authoritative. The venerable "host" tool by default sends requests for A + AAAA + MX and ensures we never propagate queries further on. Fixes: systemd#31223
This is a kinda a follow-up for ce26633: it makes resolved authoritative on our local hostname, and never contacts DNS anymore for it. We effectively already were authoritative for it, except if the user queried for other RR types than just A/AAAA. This closes the gap and refuses routing other RR type queries to DNS. Fixes: systemd#23662
37a4613 to
6399be2
Compare
|
added a couple of additional fixes on top. |
|
@mrc0mmand this commit disables one of the DNSSEC tests you added, since we'll now just propagate a request upstream as is, and the result is now different, but we don#t really care because we don#t want to test knot, but resolved. I just commented the code for now, because there's something weird going on here: the server refuses to recurse for us, but that means the server is misconfigured: it shouldn't be an upstream resolver to resolved if it doesn#t recurse... |
The Knot DNS server in our case is configured as an authoritative DNS server (well, it can be configured only as an authoritative DNS server) and iirc in that case it shouldn't allow recursion? |
iirc there's nothing stopping a dns server being authoritative for some zone but also provide recursion. Right now it seems the server refuses to do recursion though. At least that#s what the dig output says. |
From what I've read so far it's generally agreed upon that an authoritative DNS server should not do recursion (except for maybe queries coming from localhost). And Knot does this separation completely, so Knot DNS is an authoritative DNS server (that doesn't support recursion) and Knot Resolver is a recursive resolver. Once I have a bit of spare time I'll tweak the test so resolved talks to the recursive resolver instead of directly to the authoritative server. |
|
It is considered best practice to have authoritative servers and recursive servers separate. Basically the only open-source implementation offering both in single package is bind9. All others have special instances. nsd/unbound, powerdns/pdns-recursor, knot/knot-resolver. Check https://www.fedoraproject.org/wiki/SIGs/DNS#Implementations for examples with links. |
Let's merge with that test case disabled for now, and it can be enabled again as a follow-up |
Fixes: #23662 #31223 #19227 #23737 #25105