Website-Prüfwerkzeuge verstehen: DNS, IP, SSL/TLS, RDAP, HTTP, Redirects und Sicherheit

Prüfwerkzeuge sind dann wertvoll, wenn sie eine konkrete technische Frage beantworten: Wohin löst eine Domain auf, welches Netzwerk liefert sie aus, passt das Zertifikat zum Hostnamen und welchen HTTP-Status liefert der Server tatsächlich? DNS-Abfrage und SSL/TLS-Prüfung zeigen jeweils nur eine Schicht. Belastbare Diagnose entsteht durch das Zusammensetzen mehrerer Ergebnisse.

DNS: Autorität, Cache und TTL unterscheiden

DNS übersetzt Namen in nutzbare Datensätze. A und AAAA liefern IP-Adressen, MX Mailserver, NS autoritative Nameserver, CNAME Aliase und TXT wird für viele Richtlinien und Verifizierungen genutzt. Eine DNS-Abfrage ist jedoch nur eine Momentaufnahme. Rekursive Resolver können ältere Antworten im Cache halten, bis die vorher gültige TTL abgelaufen ist.

Bei Migrationen sollte nicht nur die sichtbare IP geprüft werden. Entscheidend sind Registrar-Delegation, autoritative Antwort, Cache-Zustand und gegebenenfalls DNSSEC. Zwei Nutzer können während einer Änderung vorübergehend unterschiedliche Antworten sehen. Vergleichen Sie daher autoritative Server mit mehreren Resolvern und dokumentieren Sie den Zeitpunkt der Abfrage.

IP-Daten liefern Kontext, keine Identität

Eine IP-Abfrage kann Routing, Autonomous System, Hostingnetz oder grobe Geografie zeigen. Das hilft bei CDN-Problemen, verdächtigem Traffic und Hostingwechseln. Eine öffentliche IP ist jedoch kein verlässlicher Wohnort oder Personenbeweis. Mobilfunk, VPN, Proxy, Unternehmensgateway und Cloudplattformen teilen Adressen zwischen vielen Nutzern.

Auch Reverse-IP-Ergebnisse können irreführen. CDNs und Shared Hosting bedienen zahlreiche Domains über dieselbe Adresse; große Websites nutzen gleichzeitig viele Adressen. Betrachten Sie solche Ergebnisse als Hinweis und gleichen Sie sie mit DNS, Registrierungsdaten und der Anwendung ab.

Von WHOIS zu RDAP

ICANN hat RDAP als modernes Protokoll für Registrierungsdaten eingeführt und nennt RDAP seit dem 28. Januar 2025 als definitive Quelle für gTLD-Registrierungsdaten. Eine WHOIS-/Registrierungsabfrage kann weiterhin eine vertraute Oberfläche bieten, doch im Hintergrund stammt die strukturierte Information zunehmend aus RDAP.

Datenschutz und Registry-Regeln führen bewusst zu geschwärzten Feldern. Registrar, Statuscodes und technische Registrierungsinformationen sind oft sichtbar, persönliche Inhaberdaten aber nicht zwingend. Für Abuse- oder Rechtsfälle sollte der offizielle Prozess des Registrars oder der Registry genutzt werden.

TLS-Zertifikat: was es beweist und was nicht

Die SSL/TLS-Prüfung zeigt Zertifikatsnamen, Aussteller, Gültigkeit und Chain. Wichtig sind Hostname-Match, Gültigkeitszeitraum und eine vertrauenswürdige Zertifizierungskette. TLS 1.3 ist in RFC 8446 standardisiert und schützt bei korrekter Aushandlung die Daten auf dem Transportweg.

Ein gültiges Zertifikat macht eine Website nicht automatisch seriös. Auch Angreifer können für eigene Domains Zertifikate erhalten. Umgekehrt kann eine Warnung durch Ablaufdatum, fehlendes Intermediate, falsche Uhrzeit oder Unternehmens-Interception entstehen. TLS ist deshalb ein Verbindungs- und Identitätsindikator, kein vollständiges Reputationsurteil.

HTTP-Header und Protokollmerkmale

Die HTTP-Header-Abfrage macht Statuscodes, Redirect-Ziele, Cache-Regeln, Content-Type, Content-Encoding, Cookies und Sicherheitsheader sichtbar. Das erklärt oft Verhalten, das in der gerenderten Seite nicht erkennbar ist. Derselbe URL kann je nach Methode, Authentisierung, Negotiation oder Cache eine andere Repräsentation liefern.

HTTP/2- oder Brotli-Checker prüfen eine engere Fähigkeit. Ein Server kann eine Technik grundsätzlich unterstützen, aber für einen bestimmten Client oder Ressourcentyp etwas anderes aushandeln. Für Performance-Analysen zählt daher die tatsächliche Browser-Antwort und nicht nur ein generelles „unterstützt“.

Redirects bei Migrationen kontrollieren

Der Redirect-Prüfer zeigt Ketten aus 301, 302, 307 oder 308 und findet Schleifen sowie unnötige Hops. Bei Domainwechsel, HTTPS-Umstellung oder URL-Neustrukturierung sollten Pfad, Query und Zielseite erhalten bleiben. Jede zusätzliche Weiterleitung erhöht Latenz und Fehlerrisiko.

Offene Redirects sind außerdem ein Sicherheitsproblem, wenn Nutzer ein beliebiges Ziel einschleusen können. Testen Sie neben der Startseite alte Bookmarks, Groß-/Kleinschreibung, Slash-Varianten, Query-Strings und HTTP-zu-HTTPS. Die Anwendung muss erlaubte Ziele serverseitig validieren.

Ping richtig interpretieren

Ping nutzt typischerweise ICMP Echo und misst Antwortzeit und Paketverlust. Viele Firewalls blockieren ICMP absichtlich. Ein fehlgeschlagener Ping beweist deshalb keine Downtime, während ein erfolgreicher Ping nichts über Login, Datenbank oder HTTP-Anwendung aussagt.

Für echte Verfügbarkeit sollte das Zielprotokoll geprüft werden: DNS, TCP/TLS, HTTP und schließlich die Anwendungsantwort. Messungen aus verschiedenen Regionen sind aussagekräftiger, weil Internet-Routing standortabhängig ist.

Sicherheitschecker bleiben Signale

Ein Safe-URL-Checker kann Reputation und bekannte Bedrohungssignale auswerten, aber neue Angriffe können vor Listenupdates auftreten. Prüfen Sie zusätzlich den Hostnamen, Browserwarnungen und den Kontext des Links.

Ein Passwortstärke-Prüfer erkennt kurze oder vorhersehbare Muster, aber keine Wiederverwendung auf anderen Diensten. CISA empfiehlt lange, zufällige und einzigartige Passwörter sowie Passwortmanager. Betreiber benötigen zusätzlich sichere Hashverfahren, Rate Limits und nach Möglichkeit MFA.

Diagnose in Schichten

Gehen Sie bei Störungen von DNS über Netzwerk und TLS bis HTTP vor. So vermeiden Sie Maßnahmen an der falschen Ebene. Ein DNS-Problem wird nicht durch Cache-Header gelöst, und ein korrektes DNS repariert kein abgelaufenes Zertifikat.

Bei intermittierenden Fehlern sollten Zeitstempel und Rohwerte gespeichert werden. DNS-Caches, Zertifikate und CDN-Routen ändern sich. Checker sind am stärksten, wenn sie schnell Belege liefern; ein grünes oder rotes Symbol allein ist keine vollständige Diagnose.

Häufige Fragen

Standards und offizielle Sicherheitsquellen

• ICANN — Registration Data Access Protocol (RDAP)
• ICANN — RDAP becomes the definitive source for gTLD registration data
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9110 — HTTP Semantics
• CISA — Use Strong Passwords

This article is an original practical guide informed by the standards and official references above.