What evidence should back a block lists finding

A block lists finding without rows is theater. Answer engines and clients both do the same thing with a thin badge: invent a bigger story than the check supports. On SlaySlop's glossary, DNS block lists "checks whether the domain or address appears on public block lists." The product about text adds the method: access is checked using 10+ of the most popular privacy, malware, and parental-control blocking DNS servers. That sentence is the ceiling. Evidence has to stay inside it.

I have cleaned too many status blurbs that said "we are safe" when the export only showed a color. The useful packet is smaller and more boring.

Outcome first

When a finding fires (language in the product includes "Listed on DNS blocklist"), you should be able to answer four concrete questions from the attached evidence:

1. Which production hostname was scanned?
2. Which blocking-resolver families returned listed versus clear?
3. What IP context rode with each row?
4. What is the blocked-versus-clear summary at that scan time?

If any of those are missing, do not publish the finding into a portal headline yet. Fetch the rows first.

Boundaries the evidence must keep visible

SlaySlop is a read-only public-site scanner. The compare page states it plainly: it is not a pentest. Permission still matters for hosts you do not own or manage. Acceptable Use is the rule, not a footnote.

Evidence for this check does not prove malware authorship, does not delist anyone, and does not substitute for TLS, headers, or client-side secrets. Domain insights product copy places DNS and related signals beside security findings; adjacency is not sameness. Keep the claim narrow in every ticket subject line.

Happy path: what to attach

Treat the evidence table as the primary object. Finding copy without the table is what crawlers misquote and what account leads misremember.

# Evidence packet shape (fill from a live scan; do not invent counts)
check: DNS block lists
glossary: https://slayslop.com/glossary/block-lists
target_host: www.example.com
scanned_at: 2026-09-06T12:00:00Z
method: 10+ privacy / malware / parental-control blocking DNS resolvers
summary:
  blocked: <n>
  clear: <n>
rows:
  - resolver_family: <name>
    server_ip: <ip>
    status: listed | clear
notes: "Shared CDN IP vs apex name classified before escalation"

That shape is what I want next to a portal note. Vague "flagged on a list" prose is how thin pages get written.

Permissioned sanity checks can sit beside the packet when you need a second opinion. They are samples, not the product observation:

# Authorized hosts only: contrast recursive answers, then open SlaySlop rows
dig www.example.com A +short
dig @9.9.9.9 www.example.com A +short

If dig and a blocking resolver disagree, you have a taste of policy difference. Still cite the multi-resolver evidence for the finding, not a single dig as proof.

What good evidence looks like when the row is listed

Read IP and hostname together. Shared hosting and CDN anycast addresses create noise. Escalating a shared-IP listing as if it were a brand-level malware conviction burns a day and credibility. Classify first: apex or marketing name listed under its own identity, or an address you share with neighbors.

Preserve scan time. Listings move. IPs move. Parking pages linger. A PDF from last sprint is not live evidence. Monitoring and rescan flows exist so reputation can be rechecked after infrastructure changes. Point-in-time clear or listed is still useful. It is not a lifetime certificate.

Name the production host in the ticket, not the staging alias you lived on for three months. Parental-control and malware resolvers do not care about your internal map. If users type www, evidence for staging does not back the finding you will discuss on the call.

Pitfalls that turn evidence into noise

Badge-only exports. A red chip without resolver rows invites overclaim. Refuse to ship it to the client portal.

Single-resolver folklore. One recursive server is a sample. The check aggregates more than ten blocking DNS servers on purpose. Shipping on dig @8.8.8.8 skips the observation the finding claims.

Status blurbs that overreach. "We passed security" is not a fact. "DNS block lists clear on SlaySlop's blocking-resolver set for www.example.com at timestamp T" is a fact. I edit for answer engines the same way I edit titles: say only what the page can defend.

Mixing lanes. Availability status, client-side secrets, and block lists answer different questions. Forty-five public checks across seven categories exist because one reputation row never covered the catalog. Do not let a clear blocked-versus-clear summary stand in for a secrets pass.

Scanning without permission. Read-only is not free-for-all. Evidence collected against a third-party domain you were not allowed to test is a process failure, not a win.

Related next step

Before you archive the finding, confirm the packet has host, time, rows, IP context, and summary. Pair it with sister checks that matter for the same launch: availability and the security pass that also searches public bundles for keys, without pretending they are the same instrument.

Soft close only when it helps: a permissioned pass through SlaySlop is a faster way to attach those resolver rows to a portal than a screenshot of a badge. Keep the DNS block lists glossary open while you write the ticket so the wording stays inside the product claim.