On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> [ Multi-response to four upthread messages. ] > > ------- > > On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote: > > > Thanks for your comments. We've posted an updated draft (-01): > > > > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01 > > [ Copied from today's dns-operations post on the same general topic. ] > > A possibly inconvenient question, just to make sure we're not ignoring > the obvious sceptical position: > > * How compelling is compact DoE? > > The reason to ask is that both the original and now modified protocols > involve non-trivial complexity, and would likely require resolvers to > respond differently to queries with the DO bit set (pass them the NODATA > "truth" along with the NXNAME signal) vs. queries that don't request > validated answers (pass them the inferred NXDOMAIN). > > The savings vs. actual by-the-book NSEC responses appear to be a 2x > reduction in the number of signatures to compute (the SOA RRSIG is > > > presumably easily cached) and a 1.5x reduction in the number of > signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). > > Do the CPU and packet size reductions justify the additional protocol > complexity? > I'll also regurgitate my message here from the dns-operations@ list thread: That's a reasonable question, and perhaps best directed to the originators of the scheme at Cloudflare. I don't know if there have been any measurement studies or analyses of the cost benefits vs by-the-book DNSSEC. There are currently 3 large commercial DNS providers that have had it deployed for a while now, so I suspect that it is here to stay. Note that one other provider (UltraDNS) does support traditional NSEC White "Lies" that give by-the-book DNSSEC proofs for NXDOMAIN, so apparently they are bearing the additional costs just fine. One other point -- without the additional rcode substitution schemes under discussion, Compact Answers can cause additional work for authority servers, since NODATA responses may lead to follow-on queries by DNS client applications (e.g. the common AAAA followed by A pattern; note: most DNS resolution API functions don't do happy eyeballs today). So, the per-response crypto & size reductions need to also be weighed against the cost of these additional queries. > But the main change is to move from the ENT distinguisher RR type > > to an explicit one for NXDOMAIN (with mnemonic NXNAME). > The draft fails to explain how queries for the proposed new RRtype are > to be handled by authoritative servers and resolvers. > Since this is a "meta" type for which we don't expect normal applications to ever issue queries, its behavior could be undefined I suppose. But it's probably better to explicitly say what the response should be. Maybe NODATA for an existing name, and NODATA + NXNAME NSEC bitmap sentinel for non-existent names? Sending FORMERR or SERVFAIL might invoke unwanted additional follow-on queries by resolvers (or their downstreams), although I suppose SERVFAIL + a new EDE value might be a possibility. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
