<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 27/03/2023 à 19:19, Viktor Dukhovni
      a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:ZCHQI2BsEh2p+kWH@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">On Mon, Mar 27, 2023 at 06:30:02PM +0200, Emmanuel Fusté wrote:

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Do you have a list of operators that currently return just "RRSIG NSEC"
for ENTs?  Do you [know] what software they are running?
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
I double check: route53/AWS currently return just "RRSIG NSEC"for ENTs.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Anyone else?</pre>
    </blockquote>
    Need to investigate in my dataset, but from the tree I know for sure
    (Cloudlfare, NS1, Route53), it is the only one doing this.<br>
    <blockquote type="cite"
      cite="mid:ZCHQI2BsEh2p+kWH@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Even worse, it seems that they infer answers to non edns or cleared DO 
bit questions from a internal DNSSEC response even for non DNSSEC 
enabled zone:
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I am struggling to understand this, can you give an example?</pre>
    </blockquote>
    <br>
    This is just a (perhaps bad) AWS implementation guessing of why ENT
    is broken on AWS on non DNSSEC zones or non DNSSEC answers as for
    DNSSEC client you could not distinguish ENTs and NXDOMAINs too.<br>
    <br>
    Take an ENT for witch AWS return "RRSIG NSEC" when requested with
    the DO bit.<br>
    Do the same request without the DO bit, you will get NXDOMAIN
    status.<br>
    <br>
    The result is consistent : broken ENT with or without DNSSEC, as it
    would be if you do the minimal response decoding client side to
    synthesize the NXDOMAIN status for your application.<br>
    <br>
    We could imagine anything "explaining" this consistency in the
    implementation, but it deserve no purpose I agree.<br>
    <span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:ZCHQI2BsEh2p+kWH@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">- they currently return NXDOMAIN for ENT on apparently non DNSSEC signed 
zones.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
The ENT handling at AWS has been known to be broken for some time.

    <a class="moz-txt-link-freetext" href="https://twitter.com/VDukhovni/status/1443681398905360384">https://twitter.com/VDukhovni/status/1443681398905360384</a>
    <a class="moz-txt-link-freetext" href="https://twitter.com/VDukhovni/status/1445236728269258753">https://twitter.com/VDukhovni/status/1445236728269258753</a>

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">The only other option is to introduce yet another sentinel that signals
that the node in question is an ENT, so that the bare "RRSIG NSEC"
combination is ultimately never used.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
Yes it was my conclusion too.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I am not entirely keen on yet another sentinel, but feel free to suggest it.
The draft is currently under discussion.

</pre>
    </blockquote>
    <br>
  </body>
</html>