Von DNS-Evidenz zum Befund: AdminToolkits Methodik für DNS- und Mail-Sicherheit

Umfang und ausdrückliche Nichtaussagen

Dieses Dokument beschreibt den aktuellen DNSSEC-Validator, DANE-Validator, SPF/DMARC/DKIM-Prüfer und die SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft. Die Tools sind schreibgeschützte Erstdiagnosen. Sie ersetzen weder die Sicht auf die autoritative Zone und den Registrar noch einen vollständigen DNSSEC-Validator wie DNSViz, MTA-Logs, Paketmitschnitte oder ein umfassendes Mail-Sicherheitsaudit.

Record-Präsenz ist Inventar, keine Validierung. Akzeptierte Syntax ist kein kryptografischer Beweis. Das Authenticated-Data-Signal eines Resolvers ist Evidenz dieses Resolvers, keine eigenständige Signaturberechnung im Browser. Ein Zertifikats-Namensvergleich ist keine PKIX-Chain-Validierung. Die Prüfung von SPF-, DMARC- und DKIM-Records authentifiziert keine konkrete Nachricht. Diese Trennlinien bestimmen alle folgenden Ergebnisse.

Evidenzgewinnung und Vertrauensgrenzen

Eingefügte DNSSEC-, TLSA-, SPF-, DMARC- und DKIM-Werte werden im Browser geparst. Das Einfügen allein sendet sie nicht. Eine Live-DNS-Aktion fragt zuerst aus dem Browser den festen Cloudflare-DNS-over-HTTPS-JSON-Endpunkt ab. Scheitert diese Anfrage, ruft der Browser den Same-Origin-DNS-Helfer auf. Dieser bevorzugt für MX und TXT serverseitiges Cloudflare DoH und kann für unterstützte Record-Typen den nativen Resolver des Webservers verwenden. Soweit vorhanden, zeigt das Ergebnis Resolver- und Quellenhinweise. Live-DNS-Evidenz ist damit eine Sicht durch diese Resolverpfade samt deren Cachezustand und Vantage Point.

Live-TLSA-/Zertifikatsvergleiche nutzen einen eingeschränkten Same-Origin-Endpunkt. Er akzeptiert einen normalisierten öffentlichen DNS-Host, verwirft private oder nicht öffentliche Zieladressen, nutzt eine konservative Port-Allowlist und kurze Timeouts und ruft keine beliebigen URLs ab. Die SMTP-Bereitschaft löst öffentliche MX-Hosts auf, prüft nur die ersten drei sortierten MX-Ziele auf TCP-Port 25 und versucht EHLO, STARTTLS sowie Zertifikatserfassung separat für jede aufgelöste öffentliche A- und AAAA-Adresse jedes ausgewählten Ziels. Optionale MTA-STS-, TLS-RPT-, DANE- und FCrDNS-Prüfungen laufen nur, wenn sie ausgewählt wurden.

Der begrenzte SMTP-Diagnosepfad kann Zertifikatsevidenz pro Adresse von kaputten Servern bewahren, ohne daraus einen PKIX-Beweis abzuleiten. Wenn MTA-STS ausgewählt ist, verlangt ein separates striktes Transportergebnis für jede aufgelöste Adresse SNI für den MX-Hostnamen, eine vertrauenswürdige und zeitlich gültige WebPKI-Kette sowie eine passende DNS-ID im SAN des Zertifikats; einen CN-Fallback akzeptiert es nicht. Der DANE-EE-Vergleich hasht stattdessen Zertifikat oder SPKI aus jeder adressspezifischen STARTTLS-Sitzung und vergleicht diesen Wert mit DNSSEC-sicheren TLSA-Daten dieses MX-Owner-Namens.

Normalisierung vor der Entscheidung

DNS-Namen werden getrimmt, kleingeschrieben und vom abschließenden Punkt befreit. Die Browser-Validatoren lehnen URLs, User-Info, Ports und private Single-Label-Namen ab; Labels müssen normale LDH-Syntax erfüllen. Der Same-Origin-PHP-Helfer führt außerdem IDNA-Konvertierung durch, wenn die Laufzeit sie anbietet, und bewahrt den normalisierten ASCII-Namen für die Abfrage. Leere Zeilen werden aus eingefügten Record-Sets entfernt.

