Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

[Brian Dickson <[e-mail]>]

On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie <[e-mail]> wrote:

> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>

I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not include the QTYPE, the NSEC/NSEC3 record proving
non-existent is required (already).
That the types are "type-specific thing" vs "wildcard-type thing", doesn't
even require special handling.


> it's pretty not-practical at this point to add a feature whose first
> real utility will come after the last resolver understands and
> implements it.
>

I think that overstates the deployment issue; in 1990, there weren't any
public resolvers that could be used (at least not that I'm aware of, or
maybe they were but got closed down later.)

Currently, the feature becomes usable when some fraction of the
{standard,open} resolvers have deployed support, and/or enough of the
clients (browsers) provide support, or both, plus some significant
support/deployment in authorities.

The efficiencies/optimizations on queries are something that might be
signaled via EDNS (either an OPT or a flag), regarding support for the new
slew of types.

Clients could have multiple resolvers configured, and prefer ones that
support the new types (as signaled by EDNS).

Those resolvers that provide support, and resolve the RDATA names to A/AAAA
and return those (from cache or proactively), minimize the need for
parallel queries and the corresponding query load.
Clients can learn (or be configured, or whatever) about resolver support
and tune their query logic based on that support.

That would put some degree of competitive pressure on resolver operators,
as well as providing a signal on client-side support. Client queries with
EDNS signal, to resolvers that do not support, still provide meaningful
uptake signal level to resolver operators.

The remaining two elements are authority server (software/operator)
support, and end-user (registrant) use. Competitive pressure in the market
place is beneficial once the first entrant deploys. EDNS signaling can help
there too, even when no response would have been provided (due to lack of
actual RRtype(s) at owner name).

I'm optimistic that there's a clean, scalable, flag-day-less, incremental
way forward.

Brian