Alle Checks im Detail

Nameserver beantworten DNS-Anfragen für Ihre Domain. Mindestens zwei, sowohl über IPv4 als auch IPv6 erreichbar, erhöhen Ausfallsicherheit und Erreichbarkeit.

Der A-Record verweist Ihre Domain auf eine IPv4-Adresse, damit reine IPv4-Clients sie erreichen.

Der AAAA-Record verweist Ihre Domain auf eine IPv6-Adresse, damit reine IPv6-Clients sie erreichen und die Seite erreichbar bleibt, während Netze auf IPv6 umstellen.

MX-Records teilen anderen Mail Servern mit, wohin E-Mail für Ihre Domain zugestellt werden soll.

CAA-Records legen fest, welche Zertifizierungsstellen TLS-Zertifikate für Ihre Domain ausstellen dürfen, und senken so das Risiko einer Fehlausstellung.

DNSSEC signiert DNS-Antworten kryptografisch, sodass Resolver Manipulation und Spoofing erkennen können.

Ohne funktionierende DNS-Auflösung ist die Domain faktisch offline – keine Website, keine Mail, nichts. Alle weiteren Checks bauen darauf auf.

Fällt der einzige Nameserver aus, ist die gesamte Domain nicht mehr auflösbar. Mehrere Nameserver – idealerweise in getrennten Netzen – sind die einfachste und wirksamste Absicherung gegen Ausfälle (RFC 2182).

Ein eingetragener, aber toter Nameserver verlängert die Auflösungszeit für alle Besucher – Resolver müssen erst in einen Timeout laufen, bevor sie den nächsten Server versuchen. Bleibt nur ein funktionierender Server übrig, ist die Redundanz faktisch verloren.

Ein Nameserver, der in der Delegation steht, aber nicht autoritativ antwortet (z. B. weil der Zonentransfer fehlschlägt oder die Zone dort nie eingerichtet wurde), liefert je nach Resolver Fehler oder veraltete Daten – ein schwer zu diagnostizierender Teilausfall.

Unterschiedliche Serials bedeuten, dass die Server unterschiedliche Zonenstände ausliefern – Änderungen (neue Records, geänderte IPs) kommen dann nur bei einem Teil der Besucher an. Häufigste Ursache: ein hängender Zonentransfer zu einem Secondary.

Ein autoritativer Nameserver, der gleichzeitig als offener Resolver arbeitet, lässt sich für DNS-Amplification-Angriffe gegen Dritte missbrauchen und gefährdet die eigene Verfügbarkeit. Autoritative Server sollten Rekursion grundsätzlich verweigern (RFC 5358).

Ein NS-Record mit privater Adresse ist für das Internet unerreichbar und erzeugt bei jedem Resolver Timeouts. Zudem kann er interne Netzstrukturen preisgeben.

Nameserver im selben Netz teilen sich Router, Standort und meist auch den Anbieter – ein einziger Ausfall trifft dann alle gleichzeitig, und die nominelle Redundanz läuft ins Leere (RFC 2182 empfiehlt topologisch getrennte Standorte).

Damit IPv6-only-Clients eine Domain überhaupt auflösen können, müssen die Nameserver selbst über IPv6 erreichbar sein – idealerweise mindestens zwei, damit auch bei einem Ausfall noch Redundanz bleibt.

Weichen beide Listen ab, hängt es vom Zufall ab, welche Server ein Resolver verwendet – im schlechtesten Fall landen Anfragen auf Servern, die die Zone gar nicht mehr (oder noch nicht) kennen. Typische Ursache: ein Nameserver-Wechsel, der nur in der Zone oder nur beim Registrar nachgezogen wurde.

Ohne korrektes Glue entsteht ein Henne-Ei-Problem: Die Adresse des Nameservers ließe sich nur über den Nameserver selbst auflösen. Veraltetes Glue (z. B. nach einem Server-Umzug) führt zu schleichenden, schwer auffindbaren Auflösungsfehlern.

Ein Primary, der beim Parent fehlt, deutet auf eine unvollständig nachgezogene Konfiguration hin. Manche Systeme (z. B. Dynamic DNS Updates) adressieren gezielt den MNAME – ist er öffentlich nicht delegiert, verhalten sich solche Updates unzuverlässig.

