Re: [Last-Call] [DNSOP] Last Call: <draft-ietf-dnsop-dns-zone-digest-09.txt> (Message Digest for DNS Zones) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Sep 11, 2020, at 1:45 AM, Stephane Bortzmeyer <bortzmeyer@xxxxxx> wrote:
> 
> On Thu, Sep 10, 2020 at 03:03:45PM -0400,
> Warren Kumari <warren@xxxxxxxxxx> wrote 
> a message of 62 lines which said:
> 
>> Do you have any suggested text? If so, could you send it to the IETF
>> LC so it gets captured?
> 
> Done
> <https://secure-web.cisco.com/17dROtVCd8LPL7t02N7Td4TOI39uyGsdze_s6JTNPnNaX4tHIhjcs759W3j529_Py472Amqs5SXKLC5Nd_MTcJeR5PVobHvYL8yIVl_ckr9X2yFD-IE29Tg4tnmJxkdIACLzV3v0vuzCtPHg8O4MxXpQckHEIEw3ujqtvpPPWiZjt8fNMrd4dNGfALY0xk_VmBsRyjZM-dSvtuzPx3CdFLkAtORWvdiHaEtedIUgmKxcR5-YnVhgUHNObIK4ixjEcXjeUAZQAhOFPdwASB83d3l_jAVACGhC0tsmMjduyshY/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flast-call%2F7sl2rC8ql9Faj4aKVfOJSiT79n4>


Stephane,

Thank you.  We've added the following to the draft based on your feedback:

           to verify data that is read after transmission is complete.
           For example, a name server loading saved zone data upon restart
           cannot guarantee that the on-disk data has not been modified.
+          Such modification could be the result of
+          an accidental corruption of the file, or perhaps an incompletely
+          saved file <xref target="disk-full-failure"/>.
           For these reasons, it is preferable to secure the data itself.


+      <section title="DNSSESC Timing Considerations">
+        <t>
+          As with all DNSSEC signatures, the ability to perform signature
+          validation of a ZONEMD record is limited in time.
+          If the DS record(s) or trust anchors for the zone to be verified
+          are no longer available, the recipient cannot validate
+          the ZONEMD RRSet.
+          This could happen even if the ZONEMD signature is still current
+          (not expired), since the zone's DS record(s)
+          may have been withdrawn following a KSK rollover.
+        </t>
+        <t>
+          For zones where it may be important to validate a ZONEMD
+          RRset through its entire signature validity period, the zone
+          operator should ensure that KSK rollover timing takes this
+          into consideration.
+        </t>
+      </section>



<<attachment: smime.p7s>>

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux