Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-01.txt

This draft has been updated based on recent feedback. The primary change is that the new version is less prescriptive about how the resolution failure negative cache should work. e.g., rather than saying "Resolution failures MUST be cached against the specific query tuple…” it now says "Resolv

Re: [DNSOP] .alt filtering in recursive servers

I find the latest alt-tld draft to be inconsistent when it first says “[alt names] should not be looked up in a DNS context” and "DNS stub and recursive resolvers do not need to look them up in the DNS context” but then later "Caching DNS servers will treat [alt names] just as they would any other

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

I will reiterate some of my concerns with the draft: I find the format of section 3.2 to be very strange. As a paragraph it jumbles some items together. It should be a list format like the ones in RFCs 6761 and 7686. Section 3.2 does not say how applications that do not use .alt should behave

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-21.txt

Thank you authors for the update which addressed my concern about formatting of the special use considerations as an enumerated list. Forgive me if I am being difficult, but I feel that the first sentence of the privacy section, which says “... so should not attempt to be resolved using the glo

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

> On Mar 29, 2023, at 10:53 AM, Shumon Huque wrote: > > On Tue, Mar 28, 2023 at 9:51 PM Matthew Pounsett wrote: > > On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen wrote: > > > On 3/28/23 03:14, Shumon Huque wrote: > > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni >

[DNSOP] Meaning of lame delegation

Dear DNSOP, I am participating in an SSAC work party where we are writing about DNS delegations where a delegated name server might be available for registration, allowing an attacker to participate in the resolution for the domain. During report drafting we considered using the term "lame del

Re: [DNSOP] Meaning of lame delegation

Thank you everyone for your feedback on the meaning of lame delegation. I expected some different interpretations, although maybe not this many! I will take this feedback to the SSAC work party for discussion there about whether or not to use the term in the report (perhaps with a disclaimer).

Re: [DNSOP] [Ext] Meaning of lame delegation

I think Paul’s definition is good and matches the way I think of a lame delegation. My one quibble would be with the ending part that says “that zone is said to have…” This is somewhat confusing because the definition combines both a parent-child delegation and an apex/self delegation. If we’

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen: A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS rrset or by the child's apex NS rrset answers non-authoritatively

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-09.txt

Thanks to all the IESG reviewers for their feedback. We've made the following updates in revision -09: - No more uppercase RFC2119 keywords in the abstract - Added a reference to the DNS terminology RFC - Added a reference to the dig command At this point the authors believe the IESG feedback h

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03

Hi Peter, Thank you for the detailed review. Responses from the authors are inline below. > On Jun 26, 2023, at 7:47 AM, Peter van Dijk via Datatracker > wrote: > > Reviewer: Peter van Dijk > Review result: Almost Ready > > I have been selected as the DNS Directorate reviewer for this draf

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-04.txt

This revision includes some changes in response to Peter van Dijk's DNS directorate review, as well as addressing the left over "for discussion" topics. Although our conversation with Peter may still be ongoing, we wanted to get this version out so that other people can review the document as a

Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

> On Jun 30, 2023, at 2:32 PM, Joe Abley wrote: > > > > I have read -04. i like it. I think it's useful and sensible and it should be > published. Whether this particular rev is ready for publication I would say > depends on whether the authors disagree with all the pedantic nonsense that

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

Tim, You said you received some operational feedback. I wonder if it would be appropriate to add this operational (or implementation?) feedback to the (currently empty) Implementation Status section that Peter van Dijk suggested we add, in his DNS directorate review? I’m not necessarily oppos

Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures

Evan, > On Jul 24, 2023, at 10:34 AM, Evan Hunt wrote: > > The original text says a series of seven resolution failures would increase > the duration before a retry to five minutes: 5 seconds to 10 to 20 to 40 to > 80 to 160 to 300. Lowering the starting value to one second means it would > take

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-06.txt

DNSOP, Based on some discussions both in person at IETF 117 and on the list, we have updated some of the requirements language for caching resolution failures. We’ve also used an excerpt of Evan’s previous email to the list in the Implementation Status section of the document. It would be nic

Re: [DNSOP] Artart last call review of draft-ietf-dnsop-caching-resolution-failures-06

Thanks Barry for the good feedback. I've updated our source document with the changes you've suggested. DW On 8/9/23, 1:10 PM, "Barry Leiba via Datatracker" mailto:nore...@ietf.org>> wrote: Reviewer: Barry Leiba Review result: Ready with Nits Thanks for a well-written document. I found th

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06

> On Aug 14, 2023, at 1:40 AM, Peter van Dijk via Datatracker > wrote: > > Reviewer: Peter van Dijk > Review result: Ready with Nits > > Thank you for processing my previous comments. The document is in great shape. > I have one nit: > > One of the new sections based on my earlier comments

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-caching-resolution-failures-06

> On Aug 11, 2023, at 5:36 AM, Lucas Pardue via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Reviewer: Lucas Pardue > Review result: Ready

Re: [DNSOP] I-D Action: draft-ietf-dnsop-caching-resolution-failures-07.txt

DNSOP, This version of the draft addresses various comments from the Artart, Genart, and Dnsdir reviewers: * Artart review: minor editorial clarifications * Genart review: remove confusing and superfluous section references. * Genart review: clarify resolution failure caching t

Re: [DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Aug 27, 2023, at 3:47 PM, Erik Kline via Datatracker > wrote: > > ## Nits > > ### S1.2 > > * "only exacerbated" -> "further exacerbated"? > > Use of "only" here might be misread. > > ### S2.2 > > * s/2001:DB8:1::/2001:db8:1::/g > > in accordance with RFC 5952 section 4.3 > Than

Re: [DNSOP] Intdir telechat review of draft-ietf-dnsop-caching-resolution-failures-07

Carlos, Thank you for the suggestions. We’ve made all these changes. DW > On Sep 6, 2023, at 1:59 PM, Carlos Pignataro via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and kno

Re: [DNSOP] Robert Wilton's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 5, 2023, at 3:52 AM, Robert Wilton via Datatracker > wrote: > > -- > COMMENT: > -- > > Hi, > > Thanks for working on this document - I'm not a DNS

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 6, 2023, at 11:46 PM, Murray Kucherawy via Datatracker > wrote: > > > -- > COMMENT: > -- > > Thanks to Barry Leiba for his ARTART review. > > I th

Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker > wrote: > > > > -- > COMMENT: > -- > > Thanks for working on this specification. My revi

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 7, 2023, at 4:08 AM, Éric Vyncke via Datatracker > wrote: > > > > -- > COMMENT: > -- > > > # Éric Vyncke, INT AD, comments for > draft-ietf-dnsop

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker > wrote: > > > -- > COMMENT: > -- > > Thanks for this document and my apologies for being involve

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

> On Sep 20, 2023, at 2:23 PM, Paul Wouters wrote: > > >>> To prevent such unnecessary DNS traffic, security-aware resolvers >>> MUST cache DNSSEC validation failures, with some restrictions. >>> >>> What are these "some restrictions" ? >> >> Here our intention is to update this

Re: [DNSOP] DNS IPv6 Transport Operational Guidelines (draft-momoka-dnsop-3901bis-00)

Hi Momoka, I see that your draft often uses “in-bailiwick” or “out-of-bailiwick”. If you are not already aware, the latest version of the DNS terminology document (draft-ietf-dnsop-rfc8499bis) notes that “bailiwick” should be considered historic at this point. The preferred language is to ref

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

I made a pass through the document and have the following feedback. > Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The > scenario used in that description, that of a recursive server that is > also authoritative, is no longer as common. Since RFC 1034 doesn't use the term "pri

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: > >> As Mark just clarified. This isn't glue, so perhaps the text just needs >> updating. > > The current text is: > > If some root server addresses are omitted from the Additional section, > there is no expectation that the TC bit in the >

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

Paul, Here is some specific proposed text to address the concern that I raised: Whereas the priming response is not a referral, and whereas root server addresses in the priming response are therefore not considered glue records, RFC 9471 does not apply to the priming response. Root servers are

Re: [DNSOP] unrelated name server name recommendation

I understood Fujiwara’s proposal to be slightly different: If you are a DNS provider (hosting other zones) then the provider should use in-domain name servers. DW > On Mar 4, 2024, at 3:14 PM, Paul Wouters wrote: > > On Mar 4, 2024, at 14:04, Paul Vixie > wrote: >> >> >> >> this means a

Re: [DNSOP] [Editorial Errata Reported] RFC9520 (7838)

This errata seems to be valid. I have no idea why the DOI reference changed, but it appears to have changed since it was added to the document in November/December last year. DW > On Mar 5, 2024, at 9:02 PM, RFC Errata System > wrote: > > Caution: This email originated from outside the orga

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

Hi, some initial thoughts: RFC 2181 says "Data from a zone transfer, other than glue” but this draft doesn’t make any exceptions for glue or non-authoritative data from a zone transfer. Is that intentional? Should RFC 8767 stale data be ranked differently than fresh data? Should EDNS Client S

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an RFC. DW > On Mar 5, 2024, at 6:51 AM, Suzanne Woolf wrote: > > Hi, > > We're leaving this open a few more days to allow for any other comments. We'd > like to submit it for publication before IETF 119. > > > T

[DNSOP]Re: Second (short) WGLC for draft-ietf-dnsop-zoneversion

Hi Donald, Thanks for the suggestions. We’ve implemented all your suggested changes in the source document. We’ll wait a few days for any more changes and then publish a new revision. DW > On May 12, 2024, at 1:30 AM, Donald Eastlake wrote: > > Caution: This email originated from outside

[DNSOP] Re: Secdir last call review of draft-ietf-dnsop-zoneversion-06

Hi Shawn, Thank you for the review and comments. We’ve fixed the editorial comments you identified. Regarding “decimal integer” — we use that phrase only when describing the presentation format (versus, say, hexadecimal) so we think it is appropriate. However, we would defer to the advice or su

[DNSOP] Re: Artart last call review of draft-ietf-dnsop-zoneversion-07

> On Jun 9, 2024, at 7:13 AM, John Levine via Datatracker > wrote: > > > > I wonder about the paragraph "A name server MUST ignore any non-empty > ZONEVERSION payload data that might be present in the query message." It's > not > wrong, but why call out this one particular error and not ot

[DNSOP] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)

Hi Paul, thanks for the review. Comments inline… > On Jun 17, 2024, at 4:23 PM, Paul Wouters via Datatracker > wrote: > > > > -- > DISCUSS: > -- > > Just

[DNSOP] Re: [Ext] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)

> On Jun 18, 2024, at 10:49 AM, Paul Hoffman wrote: > > Responding to one bit of Duane's response. > > On Jun 18, 2024, at 10:40, Wessels, Duane > wrote: > >>> What should an authoritative nameserver return as zone version if it is >>> configur

[DNSOP] Re: Roman Danyliw's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)

Hi Roman, I wanted to let you know that we’ve incorporated these changes into the document, even though they weren’t reflected in the -09 version that was posted just the other day. DW > On Jun 18, 2024, at 11:57 AM, Roman Danyliw via Datatracker > wrote: > > > >

[DNSOP] Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)

Hi Murray, I don’t believe your comments have been addressed yet. My apologies for the delay. > On Jun 19, 2024, at 10:13 PM, Murray Kucherawy via Datatracker > wrote: > > > -- > COMMENT: >

[DNSOP] Re: Last Call: (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

> On Jul 4, 2024, at 1:55 AM, Petr Špaček wrote: > > > Unrelated thoughts: > > ### OPCODE > Currently the document sorta implicitly talks about DNS queries - mainly > implied by the structure of section 3.2 and listed possible answer types and > RCODEs. > > Should the document be explicitl

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

All, the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or incorporate the following points recently raised: - Removed from abstract (Roman Danyliw) - RFC 8499 -> RFC 9499 (Roman Danyliw) - Incorporated Joe Abley's proposed text for "enclosing zone" - Instruct responders to return

[DNSOP] Re: Fwd: New Version Notification - draft-ietf-dnsop-domain-verification-techniques-05.txt

I read through draft-ietf-dnsop-domain-verification-techniques-05 and have a few minor comments / suggestions. > this may result in IP fragmentation, which often does not work While it’s true we have come to agree that fragmentation is bad for DNS, I think “often does not work” overstates the

[DNSOP] Re: Dnsdir last call review of draft-ietf-dnsop-zoneversion-10

> On Jul 10, 2024, at 3:09 AM, Nicolai Leymann via Datatracker > wrote: > > The draft is going to be published as Informational RFC. The document is well > written and defines an EDNS option which can be used for debugging purposes. Thank you for the review! Note that as of -09 the intended

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

Hi Philip, thanks for the feedback. > On Jul 16, 2024, at 1:46 AM, Philip Homburg > wrote: > >> the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or >> incorporate the following points recently raised: > > Sorry for the late response. I didn't pay much attention to the actual > w

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

> On Jul 18, 2024, at 11:03 AM, Petr Špaček wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > On 18. 07. 24 17:28, Shane Kerr wrote: >> Petr, >> On 18/07/2024 17.

Re: [DNSOP] proposal: Covert in-band zone data

> On Jul 8, 2019, at 9:20 AM, Joe Abley wrote: > > > As far as this particular idea goes, I mentioned before what had given me > pause: we're talking about taking a protocol where every RRSet in a zone to > date has been public and is made available in DNS responses. Any server that > doesn

Re: [DNSOP] proposal: Covert in-band zone data

> On Jul 8, 2019, at 1:05 PM, Witold Krecicki wrote: > > W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > >> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow >> handling of DNSSEC. That is, covert types should not be included in

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-no-response-issue

> On Jul 17, 2019, at 5:17 AM, Tim Wicinski wrote: > > All > > Since it seems that everyone is now getting their own Flag Day, this > document's time is > now to be published. I want to thank Mark for being so patient with me as > I've > sat through several review sessions, and addressing

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.txt

Greetings DNSOP, AFAICT there was no feedback received after this most recent version of the ZONEMD draft was posted. As I mentioned before, there was one pretty significant change in that version: > The most significant change is that multiple ZONEMD records are allowed. The > document reco

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.txt

Thanks John and Joe, does this text capture what you're suggesting? 4.1. Verifying Multiple Digests If multiple digests are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Digest Type algorithms is sufficient to verify the zone

Re: [DNSOP] Rough notes for an incremental zone digest

Thanks Mukund. For everyone else's benefit, what Mukund and I were discussing is ways to make the ZONEMD algorithm more efficient for large dynamic zones. The authors are intending for that to be future work, and not a part of the current proposal, which has this to say about such zones: As

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

Dear DNSOP, The primary change between -00 and -01 is the simplification of the verification protocol when multiple ZONEMD RRs are present, per the on-list discussions. Additionally Shane Kerr kindly updated his implementation and confirmed that his and the author's implementations produce and

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

zeros state, and other states" > > Saying "must not validate" baldly basically says "will always be zero" to me > -Which I think is what you're saying! > > _G > > On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr wrote: > Duane, > > On 2019-0

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

quot;more than one apex ZONEMD RR with Reserved field equal to zero and the same > Digest Type" and updating later steps such that they apply for each ZONEMD RR > and failures mean "digest verification MUST NOT be considered successful for > that RR". Yes, this is a

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt

Dear DNSOP, Following working group feedback on the -01 version, the draft has been updated to reflect the following changes: 1) Whereas previously the Digest Type field conveyed only the hashing algorithm to be used, now the Digest Type also conveys how the hash value is constructed from the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt

Hello dnsop, This draft has been updated with the following changes since -04: - added DNS-over-TLS to the abstract - added recent discussions about avoiding fragmentation in DNS - changed "SHOULD use TFO" to "MAY use TFO" due to concerns expressed in the WG - changed discussion of KSK rollover t

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt

> On Nov 7, 2019, at 7:56 PM, Vladimír Čunát wrote: > > Hello! > > On 10/28/19 10:32 PM, Wessels, Duane wrote: >> The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to >> reflect that it designed for use on stable (or small) zones where

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-03.txt

Hi All, Based on list feedback and the IETF-106 dnsop meeting, this revision has just two substantive changes: - The mnemonic for digest type 1 has been changed to SHA384-SIMPLE (from SHA384-STABLE). - The intended status has been changed to Standards Track (from Experimental) and the Scope o

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt

> On Dec 2, 2019, at 9:38 PM, Puneet Sood > wrote: > > On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane > wrote: >> >> Hello dnsop, >> >> This draft has been updated with the following changes since -04: >> >> - added DNS-over-TLS to the ab

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt

> On Dec 4, 2019, at 4:05 PM, Paul Vixie wrote: > > > > Wessels, Duane wrote on 2019-12-04 14:22: >> ... >>DNS messages over TCP are in no way guaranteed to arrive in single >>segments. In fact, a clever attacker might attempt to hide certain >>

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

Hello Mike, thanks for the feedback. > On Jan 4, 2020, at 5:14 PM, Michael StJohns wrote: > > Hi Tim et al - > > I read through this back a few versions ago and mostly thought it harmless as > an experimental RFC. I'm not sure that it's quite ready for prime time as a > Standards track RFC.

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: > > As I suggested in one of my messages, giving an idea of how long it takes to > digest various sizes of zones given commodity hardware would be a good start. > Going on and talking about the ratio of that time to the typical update >

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: > >> >> >>> 5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's >>> the same, then this is fine, otherwise this protocol should be calculating >>> the RRSet wire representation the same as DNSSEC does it. >> In my exp

Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

> On Jan 6, 2020, at 6:15 PM, Michael StJohns wrote: > This specification utilizes ZONEMD RRs located at the zone apex. Non-apex ZONEMD RRs are not forbidden, but have no meaning in this specification. >>> Instead - "non-apex ZONEMD RRs MUST be ignored by the recei

Re: [DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

> On Jan 8, 2020, at 12:20 PM, Paul Vixie wrote: > > can we please not put the ZONEMD RR at the apex, or else, can we please add > an > ALG-ID to its rdata. because some day we're going to ship different kinds of > MD's, one of which is today's full-zone traversal-required version that > op

Re: [DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

> On Jan 8, 2020, at 3:55 PM, Michael StJohns wrote: Mike, Thank you for these suggestions. The authors have discussed them. > If the above is what you intended, then sections 3 and 4 should be labeled > "Calculating/Verifying the DIGEST for the SIMPLE scheme", and there should be > some

Re: [DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

> On Jan 15, 2020, at 12:14 AM, Shane Kerr wrote: > > Duane, > > Honestly thinking about it more, I'm not even sure we should consider > supporting an incremental version of zone digests in ZONEMD at all. I could be easily convinced to take that route. The first few revisions of the draft w

Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

> On Jan 15, 2020, at 10:25 AM, Brian Dickson > wrote: > > However, there is a Heisenberg problem, which is that any other digest type > needs to be excluded from the ZONEMD calculation (and vice versa). > > So, from the future-proofing standpoint, I think one of the two methods needs > to

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Hi Hugo, I like this proposal and think that DNSOP should adopt it. I agree that it will prove valuable in debugging. A couple of comments and suggestions: Sections 2 and 3 could be clarified regarding the value for OPTION-LENGTH. I gather the intention is that OPTION-LENGTH is zero for quer

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-04.txt

All, This version of the ZONEMD draft incorporates and addresses the feedback we received from the working group last call. The list of changes is below. Note there is one important change to the RDATA fields that we believe addresses concerns about future proofing. Previously there was a fie

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-04.txt

> On Feb 24, 2020, at 7:32 PM, Michael StJohns wrote: > An improvement, but still: Thanks Mike. > > 1.3 - general - add something like "Specifically, ZONEMD covers the > integrity of records that are not otherwise covered by > DNSSEC". Sorry, I don't quite follow this. There is currentl

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

> On Mar 8, 2020, at 11:10 PM, Dick Franks wrote: > > draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a > number of internal contradictions to be resolved. > > > [1.2 para 1] > > ... The procedures for digest calculation and DNSSEC > signing are similar (i.e., both

Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

> On Mar 9, 2020, at 9:37 AM, Dick Franks wrote: > > >>> [3.1 para 1] >>> >>> In preparation for calculating the zone digest, any existing ZONEMD >>> + and covering RRSIG >>> records at the zone apex are first deleted. >>> >>> [3.1 para 1] >>> >>> Prior to calculation of the digest, and

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

Dear DNSOP, This version of the draft includes just a couple of notable changes from the previous - As suggested by Mike StJohns, All apex ZONEMD RRs are now excluded from the digest calculation. They are now all independent from each other. - The verification procedure was clarified by descr

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

Hi DNSOP, The changes from -05 to -06 of this document include: - addressing mailing list comments (thank Puneet) - spelling, grammar, and punctuation editing pass - added a reference to dnstap DW > On May 6, 2020, at 8:13 AM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is avai

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

The essence of this draft is the addition of once sentence to RFC 1034: "If glue RRs do not fit set TC=1 in the header." I worry that this is too ambiguous. Does it mean all glue? One glue? As much as will fit? AFAIK most software today is designed to fill up the additional section with as

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

> On Jun 5, 2020, at 11:56 AM, Paul Hoffman wrote: > > On Jun 5, 2020, at 10:37 AM, Wessels, Duane > wrote: >> >> The essence of this draft is the addition of once sentence to RFC 1034: >> >> "If glue RRs do not fit set TC=1 in the header." &g

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

> On Jun 5, 2020, at 1:40 PM, John Levine wrote: > > In article <5e86e9ee-a022-44f0-9483-f498a03c3...@verisign.com> you write: >>> The current document is indeed ambiguous. I propose that it be changed to: >>> If all glue RRs do not fit, set TC=1 in the header. >> >> I believe this is contrar

Re: [DNSOP] AD review of draft-ietf-dnsop-dns-zone-digest-08

> On Jul 24, 2020, at 2:19 PM, Barry Leiba wrote: > > I am serving as responsible AD for this document, because Warren is an > author, and so is recused. Here’s my AD review. Most comments are minor, > but I’d like to resolve the ones in Sections 2 and 3.1 before going to last > call, so I

Re: [DNSOP] AD review of draft-ietf-dnsop-dns-zone-digest-08

Barry, We've submitted a new (-09) version of the zone digest draft, which I think addresses your comments. This includes a few simple grammatical changes that you suggested earlier, as well as two clarifications from our conversation below. This -09 version also includes some rearranging of

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09

Hi Elwyn, Thanks for the review! > On Sep 12, 2020, at 3:09 PM, Elwyn Davies via Datatracker > wrote: > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being pr

Re: [DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard

> On Sep 11, 2020, at 1:45 AM, Stephane Bortzmeyer wrote: > > On Thu, Sep 10, 2020 at 03:03:45PM -0400, > Warren Kumari wrote > a message of 62 lines which said: > >> Do you have any suggested text? If so, could you send it to the IETF >> LC so it gets captured? > > Done >

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09

I'm not sure why received messages in this thread are being truncated. The archive has my full response here: https://mailarchive.ietf.org/arch/msg/gen-art/MVl2P81bCi6d5l1QhuNluJZB52g/ DW smime.p7s Description: S/MIME cryptographic signature ___ D

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

Mike & everyone, Here's a response on behalf of the coauthors. > On Sep 21, 2020, at 12:06 PM, Michael StJohns wrote: > > Adding IESG - I didn't realize it was in IESG evaluation. > > I'm not sure why this version was posted as there is nothing on the > datatracker that indicates there were I

Re: [DNSOP] zone contents digest and DNSSEC stuff

> On Sep 29, 2020, at 6:42 AM, libor.peltan wrote: > > Hi Joe, > > Dne 29.09.20 v 15:03 Joe Abley napsal(a): >> The other use case I seem to think you're implying is that a consumer of the >> signed zone could verify that it was intact using the signed-zone ZONEMD, >> then strip the DNSSEC R

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

Hi Roman, thanks for the detailed review and comments. My responses are inline. > On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: Discuss > > When responding, please keep

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

Hi Benjamin, thanks for the extensive review and comments. Responses are inline. As you've noted some of this overlaps with Roman's comments as well. > On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draf

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 6, 2020, at 3:26 PM, Erik Kline via Datatracker > wrote: > > Erik Kline has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: Yes > > > -- > COMMENT: >

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 7, 2020, at 2:47 AM, Éric Vyncke via Datatracker > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > -- > COMMENT: >

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker > wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > -- > COMMENT: > -

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

> On Oct 7, 2020, at 1:52 PM, Roman Danyliw wrote: > > > In that case (where no assumptions are made about the transport), it seems > that only these scenarios from the list above apply: > > With an on-path attacker (and trusted server hosting the zone file) > > ** No DNSSEC = integrity: N

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 9, 2020, at 12:08 PM, Ben Schwartz wrote: > > > 6.2. Use of Multiple ZONEMD Hash Algorithms > >When a zone publishes multiple ZONEMD RRs, the overall security is >only as good as the weakest hash algorithm in use. > > Why not require recipients to verify all digests with re

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 7, 2020, at 11:55 PM, Murray Kucherawy via Datatracker > wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: No Objection Hi Murray, thanks for the comments. > > -

Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)

> On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-13: Yes > > > -- > COMMENT: > ---

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

> On Oct 12, 2020, at 9:24 AM, Roman Danyliw wrote: > > Hi Duane! > > Thanks for the extensive changes in -13. They address my concerns. I have > left one remaining comment about clarifying "provably secure" with a > reference. Otherwise, I've cleared my ballot. Thanks Roman, Instead of

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

> On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton) > wrote: > > > >> >>> >>> 2. The ZONEMD Resource Record >>> >>> It is >>> RECOMMENDED that a zone include only one ZONEMD RR, unless the >> zone >>> publisher is in the process of transitioning to a new Scheme or >> Has

  1   2   3   >