Ein zu hoher Refresh verzögert die Verteilung von Zonenänderungen an die Secondaries; ein extrem niedriger erzeugt unnötige Last. Mit NOTIFY ist der Wert weniger kritisch, dient aber weiterhin als Sicherheitsnetz.

Ein zu hoher Retry lässt Secondaries nach einem Fehlversuch unnötig lange mit veralteten Daten laufen; ein zu niedriger hämmert auf einen ohnehin gestörten Primary ein.

Ein zu kurzer Expire lässt Secondaries bei einem längeren Primary-Ausfall die Zone komplett einstellen – dann ist die Domain trotz Redundanz offline. Ein zu langer Wert hält im Fehlerfall wochenlang veraltete Daten am Leben. Üblich sind 1–4 Wochen.

Ein zu hoher Wert lässt „Domain existiert nicht“-Antworten stundenlang im Cache kleben – neu angelegte Records werden dann verzögert sichtbar. Ein extrem niedriger Wert erhöht die Anfragelast spürbar.

Technisch ist jedes 32-Bit-Serial gültig – das Datumsformat ist reine Konvention. Es macht aber auf einen Blick sichtbar, wann die Zone zuletzt geändert wurde, und erleichtert die Fehlersuche bei Sync-Problemen erheblich. Viele Managed-DNS-Anbieter (z. B. mit Unix-Timestamps) weichen bewusst ab; das ist kein Fehler.

Grundlegende Erreichbarkeit über HTTPS ist Voraussetzung, bevor die übrigen Web-Checks laufen können.

IPv6-Erreichbarkeit hält die Seite für reine IPv6-Clients verfügbar, während Netze sich von IPv4 wegbewegen.

IPv6-Besucher sollen dieselbe Seite sehen wie IPv4-Besucher. Weicht der Inhalt stark ab, deutet das auf einen falsch konfigurierten IPv6-Server hin – etwa eine Fehlerseite oder eine veraltete Kopie.

Eine Umleitung von HTTP auf HTTPS sorgt dafür, dass Besucher, die das Schema weglassen, trotzdem die verschlüsselte Seite erreichen.

HSTS zwingt den Browser bei erneutem Besuch direkt auf HTTPS und schützt so vor Downgrade- und SSL-Stripping-Angriffen (Machine-in-the-Middle). Eine Cache-Gültigkeit von mindestens einem Jahr (max-age=31536000) gilt als ausreichend. Eine lange Gültigkeit schützt auch seltene Besucher – bedeutet aber: wollen Sie HTTPS später wieder abschalten (generell keine gute Idee), müssen Sie warten, bis die Richtlinie in allen Browsern abgelaufen ist, die Ihre Seite zuvor besucht haben.

Ob Preloading verwendet wird oder die Domain in der HSTS-Preload-Liste steht, wird hier nicht geprüft.

Eine Content-Security-Policy schränkt ein, welche Quellen eine Seite laden darf, und mindert Cross-Site-Scripting und Injection.

X-Frame-Options verhindert, dass die Seite in einem Frame eingebettet wird, und schützt vor Clickjacking.

nosniff hindert Browser daran, den Content-Type einer Antwort zu erraten, was harmlose Dateien in ausführbare Skripte verwandeln kann.

Eine Referrer-Policy steuert, wie viel der besuchten URL an andere Seiten weitergegeben wird, und schützt die Privatsphäre der Nutzer.

HTTP-Kompression (gzip/Brotli) beschleunigt das Laden spürbar und ist Standard. Der theoretische BREACH-Angriff betrifft nur geheimnis- und eingabespiegelnde Antworten und wird anderweitig entschärft – Kompression an sich ist kein Mangel. (TLS-Kompression/CRIME wird separat geprüft.)

Eine security.txt gibt Sicherheitsforschern einen klaren, maschinenlesbaren Weg, Schwachstellen an den richtigen Kontakt zu melden, und beschleunigt so Responsible Disclosure.

HTTP/2 überträgt mehrere Anfragen gemultiplext über eine Verbindung und beschleunigt so das Laden spürbar, besonders bei vielen Ressourcen. Es ist heute breit unterstützt und sollte für öffentliche Websites aktiv sein.

