# DNS, SSL, Redirect & URL — Tipps & Tricks > Kniffe für DNS, SSL, Redirect & URL: Ergebnisse richtig deuten, typische Stolperfallen, Privacy-Implikation und Kombination mit anderen JPKCom-Tools. Source: https://www.jpkc.com/db/tools/dns-ssl-redirect-url/tips/ Zurück zur Übersicht: [DNS, SSL, Redirect & URL](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/) · Tool live öffnen: [www.jpkc.com/tools/dns-ssl-redirect-url/](https://www.jpkc.com/tools/dns-ssl-redirect-url/) Das [Manual](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/manual/) erklärt jeden Tab, die [Beispiele](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/examples/) 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 `Verification: OK` 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 Browser meckern, obwohl das Zertifikat gültig ist, fehlt meist das Intermediate-Zertifikat. Die **Certificate Chain**-Karte zeigt das sofort: Endet sie nicht bei einer echten Root CA oder fehlt die Zwischenstufe, liefert dein Server die Kette unvollständig aus. - **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. - **`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.** SPF erlaubt hart **maximal 10 DNS-auflösende Mechanismen**. `ip4:`/`ip6:` sind gratis, jedes `include:`, `a`, `mx`, `redirect=` kostet einen Lookup. Der Live-Zähler wird ab 8 gelb, über 10 rot — bleib darunter, 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. Wer Google, Microsoft 365 und drei Newsletter-Dienste gleichzeitig einträgt, ist schnell über dem Limit. Räum aus, was nicht mehr sendet. - **`~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; nutze eine öffentliche Staging-Domain oder den Expert-Modus mit lokalem Proxy. - **„Security token expired" heißt: Seite neu laden.** Das Token ist nur in einem 5-Minuten-Fenster gültig. Lag der Tab lange offen, holt das nächste Reload ein frisches Token. - **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. - **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.** Steckt in einer Adresse ein `user:pass@`-Teil, zeigt der Parser das Passwort als `***` — gut für Screenshots, aber merk dir, dass der Wert da war. ## 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. Wer Rohdaten weiterverarbeiten will, nutzt die **Copy/Save-JSON**-Buttons in jedem Tab. ## Mit anderen JPKCom-Tools kombinieren - **Seite ganzheitlich statt punktuell prüfen?** Der **[SEO & GEO Analyzer](https://www.jpkc.com/db/tools/seo/)** 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?** Mit den **[PKI-Tools](https://www.jpkc.com/db/tools/pki/)** erzeugst und inspizierst du Zertifikate, CSRs und Schlüssel — der nächste Schritt, wenn die **Verification**-Zeile rot war. - **IPs aus DNS oder Redirect weiterverfolgen?** Die **[IP-Tools](https://www.jpkc.com/db/tools/ip/)** 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](https://www.jpkc.com/db/tools/mail-header/)** 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](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/) zum großen Bild, das [Manual](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/manual/) für jeden Tab und die [Beispiele](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/examples/) für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/dns-ssl-redirect-url/).