On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie <p...@redbarn.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop