[gelöst] dns (?) will nicht so recht

[smutbert]

Hi,

auf meinem Raspberry Pi will DNS im Heimnetzwerk nicht so recht funktionieren – auf anderen Computern im Heimnetzwerk dagegen schon.
Das Auflösen von Hostnamen öffentlicher Namen (im Internet) ist dagegen nirgends ein Problem. Ein System (chiron.pan) fungiert mit dnsmasq als DHCP und DNS-Server für das lokale Netz und leitet DNS-Anfragen fürs Internet an einen weiteren DNS-Server weiter.

Was mich komplett verwirrt ist das hier (alles auf dem Raspberry Pi)

Code: Alles auswählen

$ cat /etc/resolv.conf 
nameserver 192.168.0.1

$ nslookup chiron.pan
Server:		192.168.0.1
Address:	192.168.0.1#53

Name:	chiron.pan
Address: 192.168.0.1
$ ping chiron.pan
ping: chiron.pan: Name or service not known

hilfe?

[mat6937]

Was mich komplett verwirrt ist das hier (alles auf dem Raspberry Pi)

Code: Alles auswählen

$ cat /etc/resolv.conf 
nameserver 192.168.0.1

$ nslookup chiron.pan
Server:		192.168.0.1
Address:	192.168.0.1#53

Name:	chiron.pan
Address: 192.168.0.1
$ ping chiron.pan
ping: chiron.pan: Name or service not known

nslookup fragt die DNS ab, ping wird vorher von wo anders eine Antwort bekommen haben und hat deshalb die DNS nicht mehr abgefragt.
Wie sind auf deinem PI, die Ausgaben von:

Code: Alles auswählen

cat /etc/nsswitch.conf
sudo netstat -tulpena | grep -i 53
cat /etc/hosts

?

[smutbert]

Danke, das ist die richtige Spur und bringt eine provisorische Lösung. Zuerst einmal das weniger interessantere

Code: Alles auswählen

$ cat /etc/hosts
127.0.0.1	localhost
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

(für den eigenen Hostnamen ist libnss-myhostname installiert)

Code: Alles auswählen

$ netstat -tulpena | grep -i 53
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      103        17724      425/systemd-resolve 
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      103        17730      425/systemd-resolve 
tcp        0      0 127.0.0.1:13666         127.0.0.1:41890         ESTABLISHED 65534      16796      443/LCDd            
tcp        0      0 127.0.0.1:13666         127.0.0.1:41884         ESTABLISHED 65534      16795      443/LCDd            
tcp6       0      0 :::5355                 :::*                    LISTEN      103        17727      425/systemd-resolve 
udp        0      0 127.0.0.53:53           0.0.0.0:*                           103        17729      425/systemd-resolve 
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           103        17723      425/systemd-resolve 
udp6       0      0 :::5355                 :::*                                103        17726      425/systemd-resolve

und zuletzt nsswich, das hatte ich gar nicht auf dem Schirm

Code: Alles auswählen

# /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
group:          files
shadow:         files
gshadow:        files

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

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

netgroup:       nis

Das lenkt den Verdacht dann wohl auf das resolve und [!UNAVAIL=return]. Tatsächlich funktioniert es nach dem Stoppen von systemd-resolved erst einmal.

Dann geht es jetzt an die Fehlersuche in systemd-resolved. als erstes entdecke ich die Möglichkeiten vom Befehl resolvectl.

[mat6937]

Code: Alles auswählen

# /etc/nsswitch.conf
passwd:         files
group:          files
shadow:         files
gshadow:        files

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

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

netgroup:       nis

Ändere die Zeile:

Code: Alles auswählen

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

in

Code: Alles auswählen

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

und starte danach systemd-resolved. Danach testen.

EDIT:

Wenn der DNS-Server 192.168.0.1 benutzt werden soll, musst Du systemd-resolved entsprechend konfigurieren.

[smutbert]

Danke für den Tipp, der funktioniert natürlich.

Die „richtige“ Lösung wäre aber...

Wenn der DNS-Server 192.168.0.1 benutzt werden soll, musst Du systemd-resolved entsprechend konfigurieren.

...und da hakt es überraschenderweise nicht einmal.

DNSSEC ist das Problem, aber was das soll verstehe ich nicht. So sieht es mit aktiviertem DNSSEC aus

Code: Alles auswählen

$ resolvectl status wlan0
Link 3 (wlan0)
      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: yes
  Current DNS Server: 192.168.0.1
         DNS Servers: 192.168.0.1
