On Thu, Jul 29, 2021 at 2:29 PM Peter van Dijk <peter.van.d...@powerdns.com> wrote:
> > > > Empty Non-Terminal Sentinel for Black Lies > > > > Abstract > > > > The Black Lies method of providing compact DNSSEC denial of existence > > proofs has some operational implications. Depending on the specific > > implementation, it may provide no way to reliably distinguish Empty > > Non-Terminal names from names that actually do not exist. This draft > > describes the use of a synthetic DNS resource record type to act as > > an explicit signal for Empty Non-Terminal names and which is conveyed > > in an NSEC type bitmap. > > I have read the draft, and I believe I understand what the draft is doing. > I have also read the Introduction and Motivation section. While it does > contain some motivation, I do not think it contains enough motivation. One > might argue that ENT/NXDOMAIN problems do not exist with these operators, > precisely because they do Black Lies. > > Furthermore, it looks like a trick that could only be relied on with > specific operators (such as, for now, NS1) that have implemented it. There > are plenty of differences between the implementations already. In fact, > when promoting RFC8482, CloudFlare heavily argued how the difference > between NODATA and NXDOMAIN is a very expensive one for them. So > presumably, it would not make sense for them to implement this signal. > Because of that, I wonder if it would not make more sense if the individual > implementers/operators of things that are somewhat similar under the 'Black > Lies'-umbrella document how they signal the difference between ENT and > NXDOMAIN. (It would of course be fine if some of them agree on the signal). > Hi Peter, Yes, Cloudflare is a bit different than the other 2 implementations - they did not exactly follow the spec as described in the expired ID (presumably for the reason you mention, although I don't know enough about their implementation to know why it's hard for them). For any NODATA, including ENT they return a NSEC bitmap that contains every (~ 20) RR type they support except for the queried type. I mention this in the draft. So, they effectively avoid the NXDOMAIN/ENT distinguishability problem that way. I also hope, but want to say that out loud here, that there is no expection > of -resolver- software to handle this signal in any special way. > Confirmed! :) Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop