DNS Issue with systemd-resolved

ben5123 · 2019-04-24 19:09:24

I'm having an issue getting resolved to use the DNS servers from DHCP. It seems that it is using the default fallback DNS servers (1.1.1.1, 9.9.9.10, 8.8.8.8), and I want it to use the servers from DHCP where available to take advantage of my Pi Hole at home and local services on my companies network.

I can see the correct DNS servers under the interface in resolvectl, but testing with drill it seems to only be using the global fallback settings.

$ resolvectl
Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
Fallback DNS Servers: 1.1.1.1
                      9.9.9.10
                      8.8.8.8
...
Link 3 (wlp2s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
  Current DNS Server: 10.x.x.24
         DNS Servers: 10.x.x.24
                      10.x.x.19

$ drill @10.x.x.24 xx.xxx.local
...
;; ANSWER SECTION:
xx.xxx.local.      3600    IN      A       10.x.x.24
...
$
$ drill xx.xxx.local
...
;; ANSWER SECTION:
...

I've started and enabled the systemd-networkd.service and systemd-resolved.service, and created a symbolic link from /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf. What else do I need to do to get this working right?

ben5123 · 2019-04-24 19:32:53

More information.. here's what I have for the interface network config:

$ cat /etc/systemd/network/30-wireless.network
[Match]
Name=wl*

[Network]
DHCP=ipv4

[DHCP]
UseDNS=true
UseDomains=true

Head_on_a_Stick · 2019-04-24 20:09:25

Try adding the nameserver(s) to the .network file(s), for example:

[Network]
DNS=192.168.1.254

seth · 2019-04-24 20:35:53

He seems to want to draw them from dhcp

cat /etc/resolv.conf

?

ben5123 · 2019-04-24 20:39:03

$ cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0

seth · 2019-04-24 20:55:51

That's the systemd resolver (as expectable), full output of

drill xx.xxx.local

?

ben5123 · 2019-04-24 21:00:30

Sure, here it is:

$ drill xx.xxx.local
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 57852
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; xx.xxx.local.   IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.53
;; WHEN: Wed Apr 24 15:58:16 2019
;; MSG SIZE  rcvd: 43
$

seth · 2019-04-24 21:35:05

Ah, I see - you get the answer from the resolved stub, but it doesn't resolve your local domain (so you infer it doesn't ask 10.x.x.24 but only a public DNS)
Does 10.x.x.24 full DNS or only for the subnet? (Ie. can you "drill @10.x.x.24 archlinux.org"?)

ben5123 · 2019-04-25 00:04:58

Yes, "drill @10.x.x.24 archlinux.org" works just fine. 10.x.x.24 and .19 are Windows DNS servers that are authoritative for xx.xxx.local and recursively forward everything else to CloudFlare.

One thing that I'm not sure if it could be part of the problem, when I initially installed the system there was a conflict between systemd-resolved and openresolv (going from memory, I believe those were the names). When pacman asked me to choose one or the other, I went with openresolv, and later changed my mind and uninstalled openresolv and installed the systemd version. Possibly that screwed something up? How would I figure out what?

seth · 2019-04-25 07:05:01

resolved is mandatory for systemd-networkd, a problem could arise if you're running concurrent NM services (ie. also some dhcpcd or network-manager etc.)

Does "drill archlinux.org" resolve an address (ie. does 127.0.0.53 respond at all)?
Does "resolvectl query xx.xxx.local" work?

Maybe resolved gets off the rails b/c of the ".local" domain, see https://wiki.archlinux.org/index.php/Sy … olved#mDNS for the theoretic requirements of its invocation, but try to actively deactivate it or maybe even a different tld (if you can)

ben5123 · 2019-04-25 12:00:36

That's it! It's choking up on the .local TLD.

Watching now in tcpdump, I see it's using the correct DNS server from DHCP for all lookups, except .local which doesn't seem to send any network traffic at all? I see LLMNR traffic for single label names, but nothing for any .local name. (and the query returns right away instead of timing out).

