Re: [DNSOP] [Technical Errata Reported] RFC6781 (5273)

All, I think this errata is incorrect: For an algorithm rollover it is intended that at the "DNSKEY removal" step, the DNSKEYs are removed from the zone, but the signatures stay. This is to play nicely with conservative validators: The conservative approach interprets this section very

[DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-09.txt

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 WG of the IETF. Title : DNS Terminology Authors : Paul Hoffman Andrew Sullivan

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.txt

Hello dnsop, Please find below revision 04 of the XPF draft. We believe all concerns previously raised have been addressed in this version. Additionally, two implementations (both in PowerDNS products) have popped up, along with two decoders (Wireshark, and [not mentioned in -04] tcpdump). As

[DNSOP] Status of draft-ietf-dnsop-terminology-bis

Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is out. Reading the diff might be a bit difficult because of the reorganization of some sections that y'all asked for, but I think the result is worth the extra effort. We're still not done yet. I took a hiatus from finishing

[DNSOP] I-D Action: draft-dupont-dnsop-rfc2845bis-01.txt

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 WG of the IETF. Title : Secret Key Transaction Authentication for DNS (TSIG) Authors : Francis Dupont

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-05.txt

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 WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston

[DNSOP] Updates to the KSK Sentinel document - draft-ietf-dnsop-kskroll-sentinel-05

Dear all, I've just posted an update of the KSK Sentinel document -- this is thanks to the contributions from a number of DNSOP participants - https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ Petr, Paul and Mary[0] ^h^h^h^h Duane deserve special thanks for submitting pull

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

On Sat, Mar 3, 2018 at 5:07 PM, Ray Bellis wrote: > > > On 01/03/2018 12:37, internet-dra...@ietf.org wrote: > > > Abstract: This document describes a method for automatic DNS zone > > provisioning among DNS primary and secondary nameservers by storing > > and transferring the

[DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-06.txt

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 WG of the IETF. Title : C-DNS: A DNS Packet Capture Format Authors : John Dickinson Jim Hague

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

Hi all, Per subject, see below, etc. I apologise for the ludicrous amount of time it has taken for me to do these final edits. Fortunately the beatings continued until the morale improved. I believe the -05 represents a reasonable facsimile of the consensus of suggestions that came up at the

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

To re-raise my unaddressed points: * The document should include planned text you mentioned acknowledging lack of a signal to indicate "partial response" for section 4.1/section 4.3 subset responses ([1]). * "Conventional [ANY] response" is used but not defined ([2]). * The document

[DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-05.txt

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 WG of the IETF. Title : Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY Authors : Joe Abley

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-kskroll-sentinel-05.txt

>Filename: draft-ietf-dnsop-kskroll-sentinel-05.txt Why is this written in a way that the mechanism only applies to the root zone? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-06.txt

Hi All, This update makes a few minor updates based on the most recent feedback. * Correct BlockParameters type to map * Make RR ttl optional * Add storage flag indicating name normalisation * Add storage parameter fields for sampling and anonymisation methods * Editorial clarifications and

[DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-06.txt

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 WG of the IETF. Title : Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY Authors : Joe Abley

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

On 5 Mar 2018, at 15:00, Richard Gibson wrote: > To re-raise my unaddressed points: > > • The document should include planned text you mentioned acknowledging > lack of a signal to indicate "partial response" for section 4.1/section 4.3 > subset responses

[DNSOP] The actors in draft-ietf-dnsop-refuse-any-06.txt

In Section 4, it says: 1. A DNS responder can choose to select one or a larger subset of the available RRSets at the QNAME. 2. A DNS responder can return a synthesised HINFO resource record. See Section 6 for discussion of the use of HINFO. 3. Resolver can try to give

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

> On Mar 3, 2018, at 2:32 PM, Geoff Huston wrote: > > I guess that the knowledge that resolver X trusts a key with a hash value of > Y does not leave me much the wiser in terms of exploitable knowledge about > the (in)security of that resolver. If there is a key or algorithm

[DNSOP] I-D Action: draft-ietf-dnsop-session-signal-06.txt

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 WG of the IETF. Title : DNS Stateful Operations Authors : Ray Bellis Stuart Cheshire

[DNSOP] Conflict between "Aggressive Use" and "Wildcards"

A few weeks ago, I came across a blog post describing a "security hole" in so-called "NSEC Aggressive Use" implementations. https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be After some exchanges of email with the blog author, I

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-06.txt

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 WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston

[DNSOP] Comments on draft-ietf-dnsop-session-signal-06

This draft is much clearer about DSO unacknowledged messages, which really helps understanding the protocol. Also, thank you for switching from "octet" to "byte". :-) A few other comments: = In this document the term "session" is used exclusively as described above, and is in no

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

> On 6 Mar 2018, at 9:31 am, Wessels, Duane wrote: > > >> On Mar 3, 2018, at 2:32 PM, Geoff Huston wrote: >> >> I guess that the knowledge that resolver X trusts a key with a hash value of >> Y does not leave me much the wiser in terms of exploitable

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

> On Mar 5, 2018, at 4:05 PM, Geoff Huston wrote: > > For example, if researcher Duane sets up a test zone in Freedonia and sets up > validly and invalidly signed domain names within the Freedonia name realm, > then couldn’t a Ad-bsed large scale test reveal this information

Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

> On 6 Mar 2018, at 9:31 am, Wessels, Duane wrote: > > >> On Mar 3, 2018, at 2:32 PM, Geoff Huston wrote: >> >> I guess that the knowledge that resolver X trusts a key with a hash value of >> Y does not leave me much the wiser in terms of exploitable

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5273)

Hi Peter and Matthijs, We have deleted this report as requested by Peter. If any further errata apply to Figure 8, please submit another errata report. Thank you. RFC Editor/mf On Mar 5, 2018, at 11:08 AM, Peter J. Philipp wrote: > Hi, > > I sent rfc-editor