vps/.agents/skills/encrypted-dns-skill/references/security.md

# Security and privacy requirements

Read this file before changing transports, bootstrap behavior, endpoint
validation, fallback, or result claims.

## Non-negotiable rules

1. Never silently downgrade to plaintext DNS.
2. Validate certificates and authentication domain names. DoT follows the
   strict privacy profile in [RFC 8310](https://www.rfc-editor.org/rfc/rfc8310.html).
3. Treat certificate, hostname, SNI, and any non-empty negotiated ALPN mismatch as hard
   failures, not fallback opportunities.
4. Bound response sizes, per-attempt timeouts, total time, redirects, and the
   number of attempts.
5. Do not expose an unrestricted endpoint parameter to an Agent. Built-in
   providers are allowlisted; private or custom endpoints require explicit
   user intent and policy approval.
6. Do not connect to addresses returned in DNS answers.
7. Do not enable AXFR, IXFR, or ANY queries.
8. Do not persist full query names or client identifiers by default.

## Proxy policy

DoH and DoT may use an explicit `--proxy` or the standard Go
[`ProxyFromEnvironment`](https://pkg.go.dev/net/http#ProxyFromEnvironment)
selection rules for `HTTPS_PROXY` and `NO_PROXY`. An explicit URL takes
precedence and must use `http` or `https`. DoT establishes an HTTP CONNECT
tunnel and then performs the normal resolver TLS handshake inside it; the
proxy never substitutes for resolver certificate, authentication-domain, SNI,
or ALPN validation.

Proxy credentials may be sent as HTTP Basic authentication when embedded in
the URL, but must never appear in result JSON or diagnostic errors. Result
metadata contains only a sanitized proxy endpoint. An HTTP(S) proxy can observe
the resolver destination, connection timing, and traffic volume even though it
cannot read the resolver TLS payload.

DoH3, DoQ, and the current DNSCrypt transport use UDP or QUIC and do not use a
TCP HTTP CONNECT proxy. Reject an explicit proxy for those protocols instead of
silently connecting directly. Proxy failures are transport failures and never
trigger plaintext DNS or an undisclosed direct connection.

## DoT ALPN policy

The client advertises the IANA-registered `dot` ALPN identifier. An explicit
selection other than `dot` is a hard failure before the DNS query is sent. An
empty selection is permitted and reported because RFC 7858 and RFC 8310 do not
make ALPN negotiation part of DoT server authentication; the dedicated port,
PKIX chain, SNI, and configured authentication domain still identify the
service. This deliberately restores the policy from PR #9 and supersedes the
stricter empty-ALPN rejection introduced by PR #11.

## QUIC transport policy

DoQ requires TLS 1.3 and an exact `doq` ALPN selection. DoH3 requires TLS 1.3,
HTTP/3, and an exact `h3` ALPN selection. Certificate, authentication-domain,
SNI, and ALPN failures abort before a DNS query is sent. The initial
implementation does not send 0-RTT data or enable session resumption because
their replay and linkability properties require a separate policy decision.

Each DoQ query uses one client-initiated bidirectional stream, a two-octet
length prefix, DNS Message ID 0, and STREAM FIN. Truncated frames, extra
responses, non-zero response IDs, unexpected streams, and missing FIN are
protocol failures; they never trigger plaintext or cross-protocol fallback.

Reject DNS messages with the TC bit set on every encrypted transport. In
particular, the UDP-only DNSCrypt implementation must not expose a partial
answer as a completed lookup.

## DNSCrypt transport policy

Accept only allowlisted DNSCrypt v2 stamps. Validate the stamp type, provider
public key, provider name, resolver certificate signature, validity interval,
and encrypted response. Report the stamp IP bootstrap path, provider
authentication name, certificate serial, and crypto construction. Certificate
or response-authentication failures are hard failures and never trigger
plaintext or cross-protocol fallback. Anonymized DNSCrypt remains unavailable.

## Bootstrap transparency

Connecting to a resolver hostname may require an initial DNS lookup. Report
whether the endpoint was reached using a configured bootstrap address, the
system resolver, or an already-known IP. Do not claim that a query avoided the
system resolver when bootstrap used it.

## DNS status and fallback

An HTTP, TLS, or QUIC exchange can succeed while DNS returns `NXDOMAIN`,
`SERVFAIL`, or `REFUSED`. Those are DNS outcomes and must not be converted into
transport errors. Cross-provider or cross-protocol fallback is permitted only
for explicitly classified transport failures and must be disclosed.

## DNSSEC language

The AD bit means the selected recursive resolver reports authenticated data.
It is not proof that this client validated the DNSSEC chain. Use separate
fields for resolver-reported and locally validated DNSSEC state.

## Privacy language

Encrypted transport protects the path between the client and the selected
resolver. The resolver can still observe the query. Provider policy, logging,
filtering, ECS behavior, and jurisdiction remain relevant. See
[RFC 8932](https://www.rfc-editor.org/rfc/rfc8932.html).

ODoH and Anonymized DNSCrypt add relay models but do not justify claims of
absolute anonymity. Their proxy, relay, and target roles must be reported
separately.