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 deleg

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 E

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 kno

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 i

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 se

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 the

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 > sta

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 wrote: > > > > 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

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 wrote: > > > > 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 ne

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 OpenDNS Quad9 > COTS: Nominum

Re: [DNSOP] raising the bar: requiring implementations

Bert, On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote: > On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote: > > I'd raise the bar even higher, to see complete implementation in a major > > open source DNS implementation when it applies. Sometimes implementation > > probl

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

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. > > Changes

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: > > > > https://tools.ietf.org/html/draft-mekking-mixfr-02 > > The dra

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." > > then

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

On Fri, Mar 23, 2018 at 01:22:42PM -0400, Bob Harold wrote: > On Fri, Mar 23, 2018 at 1:19 PM, Paul Hoffman wrote: > > > +1 to the title “A Root Key Trust Anchor Sentinel for DNSSEC”. > > > > +1 to option #2 with the spelling correction. > > > > --Paul Hoffman > > > > > +1 Agree with both. But

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 swi

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 ED25519/ED448

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 document is > > intended to su

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 summarized why Mark and me agree >

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 i

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 that

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 very

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

On Fri, Jan 16, 2015 at 09:58:32AM -0800, Paul Vixie wrote: > > > Olafur Gudmundsson > > 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

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 thi

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 > crack

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 l

Re: [DNSOP] On resolver priming

On Thu, Nov 11, 2010 at 05:03:51AM -0500, Andrew Sullivan wrote: > Hi all, > > The last discussion of signing ROOT-SERVERS.NET involved the arguments > that there's no real value in signing the zone and that there is a > non-zero cost to doing so. > > I agree with both of those arguments, but I w

Re: [DNSOP] A different question

Matt, In general I agree with you that due diligence is required and I would not expect anything different from that, remember how long it take us to include glues at the root. On Fri, Aug 22, 2008 at 09:41:21AM -0400, Matt Larson wrote: > On Fri, 22 Aug 2008, Mark Andrews wrote: > > Eve

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 > >DNS

Re: [DNSOP] Cache poisoning on DNSSEC

On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote: > On Tue, 19 Aug 2008, Ted Lemon wrote: > > > On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote: > > > A verifying > > > DNSSEC cache can be poised with bad glue records using the poisoning > > > attack, with only a slight change to the

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

On Wed, Aug 20, 2008 at 11:17:38AM +0200, Alexander Gall wrote: > On Tue, 19 Aug 2008 15:43:14 -0400, Andrew Sullivan <[EMAIL PROTECTED]> said: > > > On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote: > >> it in their products or services. Peter Koch did provide an interesting > >> da

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 ben

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 > entire

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

[DNSOP] reflectos-are-evil proposed changes for -05

This 05pre version address most of discuss raised during last-call as presented during the IETF70 meeting. ftp://ftp.registro.br/pub/drafts/draft-ietf-dnsop-reflectors-are-evil-05pre.txt ftp://ftp.registro.br/pub/drafts/draft-ietf-dnsop-reflectors-are-evil-05pre-from-4.diff.html This and other m

Re: [DNSOP] Always registering the IP address of the name servers during a delegation?

Bill, On Tue, Nov 27, 2007 at 08:57:13PM +, [EMAIL PROTECTED] wrote: > On Tue, Nov 27, 2007 at 02:05:55PM -0500, Edward Lewis wrote: > > At 6:25 PM + 11/27/07, [EMAIL PROTECTED] wrote: > > > > > then we have a small issue... you as zone admin, can't > > > dictate which IP's i must us