JPKCom DB

DNS, SSL, Redirect & URL — Anwendungsbeispiele

Praxisnahe Durchläufe: DNS prüfen, ein Zertifikat kontrollieren, eine Redirect-Kette lesen, eine URL zerlegen und einen SPF-Record bauen.

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 — www (A), DMARC (TXT), DKIM (TXT) und Wildcard (A).
  3. Lies die Mail-relevanten Abschnitte zuerst. Steht unter MX ein sinnvoller Mailserver? Taucht DMARC (TXT) auf? Fehlt der DMARC-Abschnitt ganz, hat die Domain keinen DMARC-Record — ein häufiger Mangel.
  4. Achte auf Wildcard (A). Erscheint dieser Abschnitt, löst jede beliebige Subdomain auf — das ist manchmal gewollt, oft aber ein Konfigurationsfehler.
  5. 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.
  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 Zeile Verification: Steht dort OK, ist die Kette sauber. Ein roter Text wie „Self-signed certificate", „Unable to get local issuer certificate" oder „Hostname mismatch" benennt das konkrete Problem.
  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, ob Server-, Intermediate- und Root-Zertifikat vollständig ausgeliefert werden. Eine unvollständige Kette ist eine häufige, leicht übersehene Fehlerquelle.

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).
  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.

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.

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.
  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 (x/10) und Length. Bleibst du unter 10 Lookups und unter 450 Zeichen, ist alles grün. Wird der Lookup-Zähler gelb (ab 8) oder rot (über 10), hast du zu viele include:/a/mx-Mechanismen — fass sie zusammen.
  5. Kopier den Record mit Copy, trag ihn laut DNS-Entry-Karte als TXT-Record (@, TTL 3600) bei deinem DNS-Provider ein.
  6. 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.

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.