$ resolvectl query archlinux.org
archlinux.org: 138.201.81.199                  -- link: wlp2s0

-- Information acquired via protocol DNS in 856us.
-- Data is authenticated: no
$
$ resolvectl query xx.xxx.local
xx.xxx.local: resolve call failed: No appropriate name servers or networks for name found
$

My reading of that wiki page suggests it should be using mDNS for .local lookups? Even mDNS working correctly won't do the job for me, as this is a corporate network spread out over several vlans and sites. How can I make it just look up .local TLDs via DNS like anything else?

seth · 2019-04-25 12:35:32

As mentioned, you could try to actively disable "MulticastDNS=false" in resolved.conf, but if that just leads it to turn a blind eye on .local domains altogether, you're kinda screwed.
You could file a bug against resolved to treat .local domains as unicast, but there're quite some reports around the topic already…

ben5123 · 2019-04-25 15:14:39

"MulticastDNS=false" doesn't help. Searching Google I see suggestions to edit /etc/nsswitch.conf, and disable or edit avahi-daemon. None of these seem to work for me.

This is very very frustrating!

I've worked as a network admin at a number of companies, representing hundreds of thousands of users altogether, and *every single one* used a .local domain as their corporate network. What are Linux users on corporate Windows networks supposed to do? I can't be the only one wanting to do this?

seth · 2019-04-25 15:24:43

This has nothing to do w/ any avahi daemon or nsswitch (which isn't used by drill anyway) - the problem here is exclusively resolved which is no way even near being a mandatory element in network setups (nor is systemd-networkd)

Head_on_a_Stick · 2019-04-25 19:02:55

seth wrote:

resolved is mandatory for systemd-networkd

No it isn't, I can run systemd-networkd with unbound (or no local nameserver at all).

@OP: why not just remove the /etc/resolv.conf symlink and replace it with a file listing the nameservers of your choice?

With that configuration systemd-resolved will act as a consumer rather than a provider of /etc/resolv.conf

seth · 2019-04-25 19:17:53

Bad wording on my part - it's not possible to make it use openresolv, though, is it?
Ie. make it obtain and write a nameserver via dhcp which, again, seems the premise of this thread?

Head_on_a_Stick · 2019-04-25 19:22:10

seth wrote:

it's not possible to make it use openresolv, though, is it?

I think it is, yes, the symlink to the stub resolver would have to be removed though.

Disclaimer: I don't have systemd on my laptop atm so I can't test.

Arch Linux

#1 2019-04-24 19:09:24

DNS Issue with systemd-resolved

#2 2019-04-24 19:32:53

Re: DNS Issue with systemd-resolved

#3 2019-04-24 20:09:25

Re: DNS Issue with systemd-resolved

#4 2019-04-24 20:35:53

Re: DNS Issue with systemd-resolved

#5 2019-04-24 20:39:03

Re: DNS Issue with systemd-resolved

#6 2019-04-24 20:55:51

Re: DNS Issue with systemd-resolved

#7 2019-04-24 21:00:30

Re: DNS Issue with systemd-resolved

#8 2019-04-24 21:35:05

Re: DNS Issue with systemd-resolved

#9 2019-04-25 00:04:58

Re: DNS Issue with systemd-resolved

#10 2019-04-25 07:05:01

Re: DNS Issue with systemd-resolved

#11 2019-04-25 12:00:36

Re: DNS Issue with systemd-resolved

#12 2019-04-25 12:35:32

Re: DNS Issue with systemd-resolved

#13 2019-04-25 15:14:39

Re: DNS Issue with systemd-resolved

#14 2019-04-25 15:24:43

Re: DNS Issue with systemd-resolved

#15 2019-04-25 19:02:55

Re: DNS Issue with systemd-resolved

#16 2019-04-25 19:17:53

Re: DNS Issue with systemd-resolved

#17 2019-04-25 19:22:10

Re: DNS Issue with systemd-resolved

Board footer