[[ A month later, we're still eager to hear responses to the draft. We
got a few that we have incorporated for a new version, but want to be
sure we're on the right track before we move ahead. ]]
On 8 Jul 2016, at 15:36, Paul Hoffman wrote:
Greetings again; I'm the new co-author on this draft. Based on the WG
discussion where a bunch of us wanted to use EDNS0 and a bunch of us
wanted to use queries, the authors tentatively decided that the best
way to go forwards is to put both methods in the draft. After all, a
motivated observer of the signals will not have much problem watching
both types of signals, and end systems can decide which of the two
they want to use.
We understand that "specify more than one" is often an unpopular
choice in the IETF, about as unpopular as "don't get consensus on
one". This is a WG document so we need consensus even to go with two
ways. We look forward to hearing from you about this choice and how we
can move forwards.
--Paul Hoffman
On 8 Jul 2016, at 15:30, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations of the
IETF.
Title : Signaling Trust Anchor Knowledge in DNS
Security Extensions (DNSSEC)
Authors : Duane Wessels
Warren Kumari
Paul Hoffman
Filename : draft-ietf-dnsop-edns-key-tag-02.txt
Pages : 13
Date : 2016-07-08
Abstract:
The DNS Security Extensions (DNSSEC) were developed to provide
origin
authentication and integrity protection for DNS data by using
digital
signatures. These digital signatures can be verified by building
a
chain-of-trust starting from a trust anchor and proceeding down to
a
particular node in the DNS. This document specifies two different
ways for validating resolvers to signal to a server which keys are
referenced in their chain-of-trust. The data from such signaling
allow zone administrators to monitor the progress of rollovers in
a
DNSSEC-signed zone.
This document describes two independent methods for validating
resolvers to publish their referenced keys: an EDNS option and a
differnt DNS query. The reason there are two methods instead of
one
is some people see significant problems with each method. Having
two
methods is clearly worse than having just one, but it is probably
better for the Internet than having no way to gain the information
from the resolvers.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-02
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-02
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.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
