Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #246401

Re: iwd + systemd-networkd + resolvconf wrinkles

From David Wright <deblis@lionunicorn.co.uk>
Newsgroups linux.debian.user
Subject Re: iwd + systemd-networkd + resolvconf wrinkles
Date 2022-03-18 06:00 +0100
Message-ID <E2cSt-2us6-5@gated-at.bofh.it> (permalink)
References <E0HH3-1AwT-9@gated-at.bofh.it> <E0Nt7-1E0V-1@gated-at.bofh.it> <E1kfn-1XxT-11@gated-at.bofh.it> <E1XA5-2llz-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Thu 17 Mar 2022 at 12:12:28 (+0000), Thomas Pircher wrote:
> David Wright wrote:
> > As I said, I tried that.
> 
> Ack. I must have glossed over that. Sorry. The rest of my mail stands,
> though.
> 
> > > You can configure various settings for the DNS resolver in your
> > > systemd-networkd setting and in /etc/systemd/resolved.conf.
> > 
> > Like what?
> 
> Full description here:
> https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BDHCPv4%5D%20Section%20Options
> https://www.freedesktop.org/software/systemd/man/resolved.conf.html

Yes, I read those, but I can see nothing to profitably change.

> But what I find useful is to be able to select per interface if DNS
> should be used from the DHCP server, if there is a clash.
> I also ended up disabling DNSSEC on some machines due to a broken
> server.

I am assuming that I don't have that problem at home. As for
on-the-road, I'm not sure I'd be capable of diagnosing such problems.

> > > On bookworm you also have the resolvectl tool, which helps debugging DNS
> > > issues.
> > 
> > And bullseye has that too. I don't really know how to use it.
> 
> Cool. If you just type resolvectl, it will show you which information it
> got on each interface.

This is machine F, where /etc/resolv.conf is a file, containing 192.168.1.1 :

$ resolvectl 
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Link 2 (enp2s2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (wlp2s4)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
$ host www.google.com
www.google.com has address 142.250.138.105
www.google.com has address 142.250.138.103
www.google.com has address 142.250.138.106
www.google.com has address 142.250.138.99
www.google.com has address 142.250.138.104
www.google.com has address 142.250.138.147
www.google.com has IPv6 address 2607:f8b0:4000:80e::2004
$ host www.lionunicorn.co.uk
www.lionunicorn.co.uk has address 149.255.60.149
$ 

Those responses were instantaneous. (I don't think I should expect
resolvectl query   to work here.)

And this is machine R, with systemd-resolved running:

$ ls -l /etc/resolv.conf 
lrwxrwxrwx [ … ] /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ resolvectl
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp1s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlan0)
    Current Scopes: DNS LLMNR/IPv4
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
$ host www.google.com
www.google.com has address 142.251.32.196
www.google.com has IPv6 address 2607:f8b0:4023:1002::63
www.google.com has IPv6 address 2607:f8b0:4023:1002::67
www.google.com has IPv6 address 2607:f8b0:4023:1002::93
www.google.com has IPv6 address 2607:f8b0:4023:1002::69
;; connection timed out; no servers could be reached

$ resolvectl query www.google.com
www.google.com: 2607:f8b0:4000:805::2004       -- link: wlan0
                142.251.46.132                 -- link: wlan0

-- Information acquired via protocol DNS in 33.6ms.
-- Data is authenticated: no
$ resolvectl query www.lionunicorn.co.uk
www.lionunicorn.co.uk: resolve call failed: Connection timed out
$ 

Here, host's substantive response was immediate, but I had to wait for
the prompt to return.

> You can also debug your slow queries by using "resolvectl query
> google.com". It will show you which interface the query goes out on and
> how long it took to get the response.

The attached file has the date, hour, hostname, systemd-resolved and
PID removed, and it pertains to the www.lionunicorn.co.uk query above.
Perhaps this would pinpoint a problem.

> > There seem to be timeouts involved in most cases, so   time ping -c 1 foo
> > will typically take 15sec, and host lookups will take 10 or 20sec.
> 
> That is far too long. A wild guess: you may have received a bunch of
> unresponsive DNS servers from your DHCP reply, and your machine is
> trying to use them in turn, until it finds a working server?
> DNSSEC problem? Or do you get IPv6 addresses for the DNS server, but
> they are not reachable?
> 
> You can try debugging this with the resolvectl tool, to find out the
> list of the servers. Then query them with the dig tool from the
> bind9-dnsutils package:
> 
> dig google.com @8.8.8.8
> 
> Replace the IP address in @8.8.8.8 with the an IP from the output of
> resolvectl.

