DNS, SSL, Redirect & URL — Tipps & Tricks

Zurück zur Übersicht: DNS, SSL, Redirect & URL · Tool live öffnen: www.jpkc.com/tools/dns-ssl-redirect-url/

Das Manual erklärt jeden Tab, die Beispiele zeigen die Abläufe. Hier geht es um das, was beides voraussetzt: wie du die Ergebnisse klug liest, wo die Fallen liegen und wie du das Tool mit anderen kombinierst.

Ergebnisse richtig deuten

Restlaufzeit schlägt Gültigkeit. Ein Zertifikat mit Trust: „Trusted" ist heute gültig — aber die Zeile Valid Until mit ihrer Tagesangabe sagt dir, wie lange noch. Ab Gelb (≤ 30 Tage) gehört die Verlängerung in die Planung; rot bedeutet, dass Besucher bereits eine Warnung sehen.
Eine unvollständige Kette ist die häufigste „komische" SSL-Meldung. Wenn manche Clients meckern, obwohl das Zertifikat gültig ist, fehlt meist das Intermediate-Zertifikat. Die Certificate Chain-Karte zeigt die Kette so, wie dein Server sie sendet: Steht dort nur das Server-Zertifikat, meldet das Tool „The server sends no intermediate certificate". Dass die Root fehlt, ist dagegen normal — die bringt der Client selbst mit.
Die Befunde-Liste ist dein Kurzbericht. Unter der Zertifikatskarte sammelt das Tool alles, was auffällt: Ablauf in höchstens 14 Tagen, nicht abgedeckter Hostname, Selbstsignatur, SHA-1- oder MD5-Signaturen, RSA-Schlüssel unter 2048 Bit, eine gebrochene Kette. Steht dort nichts und zeigt die Trust-Zeile „Trusted", ist das Zertifikat technisch sauber — die Befunde allein prüfen weder das Vertrauen in die ausstellende CA noch einen Widerruf.
„Cross-signed root" ist kein Fehler. Eine CA mit „Root" im Namen, die nicht selbstsigniert ist, wurde von einer älteren Root gegengezeichnet, damit auch ältere Geräte ihr vertrauen. Sie arbeitet in der Kette als Intermediate — entscheidend ist das grüne „signature ok".
CAA zeigt, wer ausstellen darf. Meldet die CAA-Karte „CA not listed", stammt das laufende Zertifikat von einer CA, die dein CAA-Record heute nicht erlaubt. Die nächste Verlängerung bei dieser CA scheitert dann — passe den Record an oder wechsle die CA. „not compared" heißt nur, dass das Tool die ausstellende CA keinem CAA-Namen zuordnen konnte.
Vorhandene Security-Header sind nicht automatisch gute Header. Das Zähler-Badge („x/9") zählt nur Anwesenheit. Entscheidend sind die Validierungs-Badges dahinter: HSTS mit zu kurzer max-age, eine CSP mit unsafe-inline/unsafe-eval oder ein X-Content-Type-Options ohne nosniff werden gelb bzw. rot markiert. Lies die Badges, nicht nur das Häkchen.
Jeder Redirect-Hop kostet. Drei Hops, um von http:// ohne www zur finalen https://www…-Adresse zu kommen, sind verbreitet, aber suboptimal. Ziel ist ein Sprung. Und: Pendelt die Kette zwischen http und https, ist die Server-Regel unsauber — das HTTP/HTTPS-Badge pro Hop macht es sichtbar.
DKIM „not found" heißt nicht „kein DKIM". Check All probiert 21 gängige Selektoren. Nutzt dein Anbieter einen eigenen Namen, findet das Tool ihn nicht — frag <selector>._domainkey.<domain> dann gezielt als TXT ab. Den Selektor verrät der DKIM-Signature-Header einer echten Mail; der Mail Header Analyzer zeigt ihn in der Karte „DKIM signatures" als s=.
DMARC p=none ist nur Beobachtung. Die Mail-Übersicht färbt p=none gelb („monitoring only"), weil gefälschte Mails damit weiter zugestellt werden. Grün wird es erst mit p=quarantine oder p=reject.
Wildcard (A) im Check All ist ein Signal, kein Fehler. Erscheint der Abschnitt, löst jede Subdomain auf. Manchmal Absicht (Catch-all), oft ein vergessener Wildcard-Eintrag, der Subdomain-Takeover oder ungewollte Treffer begünstigt.

Den SPF-Generator richtig nutzen

Der Lookup-Zähler ist die wichtigste Zahl — aber zähl rekursiv. SPF erlaubt hart maximal 10 DNS-Lookups, und zwar über den ganzen Record samt allen eingebundenen Records. ip4:/ip6: sind gratis, jedes include:, a, mx, ptr, exists und redirect= kostet einen Lookup. Der Live-Zähler DNS lookups (this record) sieht nur deinen eigenen Record; was ein include: seinerseits auflöst, zählt erst Count all lookups (incl. nested includes). Bleib in dieser Gesamtzahl bei höchstens 10, sonst werten Empfänger den Record als permerror.
Provider zusammenfassen statt stapeln. Jeder Provider-Preset bringt seinen include: mit, und manche lösen intern weitere Lookups aus. Trägst du Google, Microsoft 365 und drei Newsletter-Dienste gleichzeitig ein, bist du schnell über dem Limit. Der Baum der rekursiven Analyse zeigt dir, welcher Dienst wie viel kostet — räum aus, was nicht mehr sendet.
Achte auf Void-Lookups. Zeigt ein include: auf einen Namen ohne SPF-Record, meldet die Analyse einen Fehler und zählt einen „void lookup"; mehr als zwei davon machen den Record ebenfalls ungültig. Typischer Fall: ein Dienst, den du längst gekündigt hast.
Laden statt abtippen. Willst du einen bestehenden Record umbauen, trag die Domain ein und klick Load. Das Tool verteilt den Record aufs Formular; was es nicht zuordnen kann, landet unter Custom mechanisms. Erhalten bleibt dabei nicht alles: Der neu gebaute Record folgt der festen Reihenfolge des Generators, Mechanismen mit Qualifier wie -ip4:… rutschen so hinter a, mx und die include:-Einträge, und ungültige IP-Werte fallen weg. Vergleiche den neuen Record vor dem Veröffentlichen mit dem alten.
~all zum Testen, -all für Produktion. Der Default ~all (SoftFail) markiert unautorisierte Mail nur. Erst wenn du sicher bist, dass alle legitimen Sender im Record stehen, schalt auf -all (Fail) scharf. +all ist nie eine gute Idee — das Tool warnt zu Recht.
redirect= und All-Policy schließen sich aus. Setzt du redirect=, lässt der Generator die All-Policy automatisch weg und weist per Hinweis darauf hin. Nutze redirect= nur, wenn eine andere Domain die SPF-Hoheit hat.
Verify DNS schließt den Kreis. Nach dem Eintragen springst du per Verify DNS direkt in den DNS-Tab (Typ TXT) und kontrollierst den live veröffentlichten Record — denk an die Propagationszeit (bis zu 48 Stunden).

Stolperfallen aus der Praxis

Das Tool sieht, was der JPKCom-Server sieht — nicht deinen Browser. DNS, SSL und Redirect laufen serverseitig. Geo-spezifisches DNS (GeoDNS), Login-geschützte Seiten oder Inhalte, die erst clientseitig erscheinen, sieht der Server womöglich anders als du. Für reproduzierbare Checks ist das ein Vorteil, für „bei mir sieht es anders aus"-Fälle die Erklärung.
localhost und Intranet gehen nicht. Der SSRF-Schutz blockiert private, Loopback-, reservierte und CGNAT-Adressen — beim DNS-Reverse-Lookup, beim SSL-/Redirect-Abruf und bei jedem Redirect-Hop neu. Eine lokale Dev-Instanz kannst du nicht prüfen — auch nicht im Expert Mode, denn der lokale Proxy blockiert dieselben Adressbereiche. Nutze eine öffentliche Staging-Domain. Ebenso gesperrt sind Ports außerhalb von 80, 443, 3000, 5000, 8000, 8008, 8080 und 8443.
„Forbidden" oder „Security token expired" heißt: Seite neu laden. Das Tool holt vor jeder Anfrage selbst ein frisches Token. Die Schlüssel dafür stecken aber in der geladenen Seite und wechseln täglich um Mitternacht (UTC). Lag der Tab darüber hinaus offen, scheitert die nächste Anfrage mit „Forbidden" (selten mit „Security token expired") — erst ein Reload holt neue Schlüssel.
Zu schnell geklickt? Kurz warten. Eine clientseitige Drossel lässt etwa eine Server-Anfrage pro Sekunde zu; feuerst du schneller, kommt der Hinweis „Please wait a moment". Einfach einen Moment warten statt nachklicken. Dazu kommt ein serverseitiges Limit pro IP-Adresse — Check All und die SPF-Funktionen teilen sich dabei ein gemeinsames Limit von 20 Aufrufen pro Minute. Die Meldung nennt die Wartezeit gleich mit — im DNS-Tab als „Rate limited. Please wait …ms.", bei SSL, Redirect und der SPF-Analyse als „Too many requests — please wait … s and try again."
Reverse-Lookup nur für öffentliche IPs. PTR auf eine private IP (z. B. 192.168.…) lehnt das Tool ab. Das ist kein Bug, sondern derselbe SSRF-Schutz.
Der URL-Parser maskiert Passwörter — die History nicht. Steckt in einer Adresse ein user:pass@-Teil, zeigt der Parser das Passwort als ***, auch in der Encoding-Karte. Die URL-History speichert die Eingabe aber unverändert im Browser und listet sie im Klartext. Nach einem Test mit Zugangsdaten klickst du dort auf Clear.

Privatsphäre im Blick

Der serverseitige Abruf hat eine bewusste Privacy-Eigenschaft: Die geprüfte Domain protokolliert einen Request vom JPKCom-Server, nicht deine IP-Adresse. Das ist praktisch, wenn du fremde Seiten prüfst, ohne dich selbst zu „zeigen". Umgekehrt heißt es: Die Server-Endpunkte sind kein offenes API — sie sind durch Token, Zeitfenster und Referer-Prüfung abgesichert und nur aus dem Tool heraus nutzbar. Willst du Rohdaten weiterverarbeiten, nimm die JSON-Buttons der Ergebnis-Tabs: Copy und JSON im DNS-Tab, Copy JSON und Save JSON bei SSL und Redirect, Copy JSON im URL-Parser.

Mit anderen JPKCom-Tools kombinieren

Seite ganzheitlich statt punktuell prüfen? Der SEO & GEO Analyzer bewertet HTTPS, Redirects, Security-Header und Performance einer Seite im Zusammenhang und vergibt Scores — die ideale Ergänzung, wenn dir der SSL-Tab nur den Technik-Ausschnitt zeigt.
Zertifikat-Problem gefunden? Ein Klick auf PKI Viewer in der Kettenkarte öffnet den PKI Viewer mit der kompletten Kette — dort inspizierst du jedes Zertifikat mit allen Feldern, der nächste Schritt, wenn die Trust-Zeile rot war.
IPs aus DNS oder Redirect weiterverfolgen? Die IP-Tools analysieren Adressen und Subnetze, etwa wenn eine Redirect-IP oder ein A-Record verdächtig wirkt.
SPF in der echten Mail kontrollieren? Der Mail-Header-Analyzer liest Empfangs-Header und zeigt, ob SPF/DKIM/DMARC bei der Zustellung tatsächlich greifen — die Praxisprobe für den hier gebauten Record.

Das Muster ist immer dasselbe: hier diagnostizieren, mit dem passenden Tool reparieren oder vertiefen, dann erneut prüfen.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Tab und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.