DNS Probleme

ah4711 · 2024-06-12T13:47:53+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

ah4711

Hallo Community
Leider konnte mir der Tel-Support nicht helfen. Wie DNS funktioniert ist dort nicht bekannt.

Das Phänomen ist, dass ich im Browser grundsätzlich surfen kann, also z.B. google, DuckDuckGo, etc. kann aufgerufen werden, auch die präsentierten URLs können verwendet werden. Mit der URL postfinance.ch haben wir Probleme.
Technisch ist der Aufbau so, dass hinter der weissen UPC Box ein Router aufgebaut ist, auf dem unbound läuft, der die beiden Nameserver
62.2.24.158 ns4.cablecom.net

62.2.17.61 ns11.cablecom.net

eingetragen hat. Diese beiden Server wurden irgendwann mal zugewiesen und seit dem verwende ich die. Cablecom scheint also eine ganze Reihe von Servern zu haben, was ich verstehe.
Im Log vom unbound steht:
14:38:46 unbound: [1684:0] info: start of service (unbound 1.19.3).

14:38:47 unbound: [1684:0] info: generate keytag query _ta-4a5c-4f66. NULL IN

14:38:49 unbound: [1684:0] error: SERVFAIL <browser.events.data.msn.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:38:49 unbound: [1684:0] error: SERVFAIL <r.msftstatic.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:38:49 unbound: [1684:0] error: SERVFAIL <r.bing.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:38:49 unbound: [1684:0] error: SERVFAIL <img-s-msn-com.akamaized.net. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:38:49 unbound: [1684:0] error: SERVFAIL <www.bing.com. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:38:50 unbound: [1684:0] error: SERVFAIL <srtb.msn.com. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:38:50 unbound: [1684:0] error: SERVFAIL <edge.microsoft.com. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:38:52 unbound: [1684:0] error: SERVFAIL <bzib.nelreports.net. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:39:03 unbound: [1684:0] error: SERVFAIL <deff.nelreports.net. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:39:04 unbound: [1684:0] error: SERVFAIL <c.bing.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:39:04 unbound: [1684:0] error: SERVFAIL <api.msn.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:39:05 unbound: [1684:0] error: SERVFAIL <c.msn.com. A IN>: all the configured stub or forward servers failed, at zone . from 192.168.0.1 upstream server timeout

14:39:40 unbound: [1684:0] error: SERVFAIL <images.archive-digger.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:39:41 unbound: [1684:0] error: SERVFAIL <shftr.adnxs.net. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout

14:40:04 unbound: [1684:0] info: validation failure <postfinance.ch. A IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:40:04 unbound: [1684:0] info: validation failure <www.postfinance.ch. AAAA IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:40:04 unbound: [1684:0] info: validation failure <postfinance.ch. AAAA IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:40:04 unbound: [1684:0] info: validation failure <www.postfinance.ch. A IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:40:48 unbound: [1684:0] info: validation failure <postfinance.ch. A IN>: key for validation postfinance.ch. is marked as invalid because of a previous

14:42:41 unbound: [1684:0] info: validation failure <postfinance.ch. A IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:42:41 unbound: [1684:0] info: validation failure <postfinance.ch. AAAA IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

14:43:08 unbound: [1684:0] info: validation failure <postfinance.ch. A IN>: key for validation postfinance.ch. is marked as invalid because of a previous

14:43:08 unbound: [1684:0] info: validation failure <postfinance.ch. AAAA IN>: key for validation postfinance.ch. is marked as invalid because of a previous

14:43:08 unbound: [1684:0] info: validation failure <postfinance.ch. A IN>: key for validation postfinance.ch. is marked as invalid because of a previous

14:43:08 unbound: [1684:0] info: validation failure <postfinance.ch. AAAA IN>: key for validation postfinance.ch. is marked as invalid because of a previous

14:43:39 unbound: [1684:0] info: validation failure <www.postfinance.ch. A IN>: No DNSKEY record for key postfinance.ch. while building chain of trust

Ein restart des unbound auf dem Router löst das Problem temporär. Es sieht aber für mich danach aus, als ob es Errors gibt (Servfail), die von der Box nicht korrekt beantwortet werden, woraufhin die chain of trust zu postfinance.ch nicht aufgebaut werden kann.
Warum?
Was kann ich dagegen tun?
Danke!

Belegnor

ah4711

