# 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](/mcp/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](https://github.com/MadaBurns/bv-mcp/issues/417) · 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](https://github.com/MadaBurns/bv-mcp/issues/841) · 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)`:

```json
"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](https://github.com/MadaBurns/bv-mcp/issues/641) · 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](https://github.com/MadaBurns/bv-mcp/issues/421) · 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**:

| model | shipped in | dns-checks source it changed | package version |
| --- | --- | --- | --- |
| 1.13.0 | — | — | bumped to 1.24.0 by #777, then 1.27.0 by #794 |
| 1.14.0 | | scoring | **1.27.0** |
| 1.15.0 | 3.70.0 (#846) | `scoring/classifiers/dmarc.ts`, `parity-fixtures.ts` | **1.27.0** |
| 1.16.0 | 3.71.0 (#850) | `

[Read the thread](https://github.com/MadaBurns/bv-mcp/issues/855) · 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](https://github.com/MadaBurns/bv-mcp/issues/842) · 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](https://github.com/MadaBurns/bv-mcp/issues/839) · 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](https://github.com/MadaBurns/bv-mcp/issues/832) · 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](https://github.com/MadaBurns/bv-mcp/issues/831) · 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](https://github.com/MadaBurns/bv-mcp/issues/828) · 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 <domain> 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](https://github.com/MadaBurns/bv-mcp/issues/806) · 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):

```json
{ "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).