Re: [Editorial Errata Reported] RFC6840 (4191)
Edward Lewis <[email protected]> Tue, 2 Dec 2014 18:11:45 +0000
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <D0A36905.76E6%[email protected]> |
That may be - but there’s currently yet another call for a SIG(AXFR), which to me is “signing the zone.” When I was reading the RFC (just to catch up) that was in the back of my mind. FWIW, I have corrected anyone who says they 'sign the zone’. Partly because that is not what is done in much of today’s operations - most of the signing is incremental (a few sets at a time). Implementations that assume they can do batch-style signing of zones never survive the testing phase (never the load test). On 12/2/14, 12:10, "Donald Eastlake" <[email protected]> wrote: >While the new text is OK, I do not think the old text is wrong. >"signing a zone" is a well known term of art for signing the >authoritative RRsets in the zone. > >Thanks, >Donald >============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > >On Tue, Dec 2, 2014 at 11:36 AM, RFC Errata System ><[email protected]> wrote: >> The following errata report has been submitted for RFC6840, >> "Clarifications and Implementation Notes for DNS Security (DNSSEC)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Edward Lewis <[email protected]> >> >> Section: 5.11 >> >> Original Text >> ------------- >> ... >> >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. The >> zone MUST also be signed with each algorithm (though not each key) >> present in the DNSKEY RRset. >> >> Corrected Text >> -------------- >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. Each >> authoritative RRset in the zone MUST be signed with each >> algorithm (though not each key) present in the DNSKEY RRset. >> >> Notes >> ----- >> Zones aren't signed (per se), the data sets within them are. But not >>cut point (NS) and glue. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) >> -------------------------------------- >> Title : Clarifications and Implementation Notes for DNS >>Security (DNSSEC) >> Publication Date : February 2013 >> Author(s) : S. Weiler, Ed., D. Blacka, Ed. >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> dnsext mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext
smime.p7s
(application/pkcs7-signature, 4.5 KB) - not displayed