Reported issues for dns

Pod holds 23 of 75 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to dns.

Most discussed

M365 identity_secops: bv-mcp-side tracking for live Graph reads (upstream: bv-web-prod#2276, decision: #759)

Follow-up from #403 (M365 proxy repointed at bv-web-prod, shipped in bv-mcp PR #415 + bv-web-prod #467). The repoint cleared the m365_proxy_404 by pointing the 4 identity_secops tools (query_signins, query_ual, get_ca_policies, assess_coverage) at a real bv-web-prod internal route — but that route currently returns a representative: true seam, not live Microsoft Graph data. Three follow-ups:

1. Live Microsoft Graph reads (feature)

bv-web-prod has a real M365 engine (`share

Read the thread · 2026-06-19 · open · 8 comments

v3.58.0 live-verification follow-ups: timeout guidance names the wrong source, Certspotter no longer attempted, BV_CERTSTREAM bound but reports not-consulted

Found by live verification of v3.58.0 immediately after deploy (version f89d6101, 100%). #734's fix verifies correctly; these are defects in #735's messaging that I shipped, plus one observation that needs investigating before anyone trusts the new BV_CERTSTREAM binding.

1. Source-specific measurements are attributed to whichever source timed out

Live output for meta.com and anthropic.com:

crtsh timed out — this is deterministic for this domain, not transient, so an identic

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/738) · 2026-08-20 · closed · 5 comments

### MCP best-practices audit: deferred items + corpus-split finding (follow-up to #362)

Follow-up tracking issue from the MCP best-practices audit. PR #362 shipped Findings 1 (transient-DNS resilience) and 3 (tool descriptions). These remaining items were **deliberately held** — each is a public-contract or product decision, not a mechanical fix — plus one finding discovered while implementing #362.

## 1. Discovered: transient-DNS handling is split across two incompatible shapes
**Severity: low–medium (latent correctness + stale docs).**

During #362 we found `check_*` checks hand

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/363) · 2026-06-04 · closed · 5 comments

### Unprovisioned / tier-denied OSINT + recon tools return `passed: true, score: 100`

An unavailable lane returns a result that reads as a clean pass. A consumer keying on `passed`/`score` — a dashboard, a proposal generator, or an LLM skimming the response — records "no findings" where **no measurement was performed**.

### Observed (hosted deployment, 2026-08-18, v3.52.0)

```json
{"category":"osint_investigation","passed":true,"score":100,
 "findings":[{"category":"osint_investigation","title":"OSINT investigation unavailable",
 "severity":"info","detail":"OSINT domain investi

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/695) · 2026-08-18 · closed · 4 comments

### check_dnssec_chain: false 'unverified root' from cached transient-empty (edge-cache hypothesis refuted)

## Summary

`check_dnssec_chain` reports a false **HIGH "Broken DNSSEC chain at ."** for every correctly-signed domain in **production**, because the root (and TLD) `DNSKEY`/`DS` DoH queries return **empty** in prod — even though the records exist.

Surfaced during the full-tool QA pass. Reproduced on cloudflare.com and ietf.org (both broke at `.`, walk stopped at the TLD).

## Root cause — isolated to the prod edge, NOT the code

A real-network test in the **workerd** runtime (same engine as pr

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/199) · 2026-05-24 · closed · 4 comments

### check_dane_https scores a STALE TLSA pin as 100 — presence is checked, correctness is not

## Summary

`check_dane_https` scores a TLSA record **100 / "Valid TLSA record configured"** without verifying that the pinned hash matches the certificate the host actually serves. A stale DANE-EE pin — which actively breaks every DANE-validating client — is reported as a pass.

Found by scanning our own production domain during a zone audit on 2026-08-30.

## Evidence

`blackveilsecurity.com` published `_443._tcp` TLSA `3 1 1` (DANE-EE / SPKI / SHA-256):

pinned SPKI sha256: b5d294f0346bc

Read the thread · 2026-08-30 · open · 2 comments

check_ssl and check_ptr time out against fastmail.com in a full scan

Found by a live post-deploy accuracy sweep of prod 3.43.0.

Observed

scan_domain(fastmail.com, force_refresh: true):

"checkStatuses": {"ssl": "timeout", "ptr": "timeout", ...},
"inconclusiveCategories": ["ssl", "ptr"],
"categoryScores": {"ssl": null, "ptr": null},
"evidence": {"attempted": 19, "completed": 17, "ratio": 0.894...}

Two of nineteen checks timed out against a major, highly-available mail provider. The same scan completed all other 17 checks normally, and `blackvei

Read the thread · 2026-08-07 · closed · 2 comments

Harden finding-metadata sanitizer: C1 control block + Unicode vectors + dead ANSI ordering (follow-up to #389)

Follow-up from the review of #389 (createFinding metadata chokepoint, shipped in #416 / dns-checks 1.3.17). The chokepoint closes the verbatim-metadata hole; the sanitizer (packages/dns-checks/src/scoring/metadata-sanitize.ts) has known residual gaps — none are regressions (same gaps exist in the detail-channel sanitizeDnsData), but worth closing at the now-authoritative chokepoint.

1. Dead ANSI_ESCAPE ordering (MEDIUM)

CONTROL_BYTES strips \x1B (ESC, in \x0E-\x1F) befor

Read the thread · 2026-06-19 · closed · 2 comments

Most recent

@blackveil/dns-checks version has been frozen at 1.27.0 across three scoring-model bumps — the version no longer identifies the code

packages/dns-checks/package.json and PARITY_CORPUS_VERSION are both 1.27.0, and have been since #794. Since then SCORING_MODEL_VERSION has advanced three times:

Read the thread · 2026-08-30 · open · 0 comments

DMARC check recommends aspf=s unconditionally — the advice breaks mail on any ESP-relayed domain

Summary

check_dmarc emits "Relaxed SPF alignment — Consider aspf=s (strict) for stronger authentication" whenever aspf is relaxed or unset, with no regard for whether the domain's envelope-from (return-path) domain can ever align strictly with its From domain.

For any domain that sends through an ESP — Resend, SendGrid, Mailchimp, Postmark, SES-with-a-subdomain-MAIL-FROM — the return path sits on a subdomain, so aspf=s guarantees SPF alignment failure on 100% of that traff

Read the thread · 2026-08-30 · closed · 0 comments

check_ssl asserts "HSTS properly configured" (score 100, controlPresent:true) on any apex that redirects over HTTPS — the header is never read

Summary

check_ssl emits its affirmative HSTS finding from the absence of findings, not from observing the header. For any apex that answers https:// with a redirect to another HTTPS URL, the HSTS header is never read at all — so the check returns passed: true, score: 100, controlPresent: true and the text "HSTS header is properly configured" for a domain publishing no HSTS header.

This is a false affirmative, the dangerous direction, and it is the same class as #705

Read the thread · 2026-08-29 · closed · 1 comment

check_lookalikes: throttled run publishes a CONTRARY ownership attribution instead of unmeasured (jcpenny.com: third_party at 63/94 unresolved, owned_by_seed at 1/94)

Summary

Under throttling, check_lookalikes publishes a contrary ownership attribution instead of declining to attribute. A run with 63 of 94 candidate lookups unresolved reported jcpenny.com as third_party with the detail "no ownership signal links it to this organisation" — the signals weren't absent, they were unfetched. Near-complete runs of the same scan report owned_by_seed on a full 8/8 nameserver match.

Measurement (2026-08-29, three sequential force_refresh:true

Read the thread · 2026-08-28 · closed · 0 comments

check_lookalikes: registered-but-dark lookalike (NS, no A/MX) is invisible — 'held and dark' collapses into silence (febreeze.com, 3/3 runs)

Summary

A lookalike domain that is registered but deliberately dark (NS present, no A, no MX) is invisible in check_lookalikes output: it passes candidate generation and NS resolution, then the findings gate drops it silently because it has neither A nor MX. "Held and dark" and "unregistered" are opposite custody facts, but the tool's output renders them identically — as silence.

Measurement (2026-08-29)

• febreeze.com (the doubled-e cognitive misspelling of febreze.com) is ge

Read the thread · 2026-08-28 · closed · 0 comments

check_root_server_set: unvalidated probe response can throw an uncaught TypeError (evidence.rootHints read unconditionally)

Found during PR #827's work (root-server-set vacuous-pass fix), out of that PR's scope.

fetchRootServerSetEvidence() (src/lib/authoritative-dns-infra/probe-client.ts) performs no runtime schema validation on the infra-probe response, and rootHintsMatchOfficial() (src/lib/authoritative-dns-infra/analyze-root-server-set.ts) calls evidence.rootHints.length unconditionally. A probe response that omits rootHints entirely therefore throws an uncaught TypeError inside `analyzeRootServerS

Read the thread · 2026-08-28 · closed · 0 comments

check_rbl: dead SORBS zone counted as a deterministic clean verdict — effective coverage is 6 RBLs, not 7

Symptom (validation sweep 2026-08-28/29, google.com and blackveilsecurity.com)

check_rbl claims "All checked IPs for are clean on 7 RBLs." with metadata.zones including "dnsbl.sorbs.net" and "confidence": "deterministic".

Ground truth: the SORBS zone no longer exists

SORBS shut down in mid-2024; the entire domain NXDOMAINs, cross-resolver:

curl dns.google  "2.0.0.127.dnsbl.sorbs.net A"       → Status 3  (universal test point NOT listed)
curl dns.google  "dnsbl.so

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/814) · 2026-08-28 · closed · 0 comments

### check_srv: description promises directory coverage no prefix probes, and asserts a domain-wide "No SRV records" negative beyond its probe set

Two related coverage/wording defects in `check_srv`, both verified against live DNS (validation sweep 2026-08-28/29). Neither is a lookup bug — every SRV target/port the tool did report matched ground truth verbatim.

## 1. Description promises "directory" coverage; no directory prefix is probed

Tool description: *"probing ~16 common SRV record prefixes (email, calendar, messaging, web, directory)"*. `SRV_PREFIXES` (`src/tools/srv-analysis.ts:10-30`) contains **no directory prefix at all** — no

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/813) · 2026-08-28 · closed · 0 comments

### check_authoritative_dns_infra: "checks passed / satisfied all conclusive capability checks" emitted when all 22 capabilities were inconclusive (split from #786)

Split out of #786 per its closing comment ("The second item in this issue — `check_authoritative_dns_infra` finding **prose** reading 'checks passed' while its fields report nothing measured — is untouched by this release; reopen or split if you want it tracked separately.").

## Symptom (observed live on 3.67.0, 2026-08-28/29, google.com AND cloudflare.com)

`check_authoritative_dns_infra` returns a finding titled **"Authoritative DNS infrastructure checks passed"** with detail *"Infra probe ev

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/812) · 2026-08-28 · closed · 0 comments

### check_resolver_consistency: TXT comparison always reports SPLIT_HORIZON — Cloudflare DoH quote-wrapping never normalized

## Symptom (validation sweep 2026-08-28/29, live prod 3.67.0)

`check_resolver_consistency` reported *"TXT records differ between resolvers — likely GeoDNS or CDN steering. 2 resolvers returned 2 distinct answer sets."* (`status: SPLIT_HORIZON`) for **both** google.com and cloudflare.com, driving google.com's resolver score to 85.

## Ground truth

Both resolvers return the **identical** TXT record set (29 records for cloudflare.com, 16 for google.com; sorted sets equal member-for-member). The o

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/811) · 2026-08-28 · closed · 0 comments

