Function is_dns_blackhole 

pub fn is_dns_blackhole(addresses: &[SocketAddr]) -> bool

Whether every resolved address is the unspecified address (0.0.0.0 / ::).

This is the shape a filtering resolver uses to say “no”: ad and telemetry blockers answer a blocked name with the unspecified address rather than with NXDOMAIN. Those answers are refused by Policy::allows_address like any other unroutable target, but the refusal is routine housekeeping rather than evidence of anything — on a host whose resolver filters, it is the bulk of all refusals.

Callers use this to decide two things (decision D49). It picks the log level: a blackhole is an INFO, every other refusal a WARN. And it picks the answer: a blackholed name gets a 200 whose stream closes immediately, so the client sees a tunnel that opened and died — the same thing a transport without an in-band refusal channel shows it — while every other refusal keeps its 403 and its RFC 9209 destination_ip_prohibited reason. The split exists because the blackhole decision was made by the resolver upstream, not by this proxy, and a refusal from this proxy would misattribute it.

The test is deliberately all-or-nothing, and deliberately narrow to the unspecified address:

• All, because a name resolving to 0.0.0.0 and 10.0.0.1 is not a blackhole. The private address is a real target that the policy just refused, which is exactly the SSRF-shaped evidence worth keeping loud.
• Unspecified only, because loopback, RFC 1918 and the rest of the private space are what an attacker aims at, and a probe of them must stay visible. The unspecified address is the one entry in the deny list that reaches nothing at all.

An empty list is not a blackhole. It cannot arise on the paths that call this (resolution either fails or yields addresses), and “no addresses at all” is no reason to quieten a warning.