DS-, DNSKEY- und RRSIG-Werte werden in ihre Präsentationsfelder zerlegt. TLSA akzeptiert das gewöhnliche Präsentationsformat und das generische Format \# Länge Hex, ohne Zeichen still zu löschen. Die drei numerischen Felder sind Oktette; unbekannte Werte können syntaktisch gültig sein, bleiben für den Validator aber unsupported und unusable. Bekannte SHA-256- und SHA-512-Associations müssen exakt 32 beziehungsweise 64 Bytes lang sein; Exact Match verlangt vollständige, nicht leere Oktette.

SPF-Terme werden nach Whitespace getrennt. DKIM- und DMARC-Tag-Namen sowie ihre Versionswerte sind case-sensitiv; ein exakt doppelter DKIM- oder DMARC-Tag invalidiert die Tag-Liste, statt den letzten Wert auszuwählen. MTA-STS folgt einer eigenen Grammatik: Bei erforderlichen Nicht-mx-Feldern gilt der erste Wert, spätere Duplikate werden mit Warnung ignoriert. TLS-RPT folgt ebenfalls seiner eigenen Record-Grammatik und darf mehrere rua-Felder kombinieren. Parserentscheidungen sind protokollspezifisch und stammen nie aus einer generischen Last-wins-Map.

DNSSEC-Entscheidungslogik: Resolverurteil gegen Record-Inventar

Das DNSSEC-Tool parst DS, DNSKEY und RRSIG, benennt bekannte Algorithmen und Digest-Typen und meldet fehlerhafte Records, fehlende Evidenz, unbekannte Algorithmen sowie SHA-1-DS-Digests. Das bleibt strukturelles Inventar: DS plus DNSKEY plus RRSIG wird nicht zu einer validierten Chain. secure beziehungsweise ein Authenticated-Data-Signal gilt nur als Urteil des benannten validierenden Resolvers. Explizite bogus-Evidenz, einschließlich Extended DNS Error Code 6, ist blockierend. Ein nacktes SERVFAIL, Timeout oder generischer Fehler bleibt unavailable, weil viele nicht mit DNSSEC zusammenhängende Ursachen dasselbe Symptom erzeugen.

Die Seite berechnet nicht den DS-Digest jedes DNSKEY, verifiziert keine RRSIG-Kryptografie, prüft keine Signatur-Inception/-Expiry und baut keine unabhängige Chain vom Root-Trust-Anchor auf. DS-/DNSKEY-/RRSIG-Tabellen sind daher Inventar. Unabhängig sind das strukturelle Parsing und die Konsistenz der gelieferten Felder; das kryptografische Urteil ist an den gewählten validierenden Resolver delegiert. Scheitert eine Live-Teilabfrage, kann deren Evidenz leer sein. Fehlende Records ohne sicheres Urteil müssen daher unvollständig bleiben und dürfen nicht automatisch „unsigniert“ oder „sicher“ heißen.

DANE-Entscheidungslogik: drei Gates, dann nutzungsspezifisches Vertrauen

Ein vollständiges implementiertes DANE-Ergebnis braucht drei getrennte Gates: ein syntaktisch gültiges und nutzbares TLSA-RRset unter _port._protocol.host, ein DNSSEC-sicheres Resolverergebnis für dieses RRset und einen Zertifikats-Association-Vergleich. Records mit gleicher Usage, gleichem Selector und gleichem Matching Type bilden eine Parametergruppe. Innerhalb einer Gruppe darf jeder aktuelle Association-Wert passen; damit können alte und neue Credentials bei einem Rollover mit unveränderten Parametern parallel bestehen. Für ein grünes Tool-Ergebnis muss trotzdem jede unterstützte publizierte Gruppe einen aktuellen Match enthalten. Verschiedene Parametergruppen sind kein universelles logisches ODER: Ein SHA-256-Match neben einem SHA-512-Mismatch oder der umgekehrte Fall beweist wegen unterschiedlicher Digest-Unterstützung und RFC-7671-Auswahlregeln keinen Erfolg für alle Clients.

