Decide how to reduce cross-app ambiguity in DNS-based tracker blocking

[kasnder]

Current behavior

The access table has a UID, destination IP, block decision, and uncertainty flag. DNS observations are global: they store qname, aname, resource, time, and TTL, but no UID. Consequently, getQAName(uid, ip, ...) cannot determine which hostname a specific app resolved; it reuses hostnames globally observed for that IP.

This can cause both shared-IP ambiguity and cross-app attribution ambiguity in per-app blocking decisions.

Options

1. Low-risk partial improvement: key the in-memory tracker-verdict cache by (uid, destination IP) instead of destination IP alone. This reduces cross-app cache bleed but does not make DNS evidence app-specific.
2. Full attribution redesign: persist DNS observations with a UID, link DNS evidence to access observations, or adopt a different attribution model. This affects schema, migration, collection/query logic, and the semantics of uncertain.

Decision needed

Choose whether the product goal is only more-conservative cache reuse or genuine per-app DNS evidence, and decide how conservative standard blocking should be when evidence remains global and ambiguous.

[kasnder]

#654 found technical gaps in current tls.c
No cross-segment reassembly: a ClientHello split across TCP segments (increasingly common — large extension sets, post-quantum key shares push past one MTU) is silently missed, and checkedHostname means no retry.
Single TLS record only.
Memory safety: parser is bounds-checked throughout; no OOB found (one harmless cosmetic off-by-one at tls.c:66).
Cost: the parse itself is negligible, but the control-flow change moves verdict work from the cheap SYN path onto the hot data path for port 443, and robust reassembly would add per-connection buffering — against the battery-first constraint.