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