### DKIM 85 vs 0 for the same domain: assess_spoofability has a hole for exactly-one-selector-revoked (google.com)

For `google.com`, DKIM is scored **85/100** by `scan_domain` but **0/100** by `assess_spoofability` — same domain, same DNS, same run window. Ground truth: the only discoverable selector, `20230601`, is revoked (empty `p=`, verified).

This is not two scoring models by design — both tools call the same `checkDKIM` with the same 46-selector list (`packages/dns-checks/src/checks/dkim-selectors.ts:39-104`) and both receive the same `CheckResult`: score 85, `controlPresent: false`. The divergence is

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/808) · 2026-08-28 · closed · 1 comment

### Injection-guard sanitizers mangle legitimate finding prose: underscores stripped from DNS labels, < and parens deleted (garbled SOA-expire text)

Two reported symptoms, one seam: stacked markdown-stripping sanitizers whose character classes have silently drifted apart.

## The two transforms

1. **`createFinding()` auto-sanitize** — `MARKDOWN_UNSAFE = /[`*#[\]>|<]/g` at `packages/dns-checks/src/scoring/metadata-sanitize.ts:73`, applied to `detail`/`title` at construction (`scoring/model.ts:332,341`). **Mutates the Finding object**, so every surface (structuredContent, PDFs) sees the damage. Deliberately preserves `_` and `()` — the commen

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/807) · 2026-08-28 · closed · 0 comments

