[dns-operations] why does that domain resolve?

[Paul Vixie]

On Sat, Jun 05, 2021 at 04:11:43PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 05, 2021 at 06:11:06PM +0000, Paul Vixie wrote:
> > I expect these NS RRs to become visible in any validating full resolver that
> > implements QNAME Minimization. that's not a protocol change.
> 
> That does not always work, and may work even less often in the future,
> because:
> 
>     * If the query is at the zone apex (e.g. gmail.com MX lookup), then 
>       no NS query is issued at the final zone cut, since it is also the
>       final qname, and the RRtype is then from the actual question.
> 
>     * Once 7816bis is published and adopted (last call at the moment),
>       the queries used for qname minimisation will typically be "A",
>       rather than "NS".

ah. so we're back to ns-revalidate. thanks for clarifying this for me.

ns-revalidate is also not a protocol change.

"data which is not used will be wrong," according to kenneth orr, in
_structured systems development_ (1977). this condition is self-sustaining,
as we see from "parent-centric dns resolution". this logic motivates itself
by the fact that apex NS RRs are often wrong, and by avoiding the apex NS,
amplifies the likelihood that apex NS RRsets will be wrong. self-fulfilling.

we need to always-use the apex NS, and let failures occur. perhaps this
ought to be done in the modern "A/B testing" so that only some fraction of
resolutions will treat the apex NS as being of higher credibility (by being
authoritative, and subject to DNSSEC validation), so that zones whose apex
NS is wrong will have worse service overall but won't fail outright.

but "parent-centric" is bad for the hygiene, health, and future of DNS --
and this cannot be a rational choice even if it is good for the operators of
resolvers who emit SERVFAIL less often thereby. every choice we make is a
vote for one future over another.

-- 
Paul Vixie