queryDNS in internal/resolver/iterative.go sends a query again with recursion desired when a server answers REFUSED (added with the first resolver as "auto-fallback to recursive mode for environments with DNS interception"). On a network that intercepts DNS, answers can then come from a recursive resolver, silently. The README's core promise is that dnswatcher does all resolution itself and never relies on an upstream recursive resolver; this fallback breaks it without saying so.
Definition of done
A REFUSED reply is a refusal: the resolver moves on to the next server, as it does since #197, and never asks for recursion.
When every server refuses or the replies show DNS is being intercepted, the failure says so plainly in the log and the nameserver status, rather than falling back.
Before changing anything, check whether the test suite or the CI and Docker build environment rely on the fallback (run the live tests with it removed). If they do, do not work around it: put that on this issue as a question for sneak with a recommendation, and stop.
Tests: reply data built in the test, or live DNS; no stand-in resolver or client. README unchanged unless a sentence stops being true.
Model: opus-5-5
Found while reviewing https://git.eeqj.de/sneak/dnswatcher/pulls/205.
`queryDNS` in `internal/resolver/iterative.go` sends a query again with recursion desired when a server answers REFUSED (added with the first resolver as "auto-fallback to recursive mode for environments with DNS interception"). On a network that intercepts DNS, answers can then come from a recursive resolver, silently. The README's core promise is that dnswatcher does all resolution itself and never relies on an upstream recursive resolver; this fallback breaks it without saying so.
## Definition of done
- A REFUSED reply is a refusal: the resolver moves on to the next server, as it does since https://git.eeqj.de/sneak/dnswatcher/issues/197, and never asks for recursion.
- When every server refuses or the replies show DNS is being intercepted, the failure says so plainly in the log and the nameserver status, rather than falling back.
- Before changing anything, check whether the test suite or the CI and Docker build environment rely on the fallback (run the live tests with it removed). If they do, do not work around it: put that on this issue as a question for sneak with a recommendation, and stop.
- Tests: reply data built in the test, or live DNS; no stand-in resolver or client. README unchanged unless a sentence stops being true.
Model: opus-5-5
clawbot
added this to the 1.0 milestone 2026-10-02 01:44:46 +02:00
Built in #212: a refused query is no longer resent asking for recursion, and every root server refusing is reported as DNS interception. The live tests do not rely on the resend.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/dnswatcher/pulls/212: a refused query is no longer resent asking for recursion, and every root server refusing is reported as DNS interception. The live tests do not rely on the resend.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found while reviewing #205.
queryDNSininternal/resolver/iterative.gosends a query again with recursion desired when a server answers REFUSED (added with the first resolver as "auto-fallback to recursive mode for environments with DNS interception"). On a network that intercepts DNS, answers can then come from a recursive resolver, silently. The README's core promise is that dnswatcher does all resolution itself and never relies on an upstream recursive resolver; this fallback breaks it without saying so.Definition of done
Model: opus-5-5
Built in #212: a refused query is no longer resent asking for recursion, and every root server refusing is reported as DNS interception. The live tests do not rely on the resend.
Model: opus-5-5