$ resolvectl query chiron.pan    
chiron.pan: resolve call failed: DNSSEC validation failed: no-signature
$ resolvectl query debianforum.de
debianforum.de: 144.76.154.165                 -- link: wlan0

-- Information acquired via protocol DNS in 200.1ms.
-- Data is authenticated: no

und mit deaktiviertem

Code: Alles auswählen

$ resolvectl status wlan0                  
Link 3 (wlan0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.0.1
         DNS Servers: 192.168.0.1
$ resolvectl query chiron.pan    
chiron.pan: 192.168.0.1                        -- link: wlan0

-- Information acquired via protocol DNS in 7.8ms.
-- Data is authenticated: no
$ resolvectl query debianforum.de
debianforum.de: 144.76.154.165                 -- link: wlan0

-- Information acquired via protocol DNS in 5.5ms.
-- Data is authenticated: no

Eigentlich hätte ich DNSSEC fürs Internet ganz gerne, aber vielleicht geht das gar nicht ohne die Namensauflösung im Heimnnetzwerk zu verlieren?

[mat6937]

Eigentlich hätte ich DNSSEC fürs Internet ganz gerne, aber vielleicht geht das gar nicht ohne die Namensauflösung im Heimnnetzwerk zu verlieren?

Versuch mal mit:

Code: Alles auswählen

DNSSEC=allow-downgrade

Hast Du nur den 192.168.0.1 eingetragen? Der wird ja kein DNSSEC können, oder?
Versuch mal mit zusätzlichen (externen) DNS-Servern für systemd-resolved.

EDIT:

Wie ist die Ausgabe von:

Code: Alles auswählen

resolvectl query loc.gov

und

Code: Alles auswählen

resolvectl query sigok.verteiltesysteme.net

?

EDIT 2:

... und die Ausgabe von:

Code: Alles auswählen

dig +dnssec +cookie sigok.verteiltesysteme.net @192.168.0.1

?

[smutbert]

DNSSEC=allow-downgrade war bereits eingetragen (ist auch der default).

Hast Du nur den 192.168.0.1 eingetragen? Der wird ja kein DNSSEC können, oder?

Bei 192.168.0.1 handelt es sich um ein Debian mit dnsmasq. dnssec ist in dessen Konfiguration aktiviert, aber das wird dnsmasq ja höchstens von den DNS-Servern im Internet weiterreichen können.
dnssec ist in dnsmasq nicht einmal aktiviert.

und ja soweit ich das verstehe ist nur 192.168.0.1 eingetragen - diese Information verteilt ja 192.168.0.1 selbst per DHCP (ich wüsste spontan gar nicht wie ich das ändern könnte). Abgesehen halt von dem DNS-Server an den Anfragen für öffentliche Adressen weitergeleitet werden.

Code: Alles auswählen

$ resolvectl query loc.gov
loc.gov: 104.16.55.16                          -- link: wlan0
         104.16.54.16                          -- link: wlan0

-- Information acquired via protocol DNS in 460.0ms.
-- Data is authenticated: yes
$ resolvectl query sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139      -- link: wlan0

-- Information acquired via protocol DNS in 947.2ms.
-- Data is authenticated: yes

und

Code: Alles auswählen

$ dig +dnssec +cookie sigok.verteiltesysteme.net @192.168.0.1

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +cookie sigok.verteiltesysteme.net @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61515
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;sigok.verteiltesysteme.net.	IN	A

;; ANSWER SECTION:
sigok.verteiltesysteme.net. 60	IN	A	134.91.78.139
sigok.verteiltesysteme.net. 60	IN	RRSIG	A 5 3 60 20210301030001 20201130030001 30665 verteiltesysteme.net. PZH3/ddCk3i/fPmDZ54eC8QzLyQYp9laFNkY+fRpLFdAgdlInzTjCY8O 60rFCyf1kL76qJoGw4JYhHektSOIyroZYAQZ4jWeJDAROLu6efV9fPns 4mAj+zQQ9Sg+W/g/ATDTxGvOXv1wejRCR2kJ1O8KZsVj3chE7K+qxJFl 6Is=

;; Query time: 779 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Dec 18 20:51:43 CET 2020
;; MSG SIZE  rcvd: 251

[mat6937]

... und ja soweit ich das verstehe ist nur 192.168.0.1 eingetragen - diese Information verteilt ja 192.168.0.1 selbst per DHCP (ich wüsste spontan gar nicht wie ich das ändern könnte).

Das kannst Du in der config-Datei des systemd-resolved (... der ja aktiviert ist) ändern. Z. B.:

Code: Alles auswählen

:~# cat /etc/systemd/resolved.conf

[Resolve]
DNS=9.9.9.9 8.8.8.8 192.168.0.1
FallbackDNS=4.2.2.1 4.2.2.2
LLMNR=no
DNSStubListener=yes
Cache=yes
#ReadEtcHosts=no
#Domains=<....>

Dann sollte in der /etc/resolv.conf:

Code: Alles auswählen

nameserver 127.0.0.53

eingetragen werden/sein. 192.168.0.1 muss dann nicht per DHCP verteilt werden.

[smutbert]

Ach so, du meinst auf dem Pi (ich war gedanklich beim dnsmasq des DHCP/DNS-Servers). Ja das kann ich natürlich probieren:

Code: Alles auswählen

$ cat /etc/resolv.conf 
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 192.168.0.1

Code: Alles auswählen

$ resolvectl query chiron.pan
chiron.pan: resolve call failed: 'chiron.pan' not found
$ resolvectl query sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139      -- link: wlan0

-- Information acquired via protocol DNS in 340.2ms.
-- Data is authenticated: yes

außer, dass es dann auch mit nslookup nicht mehr funktioniert

Code: Alles auswählen

$ nslookup chiron.pan
Server:		9.9.9.9
Address:	9.9.9.9#53

** server can't find chiron.pan: NXDOMAIN

Code: Alles auswählen

$ dig +dnssec +cookie chiron.pan @192.168.0.1

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +cookie chiron.pan @192.168.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4130
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;chiron.pan.			IN	A

;; ANSWER SECTION:
chiron.pan.		0	IN	A	192.168.0.1

;; Query time: 1 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Fri Dec 18 22:29:36 CET 2020
;; MSG SIZE  rcvd: 55

Der ignoriert 192.168.0.1 einfach obwohl der die gewünschte Adresse auflösen könnte.

Ich stehe da so daneben wo es doch bei einem anderen System mit (netwerkmäßig) gleicher Konfiguration im gleichen Netzwerk problemlos klappt.
Wenn du noch Ideen hast was hier los sein könnte, mach ich gerne mit, um der Sache auf die Spur zu kommen.


Allerdings hätte ich dank dir auch schon eine zufriedenstellende Lösung:
systemd-resolved von der Funktion her darauf beschränken die resolv.conf zur Verfügung zu stellen und mit der nsswitch.conf gemäß deinem Vorschlag dafür zu sorgen, dass tatsächlich DNS verwendet wird. Allerdings hätte ich da noch eine Frage

in

Code: Alles auswählen

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

Wozu noch das [!UNAVAIL=return] am Ende der Kette, wenn keine der Quellen verfügbar ist?
Mich interessiert das auch weil diese Abbruchbedingung auf Systemen ohne systemd-resolved gar nicht vorkommt.

[mat6937]

Allerdings hätte ich da noch eine Frage

in

Code: Alles auswählen

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

Wozu noch das [!UNAVAIL=return] am Ende der Kette, wenn keine der Quellen verfügbar ist?
Mich interessiert das auch weil diese Abbruchbedingung auf Systemen ohne systemd-resolved gar nicht vorkommt.

Ja, das hast Du Recht, "[!UNAVAIL=return]" wird am Ende nicht benötigt. Ich habe nur alles vor das "resolve" geschoben.

BTW: Man kann lokale domains auch mit systemd-resolved auflösen. Z. B. im Subnetz meiner FritzBox die lokale domain "fritz.box":

in der resolved.conf habe ich:

Code: Alles auswählen

[Resolve]
DNS=9.9.9.9 8.8.8.8 192.168.178.1
FallbackDNS=4.2.2.1 4.2.2.2
LLMNR=no
DNSStubListener=yes
Cache=yes
ReadEtcHosts=no
Domains=fritz.box

und in der nsswitch.conf:

Code: Alles auswählen

hosts:          files dns resolve

ergibt:

Code: Alles auswählen

:~ $ host fritz.box 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases: 

fritz.box has address 192.168.178.1

Mit:

Code: Alles auswählen

tcpdump -vvveni eth0 port 53

sieht man, dass alle DNS-Server in der resolved.conf, zu fritz.box gefragt werden. Wenn man das nicht will, sollte man dnsmasq (oder gleichwertig) benutzen, denn dort kann man für eine bestimmte domain auch einen bestimmten DNS-Server konfigurieren/benutzen.

[smutbert]

Danke vielmals.
Ich werde noch einmal das System auf dem es funktioniert genau unter die Lupe nehmen, vielleicht sehe ich ja noch woher das für mich merkwürdige Verhalten kommt - aber die Lösung gefällt mir eh.