DNS per DHCP klappt nicht (Bookworm)

[knebb]

Moin,

ich habe ein neu aufgesetztes Debian12/ Bookworm System hier. Installation inkl. Holen der Pakete via Netzwerk lief einwandfrei.

Nach dem Reboot ist das System im Netz und ich kann per ssh problemlos darauf zugreifen. IP-Adresse etc. erfolgt via DHCP. Allerdings funktioniert die DNS-Namensauflösung nicht:

Code: Alles auswählen

root@hoas:~# dig www.heise.de

; <<>> DiG 9.18.12-1-Debian <<>> www.heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54035
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.heise.de.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Jun 21 23:06:19 CEST 2023
;; MSG SIZE  rcvd: 41

root@hoas:~# ping www.heise.de
ping: www.heise.de: Temporärer Fehler bei der Namensauflösung

Gut, die /etc/resolv.conf sieht erwartungsgemäß aus und verweist auf den lokalen systemd-Cache:

Code: Alles auswählen

nameserver 127.0.0.53
options edns0 trust-ad
search .

Der DHCP Server liefert die richtigen Informationen (geprüft via dhcpdump):

Code: Alles auswählen

  TIME: 2023-06-21 23:08:10.518
    IP: 192.168.9.254 (0:26:55:d2:aa:ec) > 192.168.9.13 (52:54:0:37:1b:3b)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 88fc2341
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.9.13
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 52:54:00:37:1b:3b:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
OPTION:  54 (  4) Server identifier         192.168.9.254
OPTION:  51 (  4) IP address leasetime      7200 (2h)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   192.168.9.254
OPTION:  15 (  8) Domainname                domain.de
OPTION:   6 (  8) DNS server                192.168.9.254,192.168.9.14
OPTION: 119 ( 32) Domain Search             xxxxx                 
OPTION:  12 (  4) Host name                 hoas
OPTION:  42 (  8) NTP servers               192.168.9.14,192.168.9.254

Aber der systemd-resolver scheint davon nichts mitzukriegen. Ich habe nach der Installation nichts verändert, es ist alles im Original-Debian12 Zustand. Wenn ich in der resolv.conf die beiden DNS-Server eintrage, funktioniert es. Aber das ist ja nicht Sinn und Zweck der Sache.

Wie kann ich dem Fehler auf die Spur kommen?


Wer hat eine Idee?

Danke im Voraus!

/KNEBB

[mat6937]

Gut, die /etc/resolv.conf sieht erwartungsgemäß aus und verweist auf den lokalen systemd-Cache:

Code: Alles auswählen

nameserver 127.0.0.53
options edns0 trust-ad
search .

Aber der systemd-resolver scheint davon nichts mitzukriegen.

Wie sind die Ausgaben von:

Code: Alles auswählen

systemctl status systemd-resolved
find /etc -iname '*resolve*'

?

[JTH]

Die Ausgabe von resolvectl wäre auch interessant.

[knebb]

Moin,
ist alles in Ordnung:

Code: Alles auswählen

root@hoas:~# systemctl status systemd-resolved.service 
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Wed 2023-06-21 23:05:28 CEST; 7h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 472 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 4648)
     Memory: 7.1M
        CPU: 390ms
     CGroup: /system.slice/systemd-resolved.service
             └─472 /lib/systemd/systemd-resolved

Jun 21 23:05:27 hoas systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
Jun 21 23:05:28 hoas systemd-resolved[472]: Positive Trust Anchors:
Jun 21 23:05:28 hoas systemd-resolved[472]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457>
Jun 21 23:05:28 hoas systemd-resolved[472]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arp>
Jun 21 23:05:28 hoas systemd-resolved[472]: Using system hostname 'hoas'.
Jun 21 23:05:28 hoas systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 22 04:14:19 hoas systemd-resolved[472]: Clock change detected. Flushing caches.

Code: Alles auswählen

root@hoas:~# find /etc -iname '*resolve*'
/etc/systemd/system/dbus-org.freedesktop.resolve1.service
/etc/systemd/system/sysinit.target.wants/systemd-resolved.service
/etc/systemd/resolved.conf
/etc/.resolv.conf.systemd-resolved.bak
/etc/network/if-down.d/resolved
/etc/network/if-up.d/resolved

Code: Alles auswählen

root@hoas:~# resolvectl
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

[mat6937]

Code: Alles auswählen

root@hoas:~# resolvectl
Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Jetzt noch die Ausgaben von:

Code: Alles auswählen

resolvectl query ulm.de
cat /etc/systemd/resolved.conf

?

[knebb]

Code: Alles auswählen

root@hoas:/var# resolvectl query ulm.de
ulm.de: resolve call failed: No appropriate name servers or networks for name found

Code: Alles auswählen

root@hoas:/var# cat /etc/systemd/resolved.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=yes
#LLMNR=yes
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

[mat6937]

Code: Alles auswählen

root@hoas:/var# resolvectl query ulm.de
ulm.de: resolve call failed: No appropriate name servers or networks for name found

Code: Alles auswählen

root@hoas:/var# cat /etc/systemd/resolved.conf 

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:

Dann ergänze die [Resolve]-Section der "/etc/systemd/resolved.conf"-Datei, (temporär) mit den zeilen:

Code: Alles auswählen

DNS=192.168.9.254 192.168.9.14 8.8.8.8
FallbackDNS=1.1.1.1 9.9.9.9
LLMNR=no
DNSStubListener=yes
Cache=yes
ReadEtcHosts=yes
#Domains=

und führe nach dem speichern aus:

Code: Alles auswählen

systemctl daemon-reload
systemctl restart systemd-resolved

und poste danach die Ausgaben von:

Code: Alles auswählen

resolvectl
host heise.de 127.0.0.53
resolvectl query ulm.de

[knebb]

Nach den Änderungen funktioniert es erwartungsgemäß:

Code: Alles auswählen

root@hoas:/var# resolvectl
Global
          Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
   resolv.conf mode: stub
         DNS Servers 192.168.9.254 192.168.9.14 8.8.8.8
Fallback DNS Servers 1.1.1.1 9.9.9.9

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

Code: Alles auswählen

root@hoas:/var# host heise.de 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases: 

heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de.

Code: Alles auswählen

root@hoas:/var# resolvectl query ulm.de
ulm.de: 13.69.68.7                             -- link: ens3

-- Information acquired via protocol DNS in 67.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Ach so, die lokalen DNS funktionieren einwandfrei (alle anderen Clients im Netz haben kein Problem):

Code: Alles auswählen

root@hoas:/var# host heise.de 192.168.9.14
Using domain server:
Name: 192.168.9.14
Address: 192.168.9.14#53
Aliases: 

heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de.

Und:

Code: Alles auswählen

root@hoas:/var# host heise.de 192.168.9.254
Using domain server:
Name: 192.168.9.254
Address: 192.168.9.254#53
Aliases: 
heise.de has address 193.99.144.80
heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
heise.de mail is handled by 10 relay.heise.de.

Das kann es aber ja nicht sein, dass die DNS-Server manuell eingetragen werden müssen

[mat6937]

Das kann es aber ja nicht sein, dass die DNS-Server manuell eingetragen werden müssen

Na wäre es dir lieber, wenn die devs/maintainer die DNS-Server von google (oder gleichwertig), als Fallback-DNS-Server _hardcodiert_ hätten?

[knebb]

Nö, natürlich nicht. Die hätten meine lokalen DNS hardcodieren sollen!

Es funktioniert übringens auch ohne die externen DNS-Server, auch das war zu erwarten:

Code: Alles auswählen

root@hoas:/var# resolvectl
Global
          Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
   resolv.conf mode: stub
         DNS Servers 192.168.9.254 192.168.9.14
Fallback DNS Servers 192.168.1.254

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

Code: Alles auswählen

root@hoas:/var# host zdf.de 192.168.9.254
Using domain server:
Name: 192.168.9.254
Address: 192.168.9.254#53
Aliases: 

zdf.de has address 91.197.29.78
zdf.de mail is handled by 15 inmail.zdf.de.

Bleibt also die Frage, warum das System die vom DHCP vergebenen DNS-Server ignoriert, richtig?

[mat6937]

Bleibt also die Frage, warum das System die vom DHCP vergebenen DNS-Server ignoriert, richtig?

Ist das so? Teste mal mit dhcpdump und nmap(broadcast-dhcp-discover).

[knebb]

Bleibt also die Frage, warum das System die vom DHCP vergebenen DNS-Server ignoriert, richtig?

Ist das so? Teste mal mit dhcpdump und nmap(broadcast-dhcp-discover).

Ja, ist so.
Erstens bekommen alle anderen Clients (Debian11) problemlos IP und DNS Server.
Zweitens habe ich das mittels dhcpdump bereits geprüft- siehe meinen ersten Post.

