Hi Shumon,

On Tue, 2021-07-27 at 19:34 -0400, Shumon Huque wrote:
> Folks,
> 
> While we have the attention of DNSOP folks this week, I'd like to ask for 
> review of this draft (I meant to send it earlier in time for f2f discussion 
> on Tuesday, but better late than never).
> 
>     https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01
> 
> Excerpt:
> 
>                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).

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.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to