### http_security + ssl: a 204 No Content response is scored as a fully-measured page — confident false missing-header slate (google.com)

## Symptom (scanner validation sweep, 2026-08-28, dns-checks 1.25.0)

`scan_domain google.com` emitted two false findings in one run:

- http_security: *"No X-Frame-Options header and no CSP frame-ancestors directive found"* — false; every hop of google.com's chain (apex 301 and www 200, verified live with the scanner UA) carries `x-frame-options: SAMEORIGIN`.
- ssl: *"No HTTP to HTTPS redirect (status 204)"* — false; `http://google.com` returns `301 Location: http://www.google.com/`.

$ cur

Read the thread · 2026-08-28 · closed · 1 comment

check_dnssec: unconfirmed AD=true with no DS scores 100 "cryptographically verified" — non-deterministic false pass

check_dnssec awards score 100 and the finding "DNSSEC enabled and validated — DNS responses are cryptographically verified" to domains with no DS and no DNSKEY, whenever the primary resolver's AD flag happens to come back true on that sample. Correct score is 60.

Found while sweeping 16 AI-provider domains against production v3.66.0.

Evidence

moonshot.ai — check_dnssec (force_refresh):

{ "category": "dnssec", "passed": true, "score": 100,
  "controlPresent": true

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/793) · 2026-08-26 · closed · 0 comments

### Registry drift: registry behind live (3.65.0 < 3.66.0)

### MCP Registry is behind live production

- Live `serverInfo.version` (dns-mcp.blackveilsecurity.com): `3.66.0`
- Registry `?version=latest` (registry.modelcontextprotocol.io): `3.65.0`

**Before republishing by hand, check whether `publish.yml` already ran for
`v3.66.0` and is PARKED or FAILED:**

1. `gh run list --workflow=publish.yml --repo MadaBurns/bv-mcp` - look for a run
   against tag `v3.66.0`.
2. If it is **waiting** on the `production` environment reviewer gate
   (the `Publish to M

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/792) · 2026-08-26 · closed · outside contributor · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/MadaBurns/bv-mcp/issues).