<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 05/09/2021 19.31, Andrew Sullivan
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20210905173122.4mb4bujlhcsd6ck4@crankycanuck.ca">This is
      false in multiple ways.  First, RRSIGs are in fact resource
      records and it _is_ possible to query for them directly:<br>
    </blockquote>
    <p>I would not advise using QTYPE=RRSIG.  Mainly because you may get
      sigs for some other versions of RR sets than those obtained in a
      different DNS message.  Also, RRSIG queries have similar DoS
      potential as ANY. 
      <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc8482#section-7">https://datatracker.ietf.org/doc/html/rfc8482#section-7</a></p>
    <p>Generally I'd recommend to treat sigs as attached to their
      respective RR sets.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:20210905173122.4mb4bujlhcsd6ck4@crankycanuck.ca">
      <blockquote type="cite">
        <blockquote type="cite">the RRSIG TTL should match the NS record
          TTL, but ..., the validating
          <br>
          resolver does not care, and should not, about RRSIG TTL. So
          the
          <br>
          difference between the expiration of the rrsig and the TTL
          shouldn't
          <br>
          or doesn't impact the online services.
          <br>
        </blockquote>
      </blockquote>
      <br>
      Also false.  Caches do not look at the RRTYPE to decide how to
      cache.  They just cache whatever comes along for the TTL.  If your
      RRSIG expires while it is cached, you will go bogus.  This is
      discussed (IMO somewhat elliptically, because there was some
      controversy about what the Right Thing was, IIRC, and it never
      really got resolved) in RFC 6781.
      <br>
    </blockquote>
    <p>Well, that depends on the caches.  RRSIGs do have special rules
      for TTL handling... which is surely the reason why dnsviz says
      "cache of *non-validating* resolver"  See
      <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc4034#section-3">https://datatracker.ietf.org/doc/html/rfc4034#section-3</a><br>
      <blockquote type="cite">
        <pre class="newpage">The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers.</pre>
      </blockquote>
    </p>
    <p>Also, TTL should be trimmed (by signers and validators) not to go
      past RRSIG expiration (or original TTL).  I can't recall where
      this is stated and how strongly.<br>
    </p>
    <p><br>
    </p>
    <p>To be clear, I agree with dnsviz that the state was not correct. 
      I don't like arguments in style "I tried it and it worked for me,
      so it's OK".  They make me dislike Postel's law.</p>
    <p><br>
    </p>
    <p>--Vladimir | knot-resolver.cz<br>
    </p>
  </body>
</html>