DNS, SSL, Redirect & URL — Manual

Every tab in detail: DNS with mail security, SSL chain, TLS and CAA, redirect chains, URL parser, slug and SPF generators with lookup analysis — plus limits.

Back to the overview: DNS, SSL, Redirect & URL · Open the live tool: www.jpkc.com/tools/dns-ssl-redirect-url/

This manual describes all five tabs in full: what they query, how to read the results, and what technical limits apply. Tab names, buttons, and messages are quoted exactly as they appear in the tool, so you can find them in the real interface.

Architecture and limits up front

Three tabs (DNS, SSL / Security, Redirect) pull data from the network and therefore run through the JPKCom servers. The URL parser, the slug generator, and the SPF generator compute in the browser; only the two SPF functions Load and Count all lookups query the server's DNS endpoint.

  • DNS fetch: a server-side PHP endpoint resolves the records with dns_get_record() and returns them unaltered as JSON. Special characters are only escaped when the browser displays them — so the JSON view, the zone file, and the downloads contain the original values, such as an & in a TXT record.
  • SSL fetch: the proxy (p.php) opens two connections to the host you entered, each pinned to a pre-checked IP. Both resolve the name separately — with several A records, those can be two different addresses. The first is a normal HTTPS request (GET, headers only) with certificate verification against the server's CA store — it delivers status, headers, timing, and the trust decision (12 s per request, 15 s in total). This request follows up to 5 redirects; if the address redirects, status, headers, timing, and trust refer to the final URL. The second is a bare TLS handshake without verification (8 s connect timeout, with SNI) to the host you entered, capturing the certificate chain exactly as the server sends it — so certificate, chain, TLS version, findings, and CAA always belong to the host you entered. That is how the tool can show expired, self-signed, or otherwise invalid certificates — and why it also accepts old TLS versions and weak keys for this handshake.
  • Redirect fetch: every hop is a separate request with no automatic following: HEAD first, and on status 405 or 501 a GET whose body is discarded after the headers. Each hop gets at most 10 s, the whole chain 24 s; response headers are capped at 64 KB per hop.
  • Authentication: before each server request, the JavaScript obtains a fresh, daily-rotating token via p-api.php (valid within a 5-minute window) that is referer-checked. The keys for it are embedded in the loaded page and change daily at midnight (UTC); if the tab stayed open past that point, the server refuses with "Forbidden", and only a reload fetches new ones. These endpoints are not a public API — they only work from within the tool.
  • SSRF protection: private, loopback, link-local, reserved, and CGNAT addresses (RFC 1918, 127/8, 169.254/16, 100.64/10, IPv6 fc00::/7, fe80::/10, ::1) are blocked — for the DNS reverse lookup, the SSL/redirect fetch, and on every redirect hop again. Only http/https on ports 80, 443, 3000, 5000, 8000, 8008, 8080, and 8443 are allowed. A blocked address is reported in plain language ("This address cannot be checked: …").
  • Limits: at most 10 redirect hops (loops are detected), maximum URL length 3072 characters, domain length 253 characters.
  • Throttle and rate limits: a client-side throttle allows only about 1 server request per second ("Please wait a moment before making another request."). On the server, each IP address may send 120 requests per minute to the proxy and the same to the DNS endpoint; Check All and the SPF functions additionally share a cap of 20 per minute. Exceed a server-side limit and the DNS tab (Lookup and Check All) reports "Rate limited. Please wait …ms."; SSL, Redirect, and the SPF functions report "Too many requests — please wait … s and try again."
  • Privacy: the checked domain sees the JPKCom server, not your IP.

Expert Mode (optional)

The tool supports an optional Expert Mode via a self-hosted local proxy (LocalProxy on http://127.0.0.1:<port>, version v1.1.0 or later required — the tool flags older versions as outdated, with "update required" in the status). When active, SSL and Redirect fetch their data through that local proxy instead of the JPKCom server, and the client-side throttle is lifted for these two tabs. DNS and the SPF functions do not use the local proxy and stay throttled. The local proxy blocks private, loopback, and link-local targets as well — it does not let you check intranet hosts either.

In Expert Mode the SSL tab shows a reduced scope: certificate data, SANs, the chain as a plain list of names, ten security headers (adding Cross-Origin-Embedder-Policy), the server headers Server, X-Powered-By, and Via, the raw headers, and the timing. An extra HTTP/3 row tells you whether the target advertises HTTP/3 via Alt-Svc ("Advertised" or "Not advertised"). Missing are the TLS version, serial number, fingerprint, host name check, findings, the chain's signature check, the Chain (PEM) and PKI Viewer buttons, and the CAA card. Two differences weigh more: the local proxy verifies the certificate itself, so expired, self-signed, or otherwise invalid certificates only lead to the message "Inspect failed: …" instead of the cards — inspect broken certificates in Standard Mode. And the Trust row always says "Trusted (verified against the CA store)" in Expert Mode; there it carries no information.

In Expert Mode the Redirect tab follows up to 11 stops, without the 24 s overall budget, without the GET fallback (no GET badge), and without the notes "Stopped after 10 hops …" and "Blocked redirect target" — a blocked address or any other failure shows up there as "Inspect failed: …". Loop detection stays active. The limits in the Redirect section and in the operating limits apply to Standard Mode. Setup is advanced and not needed for normal use.

DNS — query DNS records

In the DNS tab you enter a domain (e.g. example.com) or an IP address and pick the record type on the right. Lookup (or Enter) queries exactly that type; Check All queries the most important types at once. The tool strips protocol, path, and port from the input, so you can paste a complete URL.

Single lookup

The dropdown offers A, AAAA, MX, NS, TXT, CNAME, SOA, SRV, CAA, PTR, NAPTR. ANY is no longer on offer: most resolvers refuse such queries or answer them minimally (RFC 8482) — Check All is the replacement. The result contains the records found with all their fields (e.g. pri and target for MX; mname, rname, serial, refresh, retry, expire, minimum-ttl for SOA), the number of hits, and a timestamp.

Empty results and NXDOMAIN

When a query finds nothing, the tool distinguishes two cases and shows a note above the result: "The name exists, but has no … records." or "The name does not exist (NXDOMAIN) — or the resolver did not answer." To tell them apart, it additionally checks the name for A, AAAA, CNAME, MX, TXT, and NS records. If Check All returns no section at all, you see a note of its own — without that extra name check: "No records found — the name does not exist (NXDOMAIN) or the resolver did not answer."

Check All — comprehensive lookup

Check All queries A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, and CAA in turn and adds seven extra checks. Only sections that found something appear in the result:

  • www (A) — the A record of the www. subdomain.
  • DMARC (TXT) — the TXT record at _dmarc.<domain>.
  • DKIM (TXT) — records at <selector>._domainkey.<domain> for 21 common selectors: default, google, selector1, selector2, k1, k2, k3, s1, s2, dkim, mail, mandrill, smtp, zmail, protonmail, protonmail2, fm1, fm2, mailjet, brevo, key1. Only TXT records that start with v=DKIM or contain a key (p=) count; each hit carries its selector in the selector field. The list of selectors checked is in the JSON under dkimSelectorsChecked.
  • MTA-STS (TXT) — the record at _mta-sts.<domain>.
  • TLS-RPT (TXT) — the record at _smtp._tls.<domain>.
  • BIMI (TXT) — the record at default._bimi.<domain>.
  • Wildcard (A) — checks whether a random subdomain resolves; if so, the entry is shown as *.<domain> (a hint at a wildcard DNS record).

For IP addresses, Check All is disabled (record types apply to domains only).

Mail & domain security

After Check All, a "Mail & domain security" card above the JSON sums up the mail- and certificate-related entries, each with a badge and the raw value:

  • SPF — "present", "missing", or "N records — invalid" (more than one SPF record is an error). The Count lookups button switches to the SPF tab, fills in the domain, and loads the record there including the recursive lookup count.
  • DMARC — green for p=reject or p=quarantine, yellow for p=none ("monitoring only") or a missing record.
  • DKIM — "N found" with the selectors found, or "not found" with a note that none of the 21 selectors checked matched and a custom selector is possible.
  • MX — the number of mail servers with their priority, "none", or "null MX" (a single MX entry .: the domain receives no mail, RFC 7505).
  • MTA-STS, TLS-RPT, BIMI — "present" with the record, or "not set" with a one-line explanation (enforcing TLS for incoming mail, reports on TLS delivery problems, brand logo in mail clients).
  • CAA — the CAA records, or "not set" (then every CA may issue certificates).

Reverse lookup (PTR) and IDN

Enter an IP address in the domain field and the tool automatically switches the record type to PTR, disables Check All, and builds the reverse address (…in-addr.arpa for IPv4, …ip6.arpa for IPv6). Reverse lookups work only for publicly routable IPs — private, loopback, and reserved ranges are rejected. Internationalized domains (umlauts and the like) are converted to Punycode before the query; the result shows both the Unicode and the Punycode form (idnDomain, punycode).

Output: JSON or zone view

By default the result appears as JSON in a read-only CodeMirror editor. Zone switches to a BIND-style zone file: header comments (domain, IDN form if any, query type, time) and aligned columns for name, TTL, class, type, and data. TXT values appear there as a sequence of quoted strings of at most 255 characters each, with quotes and backslashes escaped; the CAA value is quoted too. The zone view is editable before you copy it.

The buttons: Copy copies whatever is currently visible (JSON or zone), JSON saves the result as dns-<domain>.json, Zone toggles the view. In the zone view, Copy Zone and Save Zone (<domain>.zone.txt) are added.

SSL / Security — certificate and headers

In the SSL / Security tab you enter a domain (https:// is prepended) and click Check SSL or press Enter. If you enter an http:// address, the server checks the https:// variant instead. The server fetches the page and returns the raw data; the tool builds several cards from it. Thanks to the extra handshake without verification, certificate and chain appear even when the normal connection fails on the certificate (in Standard Mode, see Expert Mode).

If the address redirects (say example.com → www.example.com), the result mixes two hosts: HTTP status, IP address and protocol (Connection card), security headers, server, raw headers, timing, and trust come from the redirect target, while certificate, SANs, chain, findings, and CAA come from the host you entered. To see the headers of a specific address, enter the final address.

Error messages

If the verifying HTTPS request fails, an alert appears at the top — SSL/TLS Error (red) or Connection Error (yellow) — with a cause, the cURL error code, and the original message. The tool derives the cause from cURL's message: "Certificate expired", "Certificate not yet valid", "Untrusted root certificate in the chain", "Self-signed certificate", "Host name does not match the certificate", "Incomplete chain or unknown issuer", "Certificate revoked", "TLS protocol not supported", or generally "TLS/SSL error". The cards below still appear as long as the second handshake delivered a certificate. If that fails too, the tool reports "No TLS handshake possible: …".

Connection and Certificate

  • Connection — URL, the final URL after any redirect, IP address, HTTP status code, HTTP version (HTTP/1.0, /1.1, /2, or /3), and TLS with protocol version and cipher. The TLS version is the one negotiated in the handshake, i.e. the highest both sides support. TLS 1.0, TLS 1.1, and SSL are flagged red as "outdated" — then the server offers nothing newer. Whether a server allows older versions in addition to TLS 1.2 or 1.3 is not something this row shows.
  • Certificate — common name, organization (if present), issuer (with organization if present), Valid From and Valid Until with days remaining (green, yellow at ≤ 30 days, red with "expired … days ago" once expired), Signature (signature algorithm), Public Key (e.g. "RSA 2048 bit", "EC P-256 (256 bit)", or "Ed25519"), Serial Number, SHA-256 fingerprint, Host Name ("covered by the certificate" or "not covered by the certificate", checked against the SANs with a wildcard only in the leftmost label, otherwise the CN), and Trust: "Trusted (verified against the CA store)", "Not trusted: …" with the cause, or "Unknown — the HTTP connection failed" when no HTTP response came back at all. The icon in the card header mirrors this trust status. The SHA-1 fingerprint is only in the JSON export.
  • Findings — below the table, the tool lists concrete problems as errors or warnings: expired (N days ago), not yet valid, expiring within 14 days, host name not covered, self-signed, weak signature algorithm (MD5, SHA-1), RSA key under 2048 bits, missing intermediate certificate, and a broken chain or wrong order.

Subject Alternative Names and Certificate Chain

  • Subject Alternative Names — all DNS names and IP SANs stored in the certificate; the count is in the card header.
  • Certificate Chain (as sent by the server) — the chain exactly as the server delivers it. For each certificate you see the subject, a role, and a signature badge, then issuer, key, signature algorithm, expiry date with days remaining, and the SHA-256 fingerprint. The roles: Server certificate, Intermediate CA, Cross-signed root (acts as intermediate) (a CA with "Root" in its name that is not self-signed but cross-signed by an older root), Root CA (self-signed) (only with a valid self-signature), and Certificate. The signature badge checks whether each certificate really is signed by the next one in the chain: "signature ok", "signature does not match", or "issuer not sent" (the issuer is missing from the chain as sent — normal for the last link, because servers usually do not send the root).
  • Chain (PEM) saves the complete chain as <host>-chain.pem; PKI Viewer opens the PKI Viewer in a new tab and loads the chain straight into its "PEM Decoder" tab. The handover goes through your browser's local storage, and the PKI Viewer deletes it immediately after reading.

CAA

The CAA card looks up the CAA records of the host — or of the nearest parent name that has any (RFC 8659) — and compares them with the certificate's issuer. For a wildcard certificate issuewild counts, falling back to issue if there is none. The tool maps the issuer to a CAA identifier via the names of well-known CAs (e.g. Let's Encrypt, Google Trust Services, DigiCert, Sectigo, GlobalSign, Amazon). Possible badges: CA allowed, CA not listed (the certificate comes from a CA the record does not permit today), not compared (the CA could not be mapped), no CAA (any CA may issue), and not restricted (CAA records exist, but none for the relevant tag). Below are the records found, with the name they are attached to. For bare IP addresses the card is skipped.

Security Headers

Nine headers are checked: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy. A counter badge shows "present/total" (green from 6, yellow from 3, otherwise red). Values longer than 80 characters are truncated; the tooltip shows the full value.

Present headers are validated for content and tagged with an OK, warning, error, or info badge:

  • HSTS: missing max-age (error), max-age under 31536000 seconds (warning), missing includeSubDomains or preload (info).
  • CSP: unsafe-inline and unsafe-eval per directive, plus the absence of both default-src and script-src (warning each).
  • X-Frame-Options: values other than DENY/SAMEORIGIN (error), ALLOW-FROM as deprecated (info).
  • X-Content-Type-Options: anything other than nosniff (error).
  • Referrer-Policy: an unknown value or unsafe-url (warning).
  • Permissions-Policy: a wildcard * (warning).

X-XSS-Protection and the two cross-origin headers are only checked for presence. Missing headers get a short note on what they would protect against. If no HTTP response came back, the card shows "not available" instead of a zero score — the headers are unknown then, not missing.

Timing, Server and Export

  • Timing — DNS Lookup, TCP Connect, SSL Handshake (when measurable), Pretransfer, Start Transfer, and Total.
  • Server — Server, X-Powered-By, Via, X-Cache, Cf-Ray, X-Served-By, and Content-Type headers where present.
  • Raw Headers — the complete raw response headers, collapsible.

Copy JSON / Save JSON (ssl-check-<host>.json) keep the full result, including the chain's PEM data.

Redirect — trace the redirect chain

In the Redirect tab you enter a URL and click Trace Redirects (or press Enter); if the scheme is missing, the tool adds https://. The server follows the chain hop by hop (it does not auto-follow Location, but steps through each one), up to 10 hops. It asks with HEAD first; if the server refuses that with 405 or 501, the tool reads the headers via GET and marks the hop with a GET badge. Per hop you see:

  • the hop number and that stop's URL,
  • the status code (colored by 2xx/3xx/4xx/5xx),
  • an HTTPS or HTTP badge,
  • the IP address of the connection actually used, the timing, and the Server header,
  • for HTTPS hops, the certificate name with days remaining (green above 30, yellow from 1 to 30, red at 0 and below — days are rounded down, so a certificate with less than 24 hours left is red too),
  • the raw headers of that hop including the status line (collapsible),
  • on failure, the error message — for certificate problems with the cause (e.g. "Certificate expired").

Relative Location redirects are resolved to absolute URLs per RFC 3986, including forms like //host/path, ?query, or ../path. If an already visited URL is targeted again, the tool stops with "Redirect loop detected". A hop pointing to a private/internal address is rejected as "Blocked redirect target". Once the 24 s time budget is used up, the chain ends with "Stopped: time budget of 24 s for the whole chain used up". If the tenth hop still redirects, you see "Stopped after 10 hops — the chain continues". The last hop (no longer a 3xx) is marked as the endpoint. Copy JSON / Save JSON (redirect-trace.json) keep the whole chain. These limits apply to Standard Mode; for Expert Mode see Expert Mode (optional).

URL — parser and slug generator

This tab works entirely in the browser, with no server fetch.

URL parser

With Parse URL (or Enter) the tool breaks an address into its parts via the JavaScript URL API: href, protocol, hostname (plus hostname (Unicode) for IDN, converted back from Punycode in the browser), port (or "(default)"), pathname, search, hash, origin, host, username, and password (masked as ***). If a protocol is missing, https:// is added. Below, a Search Parameters table lists all query parameters as key/value pairs.

The Encoding card shows the address twice: Encoded (as sent) is the normalized, percent-encoded form that goes over the wire; Decoded (readable) shows the host in Unicode and decodes each valid escape sequence on its own — a stray % stays put instead of spoiling the rest. A password is masked in both rows. All fields are editable; Copy JSON copies the structure of components and parameters.

URL slug generator

The URL Slug Generator turns arbitrary text into a URL-safe slug live (as you type). It handles German umlauts (ä→ae, ö→oe, ü→ue, ß→ss), decomposes accented characters via Unicode normalization (é→e, ñ→n …), replaces all other special characters with the separator (- or _), collapses repeated separators, and trims them at the edges. A character count sits below; Copy copies the slug.

SPF — build an SPF TXT record

The SPF tab generates a valid v=spf1 record live in the browser. You configure the form on the left, and the record updates instantly on the right. The output box can also be edited directly, but only Copy picks up such edits: the lookup counter, Length, the warnings, the value in the DNS Entry card, and Count all lookups keep working with the record from the form, and every form change overwrites the box.

  • Domain (optional) with a Load button — loads a domain's published record, see Loading and analyzing an SPF record.
  • All Policy (catch-all): -all (Fail, recommended for production), ~all (SoftFail, default, for testing), ?all (Neutral), +all (Pass — explicitly not recommended), or "None" (omit). A hint below the select explains the chosen policy.
  • Own Mail Servers — checkboxes for a (the domain's A record sends mail) and mx (the MX servers send mail; on by default).
  • Mail Providers — 16 one-click presets: Google, Microsoft 365, Amazon SES, SendGrid, Mailchimp, Postmark, Brevo, Mailgun, Zoho, HubSpot, Salesforce, Mailjet, SparkPost, Klaviyo, Fastmail, and Proton Mail. Each preset adds its include: mechanism; a second click removes it again.
  • Add include: and IP Addresses — your own include: lines plus any number of ip4:/ip6: entries, each with an optional prefix length. Invalid addresses are marked red and left out of the record; a warning names them.
  • Advanced — a redirect= (points the policy at another domain; the all-policy is then dropped) and a free Custom mechanisms field for additional, space-separated mechanisms.

The record is assembled in a fixed order: ip4:/ip6: first (no DNS lookup), then a, mx, the provider presets, your own include: lines, custom mechanisms, redirect=, and finally the all-policy.

On the right, a stats row shows two live values: DNS lookups (this record) (x/10, yellow from 8, red above 10) and Length (characters, yellow above 300, red above 450). The counter only rates the record itself: include, a, mx, ptr, exists, and redirect= cost one lookup each, ip4:/ip6: cost none — whatever the included records consume in turn only shows up with Count all lookups. The generator warns at more than 10 DNS lookups, above 450 characters, at +all, at invalid IP addresses, and at the redirect= plus all-policy conflict. If the record is longer than 255 characters, the DNS Entry card adds a Zone file / split row with the value split into several quoted strings; most DNS providers split automatically.

The DNS Entry card summarizes how to publish the record (type TXT, host @, the value, TTL 3600), followed by a short How to deploy guide. Copy copies the record; Verify DNS jumps to the DNS tab and sets the type there to TXT, so you can look up your published record directly — you enter the domain there yourself.

Loading and analyzing an SPF record

Two functions query the server's DNS endpoint and are therefore subject to the throttle and the rate limit:

  • Load reads the SPF record published for the Domain (the TXT record starting with v=spf1) and maps it onto the form: ip4:/ip6: into IP lines, a and mx into the checkboxes, known providers as active presets, other include: as your own lines, redirect= and the all-policy into their fields; everything else lands under Custom mechanisms. The analysis starts at the same time. The rebuilt record follows the generator's fixed order: mechanisms with a qualifier such as -ip4:…, ~a, or -include:… land under custom mechanisms and therefore end up behind a, mx, presets, and include: — since the first match wins in SPF, that can change the result. Invalid ip4:/ip6: values drop out of the record with a warning. So compare the new record with the old one before you publish it.
  • Count all lookups (incl. nested includes) analyzes the record currently generated. As the domain, the tool uses the Domain field, or example.com if it is empty.

The analysis follows every include: and redirect= recursively and shows: the total number of DNS lookups (x/10, badge green, yellow from 8, red above 10), the void lookups (references without records, at most 2 allowed), errors and warnings, and a tree of all included records with the lookups per level. It reports as errors: more than one SPF record, more than 10 lookups, more than 2 void lookups, invalid ip4:/ip6: values, unknown terms, loops or too deep nesting, and include: targets without an SPF record (receivers treat that as permerror). It reports as warnings: ptr (deprecated and slow) and +all/all. Without errors it says "Within the limits of RFC 7208.". References containing macros (%{…}) are not resolved; redirect= is only evaluated when the record has no all.

Limits: at most 40 DNS queries per analysis, 10 levels of nesting; a submitted record may be at most 2048 characters long, must start with v=spf1, and may contain printable ASCII only.

History

The DNS, SSL / Security, Redirect, and URL tabs store their last 20 inputs in your browser's local storage; duplicates are merged. Clicking an entry puts the input back into the field (in the DNS tab also the record type, type A after Check All) — you then start the query yourself with the button. Clear empties the history of that tab. The SPF tab and the slug generator keep no history. The URL history stores the address exactly as you typed it — a password in user:pass@ is kept there in plain text.

Operating limits — at a glance

  • Privacy: fetches run through the JPKCom server; the target does not see your IP.
  • SSRF / private-IP protection: private, local, reserved, and CGNAT addresses are blocked (DNS reverse, SSL, every redirect hop); only http/https on ports 80, 443, 3000, 5000, 8000, 8008, 8080, and 8443.
  • Limits (Standard Mode): max. 10 redirect hops, 10 s per hop and 24 s per chain, SSL fetch 15 s, URL ≤ 3072 characters, domain ≤ 253 characters; SPF analysis max. 40 DNS queries and 10 levels.
  • Throttle: client-side ~1 server request per second (in Expert Mode only for DNS and SPF).
  • Rate limits per IP: 120 requests per minute for the proxy and for the DNS endpoint, Check All and the SPF functions additionally a shared 20 per minute.
  • Token: daily-rotating, 5-minute window, referer-checked — not a public API.
  • Usable without the server: URL parser, slug generator, and SPF generator compute entirely in the browser; only Load and Count all lookups in the SPF tab need the server.

For the big picture and the audiences, see the overview. Concrete workflows are in the examples, tricks in the tips & tricks. You can try everything right in the tool.