sieht nach einem DNSSEC-Problem aus. Ist diese Option aktiviert? Falls ja, was geschieht, wenn du sie deaktivierst?

ah4711

Hallo Belegnor
Die Option ist aktiviert.

    # DNSSEC
    auto-trust-anchor-file: "/somewhere/some.key"
    val-log-level: 1
    log-servfail: yes

Es funktioniert mit dieser Option! Irgendwann funktioniert es aber nicht mehr. Es ist mir nicht klar, was der Trigger dafür ist.
Die Option auszuschalten ist hier m.E. kontraproduktiv. Ich hätte jetzt erwartet, dass DNSSec nicht mehr funktioniert, aber Postfinance u.U. nicht erreichbar ist. Wenn es doch erreichbar wäre, dann wäre die Verbindung theoretisch angreifbar. Den Grund für den Abbruch nach einiger Zeit finden wir damit aber nicht.

Belegnor

ah4711

Warum die Ausschaltung dieser Option kontraproduktiv sein soll, verstehe ich nicht. Eine funktionierende DNS Auflösung ist in der Regel wichtiger als eine „sichere“ Namenauflösung, die Probleme verursacht.

DNSSEC zu deaktivieren, wäre in sofern eine gute Idee, um zu prüfen, ob die Namenauflösung dann funktioniert. Wenn das der Fall ist, könnte man sich überlegen, ob man eine Validierungsausnahme für einzelnen Domänen konfigurieren will. Ob dies mit Unbound möglich ist, kann ich nicht sagen.

GrandDixence

ah4711

auto-trust-anchor-file: “/somewhere/some.key”

Diese für Unbound sehr wichtige Datei enthält die “DNSSEC”-Schlüsseln für die root-Zone (initial trust anchor). Fehlt Unbound der lokale Lesezugriff auf diese DNSSEC-Schlüsseln, oder hat Unbound nur lokalen Lesezugriff auf veraltetes Schlüsselmaterial, so funktioniert die Namensauflösung mit DNSSEC nicht!

Kontrollieren, ob der automatische Updatevorgang der “DNSSEC”-Schlüsseln der root-Zone funktioniert. Siehe dazu:
https://www.nlnetlabs.nl/documentation/unbound/howto-anchor/

https://www.iana.org/dnssec/files

https://www.heise.de/news/l-f-Wo-ist-der-ver-Schluessel-4659832.html

# more /var/lib/unbound/root.key ; autotrust trust anchor file ;;id: . 1 ;;last_queried: 1718641369 ;;Mon Jun 17 18:22:49 2024 ;;last_success: 1718641369 ;;Mon Jun 17 18:22:49 2024 ;;next_probe_time: 1718681056 ;;Tue Jun 18 05:24:16 2024 ;;query_failed: 0 ;;query_interval: 43200 ;;retry_time: 8640 . 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jL HwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1634068295 ;;Tue Oct 12 21:51:35 2021

Im Anbetracht, dass immer mehr Schweizer Banken ihr Online Banking (eBanking) mit DNSSEC absichern, ist der Einsatz von DNSSEC aus Sicherheitsgründen empfehlenswert.

ah4711

Nochmals: die Namensauflösung funktioniert jetzt bereits mit DNSSEC.

Es ist kontrarproduktiv, weil die DNS-Abfragen nicht kryptografisch abgesichert sind und man so Tür und Tor öffnet, eine Verbindung zu haben, wo man sie nicht hin haben möchte. Dann - gerade dann - ist keine Verbindung wesentlich sicherer als eine unsichere Verbindung.

Nach Rücksprache mit jemanden, der unbound kennt und täglich damit zu tun hat, steht das Problem oben im Log: zone . upstream server timeout

Das bedeutet, dass es kein lokales unbound-Problem ist, sondern der Upstream-Server - hier der Cablecom NS, der keine Antwort gibt - aus welchen Gründen auch immer. Das stünde wohl im Log dieses Servers. Da man bei Cablecom aber nicht weiss, was ein DNS-Server ist, …

Die Lösung des Problems sehe ich eher darin, dass ich andere Upstream-Server verwende. Die sind dann leider nicht mehr so nah erreichbar, aber die haben andere Datenschutz-Standards. Das ist auch etwas wert.

Belegnor

ah4711

Nochmals: die Namensauflösung funktioniert jetzt bereits mit DNSSEC.

… Offensichtlich hat sie nicht funktioniert, zumindest für bestimmte Domains … 🤔

