Thanks for your comments. We've posted an updated draft (-01): https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
Some smaller updates: * Remove the "Lies" moniker. We now refer to this mechanism as just Compact Denial of Existence, or Compact Answers if you prefer pithy. (Renaming the draft filename is too much work - we'll do that if/when the WG adopts this.) * Move the various types of responses into subsections and provide an expanded treatment of them. * Update the operational implications section with the observation by Paul Vixie that this can cause additional queries from name lookup functions/methods. But the main change is to move from the ENT distinguisher RR type to an explicit one for NXDOMAIN (with mnemonic NXNAME). When I originally devised the ENT distinguisher, it was because we could use the same type bitmap pattern (NSEC RRSIG) to identify NXDOMAIN at those implementations and also at other implementations like Cloudflare that used a broad bit pattern of many types in ENT responses. Secondarily, I thought this would cause less work at servers since ENTs are far less common than NXDOMAIN (but that is likely just in the noise compared to the crypto work to generate the response). After chatting this through with Christian/Cloudflare, we've now agreed that a precise distinguisher for NXDOMAIN is better. We hope others will also agree. There are more details in Section 2. Cloudflare colleagues also have an interest in using the NXDOMAIN signal to allow resolvers to modify the response code from NOERROR to NXDOMAIN back to non-validating clients. I'm not yet persuaded that this is worth doing, but the draft enables that. Ultimately, if all client systems run validating stubs/resolvers, they will need to fully authenticate the contents of the DNS message (the RCODE is then merely a hint for what to look for, and not essential to that task). Shumon
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
