Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)

Paul, On Wed, Nov 01, 2023 at 12:38:09AM +0100, Paul Wouters wrote: > On Oct 31, 2023, at 19:17, Frederico A C Neves wrote: > > > > Dear David, > > > > Section 7 of the draft is sufficiently clear, precise, and complete. > > > > This registration

Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)

Dear David, On Tue, Oct 24, 2023 at 07:39:27PM +, David Dong via RT wrote: > Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG), > > As the designated experts for the Underscored and Globally Scoped DNS Node > Names registry, can you review the proposed registration in

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

On Mon, May 01, 2023 at 04:43:11PM +, Wessels, Duane wrote: > 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

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

On Sat, Apr 15, 2023 at 11:20:13AM +1000, Mark Andrews wrote: > At this stage I think the only way to force this is to drop negative > responses without SOA records present. To have the lookups fail and > that requires buy in by the large recursive server operators. > > Similarly add an unknown

Re: [DNSOP] RFC5155 and hash collision vs RFC9276

On Tue, Jan 17, 2023 at 01:56:04PM +0100, Otto Moerbeek wrote: > Hi, > > I was wondering about RFC9276 which says: "SHOULD NOT use salt", while > RFC5155 section 7.1. says: > > "If a hash collision is detected, then a new salt has to be chosen, > and the signing process restarted." > > Now I

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

On Fri, May 07, 2021 at 01:39:56PM -0400, John Levine wrote: > It appears that Hugo Salgado said: > >-=-=-=-=-=- > > > >I'll upload a new version to revive it, and ask for a slot > >in IETF111 for further discussion! > > It looks like it's worth considering, but I also wonder how > relevant it

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

Hi Shumon, On Tue, Jan 21, 2020 at 10:05:56AM -0500, Shumon Huque wrote: > Hi Matthijs, > > Sorry, I did miss your original note on this point. Now that I've seen it, > I'm copying back dnsop@ietf.org to see if there are other comments on your > proposal. > > When the Algorithm Considerations

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec

Shane, On Wed, Nov 20, 2019 at 04:52:22PM +0100, Shane Kerr wrote: > Benno and all, > > Overall the document is clear and I hope helpful to organizations > pursuing a multi-DNS vendor setup who want to use DNSSEC (as all do, I > am sure). > > One minor thing I noticed while looking through

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

On Mon, Mar 25, 2019 at 04:30:01PM +0100, Ray Bellis wrote: > > > On 25/03/2019 16:08, Puneet Sood wrote: > > > you mean lots of changes or lots of agreement with the quoted text? > > They mean very different things. > > I was agreeing with the quoted text - I believe that any serving of >

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

On Fri, Jul 06, 2018 at 08:26:59PM -0400, Tim Wicinski wrote: > We've had some interest in moving this document forward, and the chairs > wanted to kick off this Call for Adoption before Montreal so if there > are concerns there will be some meeting time to address. > > This document is label as:

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On Thu, May 03, 2018 at 10:27:30PM +, David Huberman wrote: > Mark Andrews stated: > > >It’s amazing how fast people can fix lame delegations once email and other > >services stop flowing. The only reason you think it is un- winnable is that > >you > >are unwilling to remove the delegation

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Hi Matthijs, On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote: > Hi Frederico, > > On 03/29/2018 08:45 PM, Frederico A C Neves wrote: > > I was looking at our server to evaluate the MIXFR implementation and > > it seams to me that the current text coverin

[DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

I was looking at our server to evaluate the MIXFR implementation and it seams to me that the current text covering dnssec aware client logic don't take in account that a posterior record at the addition section, by an MIXFR DNSSEC aware server, will implicitly replace the RRSIG RRset. Logic could

Re: [DNSOP] A new version of mixfr

On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote: > > > On 29 Mar 2018, at 9:05 am, Frederico A C Neves <fne...@registro.br> wrote: > > > > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote: > >> On Thu, Mar 29, 2018 at

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote: > > One comment, > > > > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text > > regarding NSEC3PARAM update as well. > > > > For that I suggest to change 3.1 section name and include an extra > > paragraph. > >

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote: > On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote: > > No. You can have multiple nsec3 chains in a zone at the same time. Only one > > is active. Some may be incomplete. > > > > Named

Re: [DNSOP] A new version of mixfr

rk Andrews > > > On 29 Mar 2018, at 02:06, Frederico A C Neves <fne...@registro.br> wrote: > > > > Hi Matthijs, > > > >> On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote: > >> All, > >> > >> It's been a while

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > bert hubert wrote: > > > > Well to allow the one remaining closed source DNS implementation some room, > > authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign > recursive services: Google

Re: [DNSOP] A new version of mixfr

Hi Matthijs, On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote: > All, > > It's been a while, but I have put up a new version of the MIXFR draft: > > https://tools.ietf.org/html/draft-mekking-mixfr-02 > > The IETF 101 Hackathon lead to the revival of this draft. > >

Re: [DNSOP] A new version of mixfr

On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote: > Hi Matthijs, > > On Wed, 28 Mar 2018 15:31:57 +0200 > Matthijs Mekking wrote: > > > It's been a while, but I have put up a new version of the MIXFR draft: > > > >

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

Paul, On Fri, Mar 23, 2018 at 11:00:03AM -0700, Paul Vixie wrote: > i'm concerned about the age-old human protocol being employed here. > > first one guy shouts bikeshed! (usually somebody who's been bikeshedding.) > > nextly, some folks say "the details don't matter, only uniqueness." > >

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On Fri, Mar 23, 2018 at 03:58:02PM +, Viktor Dukhovni wrote: > On Thu, Mar 22, 2018 at 01:27:38PM -0400, Paul Wouters wrote: > > > I think this text also needs an update: > > > > RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones > > deploying it are recommended to

Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