Für einen Credential-Rollover werden alter und neuer Association-Wert mindestens zwei relevante TLSA-TTLs vor dem Credential-Wechsel vorpubliziert; dabei müssen Publikations- und Cache-Laufzeiten berücksichtigt werden. Anschließend werden Credential und alle Service-Endpunkte umgestellt und geprüft. Der alte Wert wird erst entfernt, wenn das alte Credential nirgends mehr verwendet wird. Der aktuelle Livepfad prüft DANE-EE Usage 3 für Selector 0 (vollständiges Zertifikat) und 1 (SPKI) sowie Matching Type 0 (exakt), 1 (SHA-256) und 2 (SHA-512) und vergleicht jede Gruppe mit Material aus derselben STARTTLS-Sitzung. Ein Usage-3-Match verlangt weder PKIX-Validierung noch Hostnamenmatch oder ein im WebPKI-Sinn unablaufenes Zertifikat; diese Fakten bleiben separate Betriebs- beziehungsweise MTA-STS-Evidenz. DANE-TA Usage 2 wird als unsupported gemeldet, weil ein gültiges Resultat die präsentierte vollständige Chain, eine Association zum gewählten Trust Anchor und SMTP-Referenzidentitätsprüfung erfordern würde. Das aktuelle Tool behandelt PKIX-TA (Usage 0) und PKIX-EE (Usage 1) in diesem opportunistischen SMTP-DANE-Profil als unbrauchbar. Dies entspricht RFC 7672 §3.1.3: Dort ist ihre Behandlung durch SMTP-Clients nicht definiert, und Clients dürfen sie als unbrauchbar behandeln.

Ein sicherer TLSA-Match authentifiziert nur den geprüften Service-Host und TLSA-Owner. DANE-authentifiziertes Routing für eine Mail-Domain verlangt zusätzlich ein authentifiziertes MX-RRset und die authentifizierte Verarbeitung jedes Alias-Schritts. Die aktuelle SMTP-Readiness-Laufzeit validiert diese vollständige Domain-Routing-Kette nicht unabhängig; ihr hostbezogenes DANE-Ergebnis ist deshalb kein domainweiter DANE-Beweis. Ein sicheres RRset mit einer nicht passenden unterstützten Gruppe ist blockierend; nicht verfügbares DNSSEC, fehlendes TLSA oder ausschließlich nicht unterstützte Records bleibt unavailable oder unsupported.

Mail-Authentifizierungslogik: Syntax und Policy, keine Nachrichtenauthentifizierung

Der Mail-Authentifizierungsprüfer sucht SPF-TXT am Domainnamen, DMARC unter _dmarc.domain und DKIM unter einem manuellen Selector oder beim ersten Treffer in einer dokumentierten Liste gebräuchlicher Selector-Namen. Die automatische Selector-Suche ist Komfortevidenz, keine vollständige Discovery. Findet sie nichts, ist das unknown und kein Beweis, dass die Domain Mail nicht signiert.

SPF prüft den v=spf1-Marker, mehrere SPF-Records, gefährliches +all, terminale Reihenfolge, Modifier, Adress-/CIDR-Syntax, den laut RFC 7208 nicht zu verwendenden ptr-Mechanismus und eine statische Zahl direkt DNS-auslösender Terme. Diese Zahl ist nur eine Schätzung: Includes, Redirects, A- oder MX-Bäume werden nicht rekursiv expandiert, und der implizite SMTP-MX-Fallback darf nie auf den SPF-Mechanismus mx übertragen werden. Das Tool kann deshalb keinen vollständigen Pass für das Zehn-Lookup-Budget vergeben. DMARC prüft case-sensitive Version, Policies, Alignment-Tags, Report-URIs, Duplikate, historische Tags und Monitoring-only p=none. Der aktuelle Checker implementiert weder die vollständige RFC-9989-DMARC-Policy-Discovery mittels DNS Tree Walk noch die Ermittlung der Organizational Domain. Fehlt am exakten Owner _dmarc.<input> ein Record, beweist das deshalb nur, dass an genau diesem Owner kein DMARC Policy Record gefunden wurde; es beweist nicht, dass für die Domain keine geerbte DMARC Policy gilt. Der Checker simuliert außerdem kein Identifier-Alignment für eine Nachricht. DKIM prüft case-sensitive Tag-Syntax, Versionsposition, Duplikate, vorhandene beziehungsweise widerrufene Keys, Base64, erkennbares RSA-/Ed25519-Key-Material und, soweit decodierbar, die Key-Länge; eine DKIM-Signature über Nachrichteninhalt verifiziert es nicht.