HTTP/3 läuft über QUIC (UDP) statt TCP und vermeidet dessen Head-of-Line-Blocking; das verbessert die Ladezeit vor allem bei wackligen Mobilverbindungen. Es ist eine sinnvolle Ergänzung, aber (noch) kein Muss.

Secure verhindert die Übertragung über unverschlüsseltes HTTP, HttpOnly schützt vor Auslesen per JavaScript (XSS) und SameSite erschwert Cross-Site-Request-Forgery. Fehlen diese Flags, sind Session-Cookies leichter angreifbar.

Über HTTP geladene Teilressourcen auf einer HTTPS-Seite lassen sich unterwegs manipulieren und heben den Schutz der verschlüsselten Verbindung teilweise auf. Browser blockieren aktives Mixed Content (Skripte) inzwischen, warnen aber nicht immer sichtbar.

SRI hinterlegt einen kryptografischen Hash der erwarteten Datei; der Browser lädt die Ressource nur, wenn sie exakt passt. Das schützt davor, dass ein kompromittiertes CDN oder Fremdhosting unbemerkt schädlichen Code ausliefert.

HTTPS verschlüsselt den Verkehr zwischen Besuchern und Server und ist die Grundlage jedes weiteren TLS-Checks.

TLS sichert die Verbindung zwischen Besuchern und Server. Ältere Versionen haben kryptografische Schwächen. Die Sicherheitsstufe je Version:

Es sollten nur TLS 1.2 und 1.3 angeboten werden.

Forward Secrecy stellt sicher, dass aufgezeichneter Verkehr später nicht entschlüsselt werden kann, selbst wenn der private Schlüssel des Servers kompromittiert wird.

Ein gültiges Zertifikat weist die Identität des Servers nach: Es muss zu einer vertrauenswürdigen Stelle zurückführen und zum angefragten Hostnamen passen.

Der öffentliche Schlüssel schützt den Schlüsselaustausch. RSA-Schlüssel sollten mindestens 2048 Bit, ECDSA mindestens 256 Bit haben.

Der Signaturalgorithmus schützt das Zertifikat vor Fälschung. SHA-1 und MD5 sind gebrochen und dürfen nicht verwendet werden.

OCSP-Stapling erlaubt dem Server nachzuweisen, dass sein Zertifikat nicht widerrufen ist, ohne dass der Besucher die Stelle kontaktiert — das verbessert Geschwindigkeit und Datenschutz.

DANE bindet Ihr Zertifikat an DNSSEC und lässt unterstützende Clients ein gefälschtes oder fehlausgestelltes Zertifikat erkennen, das eine öffentliche Stelle sonst akzeptieren könnte. Ein veröffentlichter, aber nicht passender Record ist schlimmer als keiner, weil strikte Clients die Verbindung verweigern.

Bestimmt der Server die bevorzugte Cipher Suite selbst, kann er immer das stärkste gemeinsam unterstützte Verfahren erzwingen. Überlässt er die Wahl dem Client, könnte ein manipulierter oder veralteter Client ein schwächeres Verfahren durchsetzen.

Ein ephemeraler Schlüsselaustausch (ECDHE oder DHE) sorgt für Forward Secrecy: Selbst wenn der private Serverschlüssel später kompromittiert wird, bleiben frühere Verbindungen geschützt. Statischer RSA-Schlüsselaustausch bietet das nicht.

Einordnung:

• Gut: ECDHE mit moderner Kurve (X25519, secp256r1/384r1), Hash SHA-256/384
• Ausreichend: DHE mit ≥ 2048-bit-Parametern
• Unzureichend: statischer RSA-Schlüsselaustausch, DH-Parameter < 2048 bit, Hash SHA-1/MD5

Aktive TLS-Kompression ermöglicht den CRIME-Angriff: Aus der komprimierten Nachrichtengröße lassen sich Rückschlüsse auf verschlüsselte Inhalte (z. B. Session-Cookies) ziehen. Kompression auf TLS-Ebene muss daher abgeschaltet sein.

