We have submitted a new draft that allows a DNS operator to signal for the addition or removal of a DS record at the parent. This addresses a roadblock in DNSSEC deployment where some DNS hosters are sitting on thousands of domains that are very hard to get securely delegated in the existing process. It also helps DNS operators when DNSSEC changes are required for moving a domain to another DNS operator, for instance when it is required that secure delegation is removed due to an incompatible algorithm rollover. I'll give a very short overview in Yokohama if the schedule allows for that. Paul ---------- Forwarded message ---------- From: <internet-dra...@ietf.org> Date: Thu, Oct 15, 2015 at 12:13 PM Subject: New Version Notification for draft-ogud-dnsop-maintain-ds-00.txt To: Paul Wouters <pwout...@redhat.com>, Olafur Gudmundsson <olafur+i...@cloudflare.com> A new version of I-D, draft-ogud-dnsop-maintain-ds-00.txt has been successfully submitted by Olafur Gudmundsson and posted to the IETF repository. Name: draft-ogud-dnsop-maintain-ds Revision: 00 Title: Managing DS records from parent via CDS/CDNSKEY Document date: 2015-10-15 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ogud-dnsop-maintain-ds-00.txt Status: https://datatracker.ietf.org/doc/draft-ogud-dnsop-maintain-ds/ Htmlized: https://tools.ietf.org/html/draft-ogud-dnsop-maintain-ds-00 Abstract: RFC7344 specifies how DNS trust can be maintained in-band between parent and child. There are two features missing in that specification: initial trust setup and removal of trust anchor. This document addresses both these omissions. Changing a domain's DNSSEC status can be a complicated matter involving many parties. Some of these parties, such as the DNS operator, might not even be known by all organisations involved. The inability to enable or disable DNSSEC via in-band signalling is seen as a problem or liability that prevents DNSSEC adoption at large scale. This document adds a method for in-band signalling of DNSSEC status changes. Initial trust is considered a much harder problem, this document will seek to clarify and simplify the initial acceptance policy. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