On Thu, Mar 22, 2018 at 05:47:58PM +, Ondřej Surý wrote: ... > > They should switch away from SHA1 as SHA1 is being deprecated industry > > wide. Even if we recommend to move away from RSA (which I'm not sure if > > there > > is consensus on) to ECC, I would like to move them to

Re: [DNSOP] Question about usage of ip6.arpa and in-addr.arpa

On Tue, Mar 13, 2018 at 11:16:56AM -0400, Joe Abley wrote: > On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker > wrote: > > > After a number of discussions I’m interested in returning to the original > > concept as it simplifies a number of use cases that this

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

On Mon, Nov 13, 2017 at 03:45:30PM +, Edward Lewis wrote: > On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" behalf of e...@isc.org> wrote: > > >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > >> Nice write-up Edward! You have nicely

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

Jakob, On Tue, Mar 14, 2017 at 09:04:53AM +0100, Jakob Schlyter wrote: > This draft should be of interest to this WG, providing an alternative to > draft-wouters-sury-dnsop-algorithm-update. > > jakob > > > https://tools.ietf.org/html/draft-arends-dnsop-dnssec-algorithm-update-00 This

Re: [DNSOP] Updated NSEC5 protocol spec and paper

On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote: ... > > Apparently there are many folks in the community who think so, otherwise > NSEC3 would not have been developed. I personally don't care for any zones I know others have already stated this but zone enumeration, at least at

Re: [DNSOP] Asking TLD's to perform checks.

On Wed, Nov 11, 2015 at 07:25:39AM +0100, Patrik Fältström wrote: ... > > That said, initiatives like the one I did run did push errors (for some > definition of errors) from 22% to maybe 17% in .SE and my inspection of the > rest say that getting errors down to 15% is possible, but more is

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

On Fri, Jan 16, 2015 at 09:58:32AM -0800, Paul Vixie wrote: Olafur Gudmundsson mailto:o...@ogud.com Friday, January 16, 2015 7:51 AM ... One of the oldest ideas on that was from Andreas Gustafsson was to wrap XFR transmission inside compressed transmission. late BIND4 and early

Re: [DNSOP] Call for Adoption: draft-eastlake-dnsext-cookies

On Thu, Nov 13, 2014 at 04:55:36PM -1000, Tim WIcinski wrote: DNSOP WG, This starts a call for adoption for draft-eastlake-dnsext-cookies. The draft is available here: https://datatracker.ietf.org/doc/draft-eastlake-dnsext-cookies/ Please review this draft to see if you think it is

Re: [DNSOP] key lengths for DNSSEC

Nicholas, On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote: ... And please don't discount the psychology of the issue. If DNSSEC wants to be taken seriously, it needs to show it. Using short keys for root and the major TLDs, under the assumptions that it can't be cracked

Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

On Fri, Mar 07, 2014 at 03:03:40AM +0900, fujiw...@jprs.co.jp wrote: ... I would like to know whether the increase of DS queries are observed commonly or not. (with small NCACHE TTL value) We are observing around the same % of qps but still need to confirm the other characteristics. Fred

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

On Fri, Mar 30, 2012 at 10:19:43AM +, Ray Bellis wrote: On 30 Mar 2012, at 12:09, Ond??ej Surý wrote: Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the

Re: [DNSOP] A different question

On Thu, Aug 21, 2008 at 09:47:38AM -0700, David Conrad wrote: ... If the root zone were to strobe between signed and unsigned, what minimum duration of signed, and what maximum duration of unsigned would be likely to not cause operational problems for the aforementioned DNSSEC-configured

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote: Hi, On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote: But until we have root and .com signed, and until the average end- user is protected by a validating resolver, we aren't done yet, and I don't really get any actual benefit

Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt

Mr. Anderson, On Sat, Jun 28, 2008 at 05:36:04PM -0400, Dean Anderson wrote: A number of the points you raise have already been addressed. The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely

Re: [DNSOP] AS112 for TLDs

On Fri, Apr 04, 2008 at 11:19:58AM -0400, Andrew Sullivan wrote: On Fri, Apr 04, 2008 at 07:37:31AM -0700, David Conrad wrote: ... I can just imagine the hue and cry that would happen when new top level domains don't work for everybody. Or in a future, actually very far from today, when DS