ubuntuusers.de

Ich habe vor einigen Wochen einen Server von Ubuntu 20.04 auf 22.04 via do-release-upgrade geupgradet. So weit, so gut. Leider funktioniert seitdem das DNS nicht mehr richtig. In /etc/resolv.conf steht bei

1

nameserver 127.0.0.53

Darauf aufbauend funktioniert kein DNS mehr und ich kann nichts mehr updaten, die Nextcloud sendet nichts mehr usw. Als "Hotfix" habe ich bei nameserver die 9.9.9.9 eingetragen, was kurzzeitig Abhilfe schafft, aber spätestens beim nächsten Update ist das wieder überschrieben.

Habt ihr eine Idee, was da los ist?

resolvectl

Wie sieht denn deine Netplan oder Interfaces Konfiguration aus?

Bittesehr:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

resolvectl 
Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 9.9.9.9#dns.quad9.net
         DNS Servers: 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
Fallback DNS Servers: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google

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

Link 3 (br-e145bc2027f4)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

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

encbladexp schrieb:

Wie sieht denn deine Netplan oder Interfaces Konfiguration aus?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

ifconfig 
br-e145bc2027f4: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        ether 02:42:fa:c0:2a:4a  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:f2ff:feda:39dd  prefixlen 64  scopeid 0x20<link>
        ether 02:42:f2:da:39:dd  txqueuelen 0  (Ethernet)
        RX packets 367815  bytes 60208084 (60.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 275205  bytes 6388814022 (6.3 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet xxx.xxx.xxx.249  netmask 255.255.252.0  broadcast 202.61.251.255
        inet6 fe80::4484:yyyy:yyyy:yyyy  prefixlen 64  scopeid 0x20<link>
        inet6 2a03:4000:54:fee:4484:yyyy:yyyy:yyyy  prefixlen 64  scopeid 0x0<global>
        ether 46:84:74:db:4a:89  txqueuelen 1000  (Ethernet)
        RX packets 326854628  bytes 43693927642 (43.6 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 135745358  bytes 36776795179 (36.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 4224187  bytes 4380093962 (4.3 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4224187  bytes 4380093962 (4.3 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Wenn ich neu starte, dann steht bei resolvctl dasselbe Ergebnis drin wie oben, egal ob ich manuell in /etc/resolv.conf die 9.9.9.9 eintrage oder nicht.

mokkin schrieb:

Wenn ich neu starte, dann steht bei resolvctl dasselbe Ergebnis drin wie oben, egal ob ich manuell in /etc/resolv.conf die 9.9.9.9 eintrage oder nicht.

Wenn Du nicht selber systemd-resolved konfigurieren willst (und Einträge in der resolv.conf machst), kannst Du die Ausgabe von resolvectl auch ignorieren.
Wie ist jetzt, mit 9.9.9.9 in der resolv.conf, die Ausgabe von:

host -v heise.de

?

lubux schrieb:

mokkin schrieb:

Wenn ich neu starte, dann steht bei resolvctl dasselbe Ergebnis drin wie oben, egal ob ich manuell in /etc/resolv.conf die 9.9.9.9 eintrage oder nicht.

Wenn Du nicht selber systemd-resolved konfigurieren willst (und Einträge in der resolv.conf machst), kannst Du die Ausgabe von resolvectl auch ignorieren.
Wie ist jetzt, mit 9.9.9.9 in der resolv.conf, die Ausgabe von:

host -v heise.de

?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

host -v heise.de
Trying "heise.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2702
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;heise.de.			IN	A

;; ANSWER SECTION:
heise.de.		22299	IN	A	193.99.144.80

Received 42 bytes from 9.9.9.9#53 in 8 ms
Trying "heise.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58149
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;heise.de.			IN	AAAA

;; ANSWER SECTION:
heise.de.		11886	IN	AAAA	2a02:2e0:3fe:1001:302::

Received 54 bytes from 9.9.9.9#53 in 4 ms
Trying "heise.de"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2586
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;heise.de.			IN	MX

;; ANSWER SECTION:
heise.de.		43200	IN	MX	10 relay.heise.de.

Received 48 bytes from 9.9.9.9#53 in 12 ms

mokkin schrieb:

;; ANSWER SECTION:
heise.de.		22299	IN	A	193.99.144.80

;; ANSWER SECTION:
heise.de.		11886	IN	AAAA	2a02:2e0:3fe:1001:302::

D. h. die Namensauflösung (DNS) funktioniert. Jetzt kannst Du die resolv.conf noch gegen überscheiben/ändern/etc. sichern, mit z. B.:

sudo chattr +i /etc/resolv.conf

Die /etc/resolv.conf ist im Standard in Symlink auf /run/...., und zeigt dort auf den resolved. Ein chattr wird diese also im Standard nicht jucken, weil das nur ein Symlink ist. Wenn man bedenken hat das systemd-resolved verantwortlich ist, z.B. weil Docker sich damit komisch verhält, sollte man erstmal den Link /etc/resolv.conf auf umbiegen, es gibt unter (AFAIR) /run/systemd/resolv 2 Dateien, eine resolv.conf, und eine stub-resolv.conf. Im Standard geht der Link auf stub-resolv.conf, schau mal bitte in die dortige resolv.conf, dort sind die normalen Nameserver drin.

Beachte bitte auch, das die Nameserver Konfiguration per /etc/nsswitch.conf regelt ist, also manche Apps die /etc/resolv.conf ohnehin nicht beachten.

Leider hast du bisher nicht deine z.B. /etc/network/interfaces oder Netplan configs gezeigt, was hilfreich wäre. Schau dir aber mal die beiden Dateien in /run/systemd/resolve an.

btw, kann es sein das du Nextcloud in Docker hast, und nur das Probleme hat?

encbladexp schrieb:

Die /etc/resolv.conf ist im Standard in Symlink auf /run/...., und zeigt dort auf den resolved. Ein chattr wird diese also im Standard nicht jucken, weil das nur ein Symlink ist.

BTW: Wenn beim TE die /etc/resolv.conf ein symlink ist, wird er das i-flag, mit chattr nicht setzen können und bekommt die Meldung:

chattr: Operation not supported while reading flags on /etc/resolv.conf

Genauso ist es und der Hinweis kommt...

mokkin schrieb:

... der Hinweis kommt...

Dann kannst Du jetzt entweder systemd-resolved richtig konfigurieren oder warten ob bzw. bis die Datei, auf die der symlink "/etc/resolv.conf" zeigt, überschrieben/geändert wird oder Du löscht den symlink und erstellst danach die Datei /etc/resolv.conf mit deinem gewünschten Inhalt und setzt das i-flag.

Ich habe es jetzt wie empfohlen gemacht, und den Symlink gelöscht und die Datei manuell erstellt. Mal schauen, ob es so bleibt.

Danke schon mal für eure Tipps!