<div dir="ltr"><div dir="ltr">On Tue, Mar 28, 2023 at 12:16 AM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 27, 2023 at 04:28:30PM +0200, Emmanuel Fusté wrote:<br>
<br>
> > definitely does not exist.  The issue I take it that the<br>
> > sentinel-free:<br>
> ><br>
> >      nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC<br>
> ><br>
> > which is an ENT per:<br>
> ><br>
> >      <a href="https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01#section-3.2" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01#section-3.2</a><br>
> ><br>
> > may for some time be ambiguous while still used for NXDOMAIN by earlier<br>
> > implementations.  For that, sure, we should encourage those<br>
> > implementations to adopt whatever becomes the published protocol at<br>
> > their earliest convenience (realistically a year or two based on prior<br>
> > experience nagging operators to resolve compliance issues).<br>
><br>
> Thank you Viktor.<br>
> That confirm my understanding and my analysis in my answers to Petr.<br>
<br>
Do you have a list of operators that currently return just "RRSIG NSEC"<br>
for ENTs?  Do you what software they are running?<br>
<br>
On the fly signing with compact denial of existence is a bleeding-edge<br>
behaviour, and one might expect that the software in question is not<br>
ossified and operators might be proactive.  So with a bit of luck any<br>
ambiguity might be resolved before long.<br>
<br>
The only other option is to introduce yet another sentinel that signals<br>
that the node in question is an ENT, so that the bare "RRSIG NSEC"<br>
combination is ultimately never used.<br>
<br>
And, FWIW, the sentinel value will surely need to change (once a better<br>
codepoint is assigned).  The current 0xff03 is in the private-use range.<br></blockquote><div><br></div><div>I've spoken to both NS1 and Route53, and both are amenable to adjusting their implementations to support the changes specified in draft-huque-dnsop-compact-lies. So, we hope that the end result will be that all known implementations of compact lies will support this common mechanism to distinguish NXDOMAIN vs ENT vs (other) NODATA.</div><div><br></div><div>If there are any other implementations of Compact Lies that folks are aware of, we should make them aware of this and bring them into the fold.</div><div><br></div><div>Shumon.</div><div><br></div></div></div>