SMTP-Transport-Entscheidungslogik

MX-Evidenz wird vor jeder Verbindung klassifiziert: gewöhnliches MX, Null MX, implizites MX, gemischt, fehlerhaft oder NXDOMAIN. Eine existierende Domain ohne MX-RRset nutzt sich selbst als effektives SMTP-Ziel mit Präferenz 0. Null MX bedeutet separat „kein eingehender Maildienst“. Explizite MX-Records deaktivieren den impliziten Fallback auch dann, wenn ihre Ziele kaputt sind. Pro ausgewähltem effektivem Ziel versucht das Tool jede aufgelöste öffentliche IPv4- und IPv6-Adresse und erfasst STARTTLS-Ankündigung, Handshake-Evidenz, Zertifikatsmaterial, ausgehandeltes Protokoll und ausgewählten Trust-Modus pro Adresse. Ein vollständiger Readiness-Pass verlangt Abdeckung aller effektiven MX-Ziele und jeder aufgelösten Adresse im ausgewählten Top-3-Satz. Eine nicht versuchte Adresse ist incomplete, kein abgeleiteter STARTTLS-, Zertifikats-, MTA-STS-, DANE- oder FCrDNS-Fehler.

Ausgewählte Policy-Layer behalten eigene Trust- und Schweregrade. Bei der MTA-STS- und TLS-RPT-Discovery werden Records, die mit dem jeweiligen Protokoll-Versionsmarker beginnen, gezählt, bevor der ausgewählte Record vollständig geparst wird. Ein zweiter fehlerhafter Protokollkandidat kann daher nicht verschwinden und scheinbar einen einzelnen gültigen Record übrig lassen. MTA-STS verlangt anschließend exakt einen Kandidaten-TXT-Record sowie eine syntaktisch vollständige Policy von der festen HTTPS-URL mit exakt HTTP 200 und ohne Redirects, WebPKI-Authentisierung des Policy-Hosts, vollständige Policy-MX-Abdeckung und strikte STARTTLS-/WebPKI-/SAN-only-Auditevidenz für jedes abgedeckte Ziel. Die Runtime erfasst den Content-Type der Policy-Antwort und warnt, wenn ein vorhandener Medientyp nicht dem von RFC 8461 empfohlenen text/plain entspricht; ein vollständig fehlender Content-Type wird derzeit nicht beanstandet. mode: none benötigt kein mx-Feld und ist inaktiv. testing protokolliert Fehler, verlangt aber anders als enforce von einem konformen Sender keinen Zustellabbruch. Das Tool prüft die aktuell beobachteten Endpunkte gegen strikte Transportanforderungen; es reproduziert weder die gecachte Policy noch die Zustellentscheidung eines konkreten Senders.

TLS-RPT verlangt exakt einen v=TLSRPTv1-Kandidaten und mindestens eine syntaktisch gültige mailto:- oder https:-rua-URI; dies beweist weder Annahme am Ziel noch Report-Zustellung. Ein fehlgeschlagener DANE-Check wird nicht durch MTA-STS gerettet. FCrDNS verlangt für jede geprüfte IP einen PTR-Namen, dessen A- oder AAAA-Antwort die ursprüngliche IP enthält. PTR-Gleichheit mit dem MX-Hostnamen ist separate Identitätskonsistenz, nicht Teil der Roundtrip-Definition.

Schweregradsemantik und Unknown-Behandlung

Ein error bedeutet, dass die gelieferte oder beobachtete Evidenz für das ausgewählte Audit einen blockierenden Widerspruch enthält: fehlerhafte Pflichtsyntax, explizites DNSSEC bogus, ein sicheres nutzbares TLSA-RRset mit einer nicht passenden unterstützten Parametergruppe, fehlendes STARTTLS, ein strikter MTA-STS-PKIX-/SAN-Auditfehler, verbotenes Legacy-TLS oder ein unmöglicher MX-Zustand. Das ist nicht automatisch eine Prognose für die Zustellaktion eines Senders: MTA-STS testing meldet Fehler, während enforce die Zustellung blockieren kann. Derselbe Fakt kann unter opportunistischem SMTP, MTA-STS testing, MTA-STS enforce und DANE unterschiedliche Bedeutung haben; Schweregrade werden nicht zwischen Trust-Modi kopiert. Eine warning steht für unvollständige, nicht bewiesene oder betrieblich schwache Evidenz, für ausgewählte, aber fehlende optionale Layer oder für nicht vollständige Heuristiken. Info ist Inventar oder Kontext und verbessert die Gültigkeit nicht von selbst.

Pass bedeutet, dass alle für die ausgewählte Prüfung implementierten Gates durch die gelieferten und beobachteten Daten erfüllt wurden. Es ist kein pauschaler Security-Score. Netzwerk-Timeout, Resolverfehler, natives DNS ohne vertrauenswürdigen DNSSEC-Status, nicht geprüfte MX-Hosts, fehlendes Zertifikatsmaterial, ein nicht gesuchter DKIM-Selector oder nicht unterstütztes DANE-TA müssen unavailable, incomplete, unsupported oder warning bleiben. „Konnte nicht prüfen“ darf nie zu „kein Problem“ werden.

Evidenz manuell reproduzieren

Ersetze die Dokumentationsplatzhalter unten durch dieselbe Domain, denselben MX-Host und denselben Selector wie im Tool. Frage mindestens einen validierenden Resolver ab und sichere vollständige Ausgabe, Resolveradresse und Beobachtungszeit.

# DNSSEC-Inventar und Urteil eines validierenden Resolvers
dig @1.1.1.1 +dnssec example.net DS
dig @1.1.1.1 +dnssec example.net DNSKEY
dig @1.1.1.1 +dnssec example.net A
# In der letzten Antwort Status, Flags inklusive ad, Answer und Authority prüfen.

# Inventar für Mailrouting und Authentifizierungs-Records
dig @1.1.1.1 example.net MX
dig @1.1.1.1 example.net TXT
dig @1.1.1.1 _dmarc.example.net TXT
dig @1.1.1.1 selector1._domainkey.example.net TXT

# TLSA-Evidenz und 3-1-1-Wert für eine konkrete MX-Adresse.
# Mit jeder A- und AAAA-Adresse wiederholen; der Digest stammt aus diesem Leaf.
set -euo pipefail
mx=mail.example.net
ip=192.0.2.10
case "$ip" in *:*) connect="[$ip]:25" ;; *) connect="$ip:25" ;; esac
work=$(mktemp -d)
trap 'rm -rf "$work"' EXIT

dig @1.1.1.1 +dnssec "_25._tcp.$mx" TLSA >"$work/tlsa.txt"
timeout 15s openssl s_client -starttls smtp -connect "$connect" \
  -servername "$mx" -showcerts </dev/null 2>&1 | tee "$work/session.txt" >/dev/null
awk '/-----BEGIN CERTIFICATE-----/{copy=1} copy{print} \
  /-----END CERTIFICATE-----/{exit}' "$work/session.txt" >"$work/leaf.pem"
test -s "$work/leaf.pem"
openssl x509 -in "$work/leaf.pem" -noout >/dev/null
openssl x509 -in "$work/leaf.pem" -pubkey -noout >"$work/spki.pem"
openssl pkey -pubin -in "$work/spki.pem" -outform DER -out "$work/spki.der"
test -s "$work/spki.der"
openssl dgst -sha256 -binary "$work/spki.der" | xxd -p -c 256

