DNS aussetzer

[michaa7]

Debian unstable (sid(uction))

Das system ist weit über ein Jahr alt und wird fast täglich aktualisiert. Soweit alles ok.

Die letzten zwei Abende kam es plötzlich zu Aussetzern in Videostreams, die mich dann jeweils 15-20 Minuten beschäftigten. Im Browser (Vivaldi, aber auch testweise Chromium) sah ich dann in der Statuszeile immer "resolve host" oder sowas ähnliches. Gleichzeitig signalisierte mir mein Router dass eine Neuverbindung ausgelöst wurde. Das Spiel wiederholte sich mehrfach innerhalb des genannten Zeitraums bis dann irgendwann alles wieder normal funktionierte ... was mir Anlaß zu der Vermutung gibt, dass das eher auf Tests oder Wartungsarbeiten beim (DNS-) Provider (openddns/congstar) zurückzuführen war.

Ich schrecke allerdings auch davor zurück mich näher mit meiner DNS Konfiguration zu befassen weil ich da überhaupt nicht mehr durchblicke seit das nicht mehr mit ceni zu erledigen ist sonder irgendwie über einen systemd service läuft.

Mein erster Versuch war:

[# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 208.67.220.220
nameserver 208.67.222.222.
nameserver 192.168.2.1
/quote]
der weitere dann wie empfohlen:

~# systemd-resolve --status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

Ich würde ja gerne mal testweise die congstar/telekom bzw den google dns server mit eingeben, aber ich weiß nicht mehr wo und wie ich das machen muß. Und die Fehlermeldung zeigt mir dass systemd gegenwärtig auch keine hilfreichen Infos liefern kann.

Wie komme ich denn weiter?

[MSfree]

Gleichzeitig signalisierte mir mein Router dass eine Neuverbindung ausgelöst wurde.

Dann hatte dein Provider Probleme. Da ist wohl die PPPoE-Verbindung zusammengebrochen, was zu einer Neueinwahl führt.

was mir Anlaß zu der Vermutung gibt, dass das eher auf Tests oder Wartungsarbeiten beim (DNS-) Provider (openddns/congstar) zurückzuführen war.

Mit DNS hat das nichts zu tun. DNS fällt natürlich aus, wenn die Hauptverbindung zusammenbricht, aber DNS ist nicht die Ursache des Zusammenbruchs sondern nur eine Folgeerscheinung.

[michaa7]

Also eigentlich waren die Verbindungen der Telekom und ihres Ablegers Congstar hier immer problemlos. Was mich aber wirklich auf die DNS-Schiene bringt ist - da hatte ich im Posting nicht klar gemacht - dass die DNS Auflösung auch lange nach erfolgreichem Verbindungsaufbau (Webseiten über IP erreichbar) noch gestört war. Abgesehen von den geschilderten Ausfällen klappt alles wieder ganz normal.

Was ich nicht verstehe ist warum mein System nicht in der Lage ist IPs von Domains, die ich schon x mal besucht habe so zu cachen, das für diese Domains keine erneute Anfrage an einen DNS Server notwendig ist. Das ist letztlich auch der Hintergrund weshalb ich verstehen möchte wie das mit systemd einzurichten/ zu ändern ist und was ich mit der erwähnten Fehlermeldung anfange.

[MSfree]

Also eigentlich waren die Verbindungen der Telekom und ihres Ablegers Congstar hier immer problemlos.

Jedem Provider kann mal ein Server, ein Router, ein Ethernetswitch... ausfallen. Auch Netzwerkgeräte müssen regelmässig aktualisiert werden, was zu Ausfällen führen kann. Und im dümmsten Fall gibt es kein Fail-Over. Es soll auch schonmal vorgekommen sein, daß ein Baggerfahrer ein Kabel rausgerissen hat.

Was ich nicht verstehe ist warum mein System nicht in der Lage ist IPs von Domains, die ich schon x mal besucht habe so zu cachen

Cachen tut der DNS-Server, in deinem Fall also der Server bei opendns.com. Dein Arbeitsplatzrechner cacht nichts.

[bluestar]

Dein Arbeitsplatzrechner cacht nichts.

Natürlich cacht jeder Resolver die DNS-Lookups. Bei Systemd-resolvd findest du die Details dazu im Quellcode: https://github.com/systemd/systemd/blob ... ns-cache.c

Ich würde jedoch gerne mal wissen, ob du systemd-resolved aktiviert hast und selbigen benutzen möchtest?

[mat6937]

Was ich nicht verstehe ist warum mein System nicht in der Lage ist IPs von Domains, die ich schon x mal besucht habe so zu cachen, das für diese Domains keine erneute Anfrage an einen DNS Server notwendig ist. Das ist letztlich auch der Hintergrund weshalb ich verstehen möchte wie das mit systemd einzurichten/ zu ändern ist und was ich mit der erwähnten Fehlermeldung anfange.

Das kannst Du testen, mit z. B.:

Code: Alles auswählen

netstat -tulpena | grep -i 53
tcpdump -vvveni any port 53
tcpdump -vvveni lo port 53
dig whitehouse.gov @127.0.0.53 | grep msec -A1
dig whitehouse.gov | grep msec -A1
resolvectl statistics
resolvectl status

EDIT:

Bei mir wird der dns-cache (auch wenn er auf yes ist) von systemd-resolved nicht benutzt:

Code: Alles auswählen

s:~# resolvectl statistics
DNSSEC supported by current servers: yes
Transactions
Current Transactions: 0
  Total Transactions: 16
Cache
  Current Cache Size: 0
          Cache Hits: 0
        Cache Misses: 16
DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

Ich denke weil dieser auf 127.0.0.53 lauscht:

Note that caching is turned off implicitly if the configured DNS server is on a host-local IP address (such as 127.0.0.1 or ::1), in order to avoid duplicate local caching.

EDIT 2:

Und btw. die query time via systemd-resolved (ohne cachen) ist hier das ca. 2- bis 3-fache, im Vergleich zur direkten (d. h. nicht via systemd-resolved) DNS-Anfrage (auch ohne cachen)

[michaa7]

Da klemmt irgendetwas in systemd bei mir.

# resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

# resolvectl statistics
Failed to get DNSSEC supported state: Unit dbus-org.freedesktop.resolve1.service not found.

# systemd-resolve --status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

[bluestar]

Bei mir wird der dns-cache (auch wenn er auf yes ist) von systemd-resolved nicht benutzt:

Code: Alles auswählen

s:~# resolvectl statistics
DNSSEC supported by current servers: yes
Transactions
Current Transactions: 0
  Total Transactions: 16
Cache
  Current Cache Size: 0
          Cache Hits: 0
        Cache Misses: 16
DNSSEC Verdicts
              Secure: 0
            Insecure: 0
               Bogus: 0
       Indeterminate: 0

Ich denke weil dieser auf 127.0.0.53 lauscht:

Das wundert mich auch nicht, weil du ja in /etc/resolv.conf nicht auf systemd-resolved zugreifst, bei mir ist /etc/resolv.conf ein Symlink nach /var/run/systemd/resolve/stub-resolv.conf und darin steht:

Code: Alles auswählen

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must 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.

nameserver 127.0.0.53
options edns0

Das sieht dann wie folgt aus:

Code: Alles auswählen

root@server1:~# resolvectl statistics
DNSSEC supported by current servers: yes

Transactions
Current Transactions: 0
  Total Transactions: 999

Cache
  Current Cache Size: 21
          Cache Hits: 230
        Cache Misses: 863

DNSSEC Verdicts
              Secure: 466
            Insecure: 500
               Bogus: 4
       Indeterminate: 0

[bluestar]

Was ich nicht verstehe ist warum mein System nicht in der Lage ist IPs von Domains, die ich schon x mal besucht habe so zu cachen, das für diese Domains keine erneute Anfrage an einen DNS Server notwendig ist.

Die Frage ist ohne Beispieldomains zu kennen, nur schwer zu beantworten.

Du solltest wissen, dass DNSSEC sich negativ auf Caching und auch auf die Geschwindigkeit von DNS-Antworten auswirkt.

[mat6937]

Das wundert mich auch nicht, weil du ja in /etc/resolv.conf nicht auf systemd-resolved zugreifst, ...

Das muss ich ja für einen Test auch nicht, denn mit dem tool (hier dig) greife ich direkt auf systemd-resolved zu.
Das sieht man ja auch durch "Cache Misses: 16". Wenn ich nur die resolv.conf benutze, gibt es dort ja richtigerweise gar keinen Eintrag.

[bluestar]

Das muss ich ja für einen Test auch nicht, denn mit dem tool (hier dig) greife ich direkt auf systemd-resolved zu.

Da du resolvectl status leider nicht gepostet hast, kann ich nicht sagen, welche DNS-Server dein systemd-resolved im Hintergrund letztlich befragt, wenn du keine angegeben hast dann laufen alle Anfragen ja erst mal zu Google.

[mat6937]

