Re: [DNSOP] [IANA #1285115] expert review for draft-ietf-dnsop-dns-error-reporting (DNS EDNS0 Option Codes (OPT))

This specification is complete and clear Status: Approved Ólafur > On Oct 24, 2023, at 3:36 PM, David Dong via RT > wrote: > > Dear Olafur Gudmundsson (cc: dnsop WG), > > As the designated expert for the DNS EDNS0 Option Codes (OPT) registry, can > you review the

[DNSOP]Re: [IANA #1365805] expert review for draft-ietf-dnsop-zoneversion (dns-parameters)

of this document did a great job Olafur > On Jun 5, 2024, at 12:35 PM, David Dong via RT > wrote: > > Dear Olafur Gudmundsson (cc: dnsop WG), > > As the designated expert for the DNS EDNS0 Option Codes (OPT) registry, can > you review the proposed registratio

[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC

> On Jul 26, 2024, at 20:02, Paul Wouters wrote: > > > >> On Jul 26, 2024, at 16:08, Mark Andrews wrote: >> >> >> Even if we where to go with one failure is allowed we still need to >> write down the new rules and there will be complaints that we are >> retrospectively changing the rules.

Re: [DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis

Hi Scott, some nits below > On Jul 8, 2019, at 3:00 PM, Hollenbeck, Scott > wrote: > > I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to > propose some additional text for the Security Considerations section in the > spirit of this sentence from the abstract: > > "Futur

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

> On May 11, 2020, at 1:41 PM, Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for dr

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

istake. I think NOT publishing this document at all would be a BAD thing. I support adoption and will review and continue to agrue against standards track. > tim > Olafur > > On Tue, May 12, 2020 at 9:35 PM Olafur Gudmundsson <mailto:o...@ogud.com>> wrote: >

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

Thom As I have before stated in the past, adding new DNSSEC algorithm is bad for interoperability, I oppose the adoption of this document unless there are better reasons put forward why this algorithm is better than the 4 ECC algorithms that have been standardized so far. Better in this case

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman wrote: > > On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: >> The 2nd registry >> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms >> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 >> >>

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On Dec 25, 2020, at 3:27 PM, Paul Hoffman wrote: > > On Dec 24, 2020, at 10:28 AM, Daniel Migault > wrote: >> >> Hi, >> >> As the DNS is a global shared resource and its reliability is based on >> **all** pieces of software adhering a common standard, I am inc

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I guess I support the document but would like it to say “Please do not use NSEC3 but if you have to use NSEC3 use it use these settings” The document should point how trivial it is to expose most names in NSEC3 signed zone using Graphics cards and dictionaries. Olafur > On May 10, 2021, at

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

> On Aug 4, 2021, at 11:29 AM, Tim Wicinski wrote: > > > All > > This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ >

Re: [DNSOP] nsec3-parameters opinions gathered

Publishing iteration count higher than 10 is reckless as that affects the performance of recursive resolvers in particular the ones that run on small CPE equipment. The document should strongly discourage any use of NSEC3 For the that want to keep using it the limit should be real low of wha

Re: [DNSOP] Multi Provider DNSSEC Models

> On Mar 21, 2018, at 8:35 AM, Shumon Huque wrote: > > On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch > wrote: > > On 20 Mar 2018, at 11:50, Shumon Huque > wrote: > >> We've posted a new draft on Multi Provider DNSSEC models, >> which we're planni

Re: [DNSOP] DNS Camel Viewer

> On Mar 26, 2018, at 4:15 AM, Matthijs Mekking wrote: > > Nice viewer :) > > What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 are a > Proposed Standard, and RFC 5011 is an Internet Standard. In fact, RFC 5011 is > the only DNSSEC Internet Standard. That can't be right,

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

> On Jun 22, 2018, at 6:58 AM, Petr Špaček wrote: > > On 21.6.2018 22:31, Hugo Salgado-Hernández wrote: >> On 22:09 21/06, Shane Kerr wrote: Dne 1.6.2018 v 12:51 Shane Kerr napsal(a): Hmm, can you share some details about your experience? Did you find out when the data corr

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

> > in-band is great. but, sometimes, its really hard. > > So how about use of a PGP key which is a payload in TXT signed over by > the ZSK/KSK so the trust paths bind together? > > fetch one DNS record +sigs, check against the TA (which has to be a > given) and then..

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Camel says ? Olafur >> On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson wrote: >> >> >> >>> On Jun 22, 2018, at 6:58 AM, Petr Špaček wrote: >>> >>> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote: >>>> On 22:09 21/06, Shane Ker

Re: [DNSOP] The EDNS Key Tag Option

> On Jul 29, 2015, at 8:09 PM, Wessels, Duane wrote: > > Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged > me to finish and submit what I think may be a better method for tracking > trust anchor updates. I've described an edns-key-tag option, which puts > trust anchor

Re: [DNSOP] The EDNS Key Tag Option

if the “local” resolver set is using expected TA’s, and if it is not enable “user” to complain. Olafur > > DW > > From: Olafur Gudmundsson [o...@ogud.com] > Sent: Wednesday, July 29, 2015 9:19 PM > To: Wessels, Duane > Cc: IETF DNSOP WG > Subject: Re: [DNSOP] The EDNS Ke

Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views: IPR issues

cek wrote: >> On 25.8.2015 17:34, Petr Spacek wrote: >>> On 26.6.2015 22:45, Olafur Gudmundsson wrote: >>>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote: >>> [...] >>>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic&quo

Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

> On Nov 5, 2015, at 9:55 PM, Shane Kerr wrote: > > Dear dnsop working group, > > On Thu, 05 Nov 2015 17:20:18 -0800 > IETF Secretariat wrote: > >> The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state >> Candidate for WG Adoption (entered by Tim Wicinski) >> >> The document is avai

Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt

> On Nov 2, 2015, at 12:28 AM, Woodworth, John R > wrote: > > See inline comments: > >> -Original Message- >> From: Edward Lewis [mailto:edward.le...@icann.org >> ] >> Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt >> >> Process wise

Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

> On Dec 27, 2015, at 11:40 PM, John Levine wrote: > >>> NEW >>> For instance, some authoritative name servers embedded in load >>> balancers reply properly to A queries but send REFUSED to NS queries. >>> This behaviour violates the DNS protocol (see Section ??? of [RFC??], >>> and impr

[DNSOP] SecDIr review: draft-holmberg-dispatch-pani-abnf-02

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just li

Re: [DNSOP] IPR Disclosure Red Hat, Inc.'s Statement about IPR related to draft-ietf-dnsop-dnssec-roadblock-avoidance and This disclosure relates to text amendment proposed in http://www.ietf.org/mail

Petr, I’m sorry I failed to include this in the 03 update of the roadblock draft issued 2 weeks ago. A new version that includes your text slightly edited was just submitted as 04. Version 04 only contains textual clarifications and corrections in addition to the valuable contribution from Re

Re: [DNSOP] draft-ietf-dnsop-maintain-ds adding vs. deleting DS, and document track

> On Apr 6, 2016, at 3:50 PM, Shane Kerr wrote: > > Hello, > > RFC 7344 left out the problems of deletion and addition because they > were scary. > > I think that the draft-ietf-dnsop-maintain-ds document is quite clear > about deleting DS records, and I think it makes sense. > > However, in

Re: [DNSOP] draft-ietf-dnsop-maintain-ds adding vs. deleting DS, and document track

> On Apr 7, 2016, at 5:33 PM, John Levine wrote: > >> We could have written >> “After observing CDS records for 15 days or 2 resigning cycles which ever is >> longer, accept them and upload DS” >> Is that better ? >> It sets expectations > > I think my users (the ones who know about DNSSE

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

Thanks Bob fixed in my repo Olafur > On Apr 5, 2016, at 9:42 AM, Bob Harold wrote: > > > On Sun, Apr 3, 2016 at 11:25 PM, Ólafur Guðmundsson > wrote: > > Dear colleagues, > a new version of the document has been posted that fixes few minor > grammatical and sp

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

> On Apr 7, 2016, at 11:40 AM, Jacques Latour wrote: > > Read it, like it, and > > >3.1 ... The parent retrieves the CDS and inserts the corresponding DS RRset > >as requested, > > I think the parent can accept the CDS and insert the DS RRset as requested or > as per Parent policy. > > Mea

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

I have read the draft and support its adoption Olafur > On Apr 10, 2016, at 10:18 AM, Tim Wicinski wrote: > > This was discussed in Buenos Aires Friday morning, but the sense we received > from the room is that the group should move forward with this draft. While > we like the simplicity of

Re: [DNSOP] Olafur's "black lies" presentation

> On Apr 8, 2016, at 11:08 AM, Ray Bellis wrote: > > > > On 08/04/2016 11:39, Edward Lewis wrote: >> I can't find a draft to cite for this talk, so this refers to the slides >> presented. >> >> "DNSSEC Protocol Modifications" >> (http://www.rfc-editor.org/rfc/rfc4035.txt) has an explicit proh

Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

> On Nov 14, 2016, at 5:01 PM, Ondřej Surý wrote: > > > - Original Message - >> From: "Edward Lewis" >> To: "Ondřej Surý" >> Cc: "dnsop" >> Sent: Monday, 14 November, 2016 08:31:51 >> Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00 > >> I'm a little confus

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking wrote: > > Hi, > > I have read the draft and have two comments. Both of these have been called > out before, but I don't see them addressed in this version (-03): > > 1. In case of a DNS responder selecting one or a subset of the RRsets at the

Re: [DNSOP] DNSSEC operational issues long term

> On Nov 16, 2016, at 5:05 AM, George Michaelson wrote: > > On the current timeline, October 11 -> January 11 so three months. > > Vendors of sealed units who ship equipment from before October 11 with > delivery held up for three months at the docks by a strike, or people > who put the sealed

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

> On Dec 2, 2016, at 2:55 PM, 神明達哉 wrote: > > At Fri, 25 Nov 2016 19:50:48 -0500, > tjw ietf wrote: > >> Please review the draft and offer relevant comments. Also, if someone feels >> the document is *not* ready for publication, please speak out with your >> reasons. >> >> *Also*, if you have

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

+1 I agree this is ugly as ugly can be but that ship has sailed. For interoperability sake lets just publish this with a note that says something like this; This is documentation of fielded useful protocol. This is ugly protocol and it copying it is strongly discouraged. Olafur > On Dec

Re: [DNSOP] ALT-TLD and (insecure) delgations.

> On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote: > > > > On 04/02/2017 02:13, Andrew Sullivan wrote: >> Right, that's always been the problem with using this _for the DNS_. >> Homenet has no choice in that, because the whole point of the homenet >> name is precisely to enable in-homenet DNS wit

Re: [DNSOP] [Ext] order of records in DNAME responses

> On Feb 24, 2017, at 12:35 PM, Evan Hunt wrote: > > On Fri, Feb 24, 2017 at 02:46:28PM +, Edward Lewis wrote: >> The reason I point this out is that the order of records in a section has >> been famously undefined, with the convention of supporting round robin >> (an undocumented feature of

Re: [DNSOP] call for agenda items, IETF 98

> On Mar 1, 2017, at 2:19 PM, Suzanne Woolf wrote: > > Hi, > > This is a good point, thanks Paul. > > If you’re an editor on a WG document, please consider what you need from the > WG to get it ready for a Working Group Last Call. If you’re missing > reviews/reviewers, the chairs/secretary

Re: [DNSOP] draft-tale-dnsop-edns-clientid

es are not achievable in his. I'd > welcome joining up. > > The one other thing I wanted to mention in the WG is that I tried to > get an EDNS code point assigned through the "Expert Review" process, > which it turns out is very poorly documented for either process

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman wrote: >> > > We kind of restarted the draft adopting RSASSA-PSS, so please can you > review it this time from scratch without looking at the diff? > > Many of the examples will need updating once algorithm numbers are > assigned for them (as fo

Re: [DNSOP] Proposed text for reverse-mapping-considerations draft

I think this text is helpful, to understand where the 'requirement´ for reverse DNS entries came from. This mechanism was used by ftp servers to keep logs and enforce export control on cryptographic software :-) You may want to add a paragraph that the r* command use of reverse mapping for secu

Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?

This is getting silly, where Rob works, who Rob works with, who Rob talks to, are all irrelevant. Rob is a co-chair of the working group and serves at the pleasure of the AD, he can be terminated at any moment, if he engages in anything that the AD perceives as un-professional, un-ethical or just

Re: [DNSOP] WGLC for

Review: The document is well written, and I did not find any factual errors. I generally support the document for advancement, with one caveat: Section 7 paragraph 2 This section assumes ALL traffic coming to a site from AS112 servers is in response to DNS queries ISSUED BY THE SITE. IMHO the d

Re: [DNSOP] WGLC for

At 13:22 20/07/2007, Peter Koch wrote: Dear WG, the draft , "DNS Referral Response Size Issues" has been on our plate for quite a while. After the Prague meeting, four people have come forward with a review, all but one supported the document with minor changes suggested, the fourth reviewer pu

Re: [DNSOP] WGLC for

Joe, At 11:53 24/07/2007, Joe Abley wrote: Olafur, On 20-Jul-2007, at 23:11, Olafur Gudmundsson wrote: Section 1.2 (issue) I think this section is out of date, most recursive resolvers support ENDS by now. In a quick sample I did on my authoritative nameserver logs I found almost 2

[DNSOP] draft-ietf-dnsop-dnssec-trust-anchor-00

As instructed by chair we have submitted a version 00 that is IDENTICAL to the 02 version of the individual submission. Please ignore this version as 01 will be posted early next week with the edits we have accumulated. Olafur & Matt ___ DNSOP

Re: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-01.txt

At 11:00 11/02/2008, [EMAIL PROTECTED] wrote: > Title : DNSSEC Trust Anchor Configuration and Maintenance > Author(s) : M. Larson, O. Gudmundsson > Filename: draft-ietf-dnsop-dnssec-trust-anchor-01.txt > Pages : 14 > Date

Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02

At 13:46 06/08/2008, Paul Hoffman wrote: Greetings again. The end of section 2 of this document says: Another advantage of configuring a trust anchor using a DS record is that the entire hash of the public key in the DS RDATA need not necessarily be specified. A validating resolver MAY

Re: [DNSOP] Questions on section 3 of draft-ietf-dnsop-dnssec-trust-anchor-02

We have had an off-line discussion with Paul on how to address his comments and this is the result of that discussion. New version will show up RSN. At 13:55 06/08/2008, Paul Hoffman wrote: Greetings again. Section 3 of this document says: If any of the steps above result in an error, the va

Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02 )

At 17:35 09/03/2009, Mark Andrews wrote: On a related issue DS -> DNSKEY translations cannot be performed until the DNSKEY is published in the zone. The use of DS prevents pre-publishing of keys. Once the key is generated a DS of it can be generated. Our draft does no

Re: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02

At 00:43 10/03/2009, Mark Andrews wrote: In message <20090310041254.gb4...@vacation.karoshi.com.>, bmann...@vacation.kar oshi.com writes: > On Tue, Mar 10, 2009 at 12:55:51PM +1100, Mark Andrews wrote: > > > > In message , David Black > a wr > > ites: > > > > > > On Mar 9, 2009, at 5:35 PM, M

Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

At 22:30 29/04/2009, Paul Hoffman wrote: At 8:13 PM +0200 4/22/09, Peter Koch wrote: >Please review the draft and send comments and/or statements of support or >non-support to the WG mailing list. >There will be a five reviewer threshold. I support the publication of this document. Some comments

Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

At 14:45 22/04/2009, Edward Lewis wrote: At 20:13 +0200 4/22/09, Peter Koch wrote: >this is to initiate a working group last call on > >"DNSSEC Trust Anchor Configuration and Maintenance" > draft-ietf-dnsop-dnssec-trust-anchor-03.txt > >ending Friday, 2009-05-08, 23:59 UTC. The too

Re: [DNSOP] WGLC: DNSSEC Trust Anchor Configuration and Maintenance

At 15:05 22/04/2009, Paul Wouters wrote: On Wed, 22 Apr 2009, Peter Koch wrote: Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. It seems a comma is missing between Scott's name and mine. Fixed, One issue came up recently with

Re: [DNSOP] query regarding DNS Cache in resolver.

At 00:56 27/07/2009, venkatesh.bs wrote: Hi all, I have one query regarding DNS cache maintaince in dns resolver, Whether DNS Cache should be based on per server address or based on FQDN only. DNS caches MUST cache by the holy DNS Trinity: Query Name, Query Type, Query Class DNSSE

[DNSOP] Priming query transport selection

Draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02 says "2.1. Parameters of a Priming Query A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). The UDP source port SHOULD be randomly se

Re: [DNSOP] Priming query transport selection

At 15:01 13/01/2010, Alex Bligh wrote: --On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson wrote: Going forward I think this is a bad recommendation. I would like to propose that the document take the plunge of recommending that modern DNSSEC capable resolvers perform the priming query

Re: [DNSOP] Priming query transport selection

At 16:33 13/01/2010, Edward Lewis wrote: At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote: The benefit is that a single query can retrieve the signed root NS set and all the signed glue records. I am not certain that the cost of doing TCP for this is worth the benefit of getting a signed

Re: [DNSOP] Priming query transport selection

At 16:16 13/01/2010, Jim Reid wrote: On 13 Jan 2010, at 20:49, Alex Bligh wrote: Current operational practice would result in DO clear packets fitting within 4096 bytes, so no need for TCP when DO is clear. I don't think that's always the case Alex. See the lengthy discussion in this list abo

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

At 15:54 22/01/2010, Alex Bligh wrote: --On 22 January 2010 15:45:54 -0500 Edward Lewis wrote: contents) in example.org. So, whilst opt-out should be avoided across intervals containing secure delegations, I see no reason to avoid it across intervals that don't contain secure delegations.

Re: [DNSOP] [dnsext] Re: Priming query transport selection

At 00:38 24/01/2010, Danny Mayer wrote: >> Proposed replacement text: >> >> |2.1. Parameters of a Priming Query >> | >> | A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS >> | of IN, with RD bit set to 0, the source port of the query should >> | be randomly selected [RFC5452

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

5. Next Record type There are currently two types of next records that are provide authenticated denial of existence of DNS data in a zone. I have a problem with this presentation. There are two mechanishm to provide proof of non-existance, each has a RR type associated with it. The

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

Thanks Evan and Andrew fot translating my thoughts into better prose. Evan, you captures my meaning. Olafur On 20/02/2010 4:31 PM, Evan Hunt wrote: I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. Same here. Nits: There are to m

Re: [DNSOP] automatic update of DS records

On 02/03/2010 7:40 PM, Jay Daley wrote: On 3/03/2010, at 1:36 PM, bmann...@vacation.karoshi.com wrote: That I don't. Currently the registrant's DNS provider tells them "cut and paste this blob from here into the field marked 'nameservers' in your registrar's interface" and to that they wil

Re: [DNSOP] m.root-servers.net DNSSEC TCP failures

Here is what I get: dig any . @m.root-servers.net. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.6.1-P1 <<>> any . @m.root-servers.net. Thus I think the any-cast instance you are using is the broken one, I'm talking to the one on the west coast of the US. (SFO ?). traceroute to m.root-server

[DNSOP] RFC4641-bis: The case for single active key

Currently section 3 of the document "mandates" that all zones be signed using the KSK+ZSK model, I content this is outdated advice. Background #1: Why bring this up now While reviewing draft-ietf-dnsop-dnssec-dps-framework I found myself loving certain sections of the document and hating othe

Re: [DNSOP] RFC4641-bis: The case for single active key

On 17/06/2010 5:34 PM, Eric Rescorla wrote: On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson wrote: Background #3: Key strengths and life time RSA and DSA algorithms have the interesting property that the number of bits in the key can be selected, by adding bits to the key the key gets

Re: [DNSOP] That key size argument...was Re: The case for single active key

On 18/06/2010 12:35 PM, Edward Lewis wrote: At 18:30 -0400 6/17/10, Olafur Gudmundsson wrote: I agree with you but there are still people out there that believe that key size is a tradoff in time. "Belief" - engineering shouldn't be about beliefs. I think the hard part fo

Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00

On 20/10/2010 4:32 AM, Matthijs Mekking wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/20/2010 01:03 AM, Suzanne Woolf wrote: On Tue, Oct 19, 2010 at 10:22:25AM -0400, Andrew Sullivan wrote: On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: B. "Better to publish what we

Re: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-anchor-04.txt

Matt and I updated the document to reflect the comments received during the last call and some comments from the chair, in addition the document now reflects that the root is signed. Major changes: Input format of trust anchor specified with example Reflect signed root

Re: [DNSOP] Comments on DS Publication draft

On 11/11/2010 5:32 PM, Stephan Lagerholm wrote: -Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of George Barwood Sent: Thursday, November 11, 2010 4:15 PM To: Rickard Bellgrim; dnsop@ietf.org Subject: Re: [DNSOP] Comments on DS Publication draf

Re: [DNSOP] watching for signature expiration in zones you don't sign

On 02/06/2011 11:23 AM, Richard Lamb wrote: I still think, stale or not, having some idea of what the zone's policy is regarding signature updates would be useful. I've been running signature expiry monitoring scripts for a few years and having some idea of what is "ok" for a zone would be ver

Re: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt

On 13/06/2011 1:22 PM, Stephen Morris wrote: Dear DNSOP WG, This is to initiate a working group last call (WGLC) on "DNSSEC Policy& Practice Statement Framework" draft-ietf-dnsop-dnssec-dps-framework-04.txt Owing to the length of the document, the WGLC will last for three weeks

Re: [DNSOP] WGLC: draft-ietf-dnsop-dnssec-dps-framework-04.txt

Fredrik, On 19/06/2011 12:22 PM, Fredrik Ljunggren wrote: On 2011-06-17, at 13:31, Olafur Gudmundsson wrote: Few nits and questions below: a) DP and DSP should be included in the Definitions section 2, even though the abbreviations are are defined in section 1.2 Alternatively spell out in

Re: [DNSOP] CDS RRtype - automated KSK rollover

On 30/06/2011 10:32 AM, Stephen Morris wrote: On 12/06/2011 20:50, George Barwood wrote: I have updated the draft http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt . I agree with Ed and think that we before adopting a solution, we should step back and ask some basic questions s

Re: [DNSOP] CDS RRtype - automated KSK rollover

On 05/07/2011 3:48 PM, Chris Thompson wrote: On Jun 30 2011, Olafur Gudmundsson wrote: [... snip ...] It would be nice, and make the system more robust. FWIW I think NS can be automatically maintained after we have DNSSEC by having the parent copy what the child publishes. At first sight this

Re: [DNSOP] CDS RRtype - automated KSK rollover

On 08/07/2011 5:18 PM, Joe Abley wrote: On 2011-07-08, at 14:03, Stephen Morris wrote: If the answer is yes, then the CDS approach is certainly one to be looked at. The answer also suggests that we should be looking at an equivalent mechanism for updating NS (and possibly glue) information in

Re: [DNSOP] feedback/feelings around : draft-barwood-dnsop-ds-publish-02.txt ?

On 21/07/2011 7:39 AM, Antoin Verschuren wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-07-11 11:51, Marc Lampo wrote: Dear all, http://tools.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt There does not seem to be a lot of feedback on this draft ? (some comments on version 0

Re: [DNSOP] New I-D on Negative Trust Anchors

Jason, I read the draft and like the direction of it. It looks like you are proposing turning off a validation for domain by the negative trust anchor. An alternative is to insert a negative trust anchor for a particular trust anchor. In the first case there is an action required by the validato

[DNSOP] What does a NTA validator return in an answer under the NTA?

When resolving with DNSSEC-trigger on Comcast's network DNSSEC-Trigger acts like forwarding stub-validator. For it to be happy when there is a NTA in place, the upstream resolvers MUST return to it the non validatable RRSIG (if they exist). The current draft is silent on the behavior of the v

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt

On 24/07/2012 07:53, Matthijs Mekking wrote: General comment: this is an improvement. some comments and suggestions below The "state" of the key frequently depends on the viewpoint, for example zone may have key in active state but due to propagation delay some validators may think the key is P

Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14

On 23/08/2012 17:49, Peter Koch wrote: Dear DNSOP WG, this is to initiate a working group last call (WGLC) for "DNSSEC Key Timing Considerations" draft-ietf-dnsop-dnssec-key-timing-03.txt The WGLC

Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13

On 23/10/2012 09:46, Niall O'Reilly wrote: On 23 Oct 2012, at 14:29, Miek Gieben wrote: The paragraph is a *suggestion* in a *bcp*. I don't see what point you're trying to make with this remark. Indeed, if the suggestion is not congruent with current practice, it see

Re: [DNSOP] RFC2308/6604 violation in NSD and BIND?

Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted are under DNSEXT change control. Please move the discussion there. On 26/10/2012 09:25, Peter van Dijk wrote: Hello Mark, Thank you for your swift and accurate response. On Oct 26, 2012, at 15:12 , Mark Andrews wrote:

Re: [DNSOP] finding the closest delegation

Just use DNSSEC, the RRSIG records tell you the apex of the zone :-) Olafur On 23/11/2012 06:42, Jim Reid wrote: On 23 Nov 2012, at 11:17, Tony Finch wrote: Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authori

Re: [DNSOP] New draft-livingood-negative-trust-anchors-04

On 17/02/2013 10:22, Livingood, Jason wrote: Based on feedback yesterday on the list, I did a quick –04 update, which is now at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/. The are seven open issues documented at the end of the I-D. But the most important questions

Re: [DNSOP] New draft-livingood-negative-trust-anchors-04

Jason, in section 10 you talk about possible early removal the NTA when validation succeeds but there may be instances where validation succeeds when using a sub-set of the authoritative servers thus NTA should only be removed if all servers are providing "good" signatures. Furthermore what to

Re: [DNSOP] Fwd: New Version Notification fordraft-kumari-ogud-dnsop-cds-00.txt

On 18/02/2013 19:05, Stephan Lagerholm wrote: Warren Kumari, Monday, February 18, 2013 4:36 PM: Hi all, This is a compilation of two earlier drafts, draft-barwood-dnsop-ds- publish and draft-wkumari-dnsop-ezkeyroll. The basic idea remains the same -- allow operators to publish new (and stand

Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt

I just posted a new version: http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-01.txt On 19/02/2013 11:07, Paul Wouters wrote: On Mon, 18 Feb 2013, Warren Kumari wrote: The basic idea remains the same -- allow operators to publish new (and standby) DS records at the parent by p

Re: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt

On 25/02/2013 17:27, Paul Wouters wrote: On Mon, 25 Feb 2013, Olafur Gudmundsson wrote: You have to be more strict then just "validation succeeds". You MUST ensure the proper DNSKEY's matching the CDS records exist on ALL secondary servers, and must wait AT LEAST a TTL ti

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

Ed, Thank you for your review from the "parent perspective". CDS is designed to be as simple as possible to operate for both parents and child. CDS is designed around the "Replace" operation, you and Marc are proposing to change that to Add/Delete operations. In the draft a Parental Agent can

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

Tony, CDS allows: publication of DS w/o inclusion in DNSKEY publication of DS w hash that the Parental Agent does not "support". One CDS's goals is to get the "Parent" out of the habit of calculating hash, just publish what the Child wants. In theor

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On Mar 5, 2013, at 5:25 AM, Antoin Verschuren wrote: > >> So, to clarify, can the operator of a child zone who prefers to use >> an algorithm 14 DNSKEY send you that key, confident that you will >> accept it? What about algorithm 253? > > No. > If the child prefers to use an experimental algori

[DNSOP] F2F meeting in Orlando Re: General comments on draft-kumari-ogud-dnsop-cds-01

I will try to organize a face to face meeting on the topic of moving DNS delegation information in-band (inside DNS) from child to parent, at the IETF next week (will send out report after meeting) If you are interested in attending let me know and in general what times are good for you,

Re: [DNSOP] F2F meeting in Orlando Re: General comments on draft-kumari-ogud-dnsop-cds-01

On Mar 5, 2013, at 3:50 PM, Paul Hoffman wrote: > On Mar 5, 2013, at 12:10 PM, Olafur Gudmundsson wrote: > >> I will try to organize a face to face meeting on the topic of moving DNS >> delegation information in-band (inside DNS) >> from child to parent, at the I

Re: [DNSOP] F2F meeting in Orlando Re: General comments on draft-kumari-ogud-dnsop-cds-01

t; schedule and then we see how it shapes up. > > Jim > > > > -- On March 5, 2013 3:10:16 PM -0500 Olafur Gudmundsson wrote > regarding [DNSOP] F2F meeting in Orlando Re: General comments on > draft-kumari-ogud-dnsop-cds-01 -- > >> I will try to organize a face t

[DNSOP] F2F CDS discussion @IETF-86

About 20 people attend the gathering Tuesday. We started off by going over different scenario's in relationships between "parent" and child DNS Operator http://dl.dropbox.com/u/81151626/CDS%20Scenarios.pptx Then followed lively discussion about alternatives and applicability in different situ

Re: [DNSOP] Adoption of as a WG work item?

On Mar 14, 2013, at 6:55 PM, Joe Abley wrote: > > On 2013-03-14, at 18:52, George Michaelson wrote: > >> how many of the deployed resolvers can understand DNAME > > Good question, it would interesting to design an experiment to measure that. > >> and whats the outcome for dns lookups where

Re: [DNSOP] Thoughts on CDS

On Apr 19, 2013, at 11:28 AM, Joe Abley wrote: > > On 2013-04-19, at 11:21, Wes Hardaker wrote: > >> Joe Abley writes: >> >>> By this thinking, a signed apex DS RRSet with the meaning discussed >>> for CDS could be deployed today, with no need for code point >>> assignment. What am I missin

  1   2   >