# Separater strikter WebPKI-/SAN-Test; diese zweite Sitzung nicht als Digest-Quelle nutzen.
timeout 15s openssl s_client -starttls smtp -connect "$connect" \
  -servername "$mx" -verify_hostname "$mx" -verify_return_error </dev/null

DNS- und SMTP-Beobachtung sollten zeitlich nah beieinander liegen. Ein TLSA-Mismatch während eines Zertifikats-Rollovers kann aus zwei Cache-/Vantage-Snapshots verschiedener Zeitpunkte entstehen. Vergleiche den exakten Owner-Namen, Usage, Selector, Matching Type und Digest – nicht nur die letzte Hex-Zeichenfolge.

Grenzen und typische False Positives

DNS-Caches können unterschiedliche Rollover-Stufen zeigen. Split-Horizon-DNS, ECS, Anycast und Provider-Steering können Vantage Points von Webserver und Operator unterscheiden. Ein Browser-DoH-Fehler kann die Quelle auf den Same-Origin-Helfer umschalten. Nativer DNS-Fallback kann Records ohne verifizierbaren DNSSEC-Zustand liefern. Der Secure-Zustand der DNSSEC-Seite beruht auf Resolverevidenz und ist keine unabhängige kryptografische Validierung.

SMTP-Tests sind auf die ersten drei MX-Hosts begrenzt, versuchen dort aber jede zurückgegebene öffentliche Adresse. Greylisting, Verbindungslimits, Tarpits, regionale ACLs, vorübergehender Paketverlust, SNI-Verhalten und unterschiedliche Zertifikate pro Adresse können das Ergebnis verändern. Nicht geprüfte MX-Hosts oder Adressen halten die Gesamt-Coverage incomplete; ein realer Verbindungs- oder Protokollfehler einer versuchten Adresse wird als solcher ausgegeben. SPF-Lookup-Schätzungen schließen rekursive Expansion aus. Die DKIM-Discovery mit üblichen Selectors ist unvollständig. TLS-RPT-Syntax kann keine Report-Zustellung beweisen. Die MTA-STS-Sicht ist ein Audit-Snapshot und keine Evidenz für die gecachte Policy jedes Senders. DANE-TA bleibt ohne echte Chain- und Identitätsvalidierung unsupported; der DANE-EE-Livevergleich authentifiziert den geprüften Host, nicht die vollständige MX-/Alias-Routing-Kette der Domain. Ein syntaktisch gültiger Record kann für reale Sender, Empfänger oder den Rollover-Zustand der Organisation trotzdem betrieblich falsch sein.

Standards und Methodikversion

Primärreferenzen: RFC 4033, RFC 4034 und RFC 4035 für DNSSEC; RFC 8914 für Extended DNS Errors; RFC 6698, RFC 7671 und RFC 7672 für DANE/TLSA und SMTP; RFC 5321 und RFC 3207 für SMTP-Routing und STARTTLS; RFC 7208 für SPF; RFC 6376, RFC 8301 und RFC 8463 für DKIM einschließlich Ed25519; RFC 9989, RFC 9990 und RFC 9991 für DMARC und Reporting; RFC 8461 für MTA-STS; RFC 8460 für TLS-RPT; und RFC 7505 für Null MX. RFC 8624 ist historisch und wurde durch RFC 9904 abgelöst; die aktuellen DNSSEC-Algorithmusempfehlungen stehen in den IANA-Registern DNS Security Algorithm Numbers und DS Digest Algorithms. RFC 9325 und RFC 9525 liefern aktuelle TLS- und Identitätsempfehlungen.

Methodikversion 1.4 vom 2026-09-07. Die Version beschreibt das auf dieser Seite dokumentierte Verhalten. Änderungen an Evidenzquellen, Resolverpfaden, Trust-Gates oder Schweregradregeln verlangen ein Methodik-Update.