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.
>
>
>
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
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
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
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
> 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
>
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
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
> 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
> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker
> wrote:
>
>
> --
> COMMENT:
> --
>
> Thanks for this document and my apologies for being
> On Sep 7, 2023, at 4:08 AM, Éric Vyncke via Datatracker
> wrote:
>
>
>
> --
> COMMENT:
> --
>
>
> # Éric Vyncke, INT AD, comments for
>
> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker
> wrote:
>
>
>
> --
> COMMENT:
> --
>
> Thanks for working on this specification. My
> On Sep 6, 2023, at 11:46 PM, Murray Kucherawy via Datatracker
> wrote:
>
>
> --
> COMMENT:
> --
>
> Thanks to Barry Leiba for his ARTART review.
>
> I
> 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
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
> 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
>
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
> 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
> 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
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
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
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
>
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
> 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
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
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
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
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
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
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
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
> 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 >
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
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
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
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
Hi Petr, thank you for the feedback!
> On Jul 28, 2022, at 5:06 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 27. 07. 22 19:42,
I support the adoption of this draft.
I think there is value in keeping the specific examples (with named companies,
etc) but agree with John that placing them in an appendix would be better.
DW
> On Jul 12, 2022, at 6:29 AM, Tim Wicinski wrote:
>
>
>
> This starts a Call for Adoption for
Hi Mukund,
> On Jul 12, 2022, at 8:24 AM, Mukund Sivaraman wrote:
>
> Some comments quickly browsing this draft, as we're handling a quirky
> issue around NS timeouts and it looked relevant.
>
> Firstly, some resolver implementations do cache upstream NS timeouts in
> various non-standard
> On Apr 25, 2022, at 8:56 AM, Hugo Salgado wrote:
>
> Thank you very much Duane for the changes. For my part, the paragraph
> on the requirements on data in zones and registries seems perfect.
>
> I also find the new way of mentioning glues for in-domain/sibling
> domain name servers
There are three noteworthy changes from the previous version of this draft:
1. We no longer use the term “referral glue”.
2. Instead of introducing new (and likely confusing) terms such as “sibling
glue” and “in-domain glue” we now refer to these as “glue for sibling domain
name servers” and
> On Mar 22, 2022, at 6:02 AM, Ralf Weber wrote:
>
> Moin!
>
> So to follow up on my comment in the working group on registries not having
> anything to do with it. I understand that this drafts is for authoritative
> name server implementers, however I think that we should make clear that
Hi Eugène, I read through the draft and have a few suggestions for you to
consider:
1) The CRS and CRC RDATA fields have a lot in common with TXT records. On one
hand you might find some benefits from making these new RR types have the same
parsing, wire format, and presentation format as TXT
> On Mar 30, 2022, at 1:27 PM, Raymond Burkholder wrote:
>
>
> Hello,
>
> There once was a link posted to a web site which attempted to collect/collate
> all the RFCs referencing DNS. Is this the one: https://rfcs.io/dns Or is
> there another?
>
Some others:
> On Mar 24, 2022, at 4:07 PM, Tim Wicinski wrote:
>
>
> All
>
> If you attended the most recent DNSOP session, you've heard Warren speak
> about creating a BCP for DNSSEC, including all of the DNSSEC related RFCs,
> in order to make life easier for implementers and DNS operators.
>
>
Hi Paul,
I think this is good.
Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in
PowerDNS, and they used the next unused algorithm number rather than a private
algorithm? If the authors of that work are on this list I would be interested
to hear from them about
Hello DNSOP,
Here is a short summary of the changes between -03 and -04 of this draft:
We use "referral glue" on the assumption that other types of glue may be
defined in the future. Not all authors necessarily like this change but we are
trying it on for size.
Added an Operational
the same topic - this new one and
> draft-moura-dnsop-negative-cache-loop.
>
> Perhaps authors could discuss if they are in agreement and could pick one?
>
> Petr Špaček @ Internet Systems Consortium
>
>
>
> On 14. 01. 22 19:14, Wessels, Duane wrote:
>&g
Dear DNSOP,
In light of some recent events and research, we feel that it could be
beneficial to strengthen the requirements around negative caching of DNS
resolution failures. Please see the recently submitted Internet Draft
referenced below and let us know if you have any feedback.
DW
to work, perhaps similar to TsuNAME-style external delegation
cycles.
2. increases response sizes, truncation probability, and amount of TCP.
DW
> On Oct 11, 2021, at 4:51 PM, Wessels, Duane wrote:
>
> Dear DNSOP,
>
> Changes to this draft from the previous version
hCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11
> for some further edits to the text for discuss point (1).
>
> On Mon, Nov 08, 2021 at 10:35:21PM +, Wessels, Duane wr
> On Dec 23, 2021, at 10:28 AM, Benjamin Kaduk wrote:
>
>
> Hi Duane,
>
> On Mon, Nov 29, 2021 at 11:53:48PM +0000, Wessels, Duane wrote:
>>
>>
>>> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker
>>> wrote:
> [...]
>&g
> On Dec 15, 2021, at 5:31 PM, Paul Wouters wrote:
>
> On Dec 15, 2021, at 18:56, Wessels, Duane
> wrote:
>>
>> For me “necessary” is an important distinction and “might be useful” is too
>> broad or ambiguous. I have a hard time reconciling the idea
ke this definition. However, I think it would be clearer to say "useful"
> instead of "necessary".
>
> On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane
> wrote:
> Despite what the subject line says, I’d like to follow up on the discussion
> abou
Despite what the subject line says, I’d like to follow up on the discussion
about glue from today’s interim meeting.
First, I think the definition of glue given in RFC 2181 is problematic in a
number of ways. It is overly broad (e.g., "any record ... that is not properly
part of that zone”
> On Nov 29, 2021, at 11:51 PM, Lars Eggert wrote:
>
>
>> I dont necessarily agree that operating systems alone do a very good job
>> of preventing DOS conditions. It is possible that Im not up-to-date on
>> the latest and greatest in terms of operating system features, but I think
>>
> On Nov 8, 2021, at 4:24 PM, Joe Abley 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 Nov 8, 2021, at 17:35, Wes
> On Oct 26, 2021, at 4:35 AM, Lars Eggert 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.
>
> Lars Eggert has entered the following ballot
John, thanks for the review.
> On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker
> wrote:
>
>
>
> --
> COMMENT:
> --
>
> Thanks for the
Hi Éric, thank you for the review!
> On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker
> wrote:
>
> --
> COMMENT:
> --
>
> Thank you for the work
> On Nov 1, 2021, at 3:29 PM, Erik Kline 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.
>
>>> [S4.1, comment]
>>>
>>> * "Resolvers and other DNS clients
Francesca, thank you for the review.
> On Oct 28, 2021, at 2:43 AM, Francesca Palombini via Datatracker
> wrote:
>
>
>
> I only have one very minor comments, to take or leave as you please:
>
> headers are 40 bytes (versus 20 without options in IPv4). Second, it
> seems as though some
Erik, thanks for the review
> On Oct 26, 2021, at 1:09 PM, Erik Kline via Datatracker
> wrote:
>
>
>
> --
> COMMENT:
> --
>
> [abstract vs. S1/S3,
Lars, thank you for the review.
Some of your easier comments and suggestions have been addressed, but for some
of them will require more thought and attention. I am waiting to coordinate
with my coauthor, and possibly the WG chairs.
> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker
Hi Roman, thanks for the review. My responses are inline.
> On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker
> wrote:
>
>
>
> --
> DISCUSS:
> --
> On Oct 28, 2021, at 7:16 AM, Roman Danyliw wrote:
>
>
> [snip]
>
>> 3. Section 6 says applications should perform “full TCP segment reassembly”.
>> What does that mean? A quick google search doesn’t suggest it’s a well-known
>> term of art. I'm guessing that what you mean is that the
This version of draft-ietf-dnsop-dns-tcp-requirements includes a number of
changes made in response to GENART, SECDIR, ARTART, and TSVART reviews. The
notable changes are:
- added RFC 1536 as a document that this one updates
- new section 2.6. Reuse, Pipelining, and Out-of-Order Processing
-
Dear DNSOP,
Changes to this draft from the previous version are as follows:
* Clarified scope to focus only on name server responses, and not
zone/registry data.
* Reorganized with section 2 as Types of Glue and section 3 as
Requirements.
* Removed any discussion of
> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind wrote:
>
> Thanks for the updates! One quick comment below.
>
>> On 7. Sep 2021, at 18:23, Wessels, Duane wrote:
>>
>>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker
>>> wrote:
>>
> On Sep 3, 2021, at 5:29 PM, Jean Mahoney 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: Jean Mahoney
> Review result: Ready
Dan, thanks for the review. Responses are inline.
> On Sep 1, 2021, at 3:12 AM, Dan Romascanu via Datatracker
> wrote:
>
>
> Minor issues:
>
> 1. In Section 4.1:
>
>> DNS clients MAY also enable TFO when possible.
>
> Maybe I do not fully understand the intent here, but 'MAY ... when
> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker
> wrote:
>
>
>
> First a minor comment here:
> "TCP connection timeout, which is often around 60-120 seconds."
> I guess this value relates to an RTO of 1s and 6 SYN retries which is the
> default in Linux. Maybe say that...? I
> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind 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: Mirja Kühlewind
> Review result:
Thanks Warren, I made all of your proposed changes. Here's a rewrite of the
DNS wedgie paragraph:
Networks that filter DNS over TCP may inadvertently cause problems
for third-party resolvers as experienced by [TOYAMA]. For example, a
resolver receives queries for a moderately popular
This revision only addresses a small number if "idnits".
DW
> On Jun 11, 2021, at 9:59 AM, 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 WG of the IETF.
>
Dear DNSOP,
John and I have made a number of changes since the start of Working Group Last
Call, thanks to your good feedback. Here's a summary of the noteworthy changes
since -06:
- The abstract emphasizes this document speak to operational requirements, in
alignment with previously
> On May 10, 2021, at 5:44 PM, Mark Andrews wrote:
>
>
>> On 11 May 2021, at 09:20, Paul Hoffman wrote:
>>
>> On May 10, 2021, at 4:14 PM, Mark Andrews wrote:
>>> Actually, the process problem is that record format keeps changing AFTER
>>> the code point has been assigned and the record
> On Apr 22, 2021, at 11:50 AM, Donald Eastlake wrote:
>
>
> Hi,
>
> This is a good document and I support publication.
>
> However, I do have some comments. I scanned the Last Call comments by
> others, and they mostly seem like improvements, but some of my
> comments below may duplicate
> On Apr 21, 2021, at 4:39 PM, Wessels, Duane
> wrote:
>
>> 2.2:
>>
>> DNSSEC originally specified in [RFC2541]
>>
>> I thought this should be RFC 2535 rather than the operational guidelines?
>
> Sure, 2535 works for me.
>
Oops, correcti
> On Apr 19, 2021, at 9:34 AM, Peter van Dijk
> wrote:
>
>> This message starts the Working Group Last Call for
>> draft-ietf-dnsop-tcp-requirements
>>
> On Apr 19, 2021, at 8:45 AM, Tony Finch wrote:
>
> Suzanne Woolf wrote:
>>
>> This message starts the Working Group Last Call for
>> draft-ietf-dnsop-tcp-requirements
>
> I have read the draft and I am keen to see it published. Just the other
> day I was having a discussion about whether
> On Apr 19, 2021, at 4:31 AM, Joe Abley wrote:
>
>
> Hi Suz,
>
> On 18 Apr 2021, at 19:17, Suzanne Woolf wrote:
>
>> This message starts the Working Group Last Call for
>> draft-ietf-dnsop-tcp-requirements
>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/)
>
>
the zone. Section
> 2 is describing the format of the record itself, not the process of
> validation, so I would expect the specific text in 2.2.3 to be applicable to
> parsing the record, not validating it.
>
> Thanks,
> Brian
>
>> On Feb 11, 2021, at 10:25 AM, Wessel
Brian,
Thank you for reporting this. Indeed this example SHA384 digest should have 48
octets, although the A.3 example zone as a whole is still valid because a
verifier will either exclude the ZONEMD RR in question either because of the
private-use scheme or because it is truncated. Since
> On Feb 3, 2021, at 3:24 PM, Michael StJohns 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 2/3/2021 2:31 PM, Paul Hoffman wrote:
>> On Jan 29, 2021, at
All,
I have a few comments, focusing on the algorithm in section 3.
> 3. Algorithm to Perform QNAME Minimisation
>
> This algorithm performs name resolution with QNAME minimisation in
> the presence of zone cuts that are not yet known.
>
> Although a validating resolver already has
Rob
>
>> -Original Message-
>> From: iesg On Behalf Of Wessels, Duane
>> Sent: 14 October 2020 13:35
>> To: Rob Wilton (rwilton)
>> Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski
>> ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG
>>
> 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
>>
> 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
> 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:
>
> 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.
>
>
> 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
> 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:
> 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:
>
> 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:
>
> 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:
>
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
>
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
> 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
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
1 - 100 of 235 matches
Mail list logo
