[rfc-dist] RFC 8078 on Managing DS Records from the Parent via CDS/CDNSKEY
rfc-editor@rfc-editor.org Fri, 10 March 2017 17:23 UTC
Return-Path: <rfc-dist-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-dist-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-dist-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9416C1296A5 for <ietfarch-rfc-dist-archive@ietfa.amsl.com>; Fri, 10 Mar 2017 09:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NaT5m8dAVq0 for <ietfarch-rfc-dist-archive@ietfa.amsl.com>; Fri, 10 Mar 2017 09:23:26 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2CD1294CF for <rfc-dist-archive-yuw6Xa6hiena@ietf.org>; Fri, 10 Mar 2017 09:23:26 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 0D080B80E4F; Fri, 10 Mar 2017 09:23:20 -0800 (PST)
X-Original-To: rfc-dist@rfc-editor.org
Delivered-To: rfc-dist@rfc-editor.org
Received: by rfc-editor.org (Postfix, from userid 30) id 31EA1B80E4E; Fri, 10 Mar 2017 09:23:19 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20170310172319.31EA1B80E4E@rfc-editor.org>
Date: Fri, 10 Mar 2017 09:23:19 -0800
Subject: [rfc-dist] RFC 8078 on Managing DS Records from the Parent via CDS/CDNSKEY
X-BeenThere: rfc-dist@rfc-editor.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: RFC Announcements <rfc-dist.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-dist>, <mailto:rfc-dist-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-dist/>
List-Post: <mailto:rfc-dist@rfc-editor.org>
List-Help: <mailto:rfc-dist-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-dist>, <mailto:rfc-dist-request@rfc-editor.org?subject=subscribe>
Cc: drafts-update-ref@iana.org, dnsop@ietf.org, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: rfc-dist-bounces@rfc-editor.org
Sender: rfc-dist <rfc-dist-bounces@rfc-editor.org>
A new Request for Comments is now available in online RFC libraries. RFC 8078 Title: Managing DS Records from the Parent via CDS/CDNSKEY Author: O. Gudmundsson, P. Wouters Status: Standards Track Stream: IETF Date: March 2017 Mailbox: olafur+ietf@cloudflare.com, pwouters@redhat.com Pages: 10 Characters: 21001 Updates: RFC 7344 I-D Tag: draft-ietf-dnsop-maintain-ds-06.txt URL: https://www.rfc-editor.org/info/rfc8078 DOI: 10.17487/RFC8078 RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes. This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records). It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org