Da du resolvectl status leider nicht gepostet hast, kann ich nicht sagen, welche DNS-Server dein systemd-resolved im Hintergrund letztlich befragt, wenn du keine angegeben hast dann laufen alle Anfragen ja erst mal zu Google.

Ist es so, dass der Eintrag in den dns-cache davon abhängig ist, welche DNS-Server systemd-resolved im Hintergrund befragt? Die von google sind es nicht, weil ich andere eingetragen habe.

[MSfree]

Da du resolvectl status leider nicht gepostet hast, kann ich nicht sagen, welche DNS-Server dein systemd-resolved im Hintergrund letztlich befragt,

systemd-resolved läuft bei mir auf keinem einizigen Debianrechner und das sind praktisch Defaultinstallationen, wegkonfiguriert habe ich da nichts. Das läßt mich vermuten, daß dieser Dienst unter Debian gar nicht vorkonfiguriert ist, und daher auch kein Caching stattfinden kann.

[bluestar]

systemd-resolved läuft bei mir auf keinem einizigen Debianrechner und das sind praktisch Defaultinstallationen, wegkonfiguriert habe ich da nichts. Das läßt mich vermuten, daß dieser Dienst unter Debian gar nicht vorkonfiguriert ist, und daher auch kein Caching stattfinden kann.

Damit kommen wir zur nächsten Systemd-Geschichte, wie konfigurierst du deine Netzwerkschnittstellen über /etc/network/interfaces oder über systemd-networkd? Bei mir sieht resolvctl status so aus (gekürzt auf ein Interface, wo ich DNS-Server in der systemd-networkd Konfiguration eingetragen habe:

Code: Alles auswählen

Link 6 (br-wan-10g)
      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: 2003:xxx:xxxx::1
         DNS Servers: 2003:xxx:xxxx::1
                             87.191.x.x

und so ist resolved konfiguriert in /etc/systemd/resolved.conf:

Code: Alles auswählen

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=yes
#MulticastDNS=yes
#DNSSEC=allow-downgrade
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes

[MSfree]

Damit kommen wir zur nächsten Systemd-Geschichte, wie konfigurierst du deine Netzwerkschnittstellen über /etc/network/interfaces oder über systemd-networkd?

Bis Debian 9 hatte ich das in der /etc/network/interfaces, Debian 10 macht es per Default über systemd-networkd.

Jedenfalls liefert bei mir resolvectl status einen dbus-Fehler.

Code: Alles auswählen

systemctl status systemd-resolved.service

liefert "inactive (dead)" als Zustand.

Code: Alles auswählen

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=yes
#MulticastDNS=yes
#DNSSEC=allow-downgrade
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes

sieht bei mir genauso aus, das ist nämlich der Defaultzustand.

[bluestar]

Dann dürfte bei keine DNS-Abfrage über

Code: Alles auswählen

dig whitehouse.gov @127.0.0.53 | grep msec -A1

funktionieren...

[MSfree]

Dann dürfte bei keine DNS-Abfrage über... funktionieren

Nein, tut es auch nicht.

[bluestar]

Nein, tut es auch nicht.

Und wo liegt nun dein Problem?

[michaa7]

Die Leitung ist dann vor 10 (in worten: zehn) Tagen komplett zusammengebrochen, d.h. eigentlich war sie da, ich konnte sie nur nicht nutzen ...

Dienstag oder Mittwoch vergangener Woche geht also gar nichts mehr. Obwohl die DSL Leitung steht (Fritzbox, Provider und Netzbetreiber bestätigen das !) klappt die PPPoE Aushandlung nicht (mehr), kontinuierlich, andauernd. Dem Netzbetreiber, der dann Samstag Spätnachmittag einen Techniker in meine Wohnung zur Messung schickt weiß das, der Techniker auch (sie sind in der Gegend hier nicht der einzige, es muß eine Portumschaltung durchgeführt werden, d.h. das Kabel (mein Kabel) beim Netzbetreiber in einen anderen Port gesteckt werden; Aber nicht jetzt, da ist niemand mehr da.)
Am darauffolgenden Montag erfahre ich dann: nächster Termin Freitag nachmittag dieser Woche, gestern also. Der Techniker am Schaltkasten hier in der Gegend rief mich dann an, ob ich wieder ins Internet käme, und mein Test ergab: Ja, geht wieder. Was er gemacht habe? Das Kabel umgesteckt. Sie kännten den Fehler, können von der Zentrale aus nichts machen, wissen nicht woran es liegt, wüssten nur dass Kabel umstecken hilft.
Hightec eben ...