Ohne sichere Renegotiation (RFC 5746) ist ein Prefix-Injection-Angriff möglich, bei dem ein Angreifer Daten vor die eigentliche Anfrage schiebt. Ergänzend sollte Client-initiierte Renegotiation deaktiviert sein, da sie sich für DoS missbrauchen lässt – TLS 1.3 entfernt Renegotiation vollständig, und moderne TLS-1.2-Server mit RFC-5746-Unterstützung lehnen Client-Renegotiation standardmäßig ab.

Extended Master Secret bindet das Master Secret an den gesamten Handshake und verhindert damit Triple-Handshake-Angriffe, bei denen sich TLS-Sitzungen über verschiedene Verbindungen hinweg verketten lassen. Bei TLS 1.2 sollte es aktiv sein.

0-RTT beschleunigt wiederkehrende Verbindungen, weil der Client schon vor Abschluss des Handshakes Daten mitsenden darf. Der Preis: Diese Early Data kann von einem Angreifer erneut eingespielt (repliziert) werden. Ohne serverseitigen Replay-Schutz – den man von außen nicht zuverlässig prüfen kann – ist das ein Risiko, vor allem für zustandsändernde Anfragen.

RPKI (Resource Public Key Infrastructure) lässt Netzbetreiber kryptografisch autorisieren, welche ASN einen IP-Präfix announcieren darf. Ein gültiger Eintrag schützt vor Route-Hijacking und Fehlkonfigurationen im BGP.

Einordnung:

• Gültig: ein ROA deckt die Route ab und die announcierende ASN stimmt überein
• Kein ROA: noch keine RPKI-Autorisierung veröffentlicht – empfohlen, aber kein akuter Fehler
• Ungültig: ein ROA existiert, aber die Announcement verletzt es (mögliche Fehlkonfiguration oder Hijack)

RPKI (Resource Public Key Infrastructure) lässt Netzbetreiber kryptografisch autorisieren, welche ASN einen IP-Präfix announcieren darf. Ein gültiger Eintrag schützt vor Route-Hijacking und Fehlkonfigurationen im BGP.

Einordnung:

• Gültig: ein ROA deckt die Route ab und die announcierende ASN stimmt überein
• Kein ROA: noch keine RPKI-Autorisierung veröffentlicht – empfohlen, aber kein akuter Fehler
• Ungültig: ein ROA existiert, aber die Announcement verletzt es (mögliche Fehlkonfiguration oder Hijack)

MX-Records sind der Einstiegspunkt der Mail-Konfiguration. Ohne sie empfängt die Domain keine E-Mail, und die folgenden Mail-Transport-Checks entfallen.

SPF legt fest, welche Server Mail für Ihre Domain senden dürfen. Eine strikte Policy (-all) weist Empfänger an, Mail aus jeder anderen Quelle abzulehnen, und erschwert so Spoofing. Ein Soft-Fail (~all) markiert solche Mail nur; eine fehlende oder freizügige Policy schützt kaum.

DKIM versieht ausgehende Mail mit einer kryptografischen Signatur, sodass Empfänger prüfen können, dass sie von Ihrer Domain autorisiert und unterwegs nicht verändert wurde. Eigene Selektoren lassen sich nicht aus dem DNS ermitteln – ein negatives Ergebnis bedeutet also nicht zwingend, dass DKIM fehlt.

DMARC verbindet SPF und DKIM und legt fest, was Empfänger mit Mail tun sollen, die beide nicht besteht – und wohin Berichte gehen. Eine durchsetzende Policy (quarantine oder reject) blockiert gefälschte Mail aktiv; p=none beobachtet nur.

Sendende Server in reinen IPv6-Netzen können Mail nur zustellen, wenn Ihre Mail Server über IPv6 erreichbar sind.

STARTTLS verschlüsselt Mail auf dem Transport zwischen Servern. Ohne STARTTLS wandern Nachrichten im Klartext und können unterwegs gelesen oder verändert werden. Für vertrauenswürdige Verschlüsselung braucht es ein gültiges, zum Hostnamen passendes Zertifikat.

Wie beim Webserver gelten nur TLS 1.2 und 1.3 als sicher für den Mail-Transport; ältere Versionen haben bekannte Schwächen.

DANE bindet die Zertifikate Ihrer Mail Server an DNSSEC, sodass ein sendender Server ein gefälschtes oder heruntergestuftes Zertifikat erkennt, das eine öffentliche Stelle sonst akzeptieren könnte. Ein veröffentlichter, aber nicht passender TLSA-Record ist schlimmer als keiner, weil strikte Absender die Zustellung verweigern.

BIMI (Brand Indicators for Message Identification) lässt unterstützende Mail-Clients Ihr Marken-Logo neben authentifizierten E-Mails anzeigen. Es ist kein Sicherheitsmechanismus, sondern eine Zusatzfunktion für die Markendarstellung – setzt aber saubere Mail-Authentifizierung (SPF, DKIM, strikte DMARC-Policy) voraus und ist damit ein sichtbarer Bonus einer korrekten Konfiguration.

MTA-STS zwingt sendende Mailserver, Ihre MX nur über eine verschlüsselte, zertifikatsgeprüfte Verbindung zu erreichen. Das schliesst eine Lücke von opportunistischem STARTTLS, das sich per Downgrade-Angriff aushebeln lässt. Der Modus „enforce“ bietet den vollen Schutz.

TLS-RPT lässt andere Mailserver Ihnen täglich Berichte über fehlgeschlagene TLS-Verbindungen zu Ihren MX schicken. So bemerken Sie Zertifikats- oder STARTTLS-Probleme, bevor Mail unbemerkt unverschlüsselt oder gar nicht mehr zugestellt wird – ideal in Kombination mit MTA-STS.

Empfangende Mailserver prüfen häufig, ob die IP eines sendenden Servers einen PTR-Record hat (idealerweise passend zum HELO-/MX-Namen). Fehlt er, landen Ihre Mails schneller im Spam oder werden ganz abgewiesen.

Ein offener Relay nimmt Mail von beliebigen Absendern an beliebige Empfänger an und wird umgehend für Spam- und Phishing-Versand missbraucht. Das schädigt die Reputation der Server-IP massiv und führt schnell zu Blacklist-Einträgen.

Forward Secrecy (ECDHE/DHE) sorgt dafür, dass eine spätere Kompromittierung des Serverschlüssels frühere, mitgeschnittene Mail-Verbindungen nicht nachträglich entschlüsselbar macht.

Ein gültiges, passendes Zertifikat ist die Voraussetzung dafür, dass sendende Server die TLS-Verbindung tatsächlich verifizieren können (relevant besonders bei MTA-STS/DANE). Bei opportunistischem STARTTLS ohne Erzwingung wird ein ungültiges Zertifikat zwar oft akzeptiert, untergräbt aber den Schutz.

Zu kurze Schlüssel (RSA < 2048 bit, ECDSA < 256 bit) gelten als unsicher und lassen sich mit vertretbarem Aufwand angreifen.

Signaturen mit SHA-1 oder MD5 gelten als gebrochen und ermöglichen theoretisch gefälschte Zertifikate. Moderne Zertifikate nutzen SHA-256 oder stärker.

Aktive TLS-Kompression ermöglicht CRIME-artige Angriffe und muss deaktiviert sein. TLS 1.3 kennt keine Record-Kompression.

Ohne sichere Renegotiation ist ein Prefix-Injection-Angriff auf die TLS-Verbindung möglich. TLS 1.3 entfernt Renegotiation vollständig.

Extended Master Secret bindet das Master Secret an den gesamten Handshake und verhindert Triple-Handshake-Angriffe. Bei TLS 1.2 sollte es aktiv sein; TLS 1.3 ersetzt es durch seinen Schlüsselplan.

RPKI (Resource Public Key Infrastructure) lässt Netzbetreiber kryptografisch autorisieren, welche ASN einen IP-Präfix announcieren darf. Ein gültiger Eintrag schützt vor Route-Hijacking und Fehlkonfigurationen im BGP.

Einordnung:

• Gültig: ein ROA deckt die Route ab und die announcierende ASN stimmt überein
• Kein ROA: noch keine RPKI-Autorisierung veröffentlicht – empfohlen, aber kein akuter Fehler
• Ungültig: ein ROA existiert, aber die Announcement verletzt es (mögliche Fehlkonfiguration oder Hijack)