☰

Kommt DNSSEC so häufig vor, oder ist systemd-resolved übereifrig?

tag-icon • tag-icon dns systemd
Kommt DNSSEC so häufig vor, oder ist systemd-resolved übereifrig?

Ich habe vor Kurzem meinen DNS-Resolver umgestellt, systemd-resolvedum die Vorteile von DNSSEC, wo verfügbar, nutzen zu können. Meine Konfiguration ist:

[Resolve]
DNS=8.8.8.8 8.8.4.4
DNSOverTLS=yes

(einschließlich der auskommentierten Vorgabe von DNSSEC=allow-downgrade)

Bei den meisten Websites, egal ob DNSSEC-fähig oder nicht, scheint alles prima zu funktionieren. Gelegentlich stoße ich jedoch auf eine Website, die Folgendes nicht auflöst:

$ resolvectl query savannah.gnu.org
savannah.gnu.org: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query keys.mailvelope.com
keys.mailvelope.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
$ resolvectl query d1dkupr86d302v.cloudfront.net
d1dkupr86d302v.cloudfront.net: resolve call failed: DNSSEC validation failed: failed-auxiliary

Ich habe versucht, dies zu überprüfen überDNSSEC-Analysator (für savannah.gnu.org). Allerdings fällt es mir schwer, das Ergebnis zu verstehen. Ich sehe nicht wirklich, wie es sich von anderen Domänen unterscheidet, die DNSSEC nicht aktivieren.

Meine Frage ist: Ist DNSSEC so häufig defekt oder macht systemd-resolved hier etwas falsch?

Antwort1

Es ist wahrscheinlich beides. Insgesamt würde ich aufgrund früherer Berichte eher zu Letzterem tendieren (systemd-resolved ist in manchen Fällen zu streng). Allerdingslaut DNSViz, auch die Konfiguration der Domänen besteht nicht alle Prüfungen.

Ich bin mir auch bei bestimmten DNSSEC-Mechanismen nicht 100 % sicher, aber hier ist meine Meinung:

savannah.gnu.org

Es ist ein riesiges Durcheinander. Systemd-resolved erkennt korrekt ein Problem mit der Domäne, lehnt es jedoch fälschlicherweise auf der Grundlage von Informationen ab, denen es nicht trauen sollte.

  1. Die gnu.org.Zone hat Signaturen, aber ihre Delegation org.enthält keine Schlüssel, anhand derer sie validiert werden können. Der Resolver sollte sich diese Signaturen also gar nicht ansehen – sie sind nicht länger Teil der Vertrauenskette. Systemd-Resolved sieht sie sich jedoch trotzdem an.

  2. Der savannah.gnu.org.Name ist an zwei Stellen vorhanden und diese stimmen nicht überein. Dieses Problem würde ohne DNSSEC unbemerkt bleiben, würde aber mit DNSSEC immer bei der Validierung fehlschlagen. Aufgrund von Problem Nr. 1 schlägt die Validierung jedoch fehl, obwohl systemd-resolved es stillschweigend ignorieren sollte.

Weitere Einzelheiten zu Nr. 2:

Dieselben Nameserver hosten sowohl die signierte übergeordnete Zone gnu.org.als auch die unsignierte untergeordnete Zone savannah.gnu.org.. Das Problem besteht darin, dass erstere keine tatsächliche NS-Delegation an letztere hat; stattdessen gibt es unter diesem Namen nur einfache Nichtdelegationsaufzeichnungen.

Das funktioniert nur, weil beide Zonen von denselben Nameservern gehostet werden. Wenn Sie also zunächst nach A- oder AAAA-Einträgen bei „savannah.gnu.org“ suchen, wird die Antwort automatisch aus der nicht signierten untergeordneten Zone bereitgestellt.

Es ist klar, dass dies der Anfang einer separaten Zone ist, da es einen SOA-Eintrag hat. Der DNSSEC-Validator muss jedoch wissen, ob diese Zone signiert werden soll oder nicht. Daher versucht er, nach DS-Einträgen (oder deren Fehlen) zu fragen. Dieses Mal wird die Antwort immer von der übergeordneten Zone bereitgestellt.

Eine nicht signierte Unterzone ist in Ordnung, wenn die übergeordnete Zone keine DS-Einträge dafür hat, was sie durch die Rückgabe eines signierten NSEC-Eintrags anstelle der Antwort beweist; der NSEC-"Nachweis der Nichtexistenz" zeigtalleDatensatztypen, die für diesen Namen vorhanden oder nicht vorhanden sind.

Die übergeordnete Zone „gnu.org“ behauptet also korrekt, dass DS-Einträge für „savannah.gnu.org“ nicht existieren... aber sie behauptet auch, dassEs gibt auch keine NS-Aufzeichnungen,d. h. der Name wird überhaupt nicht an eine untergeordnete Zone delegiert.(Anscheinend gibt es jedoch einen SSHFP-Eintrag ...)

Da der Validierer die ursprüngliche, unsignierte Antwort hat, die anzeigt, dass sie aus einer Unterzone stammt, und einen signierten Beweis, der anzeigt, dass esNEINBei einer Delegation an eine Unterzone muss die Validierung fehlschlagen.

...Aber wie in Punkt 1 erwähnt, sollte keine dieser Prüfungen überhaupt durchgeführt werden, da die Parent-Parent- org.ZoneAuchbeweist, dass die Delegation an gnu.org.unsigniert ist, was bedeutet, dass alle NSEC-Einträge von gnu.org irrelevant sind. Systemd-resolved sollte sie nicht betrachten – es sollte die gesamte gnu.org-Zone so behandeln, als ob sie kein DNSSEC hätte.

verwandte Informationen