Hostname records are queried at the servers of the name's last two labels, the wrong zone under co.uk-style suffixes and delegated subdomains #189

New Issue

2026-10-01T22:54:12+02:00

clawbot commented

2026-10-01 22:54:12 +02:00

Found while reviewing #187.

QueryAllNameservers in internal/resolver/iterative.go finds the nameservers to ask about a hostname with parentDomain, which keeps the name's last two labels. That is the wrong zone whenever the hostname's zone is not those two labels:

under a multi-label public suffix: for www.example.co.uk it asks the co.uk servers, which only refer onward, so no records are found;
in a delegated subdomain: for api.dev.example.com, where dev.example.com is delegated to other servers, it asks the example.com servers, which only refer onward.

Hostname monitoring (records, inconsistency, NS failure) is then wrong for such names, and nameserver addresses (#105) are never found for nameservers named under such zones. Target classification already uses the Public Suffix List and is not affected.

Definition of done

The nameservers asked about a hostname are those of the zone the name is actually in, found by following referrals down from the root for that name, the way the resolver already follows delegations; not by counting labels.
Ordinary names (www.example.com) give the same nameservers as before.
Live-DNS tests (retries via internal/livednstest, no assertions on live record values) cover a name under a multi-label suffix and a name in a delegated subdomain, both getting answers from their own zone's servers. No stand-in resolver.

Model: opus-5-5

Found while reviewing https://git.eeqj.de/sneak/dnswatcher/pulls/187. `QueryAllNameservers` in `internal/resolver/iterative.go` finds the nameservers to ask about a hostname with `parentDomain`, which keeps the name's last two labels. That is the wrong zone whenever the hostname's zone is not those two labels: - under a multi-label public suffix: for `www.example.co.uk` it asks the `co.uk` servers, which only refer onward, so no records are found; - in a delegated subdomain: for `api.dev.example.com`, where `dev.example.com` is delegated to other servers, it asks the `example.com` servers, which only refer onward. Hostname monitoring (records, inconsistency, NS failure) is then wrong for such names, and nameserver addresses (https://git.eeqj.de/sneak/dnswatcher/issues/105) are never found for nameservers named under such zones. Target classification already uses the Public Suffix List and is not affected. ## Definition of done - The nameservers asked about a hostname are those of the zone the name is actually in, found by following referrals down from the root for that name, the way the resolver already follows delegations; not by counting labels. - Ordinary names (`www.example.com`) give the same nameservers as before. - Live-DNS tests (retries via `internal/livednstest`, no assertions on live record values) cover a name under a multi-label suffix and a name in a delegated subdomain, both getting answers from their own zone's servers. No stand-in resolver. Model: opus-5-5

clawbot added this to the 1.0 milestone 2026-10-01 22:54:12 +02:00

clawbot referenced this issue from a commit

2026-10-01 23:12:41 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

clawbot referenced this issue from a commit

2026-10-01 23:12:49 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

clawbot referenced this issue from a commit

2026-10-01 23:14:14 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

clawbot referenced this issue from a commit

2026-10-01 23:15:17 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

clawbot referenced a pull request that will close this issue

2026-10-01 23:16:26 +02:00

resolver: query a hostname at its own zone's servers (closes #189) #191

clawbot commented

2026-10-01 23:16:33 +02:00

Implemented in #191: a hostname's nameservers now come from FindAuthoritativeNameservers on the hostname itself, which follows delegations from the root for the name and tries each parent name until it reaches the zone the name is in. The walk stops at an authoritative reply, which is not a referral. Domain targets under a suffix like co.uk had the same fault for their own records and are fixed by the same change.

Model: opus-5-5

Implemented in https://git.eeqj.de/sneak/dnswatcher/pulls/191: a hostname's nameservers now come from `FindAuthoritativeNameservers` on the hostname itself, which follows delegations from the root for the name and tries each parent name until it reaches the zone the name is in. The walk stops at an authoritative reply, which is not a referral. Domain targets under a suffix like `co.uk` had the same fault for their own records and are fixed by the same change. Model: opus-5-5

clawbot referenced this issue from a commit

2026-10-01 23:33:55 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

clawbot closed this issue

2026-10-01 23:34:36 +02:00

clawbot referenced this issue from a commit

2026-10-01 23:34:38 +02:00

resolver: query a hostname at its own zone's servers (closes #189)

Sign in to join this conversation.