Wie kann ich das per namep prüfen? Ist mir neu.... meintest Du tcpdump?

[mat6937]

Wie kann ich das per namep prüfen?

Code: Alles auswählen

nmap -e <Interface> --script broadcast-dhcp-discover --script-trace

[knebb]

Der Vollständigkeit halber die Ausgabe von tcpdump:

Code: Alles auswählen

root@hoas:/var# tcpdump -i ens3 udp port 67 and port 68 -vvv
tcpdump: listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:15:56.974704 IP (tos 0x0, ttl 64, id 40661, offset 0, flags [DF], proto UDP (17), length 328)
    192.168.9.13.bootpc > 192.168.9.254.bootps: [bad udp cksum 0x95a1 -> 0x3be5!] BOOTP/DHCP, Request from 52:54:00:37:1b:3b (oui Unknown), length 300, xid 0xe8ffe55e, Flags [none] (0x0000)
	  Client-IP 192.168.9.13
	  Client-Ethernet-Address 52:54:00:37:1b:3b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Release
	    Server-ID (54), length 4: 192.168.9.254
	    Hostname (12), length 4: "hoas"
	    Client-ID (61), length 19: hardware-type 255, 00:37:1b:3b:00:01:00:01:2c:25:d2:87:52:54:00:37:1b:3b
	    END (255), length 0
	    PAD (0), length 0, occurs 23
10:15:57.231880 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:37:1b:3b (oui Unknown), length 300, xid 0xfa84506e, Flags [none] (0x0000)
	  Client-Ethernet-Address 52:54:00:37:1b:3b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Discover
	    Requested-IP (50), length 4: 192.168.9.13
	    Hostname (12), length 4: "hoas"
	    Parameter-Request (55), length 13: 
	      Subnet-Mask (1), BR (28), Time-Zone (2), Default-Gateway (3)
	      Domain-Name (15), Domain-Name-Server (6), Unknown (119), Hostname (12)
	      Netbios-Name-Server (44), Netbios-Scope (47), MTU (26), Classless-Static-Route (121)
	      NTP (42)
	    Client-ID (61), length 19: hardware-type 255, 00:37:1b:3b:00:01:00:01:2c:25:d2:87:52:54:00:37:1b:3b
	    END (255), length 0
	    PAD (0), length 0, occurs 8
10:15:57.232530 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 366)
    192.168.9.254.bootps > 192.168.9.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 338, xid 0xfa84506e, Flags [none] (0x0000)
	  Your-IP 192.168.9.13
	  Client-Ethernet-Address 52:54:00:37:1b:3b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Offer
	    Server-ID (54), length 4: 192.168.9.254
	    Lease-Time (51), length 4: 7200
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.9.254
	    Domain-Name (15), length 8: "domain.de"
	    Domain-Name-Server (6), length 8: 192.168.9.254,dns2.domain.de
	    Unknown (119), length 32: 90926693,1650590308,1694503777,1802858613,1852535925,1919971937,2020176685,1851965446
	    Hostname (12), length 4: "hoas"
	    NTP (42), length 8: dns2.domain.de,192.168.9.254
	    END (255), length 0
10:15:57.232677 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:37:1b:3b (oui Unknown), length 300, xid 0xfa84506e, Flags [none] (0x0000)
	  Client-Ethernet-Address 52:54:00:37:1b:3b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Request
	    Server-ID (54), length 4: 192.168.9.254
	    Requested-IP (50), length 4: 192.168.9.13
	    Hostname (12), length 4: "hoas"
	    Parameter-Request (55), length 13: 
	      Subnet-Mask (1), BR (28), Time-Zone (2), Default-Gateway (3)
	      Domain-Name (15), Domain-Name-Server (6), Unknown (119), Hostname (12)
	      Netbios-Name-Server (44), Netbios-Scope (47), MTU (26), Classless-Static-Route (121)
	      NTP (42)
	    Client-ID (61), length 19: hardware-type 255, 00:37:1b:3b:00:01:00:01:2c:25:d2:87:52:54:00:37:1b:3b
	    END (255), length 0
	    PAD (0), length 0, occurs 2