This response is immediate on R:

$ dig www.lionunicorn.co.uk @192.168.1.1

; <<>> DiG 9.16.22-Debian <<>> www.lionunicorn.co.uk @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30004
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.lionunicorn.co.uk.         IN      A

;; ANSWER SECTION:
www.lionunicorn.co.uk.  10800   IN      A       149.255.60.149

;; Query time: 191 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Mar 17 23:03:37 CDT 2022
;; MSG SIZE  rcvd: 66

$ 

In case of interest, the query time (191, 195 msec) on machine R is
consistently slower than machine F (28, 44 msec). (R is a /much/
faster machine than F, being 10 years younger.)

> > # resolvectl query smtp.lionunicorn.co.uk   answered in 57.6 secs.
> > # resolvectl query lionunicorn.co.uk   failed with:
> > lionunicorn.co.uk: resolve call failed: Query timed out
> 
> On my machine I get:
> 
> # resolvectl query smtp.lionunicorn.co.uk
> smtp.lionunicorn.co.uk: 149.255.60.149         -- link: vlan3512
> 
> -- Information acquired via protocol DNS in 31.0ms.
> -- Data is authenticated: no
> 
> Try running the queries with dig, as described above.

Silly me: I used www this time, instead of smtp. But I just checked,
and it resolves the same address in the same time. It's all just
pointing at cloud204.unlimitedwebhosting.co.uk in reality.

> > The debug output is difficult to interpret, though I did notice that
> > it was reporting "cache misses" repeatedly on the same address (but
> > there must be some caching going on, because there was an occasional
> > hit being reported).
> 
> It really sounds like some of the DNS servers are not reachable.
> 
> > The idea of "debugging DNS issues" doesn't exactly thrill me. I'm
> > imagining a scenario where I'm sitting in an airport or motel room,
> > having managed to make a connection with iwd and negotiate their
> > captive portal or whatever, and then run into /this/ problem.
> 
> Ack, fully understand. I do think there is something broken in your
> network setup or the server that gives you the list of DNS server is not
> configured correctly.

The same server is being used by machines F and R, and I could have
equally well set the two laptops up in the opposite configuration.
So something has to be wrong in the configuration of R. The nameserver
address of 127.0.0.53 in R's /etc/resolv.conf goes into one end of
systemd-resolved, and should come out at the other end as 192.168.1.1,
the sole nameserver, residing at the edge of my LAN. What goes on
inside systemd-resolved's stomach is a deep mystery.

> If you have found a way to fix the problem, or work around it, by using
> another tool, and this works for you, all the power to you. :-)

Yes, either resolvconf (for travel), or a fixed 192.168.1.1 suffices
(at home).

Cheers,
David.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-14 02:30 +0100
  Re: iwd + systemd-networkd + resolvconf wrinkles Thomas Pircher <thp.debian@p5r.uk> - 2022-03-14 08:40 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-15 19:40 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Thomas Pircher <thp.debian@p5r.uk> - 2022-03-17 13:40 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles Nicholas Geovanis <nickgeovanis@gmail.com> - 2022-03-18 20:30 +0100
            Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-19 16:40 +0100
  Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 00:00 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Stefan Monnier <monnier@iro.umontreal.ca> - 2022-03-17 15:00 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 16:00 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Stefan Monnier <monnier@iro.umontreal.ca> - 2022-03-18 13:50 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 15:50 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Charlie <taoquester@gmail.com> - 2022-03-19 00:40 +0100
          wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-23 05:30 +0100
            Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf  wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-23 19:30 +0100
            Re: wpa_supplicant, was Re: iwd + systemd-networkd + resolvconf  wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-24 17:20 +0100
  Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-17 16:10 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-18 06:00 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 15:50 +0100
  Re: iwd + systemd-networkd + resolvconf wrinkles RP <reyadmin@gmail.com> - 2022-03-17 18:10 +0100
  Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-18 22:20 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-19 13:40 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Nicholas Geovanis <nickgeovanis@gmail.com> - 2022-03-19 16:40 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-21 14:20 +0100
    Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-19 16:40 +0100
      Re: iwd + systemd-networkd + resolvconf wrinkles Brian <ad44@cityscape.co.uk> - 2022-03-19 20:00 +0100
        Re: iwd + systemd-networkd + resolvconf wrinkles Stella Ashburne <rewefie@gmx.com> - 2022-03-23 13:30 +0100
          Re: iwd + systemd-networkd + resolvconf wrinkles David Wright <deblis@lionunicorn.co.uk> - 2022-03-23 16:40 +0100

csiph-web