JPKCom DB

DNS, SSL, Redirect & URL — Anwendungsbeispiele

Praxisabläufe: Domain samt Mail-Security prüfen, kaputte Zertifikate untersuchen, Redirect-Ketten lesen, URLs zerlegen, SPF-Records bauen und nachzählen.

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

Das Manual beschreibt jeden Tab im Detail. Diese Seite ergänzt das um konkrete Arbeitsabläufe: typische Aufgaben, Schritt für Schritt durchgespielt. Die Oberfläche ist auf Englisch — Tab- und Button-Namen stehen deshalb im Original, bei Bedarf mit deutscher Erläuterung. Alle Domains und Werte hier sind Beispiele, keine festen Tool-Konstanten.

Beispiel 1: Eine Domain komplett durchleuchten (Check All)

Du hast eine Domain übernommen und willst auf einen Blick wissen, wie ihr DNS steht.

  1. Öffne den DNS-Tab, trag example.com ins Domain-Feld ein und klick auf Check All.
  2. Das Ergebnis erscheint als JSON, gegliedert in Abschnitte: A, AAAA, MX, NS, TXT, SOA, dazu — falls vorhanden — CAA, www (A), DMARC (TXT), DKIM (TXT), MTA-STS (TXT), TLS-RPT (TXT), BIMI (TXT) und Wildcard (A).
  3. Lies zuerst die Karte „Mail & domain security" über dem JSON. Sie bewertet die Mail-Einträge auf einen Blick: Ist SPF „present" — und nur einmal vorhanden? Steht bei DMARC ein grünes p=reject oder p=quarantine oder nur ein gelbes „monitoring only"? Hat DKIM unter einem der 21 geprüften Selektoren einen Schlüssel gefunden? Gibt es MX-Server, MTA-STS, TLS-RPT und CAA? Ein gelbes „missing" bei DMARC ist ein häufiger Mangel.
  4. Steht bei DKIM „not found", heißt das nur, dass keiner der gängigen Selektoren passt. Kennst du den Selektor deines Mailanbieters, fragst du <selector>._domainkey.example.com gezielt per TXT ab.
  5. Achte auf Wildcard (A). Erscheint dieser Abschnitt, löst jede beliebige Subdomain auf — das ist manchmal gewollt, oft aber ein Konfigurationsfehler.
  6. Klick auf Zone, um dasselbe Ergebnis als BIND-artige Zonendatei zu sehen, und sichere es mit Save Zone als Referenz-Snapshot.

Beispiel 2: Ein einzelnes Mail-Detail nachschlagen (TXT/MX)

Du willst nur wissen, ob ein bestimmter TXT-Record (z. B. SPF) gesetzt ist.

  1. Im DNS-Tab example.com eintragen, im Dropdown TXT wählen, Lookup klicken.
  2. Im Ergebnis suchst du die Zeile, die mit v=spf1 beginnt — das ist der SPF-Record. Fehlt sie, hat die Domain keinen SPF-Eintrag. Kommt gar kein TXT-Record zurück, sagt dir ein Hinweis über dem JSON, ob der Name existiert und nur keine TXT-Records hat oder ob es ihn gar nicht gibt (NXDOMAIN).
  3. Für die Mailserver selbst wechselst du den Typ auf MX und schaust auf pri (Priorität) und target (Zielserver).
  4. Brauchst du einen Reverse-Check, gib statt der Domain die IP-Adresse ein: Das Tool springt automatisch auf PTR und zeigt den Hostnamen hinter der IP.

Beispiel 3: Ein Zertifikat kontrollieren — gültig oder bald abgelaufen?

Der Klassiker vor einem Go-Live oder bei einer Zertifikatswarnung.

  1. Wechsle in den SSL / Security-Tab, trag example.com ein (das https:// ist schon davor) und klick Check SSL.
  2. Sieh in der Certificate-Karte auf Valid Until: Die Restlaufzeit steht in Klammern. Grün heißt reichlich Zeit, gelb ab 30 Tagen oder weniger (Verlängerung einplanen), rot bedeutet abgelaufen.
  3. Prüf die Zeilen Trust und Host Name: „Trusted (verified against the CA store)" und „covered by the certificate" heißen, dass Kette und Hostname passen. Ein roter Text wie „Not trusted: Incomplete chain or unknown issuer" oder „Host name does not match the certificate" benennt das konkrete Problem; die Befunde unter der Tabelle listen zusätzlich alles, was auffällt — etwa einen Ablauf in höchstens 14 Tagen oder einen zu kurzen RSA-Schlüssel.
  4. In der Subject Alternative Names-Karte kontrollierst du, ob alle nötigen Hostnamen (z. B. example.com und www.example.com) im Zertifikat stehen — fehlt einer, gibt es für diesen Host eine Browser-Warnung.
  5. Die Certificate Chain zeigt die Kette so, wie dein Server sie sendet: das Server-Zertifikat, dahinter mindestens ein Intermediate CA mit grünem „signature ok". Die Root fehlt dort normalerweise — die hat der Client selbst. Sendet der Server nur sein eigenes Zertifikat, meldet das Tool „The server sends no intermediate certificate" — eine häufige, leicht übersehene Fehlerquelle.
  6. Unter Connection siehst du außerdem TLS-Version und Cipher. Ein rotes „outdated" neben TLS 1.0 oder 1.1 heißt: Der Server bietet nichts Neueres an. Die Zeile zeigt nur die ausgehandelte Version — ob ein Server neben TLS 1.2 oder 1.3 zusätzlich ältere Versionen erlaubt, verrät sie nicht.

Beispiel 4: Die Security-Header einer Seite bewerten

Du willst die HTTP-Schutzmechanismen einer Seite prüfen.

  1. Im SSL / Security-Tab nach dem Lauf zur Security Headers-Karte scrollen. Das Badge zeigt z. B. „4/9" — vier von neun geprüften Headern sind gesetzt (ab 6 grün, ab 3 gelb, darunter rot). Leitet die Adresse weiter, stammen die Header vom Ziel der Weiterleitung — für eine bestimmte Adresse gibst du deshalb gleich die finale ein.
  2. Geprüft werden HSTS, CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy und Cross-Origin-Resource-Policy.
  3. Lies die Validierungs-Badges, nicht nur das Häkchen: Ein vorhandener HSTS-Header mit zu kurzer max-age bekommt ein gelbes Warn-Badge („max-age … < 31536000"), eine CSP mit unsafe-inline ebenso. Vorhanden allein heißt also nicht automatisch korrekt.
  4. Fehlende Header zeigen einen kurzen Hinweis, wovor sie schützen würden („Prevents clickjacking" usw.) — deine To-do-Liste für die Server-Konfiguration.
  5. Steht im Kartenkopf „not available" statt einer Zahl, kam keine HTTP-Antwort zustande. Dann sind die Header unbekannt, nicht fehlend — prüf zuerst den Fehler-Alert oben.

Beispiel 5: Eine Redirect-Kette nachvollziehen (www → non-www, HTTP → HTTPS)

Nach einer Migration willst du sehen, ob Weiterleitungen sauber laufen.

  1. Im Redirect-Tab http://example.com eingeben (bewusst mit http://, um die Umleitung auf HTTPS zu sehen) und Trace Redirects klicken.
  2. Du bekommst die Kette Hop für Hop, z. B.:
    • Hop 1 http://example.com → Status 301, HTTP-Badge.
    • Hop 2 https://example.com → Status 301, HTTPS-Badge.
    • Hop 3 https://www.example.com → Status 200, als Endpunkt markiert.
  3. Bewerte die Länge der Kette. Jeder zusätzliche Hop kostet Ladezeit und ist für SEO unschön. Ideal ist ein Sprung aufs Ziel; drei wie oben (erst HTTPS, dann www) lassen sich oft zu einem zusammenfassen.
  4. Achte auf gemischte Protokolle. Springt die Kette zwischen http und https hin und her, ist die Server-Regel unsauber. Das HTTP/HTTPS-Badge pro Hop macht das sofort sichtbar.
  5. Endet die Kette mit „Redirect loop detected", weisen sich zwei URLs gegenseitig zu — ein klassischer Fehlkonfigurations-Fall, den du sofort siehst. Steht stattdessen „Stopped after 10 hops — the chain continues", ist die Kette länger als zehn Sprünge; auch das gehört gekürzt.
  6. Trägt ein Hop das graue Badge GET, hat der Server die HEAD-Anfrage mit 405 oder 501 abgelehnt. Das Tool hat die Header dann per GET gelesen — das Ergebnis gilt trotzdem, aber der Server behandelt HEAD nicht sauber.

Beispiel 6: Eine URL zerlegen und einen Slug erzeugen

Du arbeitest an Tracking-Links oder sauberen Pfaden.

  1. Im URL-Tab eine Adresse mit Parametern einfügen, etwa https://example.com/produkte?ref=newsletter&utm_source=mail#oben, und Parse URL klicken.
  2. Die URL-Components-Tabelle zeigt jedes Teil einzeln: protocol (https:), hostname, pathname (/produkte), search, hash (#oben), origin und mehr. Die Search-Parameters-Tabelle listet ref = newsletter und utm_source = mail getrennt auf — praktisch, um Tracking-Parameter zu kontrollieren.
  3. Gibst du eine internationalisierte Domain ein (z. B. https://müller.de), erscheint zusätzlich hostname (Unicode) neben der Punycode-Form — so siehst du beide Schreibweisen. Die Karte Encoding zeigt die Adresse unter Encoded (as sent) so, wie sie tatsächlich übertragen wird (Punycode, Prozentkodierung), und unter Decoded (readable) in lesbarer Form mit Umlauten.
  4. Roll nach unten zum URL Slug Generator, tipp einen Titel wie Über die Größe & Schönheit moderner Webtechnologien ein. Live entsteht der Slug ueber-die-groesse-schoenheit-moderner-webtechnologien (Umlaute aufgelöst, Sonderzeichen entfernt). Über Separator schaltest du auf _ um; Copy übernimmt das Ergebnis.

Beispiel 7: Einen SPF-Record für Google Workspace bauen

Deine Domain verschickt Mail über Google und einen Newsletter-Dienst.

  1. Im SPF-Tab steht oben die All Policy. Lass sie fürs Erste auf ~all (SoftFail) — zum scharfen Schalten später auf -all.
  2. Unter Own Mail Servers ist mx bereits aktiv. Lass es an, wenn deine MX-Server selbst Mail versenden.
  3. Klick bei Mail Providers auf Google — der Record rechts ergänzt sofort include:_spf.google.com. Für den Newsletter klick zusätzlich z. B. Brevo oder leg über Add include: eine eigene Zeile an.
  4. Behalte die Statistik im Auge. Die Zeile zeigt DNS lookups (this record) (x/10) und Length. Wird der Lookup-Zähler gelb (ab 8) oder rot (über 10), hast du schon im eigenen Record zu viele include:/a/mx-Mechanismen — fass sie zusammen. Der Zähler sieht aber nur deinen Record, nicht die Lookups, die _spf.google.com und der Newsletter-Dienst ihrerseits auslösen.
  5. Klick deshalb auf Count all lookups (incl. nested includes). Das Tool löst alle include: rekursiv auf und zeigt die echte Gesamtzahl samt Baum, welcher Dienst wie viele Lookups verbraucht. Steht dort „Within the limits of RFC 7208.", passt der Record.
  6. Kopier den Record mit Copy, trag ihn laut DNS Entry-Karte als TXT-Record (@, TTL 3600) bei deinem DNS-Provider ein.
  7. Nach der Propagation klickst du Verify DNS: Das Tool springt in den DNS-Tab mit Typ TXT, du gibst deine Domain ein und siehst den veröffentlichten Record zur Kontrolle.

Beispiel 8: Einen bestehenden SPF-Record laden und rekursiv prüfen

Du übernimmst eine Domain, deren SPF-Record über Jahre gewachsen ist, und Mails landen sporadisch im Spam.

  1. Im SPF-Tab trägst du oben unter Domain example.com ein und klickst Load.
  2. Das Tool lädt den veröffentlichten Record und verteilt ihn aufs Formular: IP-Adressen in die IP-Zeilen, bekannte Provider als aktive Presets, fremde include: als eigene Zeilen, Unbekanntes unter Custom mechanisms.
  3. Darunter erscheint die Analyse. Das Badge zeigt die Gesamtzahl aller DNS-Lookups über alle verschachtelten include: — etwa „12/10 DNS lookups" in Rot. Die Fehlerliste nennt den Grund: zu viele Lookups, ein include: ohne SPF-Record oder mehr als ein SPF-Record. Empfänger werten all das als permerror und ignorieren den Record.
  4. Im Baum darunter siehst du, welcher eingebundene Dienst wie viele Lookups verbraucht. Entferne im Formular, was nicht mehr sendet, oder ersetze feste Server durch ip4:-Einträge, die keinen Lookup kosten.
  5. Klick auf Count all lookups (incl. nested includes), um die bereinigte Fassung erneut zu zählen, und übernimm sie per Copy in dein DNS.

Denselben Weg gehst du aus dem DNS-Tab: Nach Check All steht in der Mail-Übersicht neben dem SPF-Record der Button Count lookups, der genau diese Analyse im SPF-Tab startet.

Beispiel 9: Ein kaputtes Zertifikat untersuchen und im PKI Viewer öffnen

Eine Seite meldet im Browser einen Zertifikatsfehler, und du willst wissen, was genau nicht stimmt.

  1. Im SSL / Security-Tab die Domain eintragen und Check SSL klicken.
  2. Oben erscheint ein roter Alert SSL/TLS Error mit der Ursache, etwa „Certificate expired" oder „Self-signed certificate", samt cURL-Fehlercode.
  3. Die Karten darunter sind trotzdem gefüllt: Das Tool hat das Zertifikat über einen zweiten Handshake ohne Prüfung gelesen. In der Certificate-Karte steht unter Trust „Not trusted: …", die Befunde nennen das Problem im Klartext — zum Beispiel „The certificate expired 3 days ago."
  4. In der Certificate Chain prüfst du jedes Glied: Ein rotes „signature does not match" zeigt eine falsch zusammengesetzte Kette, die Rolle „Root CA (self-signed)" direkt hinter dem Server-Zertifikat deutet auf eine eigene, private CA hin.
  5. Für die Detailanalyse klickst du im Kopf der Kette auf PKI Viewer: Der PKI Viewer öffnet sich in einem neuen Tab und zeigt jedes Zertifikat der Kette mit allen Feldern im Detail. Alternativ speicherst du sie mit Chain (PEM) als Datei für den Support-Fall.

Noch tiefer: die Übersicht zum großen Bild, das Manual für jeden Tab und alle Grenzen, die Tipps & Tricks für Interpretation und Kombination. Ausprobieren kannst du alles direkt im Tool.