binsec.fail
Documented broken configurations for testing security checkers
This domain serves deliberately wrong configurations used to test security checkers. The sections below describe each published configuration, the records or endpoints involved and the behaviour a correct checker must show.
DNS 12 cases
Deliberately unusual DNS records used to exercise SPF, DMARC, MX and delegation handling of our own checkers. Each hostname below has one specific flaw or edge case.
Hostname: binsec.fail
binsec.fail. 86400 IN TXT "v=spf1 -all"
What it tests
The apex publishes a minimal SPF record with a single "all" mechanism and a fail qualifier. No host is authorised to send mail for the domain.
Expected behaviour
A valid, complete SPF record: any HELO or MAIL-FROM check against binsec.fail must result in "fail". A checker must not report warnings about missing mechanisms here.
References: RFC 7208, section 5.1
Hostname: invalid.spf.binsec.fail
invalid.spf.binsec.fail. 86400 IN TXT "v=spf1 a:%{x} -all"
What it tests
The record uses the macro %{x}, which is not defined by RFC 7208. A macro expansion in the record must therefore fail.
Expected behaviour
The parser must detect the invalid macro and treat the whole record as invalid (SPF PermError). It must not attempt a literal DNS lookup for "%{x}".
References: RFC 7208, section 7
Hostname: macro.spf.binsec.fail
macro.spf.binsec.fail. 86400 IN TXT "v=spf1 a:%{d} -all"
What it tests
The record uses the valid macro %{d}, which expands to the checked domain before the mechanism is evaluated.
Expected behaviour
The checker must expand the macro before evaluation and then look up the expanded name. macro.spf.binsec.fail has no address records, so the "a" mechanism must not match and the result must be "fail" via the trailing "-all". Checkers without macro support must at least not crash on the record.
References: RFC 7208, section 7
Hostname: loop.spf.binsec.fail
loop.spf.binsec.fail. 86400 IN TXT "v=spf1 include:loop.spf.binsec.fail -all"
What it tests
The record includes itself via the include mechanism, producing a circular reference.
Expected behaviour
A circular include must be detected (visited set or recursion limit) and reported as a permanent error. The checker must not recurse until it hangs or exhausts its query budget silently.
References: RFC 7208, section 5.2
Hostname: mx.spf.binsec.fail
mx.spf.binsec.fail. 86400 IN TXT "v=spf1 mx:manymx.binsec.fail"
What it tests
The record uses "mx:" with an explicit domain pointing at the eleven-Mail-Exchange host manymx and omits a trailing "all" mechanism.
Expected behaviour
The mx mechanism must expand to A/AAAA lookups of all eleven MX targets of manymx.binsec.fail. Because the record has no "all" mechanism, a non-matching sender must evaluate to neutral, not to "fail".
References: RFC 7208, sections 5.4 and 5.1
Hostname: noversion.spf.binsec.fail
noversion.spf.binsec.fail. 86400 IN TXT "-all"
What it tests
The TXT record contains only "-all" without the required "v=spf1 " prefix, so it is not an SPF record at all.
Expected behaviour
Only TXT records starting with "v=spf1" are SPF records. The record must be ignored and the domain must evaluate as having no SPF record ("none").
References: RFC 7208, section 3
Hostname: _dmarc.binsec.fail
_dmarc.binsec.fail. 86400 IN TXT "v=DMARC1; p=reject"
What it tests
A DMARC record carrying only the mandatory tags v and p.
Expected behaviour
The record is valid with policy p=reject and the RFC defaults applied (pct=100, no aggregate or forensic reporting, subdomain policy follows p).
References: RFC 7489, section 6.3
Hostname: _dmarc.noversion.dmarc.binsec.fail
_dmarc.noversion.dmarc.binsec.fail. 86400 IN TXT "p=reject"
What it tests
The record at the DMARC location carries a policy but is missing the mandatory v=DMARC1 tag.
Expected behaviour
A DMARC record without a valid v tag must be ignored entirely, so noversion.dmarc.binsec.fail has no DMARC policy.
References: RFC 7489, section 6.3
Hostname: _dmarc.spf-in-dmarc.dmarc.binsec.fail
_dmarc.spf-in-dmarc.dmarc.binsec.fail. 86400 IN TXT "v=spf1 -all"
What it tests
The TXT record below _dmarc is a syntactically correct SPF record placed at the DMARC position.
Expected behaviour
The record is not DMARC and must be ignored; a checker must not parse every TXT record at _dmarc as a DMARC policy.
References: RFC 7489, section 6.4
Hostname: manymx.binsec.fail
manymx.binsec.fail. 86400 IN MX 10 l<N>.manymx.binsec.fail. (l1 .. l11) l<N>.manymx.binsec.fail. 86400 IN AAAA ::1 (l1 .. l11)
What it tests
The host carries eleven MX records, all with preference 10, and the eleven targets only have AAAA records pointing at ::1.
Expected behaviour
Equal-preference MX records allow the sender to pick any target. A checker must cope with more than ten MX records and must resolve the targets over AAAA only, since the targets have no A records.
References: RFC 5321, section 5.1
Hostname: dns.binsec.fail
dns.binsec.fail. 86400 IN NS ns.binsec.fail. dns.binsec.fail. 86400 IN TXT "DNS test domain" web.dns.binsec.fail. 86400 IN AAAA 2a07:a1c1:1:1:53:fa11:a:1 backdoor.dns.binsec.fail. 86400 IN A 127.0.0.1 backdoor.dns.binsec.fail. 86400 IN AAAA ::1
What it tests
A subdomain delegated to ns.binsec.fail with its own zone: an SOA, a descriptive TXT, web as AAAA and backdoor as A 127.0.0.1 / AAAA ::1.
Expected behaviour
Exercises resolution across the referral and zone transfer (AXFR) against our own authoritative server. The backdoor name answers with loopback addresses, which is a good place to verify that a checker does not silently drop loopback targets.
References: RFC 1034, section 4.3.2
Hostname: _acme-challenge.test.binsec.fail
_acme-challenge.test.binsec.fail. 86400 IN CNAME test.binsec.fail.validation.binsec.services.
What it tests
The ACME challenge name is a CNAME to the validation domain of an external ACME service.
Expected behaviour
A CA following the CNAME authorisation method must chase the CNAME and request the TXT record at the target domain instead of demanding the TXT at the challenge name itself.
References: RFC 8555, section 8.4
DNSSEC 5 cases
A signed zone tree under dns.binsec.fail with deliberately broken signatures. The test zones are signed offline with static RRSIG validity windows, so every verdict below stays reproducible without key maintenance; the expired-signature case is the one exception where the window has intentionally lapsed. The binsec.fail apex itself is live-signed and re-signs on its own. Each case names the exact query type a validating checker must evaluate.
Hostname: binsec.fail
binsec.fail. 86400 IN DNSKEY 257 3 13 Ushn02xBklaNrJcvLw7o4GZJ4dTX/VrSygCJ3gz1iVl59S4yC4i8hXbz REEn4uxNHcEOjlsm4Wjf6AVrssm9lA== ; parent-side DS at the registry: binsec.fail. 3600 IN DS 23892 13 2 2E56B017AE6B85DCCF9DD03F26F10000B45ECA1D830F1AE7FA99ACA1 283D224F
What it tests
The apex zone is live-signed with a single ECDSAP256SHA256 zone-signing key (algorithm 13, key tag 23892) and uses NSEC for authenticated denial. The .fail registry publishes the DS record for the zone; the parent zones publish signed DS records for every signed test zone below dns.binsec.fail.
Expected behaviour
Every record type at binsec.fail must validate as SECURE over a complete chain: root, .fail TLD, binsec.fail. The checker must match the registry DS (key tag 23892, algorithm 13, SHA-256 digest 2E56...283D224F) against the published DNSKEY and must report no findings on the NSEC, TTLs or signature lifetimes used here.
References: RFC 4034, section 5, RFC 5155, section 7
Hostname: missing.dnssec.dns.binsec.fail
missing.dnssec.dns.binsec.fail. 3600 IN TXT "RRSIG stripped -> BOGUS" ; no RRSIG below this RRset, by design
What it tests
The zone dnssec.dns.binsec.fail is fully signed and secured by a DS record at its parent, but the TXT RRset of this name was stripped of its RRSIG before deployment and is served unsigned.
Expected behaviour
A secured zone must sign every RRset. The validator must report BOGUS for the name because the positive answer carries no signature; it must not downgrade the answer to INSECURE just because the RRSIG is absent.
References: RFC 4035, section 2.2
Hostname: unknown-algo.dnssec.dns.binsec.fail
unknown-algo.dnssec.dns.binsec.fail. 3600 IN TXT "unknown algorithm -> BOGUS" unknown-algo.dnssec.dns.binsec.fail. 3600 IN RRSIG TXT 254 5 3600 20370101000000 20200101000000 30256 dnssec.dns.binsec.fail. B148GfpsKzOQ/d6iwSi7L2is+xR/7mGcb9I0NHBsWis5mBJpJ9X/hO7TwOf0dDi1kDeREX7emrDnl26bO2hkUsWc6HB6B0jxAorpcXdXDqitOo6lW/008OzwZfehDOcgiwxAiDjGnKbk063khvSuHkVn7Fcjcqb3D9DYSGOvb/Y=
What it tests
The only RRSIG below this name declares algorithm number 254, which IANA has not assigned; the rest of the zone is signed with algorithm 8. The verifier therefore has no usable signature.
Expected behaviour
An RRSIG with an unsupported algorithm must count as no valid signature: the name must evaluate to BOGUS. A checker must not skip the unsigned-looking RRset as if the zone were unsigned, and must not crash on the unknown algorithm field.
References: RFC 4035, section 3.1
Hostname: expired.dnssec.dns.binsec.fail
expired.dnssec.dns.binsec.fail. 3600 IN SOA ns.binsec.fail. noc.binsec.systems. 2026102001 28800 7200 864000 300 expired.dnssec.dns.binsec.fail. 3600 IN RRSIG SOA 8 5 3600 20260201000000 20250101000000 8073 expired.dnssec.dns.binsec.fail. YVSt6HLjIBh1e6NpR6pM19jsdmWu8MS1ib1vuPNo4W/MyFa28OgbMGku0yeGcm+ok3JkpzRIAj0Z49re3ySfOI1AXfMB9g8Ala80Q0gi7LU/V073O+9SksKVryJSOb5WBHHtrXW8r7ozsw2j0kwkdZ1l8pw55UJMhOtqdr0BBHs=
What it tests
The zone is signed and secured by a DS at its parent, but every RRSIG uses a static validity window that ended in the past (its Signature Expiration field is in the past, see the record listing of this case).
Expected behaviour
The checker must report BOGUS with an expired-signature reason for any RRset in the zone. Because a secure delegation with a matching DS exists, falling back to INSECURE or to an unsigned answer is wrong.
References: RFC 4035, section 3.1
Hostname: web.bogus.dnssec.dns.binsec.fail
web.bogus.dnssec.dns.binsec.fail. 3600 IN AAAA ::1 web.bogus.dnssec.dns.binsec.fail. 3600 IN RRSIG AAAA 8 6 3600 20370101000000 20200101000000 23553 bogus.dnssec.dns.binsec.fail. A0TT9cX4IWeatIvG80WZ9Vh8yH+qhWG1bYLg3frS6Mg1PsY6wvI8UE+faUHBexlWc2zYZg+xWwDrV1mcFDPJgOr0nxk8xIZh74YWlawVk3S5ciAWxbvmWAjr4+r1Ntcp5wkG6hXnBUt9ekQMCzdlgB5ec2G20YL6V5Nmkes3Y2Y=
What it tests
The apex of bogus.dnssec.dns.binsec.fail validates SECURE and its DNSKEY RRset self-verifies, but one base64 character of the RRSIG below the AAAA record of web was altered after signing, so the cryptographic check of that signature must fail.
Expected behaviour
An AAAA lookup of web.bogus.dnssec.dns.binsec.fail must evaluate to BOGUS on signature verification, while the zone apex itself stays SECURE. A checker that only validates the DS chain and the apex, but not the RRset signatures one level down, misses this case entirely.
References: RFC 4033, section 3.2, RFC 4035, section 3.1
HTTP 12 cases
One virtual host per verdict path of our HTTP header checker below *.http.binsec.fail: a reference profile, isolated header defects from missing HSTS max-age over weakened cross-origin values to deprecated headers, plus parser traps such as duplicated headers and meta-tag fallback. Pure mod_headers configuration, no application behind it.
Hostname: good.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0
What it tests
All ten recommended headers with OWASP-recommended values; the CSP evaluates without findings.
Expected behaviour
The checker must report a clean result: every recommended header present with a recommended value and no findings for the CSP. Any finding on this host is a checker defect.
References: RFC 6797, section 6.1.1, RFC 9116, section 4
Hostname: bare.http.binsec.fail
What it tests
The vhost serves the fixture without a single security header.
Expected behaviour
All ten recommended headers must be reported as missing; the response must still be evaluated, not treated as an error.
References: OWASP Secure Headers Project
Hostname: weak-hsts.http.binsec.fail
Strict-Transport-Security: max-age=600; includeSubDomains Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0
What it tests
Baseline profile except that HSTS carries max-age=600 and no preload flag.
Expected behaviour
The checker must flag the short max-age and the missing preload while leaving the nine untouched headers alone - a finding on any of them means the report is not isolated.
References: RFC 6797, section 6.1.1
Hostname: broken-hsts.http.binsec.fail
Strict-Transport-Security: includeSubDomains Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0
What it tests
Baseline profile except that the HSTS value only carries includeSubDomains.
Expected behaviour
A syntactically valid header with no max-age directive must be reported as an error; the remaining baseline must stay clean.
References: RFC 6797, section 6.1
Hostname: csp-loose.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src *; script-src 'unsafe-inline' 'unsafe-eval' X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0
What it tests
Baseline profile except the CSP is default-src * with script-src 'unsafe-inline' 'unsafe-eval'; form-action and frame-ancestors are not set.
Expected behaviour
The checker must report the wildcard source and both unsafe keywords and flag the missing form-action and frame-ancestors directives; reading the CSP as mere present-or-absent is not enough here.
References: RFC 9116, section 4
Hostname: loose.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: all Referrer-Policy: strict-origin-when-cross-origin Cross-Origin-Resource-Policy: cross-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin-allow-popups Cache-Control: private, max-age=86400
What it tests
X-Frame-Options SAMEORIGIN, X-Permitted-Cross-Domain-Policies all, Referrer-Policy strict-origin-when-cross-origin, CORP cross-origin, COOP same-origin-allow-popups and Cache-Control private with max-age, all where the stricter value is recommended.
Expected behaviour
Every weakened header must be reported at investigation level, not as missing and not as clean: this is the most common profile of real-world sites that did half the work.
References: RFC 7034, section 3, Fetch Standard, referrer policy and cross-origin paragraphs
Hostname: unsafe-co.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: unsafe-url Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: unsafe-none Cross-Origin-Opener-Policy: unsafe-none Cache-Control: no-store, max-age=0
What it tests
COEP and COOP set to unsafe-none and Referrer-Policy unsafe-url against an otherwise recommended baseline.
Expected behaviour
The three unsafe-* opt-outs must be reported as insecure rather than accepted as configured values.
References: Fetch Standard, cross-origin embedder and opener policies
Hostname: unknown-values.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: ALLOW-ALL X-Content-Type-Options: sniff X-Permitted-Cross-Domain-Policies: everything Referrer-Policy: paranoid Cross-Origin-Resource-Policy: same-place Cross-Origin-Embedder-Policy: avoid-corp Cross-Origin-Opener-Policy: close-all Cache-Control: no-store, max-age=0
What it tests
Each of seven headers carries a plausible but non-existent token such as X-Frame-Options ALLOW-ALL or Referrer-Policy paranoid.
Expected behaviour
All seven must be reported as errors with unknown value; silently treating an unparseable value as satisfied is a checker defect.
References: RFC 7034, section 3, RFC 9116, section 4
Hostname: cache-conflict.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, no-cache, max-age=0
What it tests
Cache-Control mixes no-store, no-cache and max-age=0.
Expected behaviour
The checker must resolve the contradiction the way the fetch cache does: no-store wins, no-cache is reported as ignored rather than as an independent finding.
References: RFC 9111, section 5.2
Hostname: deprecated.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0 X-XSS-Protection: 1; mode=block Expect-CT: max-age=0 Public-Key-Pins: max-age=1234; pin-sha256=Zm9vYmFy Feature-Policy: geolocation 'none' Pragma: no-cache
What it tests
X-XSS-Protection, Expect-CT, Public-Key-Pins, Feature-Policy and Pragma on top of the recommended baseline.
Expected behaviour
All five must be flagged as deprecated while the ten recommended headers stay clean; the deprecated values themselves must not parse into additional error findings.
References: OWASP Secure Headers Project
Hostname: duplicate.http.binsec.fail
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Strict-Transport-Security: max-age=86400 Content-Security-Policy: default-src 'self'; form-action 'none'; frame-ancestors 'none'; base-uri 'self'; upgrade-insecure-requests; require-trusted-types-for 'script'; report-uri https://reports.http.binsec.fail/csp Content-Security-Policy: default-src 'unsafe-inline' X-Frame-Options: DENY X-Content-Type-Options: nosniff X-Permitted-Cross-Domain-Policies: none Referrer-Policy: no-referrer Cross-Origin-Resource-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin Cache-Control: no-store, max-age=0
What it tests
HSTS and CSP each appear as two response header lines, the baseline value first; clients merge them comma-separated.
Expected behaviour
The checker must report both headers as sent multiple times, use the first value for evaluation and must not misread the merged value as one malformed header.
References: RFC 9110, section 5.5
Hostname: meta-only.http.binsec.fail
What it tests
The page carries all ten values as http-equiv meta tags plus a named referrer tag, and the server sends none of them as headers.
Expected behaviour
Meta tags must not satisfy the recommended-header checks: all ten must be reported missing, and the meta variants reported as having no effect over HTTP; for CSP the frame-ancestors, sandbox and reporting directives are the unavailable subset.
References: RFC 9116, section 3.4
DKIM 8 cases
Selector TXT records below dkim.dns.binsec.fail covering the classic parser states: a valid key, a positive control split over several character strings, and failure modes from broken base64 over missing or revoked keys to an unusable version tag, an unknown key type and a trap hidden in a second TXT record. The zone itself is unsigned; DKIM carries its own authentication in message signatures.
Hostname: valid._domainkey.dkim.dns.binsec.fail
valid._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDxPfsFZxOkHy1zuLvKDtFHJLiD+FexGMECj55mJIDS5tyL8ylYW7nLzljp0r6UrOwwTAyusnG7XXZgGbvAF7ecWwqK7FHkT7jYQ3oTW5ydbqUFfc3LaAJWjCEAleAKjRAJbYWsoAkP5doIlbbliMHgGc8VBzJCBylpyreZo4wrGQIDAQAB"
What it tests
Positive control: a complete DKIM1 record with an RSA key (1024-bit) as a single character string.
Expected behaviour
The checker must parse the record, base64-decode the public key and report a usable key with no findings. A checker that flags the short key length may report it as a note, not an error.
References: RFC 6376, section 3.6.1
Hostname: b64._domainkey.dkim.dns.binsec.fail
b64._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa; p=0i@not-base64!0i=="
What it tests
The p tag carries "0i@not-base64!0i==", which contains characters the base64 alphabet does not define.
Expected behaviour
Decoding must fail and the checker must report a malformed key for this selector. It must not report "no DKIM record" and must not silently drop the invalid characters to force a decode.
References: RFC 6376, section 3.6.1
Hostname: nop._domainkey.dkim.dns.binsec.fail
nop._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa;"
What it tests
The record declares version and key type but carries no p tag at all.
Expected behaviour
Per RFC 6376 a selector record with no p tag means there is no key: verification must treat the selector as having no usable key, which is distinct from a parse error: the record is syntactically fine but carries no key data.
References: RFC 6376, section 3.6.1
Hostname: revoked._domainkey.dkim.dns.binsec.fail
revoked._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa; p="
What it tests
The p tag is present but empty, the RFC-defined way to revoke a key while keeping the selector in DNS.
Expected behaviour
The checker must distinguish "revoked" from "no record": an empty p means key material existed and was withdrawn, so signatures from this selector must stop verifying without the record itself being invalid.
References: RFC 6376, section 3.6.1
Hostname: version._domainkey.dkim.dns.binsec.fail
version._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM2; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDxPfsFZxOkHy1zuLvKDtFHJLiD+FexGMECj55mJIDS5tyL8ylYW7nLzljp0r6UrOwwTAyusnG7XXZgGbvAF7ecWwqK7FHkT7jYQ3oTW5ydbqUFfc3LaAJWjCEAleAKjRAJbYWsoAkP5doIlbbliMHgGc8VBzJCBylpyreZo4wrGQIDAQAB"
What it tests
The record carries v=DKIM2; the rest of the record is a perfectly valid RSA key.
Expected behaviour
A record whose v tag is present and not DKIM1 must not be used at all. The selector counts as having no usable key even though the p payload itself decodes fine.
References: RFC 6376, section 3.6.1
Hostname: algo._domainkey.dkim.dns.binsec.fail
algo._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=foo; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDxPfsFZxOkHy1zuLvKDtFHJLiD+FexGMECj55mJIDS5tyL8ylYW7nLzljp0r6UrOwwTAyusnG7XXZgGbvAF7ecWwqK7FHkT7jYQ3oTW5ydbqUFfc3LaAJWjCEAleAKjRAJbYWsoAkP5doIlbbliMHgGc8VBzJCBylpyreZo4wrGQIDAQAB"
What it tests
The record declares k=foo with an otherwise valid RSA key blob.
Expected behaviour
An unsupported key type must be reported as such. The checker must not fall back to treating the blob as RSA just because it parses as one.
References: RFC 6376, section 3.6.1
Hostname: split._domainkey.dkim.dns.binsec.fail
split._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa;" " p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNxMn8w0I4iForBb21ZOXWX1u9LtrpKM9UpSBwGvYHgWM3A60kLNVwmki+bFEzfvMKcDSymUhIVqTkB30nKi8LzOol9VOtxvkLyKwt5uyQAX6jerqL122dlHC8DCqoR1WF7rOVftd+l5NUoyAPGBLPTdO4/h" " k/rpixzeWOPfJEFF20M/NM4Yn0VMPh1wk0pzkKotxJtDXlDIsUsH3vpZvI+Fddy6i/keaWt2ceyhcP67ykdx+EElJcQ27El0a656vV8GEyh2caoNIFUfpVdfqUiehbsjmP3w9znk+iXjqvyG3jq/ZLFrEI7SmWYImKQB+6xB1RtThlXwUSGfOj1wgQIDAQAB"
What it tests
A single TXT record carries the key as three character strings, each below the 255-octet string limit, because the base64 blob is too long for one string.
Expected behaviour
The checker must concatenate the character strings in wire order before decoding; the result must parse and decode as a valid 2048-bit RSA key. Truncating at the first string or reordering strings breaks this case.
References: RFC 6376, section 3.6.2.2
Hostname: two._domainkey.dkim.dns.binsec.fail
two._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDxPfsFZxOkHy1zuLvKDtFHJLiD+FexGMECj55mJIDS5tyL8ylYW7nLzljp0r6UrOwwTAyusnG7XXZgGbvAF7ecWwqK7FHkT7jYQ3oTW5ydbqUFfc3LaAJWjCEAleAKjRAJbYWsoAkP5doIlbbliMHgGc8VBzJCBylpyreZo4wrGQIDAQAB" two._domainkey.dkim.dns.binsec.fail. 3600 IN TXT "trailing-garbage"
What it tests
Two separate TXT records sit below the selector: a complete valid record and one carrying only "trailing-garbage". Concatenated across all records the key becomes ...IDAQABtrailing-garbage.
Expected behaviour
Concatenated across the RRset the key becomes ...IDAQABtrailing-garbage and must not decode. Note that RFC 6376 leaves multiple TXT records for one selector undefined, so an RFC-true checker may report an invalid key or an ambiguous record set - what it must not do is report a usable key by reading only the first TXT record.
References: RFC 6376, section 3.6.2.2
+49 698700111-0