Es ist kontrarproduktiv, weil die DNS-Abfragen nicht kryptografisch abgesichert sind und man so Tür und Tor öffnet, eine Verbindung zu haben, wo man sie nicht hin haben möchte. Dann - gerade dann - ist keine Verbindung wesentlich sicherer als eine unsichere Verbindung.

Meiner Meinung nach ist die Aufgebe der ISPs, zu gewährleisten, dass die DNS Antworten korrekte Daten liefern. D. h., eine Verifizierung seitens Kunde sollte eigentlich überflüssig sein. Selbstverständlich bleibt dem Kunde überlassen, ob er die Daten in den Antworten auf seiner Seite validieren will. Aber dies kann jedoch zu Problemen führen, vor allem wenn man von einem fremden DNS Forwarder (z. B. Sunrise) abhängig ist, wie bei dir der Fall zu sein scheint.

Ich sehe es daher eher pragmatisch. Je nach Use Case ist eine nicht funktionierende DNS Auflösung eher kontraproduktiver als eine funktionierende „unsichere“ Namenauflösun. Sicherheit ist nichts anderes als Risikomanagement, und auch nicht funktionierende Verbindungen sind Risiken. Aus dem Grund habe ich vorgeschlagen Validierungsausnahmen für betroffene Domains einzurichten.

Ob dies für dich in Frage kommt, oder das Ändern der DNS Forwarder die richtige Lösung für dich ist, musst du selber entscheiden. Allerdings würde es mich nicht wundern, wenn ähnliche oder andere Probleme bei den alternativen DNS Server auftauchen, vielleicht halt mit anderen Domains. Just my two cents … 😉

ah4711

Belegnor Offensichtlich hat sie nicht funktioniert, zumindest für bestimmte Domains

Nein, das ist falsch. Auch für diese Domänen funktioniert es grundsätzlich. Ich kann auf Postfinance surfen und Zahlungen tätigen. Allerdings ist es zweimal ausgefallen und das einzige, was ich im Log finde, ist der obige Ausschnitt, der etwas in dieser Richtung zeigt. Ist vielleicht eine Race-Condition… Nach einem Restart des unbound-daemon funktioniert es wieder.

Ich hätte gerne verstanden, was das Problem ist. Workarounds klingen zunächst toll, aber auf Dauer sind Workarounds im Weg und müssen spätestens bei einer definitiven Lösung zurückgebaut werden.

Bisher gab es leider keinen Hinweis auf die Ursache und daher auch keinen Hinweis auf eine (echte) Lösung.
Danke trotzdem für die Antworten.

pato

ah4711 Also wenn es jeweils direkt nach einem Neustart des unbound Dienst funktioniert, liegt es sehr wahrscheinlich an diesem. Ich vermute ein Cache Problem. Wenn es häufig genug auftritt, kannst du den Unbound eventuell im Debug Modus starten und dann den Fehler reproduzieren und siehst vielleicht mehr in den Logs.

ah4711

Ich kann das Problem nicht reproduzieren, denn nach dem Restart funktioniert es ja, d.h. ich kann alle erdenklichen DNS auflösen, die es natürlich gibt und die mir in den Sinn kommen.
Ich teile Deine Meinung mit dem Cache. Wenn eine Anfrage fehlschlägt, dann merkt sich der Cache eben auch das… Ja, ein Workaround könnte auch sein, den Cache herunterzusetzen oder gar auszuschalten. Auch nicht “prickelnd”, zumal DNS ja einigermassen geschwätzig ist.

Je länger ich darüber nachdenke, desto eher sehe ich das Problem bei den Cablecom-DNS. Da kann ich dann lokal loggen, bis mir schwarz wird: es wird nicht mehr drinstehen, als dass der upstream server keine Antwort gegeben hat (Timeout).

Unterdessen habe ich andere DNS eingetragen und das funktioniert ebenfalls einwandfrei - mit DNSSEC.

GrandDixence

Ich betreibe seit einigen Jahren Unbound auf Ubuntu 20.04 mit “scharfer” DNSSEC-Konfiguration ohne Probleme mit den DNS-Servern von UPC-Sunrise.

Ich sehe drei zu lösende Probleme mit diesem Unbound auf dem eigenen Router:

1.) Die originale Upstream-Version 1.19.3 von Unbound enthält eine Sicherheitslücke mit der Kennzeichnung CVE-2024-33655. https://www.nlnetlabs.nl/projects/unbound/security-advisories/ Hier wäre wahrscheinlich das Einspielen eines Sicherheitsupdates angebracht.

2.) Der Unbound wird zu einem Zeitpunkt (14:38 Uhr) gestartet, bevor die Netzwerkverbindung voll funktionstüchtig ist. Beim Start eines EuroDOCSIS-Kabelmodem dauert der Synchronisationsvorgang mit dem CMTS rund 5 Minuten. Während diesen 5 Minuten sind keine DNS-Abfragen möglich! Ab 14:40 Uhr läuft der Internetanschluss. Ab diesem Zeitpunkt sind DNS-Anfragen möglich und werden von den DNS-Servern von Sunrise beantwortet.

3.) Zu den DNSSEC-Problemen ab 14:40 Uhr: Eine DNSSEC-Abfrage erfolgt hierarchisch: Zuerst die root-Zone (zone .), dann die Schweizer Domäne (.ch) und schliesslich der Postfinance-Bereich (postfinance.ch).
https://en.wikipedia.org/wiki/DNS_zone

Gut ersichtlich im DNSSEC-Debugger von Verisign:
https://dnssec-debugger.verisignlabs.com/www.postfinance.ch

Weshalb DNSSEC genau fehlschlägt, muss mit einer Netzwerkdatenverkehrsaufzeichnung und Wireshark herausgefunden werden:
https://www.lancom-forum.de/fragen-zum-thema-vpn-f14/geloest-esp-paketverluste-ueber-ipv6-1und1-t16595-s15.html#p93972

Ich vermute, dass DNS-Anfragen per TCP blockiert werden => Für DNSSEC wird TCP Port 53 neben UDP Port 53 benötigt! => Unten stehender TCP-Test durchführen!

Oder im Zwischenspeicher von Unbound sind die vorgängig wegen der nicht funktionstüchtigen Internetverbindung fehlgeschlagene DNS-Anfragen als “SERVFAIL”, sprich als unbeantwortbar, für mehrere Minuten zwischengespeichert. Unbound speichert nicht nur die Antworten von erfolgreichen DNS-Anfragen, sondern führt auch Buch über die misslungenen DNS-Anfragen!

Hier noch meine Anleitung zur DNSSEC-Funktionskontrolle und DNSSEC-Fehlersuche:

DNSSEC-Funktionstest
======================

https://www.internetsociety.org/deploy360/dnssec/tools/


Positiv-Test
------------------------------------------------------------------------
# dig +multili +dnssec www.nic.ch
=> status: NOERROR
=> flags: ad
=> EDNS: version: 0, flags: do;
=> SERVER: 127.0.0.1


# dig +multili +dnssec www.nic.cz
=> status: NOERROR
=> flags: ad
=> EDNS: version: 0, flags: do;
=> SERVER: 127.0.0.1


Negativ-Test
-----------------------------------------------------------------------
# nslookup www.rhybar.cz
=> Got SERVFAIL reply from 127.0.0.1

# dig +multili +dnssec www.rhybar.cz
=> status: SERVFAIL

# nslookup www.dnssec-failed.org
=> Got SERVFAIL reply from 127.0.0.1

# dig +multili +dnssec www.dnssec-failed.org
=> status: SERVFAIL



TCP-Test
--------------------------------------------------------------------------------
# dig +tcp www.meteoschweiz.admin.ch @192.168.13.55

Viel Glück bei der Fehlersuche!

GrandDixence

Die DNSSEC-Probleme könnten auch durch eine fehlende batteriegestützte Echtzeituhr (RTC) verursacht sein. Oder für die Zeitsynchronisation (NTP) wird die Namensauflösung (DNS) benötigt. Korrekterweise sollte die Zeitsynchronisation (NTP) nur mit IP-Adressen konfiguriert sein. Siehe dazu:
https://www.lancom-forum.de/lancom-wireless-aktuelle-accesspoints-f35/seltsamer-fehler-verbindungerbindung-ap-auf-wlc-t19853.html#p112758

https://www.lancom-forum.de/fragen-zur-lancom-systems-routern-und-gateways-f41/1906va-local-time-set-t19972.html#p113867

https://community.sunrise.ch/d/35364-hairpin/6

Jedoch sprechen die hier veröffentlichten Fehlermeldungen gegen ein Problem mit der Zeitsynchronisation (NTP).