agent-substrate / agent-substrate/substrate
atenet/dns: actor zone returns NXDOMAIN for empty non-terminals
- Dominant language
- Go
- Stars
- 1.8k
- Forks
- 316
- Avg merge
- 2d 43m
- Merged PRs (30d)
- 287
Description
The terminal NXDOMAIN catch-all added in #874 also answers NXDOMAIN for the zone apex, `actors.resources.substrate.ate.dev`, and for `.actors.resources.substrate.ate.dev`. Neither is an absent name: the apex exists by definition, and the zone answers for any well-formed `.` pair, so every `` label has children. Both are empty non-terminals, and the correct answer for one is NOERROR with an empty answer section, not NXDOMAIN.
NXDOMAIN asserts something stronger -- RFC 8020, "NXDOMAIN really means there's nothing below" -- so a resolver that caches it for `` may decline to resolve any actor in that atespace. That is a hard resolution outage rather than a degradation, which is why it is worth tracking even though nothing hits it today.
Latent for now: it needs a resolver in front that both queries the intermediate name (QNAME minimisation, RFC 7816) and applies NXDOMAIN cuts. kube-dns `stubDomains` and the CoreDNS `forward` plugin pass the full qname through, the CoreDNS `cache` plugin caches per (qname, qtype) without aggressive negative caching, and musl and glibc do not cache at all.
The fix is one more `template` block before the catch-all, scoped by a `match` carrying the apex and single-label patterns, with `rcode NOERROR`, the same SOA authority record, and `fallthrough`. Ordering is load-bearing: after the actor NODATA block, before the catch-all. Worth deciding first whether an apex `SOA` or `NS` query should be answered properly instead, in which case `file`/`auto` with a real zone is a better shape than a fourth `template` block.
Reproduced against `coredns/coredns:1.11.1`, the pinned image: `A ns1.actors.resources.substrate.ate.dev` and `SOA actors.resources.substrate.ate.dev` both return NXDOMAIN. `corefile.go` carries a TODO pointing here. Follow-up to #874.
Contributor guide
Assessment
This issue has not been assessed yet.