10:15:57.233063 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 366)
    192.168.9.254.bootps > 192.168.9.13.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 338, xid 0xfa84506e, Flags [none] (0x0000)
	  Your-IP 192.168.9.13
	  Client-Ethernet-Address 52:54:00:37:1b:3b (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: ACK
	    Server-ID (54), length 4: 192.168.9.254
	    Lease-Time (51), length 4: 7200
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.9.254
	    Domain-Name (15), length 8: "domain.de"
	    Domain-Name-Server (6), length 8: 192.168.9.254,dns2.domain.de
	    Unknown (119), length 32: 90926693,1650590308,1694503777,1802858613,1852535925,1919971937,2020176685,1851965446
	    Hostname (12), length 4: "hoas"
	    NTP (42), length 8: dns2.domain.de,192.168.9.254
	    END (255), length 0

Das einzige, was mir auffällt ist, dass er nur eine IP auflöst (die zu dns2.domain.de), die andere aber auf der IP belässt und nicht auflöst. Starte ich tcpdump mit "-n", sind beide als IP gelistet. Ist also eher ein tcpdump-Problem.

Und hier noch die Ausgabe von nmap, auch hier werden die DNS-Server übermittelt:

Code: Alles auswählen

root@hoas:/var# nmap -e ens3 --script broadcast-dhcp-discover --script-trace
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-22 10:23 CEST
NSOCK INFO [0.0500s] nsock_iod_new2(): nsock_iod_new (IOD #1)
NSOCK INFO [0.3560s] nsock_pcap_open(): PCAP requested on device 'ens3' with berkeley filter 'ip && udp dst port 68' (promisc=1 snaplen=1500 to_ms=200) (IOD #1)
NSOCK INFO [0.3560s] nsock_pcap_open(): PCAP created successfully on device 'ens3' (pcap_desc=6 bsd_hack=0 to_valid=1 l3_offset=14) (IOD #1)
NSE: Ethernet open ens3
NSE: Ethernet frame (352 bytes) > ens3
NSE: Ethernet close ens3
NSOCK INFO [0.3790s] nsock_pcap_read_packet(): Pcap read request from IOD #1  EID 13
NSOCK INFO [1.4100s] nsock_trace_handler_callback(): Callback: READ-PCAP SUCCESS for EID 13 
NSOCK INFO [1.4110s] nsock_pcap_read_packet(): Pcap read request from IOD #1  EID 21
NSOCK INFO [9.7060s] nsock_trace_handler_callback(): Callback: READ-PCAP SUCCESS for EID 21 
NSOCK INFO [9.7060s] nsock_pcap_read_packet(): Pcap read request from IOD #1  EID 29
NSOCK INFO [9.7100s] nsock_trace_handler_callback(): Callback: READ-PCAP SUCCESS for EID 29 
NSOCK INFO [9.7100s] nsock_pcap_read_packet(): Pcap read request from IOD #1  EID 37
NSOCK INFO [10.3790s] nsock_trace_handler_callback(): Callback: READ-PCAP TIMEOUT for EID 37 
NSE: > | CLOSE
NSOCK INFO [10.3790s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
NSE: Ethernet close 
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     Interface: ens3
|     IP Offered: 192.168.9.140
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.9.254
|     IP Address Lease Time: 2h00m00s
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.9.254
|     Domain Name Server: 192.168.9.254, 192.168.9.14
|     Domain Name: domain.de
|_    NTP Servers: 192.168.9.14, 192.168.9.254
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.42 seconds

[JTH]

Na wäre es dir lieber, wenn die devs/maintainer die DNS-Server von google (oder gleichwertig), als Fallback-DNS-Server _hardcodiert_ hätten?

Das ist beim systemd-Upstream tatsächlich der Fall:

Code: Alles auswählen

option('dns-servers', type : 'string',
       description : 'space-separated list of default DNS servers',
       value : '1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2001:4860:4860::8888#dns.google 2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google')

DNS-Server von Cloudflare und Google sind da die vorgegebenen Rückfallwerte, falls andere fehlen oder fehlschlagen. Da gab es erwartbar schon Einwände dazu:
Don't fallback to Google DNS
Please switch to cloudflare for fallback DNS servers (Gut, ob das jetzt die bessere Lösung ist …)

Debian entfernt die Rückfallwerte aber:

Code: Alles auswählen

	-Ddns-servers='' \

Mich wundert hier ein bisschen (mehr aus Interesse am Hintergrund), dass systemd-resolved nach einer frischen Installation überhaupt aktiv ist. Es gibt bisher wenige Pakete, die davon abhängen. Wurd es manuell installiert?

Noch ein paar Gedanken für Anhaltspunkte zum Einordnen:
Was steht in /run/systemd/resolve/resolv.conf, wenn nicht gerade der Nameserver manuell konfiguriert ist?
Ist resolvconf parallel ungünstigerweise auch installiert?
Wie ist das Netzwerk überhaupt konfiguriert (ifupdown (= /etc/network/interfaces), NetworkManager, systemd-networkd, …)? Die spielen auf unterschiedliche Weise mit systemd-resolved zusammen.
Sind die anderen Rechner, auf denen es keine Probleme gibt, auch frisch aufgesetzt oder tragen alte Konfiguration mit?
Nur mal so: Wie sieht /etc/nsswitch.conf aus?

[knebb]

Ich habe jetzt mal aus der "/etc/systemd/resolved.conf" die fest kodierten rausgenommen und den Rest drinnen gelassen:

Code: Alles auswählen

#DNS=192.168.9.254 192.168.9.14 8.8.8.8
#FallbackDNS=1.1.1.1 9.9.9.9
LLMNR=no
DNSStubListener=yes
Cache=yes
ReadEtcHosts=yes
#Domains=

Nach dem Neustart der entsprechenden Dienste (wichtig auch das networking!):

Code: Alles auswählen

root@hoas:~# vi /etc/systemd/resolved.conf 
root@hoas:~# systemctl daemon-reload 
root@hoas:~# systemctl restart systemd-resolved
root@hoas:~# systemctl restart networking

Ergibt sich ein interessantes Bild:

Code: Alles auswählen

root@hoas:~# host www.ard.de
www.ard.de is an alias for www.ard.de.edgekey.net.
www.ard.de.edgekey.net is an alias for e7671.e6.akamaiedge.net.
e7671.e6.akamaiedge.net has address 23.192.90.90
root@hoas:~# ping www.ard.de
ping: www.ard.de: Temporärer Fehler bei der Namensauflösung

WTF????

[knebb]

Mich wundert hier ein bisschen (mehr aus Interesse am Hintergrund), dass systemd-resolved nach einer frischen Installation überhaupt aktiv ist. Es gibt bisher wenige Pakete, die davon abhängen. Wurd es manuell installiert?

Nein, eigentlich nicht. Debian Grundinstallation ohne X-Server, nur ssh dazu installiert.

Noch ein paar Gedanken für Anhaltspunkte zum Einordnen:
Was steht in /run/systemd/resolve/resolv.conf, wenn nicht gerade der Nameserver manuell konfiguriert ist?

Code: Alles auswählen

root@hoas:~# cat /run/systemd/resolve/resolv.conf 
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

# No DNS servers known.
search .

Ist resolvconf parallel ungünstigerweise auch installiert?

Nein:

Code: Alles auswählen

root@hoas:~# dpkg -l| grep resolv
ii  libnss-resolve:amd64           252.6-1                        amd64        nss module to resolve names via systemd-resolved
ii  systemd-resolved               252.6-1                        amd64        systemd DNS resolver

Wie ist das Netzwerk überhaupt konfiguriert (ifupdown (= /etc/network/interfaces)

Code: Alles auswählen

root@hoas:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens3
iface ens3 inet dhcp
# This is an autoconfigured IPv6 interface
iface ens3 inet6 auto

, NetworkManager, systemd-networkd, …)? Die spielen auf unterschiedliche Weise mit systemd-resolved zusammen.

Das kann ich nicht genau sagen, außer: Grundinstallation, nichts zusätzlich installiert.

Sind die anderen Rechner, auf denen es keine Probleme gibt, auch frisch aufgesetzt oder tragen alte Konfiguration mit?

Älter. Die anderen Kisten sind ein bunter Zoo aus allem (Handys, Win&Mac-Laptops, IoT etc.. Zwei Debian12 sind dabei, die waren vorher Debian 11. Funktionieren einwandfrei.

Nur mal so: Wie sieht /etc/nsswitch.conf aus?

Code: Alles auswählen

root@hoas:~# cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files systemd
gshadow:        files systemd

hosts:          files resolve [!UNAVAIL=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

[mat6937]

Code: Alles auswählen

root@hoas:~# cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files systemd
gshadow:        files systemd

hosts:          files resolve [!UNAVAIL=return] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Teste mal auch mit folgender Änderung::

Code: Alles auswählen

# hosts:          files resolve [!UNAVAIL=return] dns myhostname
hosts:          files dns resolve myhostname

in der /etc/nsswitch.conf

[knebb]

Ok, damit funktioniert es. Danke!

Kannst Du mir das erklären?

Ich werde am Wochenende mal nochmal eine Debian12 aufsetzen und mal gucken, ob das da genauso ist.

/KNEBB

[mat6937]

Kannst Du mir das erklären?

Mit der Änderung wird zu erst "nss-dns von glibc upstream" zum lesen der "/etc/resolv.conf" benutzt und nicht nss-resolve.

[MSfree]

Ich habe hier glaube ich ein ähnliches Kuriosum.

Die Netzwerkschnittstelle wird via systemd-networkd per DHCP konfiguriert. Aufgrund dieses Threads habe ich bei mir nachgescheut und entdeckt, daß die Datei /etc/resolv.conf nicht aktualisiert wird. Zwar steht dort die korrekte Information drin, die zum Erreichen des DNS erforderlich ist. Ich hätte aber erwartet, daß die Datei auch mit jedem Reboot, bei dem ja auch ein DHCP-Request stattfindet, aktualisiert wird. Die Datei ist aber von Ende April, das letzte reboot war aber vor 38 Tagen, also Mitte Mai.

[JTH]

Aufgrund dieses Threads habe ich bei mir nachgescheut und entdeckt, daß die Datei /etc/resolv.conf nicht aktualisiert wird.

Wenn du das zusammen mit systemd-resolved benutzt: Ist /etc/resolv.conf ein Symlink auf /run/systemd/resolve/stub-resolv.conf oder /run/systemd/resolve/resolv.conf?

Nein, eigentlich nicht. Debian Grundinstallation ohne X-Server, nur ssh dazu installiert.

Okay, da war soweit im Folgenden nichts auffälliges, neben dem, was mat6937 angemerkt hat. Wobei mich wundert, dass es mit der Änderung funktioniert. Denn damit ist die /etc/resolv.conf nun erst recht essentiell (wenn ich mich grad nicht vertue), aber ja weiterhin nicht korrekt gefüllt.

Wenn es da jetzt mit der geänderten nsswitch.conf funktioniert: Ist libnss-resolve denn überhaupt installiert? Wenn nicht, könnte das die Fehlerursache vorher sein.


(Mich wundert eigentlich schon, dass systemd-resolved nach frischer, relativ minimaler Installation installiert ist und läuft. War bei mir heut morgen in einer Testinstallation nicht der Fall. Aber das mag durch einige, wenige Abhängigkeiten vorkommen.)

[MSfree]

Wenn du das zusammen mit systemd-resolved benutzt: Ist /etc/resolv.conf ein Symlink auf /run/systemd/resolve/stub-resolv.conf oder /run/systemd/resolve/resolv.conf?

Nein, systemd-resolved ist nicht installiert und /etc/resolv.conf ist eine normale Datei. Ich weiß auch nicht, ob ich diesen systemd-resolved haben will. Einen DNS-Cache, der noch dazu via unerwünschter externer DNS (cluodflare) versucht aufzulösen, ist mir mehr als suspekt.

Wie gesagt, der Inhalt der /etc/resolv.conf ist korrekt und der wurde ja irgendwann im April mit gültigem Inhalt via DHCP erstellt, die Namensauflösung funktioniert deshalb auch. Nur seit dem wird sie nicht mehr aktualisiert, was mich zu dem Schluß bringt, daß meine Namensauflösung ebenfalls fehlschlagen würde, wenn ich die Datei lösche oder leere.

[JTH]

Nein, systemd-resolved ist nicht installiert und /etc/resolv.conf ist eine normale Datei.

Wenn nicht stattdessen resolvconf oder irgendetwas vergleichbares oder einer der verschiedenen Netzwerkmanager installiert ist, wird die Datei natürlich nie automatisch aktualisiert.

der noch dazu via unerwünschter externer DNS (cluodflare) versucht aufzulösen

Wie oben geschrieben ist Cloudflare unter Debian nicht als Rückfallnamensserver einkompiliert oder anderweitig festgelegt. Nicht dass hier irgendwelche falschen Gerüchte entstehen

[mat6937]

Einen DNS-Cache, der noch dazu ...

BTW: Den Cache des systemd-resolved kann man in der /etc/systemd/resolved.conf ([Resolve]-Section), auch deaktivieren:

Code: Alles auswählen

Cache=no

(default ist yes).