[DNSOP] Re: Compact Denial of Existence with NSEC3?

> On Dec 26, 2024, at 14:05, John Levine wrote: > > It's fine, but two niggles: > > It appears that Shumon Huque said: >> specific benefit for online signing implementations. Hence, there >> does not appear to be a strong advantage to implementing Compact >> Denial of Existence with NSEC

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

[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

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

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] 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] 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] [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] [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] 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] 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-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] 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] 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] 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

> 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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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

[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] 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

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] 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] 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 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] 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] RFC 2181 - a pathway forward.

> On Jul 10, 2015, at 1:31 PM, manning wrote: > > I am aware of at least three of the independent ideas in RFC 2181 that folks > are working on: > > draft-pfrc-2181--naming-issues-00 > draft-pfrc-2181-handling-zone-cuts-00 (isn’t this the basis for the dbound > work?) > draft-pfrc-2181-reso

Re: [DNSOP] RFC 2181 - a pathway forward.

> On Jul 8, 2015, at 2:50 PM, manning wrote: > > With the WG Chairs permission. > > RFC 2181 is growing a both long in the tooth. It is, by its own admission, a > collection of eight distinct and independent ideas. As such, it is difficult > to work on one of > those ideas without raising

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

On Thu, Jul 9, 2015 at 9:23 AM, Suzanne Woolf wrote: > (No hats, and no strong feelings-- a minor point.) > > On Jul 8, 2015, at 11:11 PM, Evan Hunt wrote: > > > On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote: > >> Less flippantly, it is in this email: > >> https://www.ietf.org/ma

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt

n the document Olafur > On 7/1/15 8:52 AM, Olafur Gudmundsson wrote: >> This version is a final version from the editors. >> We explicitly punt on explaining how to overcome the situation when a >> ´proxy/forwarder’ “randomly” sends queries to >> Resolvers wi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt

> 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 Working Group > of the IETF. > >Title : DNSSEC Roadblock Avoidance >Authors : Wes Hardaker >

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

> On Jun 30, 2015, at 8:53 AM, Tony Finch wrote: > > Olafur Gudmundsson wrote: > >> There is much simpler way. >> Just add record to the rootzone that is only signed by the new key. >> If resolver returns AD bit it has the new key. > > I don't t

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

Atlas probes can help us we can even measure this from webpages, cellphones, OS updates can add a test etc. Olafur On Jun 29, 2015 7:33 PM, "Warren Kumari" wrote: > On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson > wrote: > > There is much simpler way. > > Jus

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

There is much simpler way. Just add record to the rootzone that is only signed by the new key. If resolver returns AD bit it has the new key. All that is needed is to sign a Rrset for a long time and add it at to the rootzone and make sure no ZSK signs it. Olafur On Jun 29, 2015 4:49 PM, "Warren

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

Petr, sorry for delayed response, > On Feb 11, 2015, at 11:24 AM, Petr Spacek wrote: > > Hello dnsop, > > draft-ietf-dnsop-dnssec-roadblock-avoidance is a nice idea in general but > current version of "Roadblock Avoidance", section 5, version 01 has a > significant drawback: > > Else if

Re: [DNSOP] RFC-3658 errata (minor)

> On Jun 7, 2015, at 6:22 PM, Paul Wouters wrote: > > > I was writing some hashing to create DS records code when I noticed > in the RFC-3658 https://tools.ietf.org/html/rfc3658#section-2.4 > Paul I would say no as document is obsoleted by newer documents Obsoleted by: 4033

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

> On Jun 4, 2015, at 7:48 PM, Paul Hoffman wrote: > > On Jun 4, 2015, at 4:05 PM, Tony Finch wrote: >> Are there any implementations of this draft? > > Assuming you mean "is anyone deploying the ideas in this draft, particularly > those in Appendix B", that would be good information for the a

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Hi I have reviewed this document, and support its publication as is. Olafur On Mon, Apr 27, 2015 at 11:58 PM, Tim Wicinski wrote: > Greetings, > > This starts a Working Group Last Call for Adoption for > draft-ietf-dnsop-negative-trust-anchors > > Current versions of the draft is available he

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

> On Mar 25, 2015, at 8:33 AM, Mark Andrews wrote: > > > In message , Tony > Finch writes: >> John Dickinson wrote: >>> >>> I support this draft. One thing that jumped out to me was there appears >>> to be no mention of NSEC/NSEC3 chain management when adding/removing >>> records. >> >> Eve

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

> On Mar 18, 2015, at 11:55 AM, Paul Vixie wrote: > > we need a document that says "If you don't want to answer ANY, here's how to > do it interoperably." we don't need to say "you should not answer ANY", but > we do need to say "if you want to query for ANY, here's what might happen." > that

[DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-acl-metaqueries-00.txt

updated based on feedback from the mailing list File name changed at WG secretary request Olafur (for editors) -- Forwarded message -- From: Date: Mon, Mar 9, 2015 at 6:25 PM Subject: New Version Notification for draft-ogud-dnsop-acl-metaqueries-00.txt To: Olafur Gudmundsson

Re: [DNSOP] More work for DNSOP :-)

Happy to pick a less offensive file name :-) will discuss with co-editors (Joe Abley is also helping) Olafur -Original Message- From: "Paul Hoffman" Sent: Monday, 9 March, 2015 11:51 To: "Olafur Gudmundsson" Cc: "IETF DNSOP WG" Subject: Re: [DNSOP] Mor

Re: [DNSOP] More work for DNSOP :-)

There is a new version in the works, expect it late tomorrow (monday) It does not outlaw ANY per say, just says limit it to trusted parties. I tries to define that resolver treat NOTIMP as long term signal that resolver should keep track of and not retry. It says ignore RD=1 on meta queries.

Re: [DNSOP] "DNS resolver should not use 'ANY' to get cached records for TTL" (bugzilla)

Paul, Marek and I agree with you to expand the scope to include all meta types at Authoratitive servers. And address your other points as well, thanks for the support. Olafur On Mar 6, 2015 11:28 PM, "Paul Vixie" wrote: > this made the news tonight: > > > Tracking Flags: > > tracking-firefox36

[DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt

As promised Olafur -- Forwarded message -- From: Date: Fri, Mar 6, 2015 at 12:27 PM Subject: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt To: Olafur Gudmundsson , Marek Majkowski < ma...@cloudflare.com> A new version of I-D, draft-ogud-dnsop-any-not

Re: [DNSOP] Definitions of foo-centric

> On Feb 25, 2015, at 4:14 AM, Ray Bellis wrote: > > >> On 25 Feb 2015, at 08:58, Stephane Bortzmeyer wrote: >> >> I'm not sure they appear in a RFC. They are commonly used (see for >> instance ) when >> discussing resolvers' behaviour. >>

Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side

Hi Petr, This has been discussed in the past a few times and died as people could not agree on what the format of the record was going to be, if it was going to be useful for human or computers etc. The first idea was probably presented in 1987 by Robert Watson and myself https://tools.ietf

Re: [DNSOP] Updating the DNS Registration Model to Keep Pace with Today’s Internet

> On Feb 5, 2015, at 11:58 AM, Stephane Bortzmeyer wrote: > > "CloudFlare is advocating to gain the ability to update NS records for > our customers and address records associated with them using automated > channels. Our goal is to be able to add and remove nameservers from > customer domains w

Re: [DNSOP] New version of the DNS terminology draft

> On Feb 4, 2015, at 11:09 AM, Stephane Bortzmeyer wrote: > > On Mon, Jan 19, 2015 at 02:16:47PM -0800, > Paul Hoffman wrote > a message of 17 lines which said: > >> Greetings again. Andrew, Kazunori, and I have done a massive >> revision on the DNS terminology draft based on the input we got

Re: [DNSOP] RSA/SHA-1 to >= RSA/SHA-256 ?

> On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN) wrote: > > Hi, > > SHA-1 for TLS-certificates is considered insufficient nowadays. > > But what about the usage of RSA/SHA-1 in DNSSEC ? > > Should TLD's such as .se make preparations for an algorithm roll-over? > > -- > Marco > > _

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

> On Jan 15, 2015, at 1:33 PM, 神明達哉 wrote: > Jinmei, thank you for your good comments. > At Thu, 15 Jan 2015 11:13:10 +0100, > Matthijs Mekking wrote: > >> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize >> this? Olafur and I have some ideas on keeping those zone transf

Re: [DNSOP] identifying an identifier's name space was Re: draft-grothoff-iesg-special-use-p2p-names-03

> On Jan 7, 2015, at 8:59 AM, Tony Finch wrote: > > Andrew Sullivan wrote: >> >> In the other case, it's an indication that the _namespace_ is >> different: that if you resolve that name on the Internet without >> special enabled software, you aren't getting the service you desired, >> regardl

Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qname-minimisation

> On Jan 5, 2015, at 12:04 PM, Rubens Kuhl wrote: > >> >> Em 05/01/2015, à(s) 14:33:000, Paul Hoffman escreveu: >> >> On Jan 4, 2015, at 12:13 PM, David Conrad wrote: > "Sending the full qname to the authoritative name server is a > tradition, not a protocol requirment." > >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

> On Dec 1, 2014, at 4:31 PM, Wes Hardaker wrote: > > 神明達哉 writes: > >> From a quick check some of them still seem to be open. And, as far as >> I remember there has been no response to my comments, so I'm not sure >> if they were considered/discussed but dismissed or simply overlooked. > >

Re: [DNSOP] Call for Adoption draft-livingood-dnsop-negative-trust-anchors

> On Nov 26, 2014, at 10:58 AM, Tim Wicinski wrote: > > > This starts a Call for Adoption for > draft-livingood-dnsop-negative-trust-anchors. There was much discussion at > the last meeting about adopting this draft and working on it. > > The draft is available here: > > https://datat

Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-5966-bis

On Nov 14, 2014, at 2:04 PM, Tim Wicinski wrote: > > This starts a Call for Adoption for draft-dickinson-dnsop-5966-bis > > The draft is available here: > https://datatracker.ietf.org/doc/draft-dickinson-dnsop-5966-bis/ > > > Please review this draft to see if you think it is suitable

[DNSOP] PTR usage cases for networking Re: Using PTRs for security validation is stupid

On Nov 11, 2014, at 5:48 PM, Lee Howard wrote: > Many SSH servers (by default) reject connections from IP addresses without > PTRs. > This is stupid. > > I heard applause during the WG meeting in response to these statements; > sounded like consensus to me. I said I would check that consensus o

[DNSOP] Automating Provision of DS Records

Hi, as I mentioned at the mike: For those at the IETF-91 I will be hosting a Beach Bof for people that are interested in working on creating an automated solution to this problem in as short time as possible. Send me an email if you are interested Time: 15:00 @ Thursday Loaction: TBD Olafur

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On Oct 25, 2014, at 8:30 PM, Paul Ebersman wrote: > > dougb> It's not just a philosophical objection, it's an operational > dougb> one. When DNSSEC fails for a domain there are 2 main > dougb> reasons. Operator error, and an actual MITM or similar attack. If > dougb> the operators of validating

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

On Oct 7, 2014, at 12:04 AM, Tim Wicinski wrote: > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. Done, will hold off sending edits to editor until after document adoption period. > > Please also in

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

I’m getting confused about what the exact semantics of the proposed mechanisms are. Q1: The intent is that ALIAS/ANAME/etc are a fallback rewrite operation if the name does not have the type asked for? Q2: Is there a good reason to restrict this to just the apex of a zone? Q3: Is there a

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

On Jul 18, 2014, at 10:52 AM, John Levine wrote: >> Many years ago Joe Abley and I suggested to create a special name for >> exactly this purpose >> a name that was guaranteed to never exist in the DNS thus the first lookup >> would always return NXDOMAIN thus the A+ lookups would never ta

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

On Jul 18, 2014, at 10:18 AM, Tony Finch wrote: > Paul Vixie wrote: >> >> what's unstated here is that every SMTP sender who encounters such an MX >> without understanding its new meaning will do two or three lookups: ". >> MX", > > No, MTAs do not look up MX records for MX targets. > >> [".

Re: [DNSOP] DNS terminology (Was: draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

On Jul 16, 2014, at 11:26 AM, Stephane Bortzmeyer wrote: > On Wed, Jul 16, 2014 at 03:21:22PM +, > Hosnieh Rafiee wrote > a message of 44 lines which said: > >> For DNS in general, I saw some terminologies in different RFCs. In >> other words, they are distributed in different RFCs. > >

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor wrote: > > On Tue, 8 Jul 2014, Olafur Gudmundsson wrote: > >> >> On Jul 8, 2014, at 7:40 AM, ? Roy Arends wrote: >> >>> Hiya, >>> >>> I really like this idea. Many ISPs alr

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

On Jul 8, 2014, at 12:33 PM, Tony Finch wrote: > Olafur Gudmundsson wrote: >> >> this document seems “bind” specific that it assumes that the recursive >> resolver can be both authoritative and recursive which is not a >> requirement. > > You can't

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

On Jul 8, 2014, at 7:40 AM, 🔒 Roy Arends wrote: > Hiya, > > I really like this idea. Many ISPs already do this, (including some high > profile public recursives, like Google and OpenDNS), because it simply makes > sense: It reduces latency for the end user, reduces outbound traffic > overhea

Re: [DNSOP] NOTE RR type for confidential zone comments

On May 28, 2014, at 8:23 AM, Ted Lemon wrote: > So not to put too fine a point on it, but where is the use case for this > proposal? It seems like something that is more of someone's cool hack than > a standard people ought to implement. What am I missing? > >

Re: [DNSOP] Extended CNAME (ENAME)

On May 19, 2014, at 8:26 PM, Bob Halley wrote: > On 5/19/14, 16:43, "Mark Andrews" wrote: > >> No. Your analysis is faulty. >> >> ENAME could be used immediately once the authoritative servers for >> the zone support it. It would just be insecure until validators >> catch up. ENAME + old a

Re: [DNSOP] call to work on edns-client-subnet

On May 16, 2014, at 7:56 AM, Ted Lemon wrote: > On May 16, 2014, at 5:35 AM, S Moonesamy wrote: >> I sent a few comments about that CDNI draft. The DNS discussion in the >> draft was problematic. It is worth documenting what people are doing. It >> is worthwhile to consider whether the mec

Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-13.txt

ilable from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations Working Group > of the IETF. > >Title : Automating DNSSEC Delegation Trust Maintenance >Authors : Warren Kumari >

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Apr 25, 2014, at 2:28 AM, Matthijs Mekking wrote: > Hi, > > On 04/24/2014 05:41 PM, 神明達哉 wrote: >> At Thu, 24 Apr 2014 07:55:52 +0200, >> Matthijs Mekking wrote: >> >>> The child can also signal its desire to remove DS records by removing >>> the corresponding records from the CDS/CDNSKEY

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On Apr 15, 2014, at 8:06 PM, Paul Hoffman wrote: > This looks greatly improved from the -03 that started the WG Last Call. It > clears almost all of my concerns, particularly about the overly-loose > language. > > There is still one assumption being made of the reader that I think can > clea

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Apr 1, 2014, at 10:48 PM, Paul Hoffman wrote: > On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson wrote: > >> Why not go to a good ECC instead ? (not sure which one, but not P256 or >> P384) > > Why not P256 or P384? They are the most-studied curves. Some of the

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Apr 1, 2014, at 11:15 AM, Colm MacCárthaigh wrote: > > On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson wrote: > Doing these big jumps is the wrong thing to do, increasing the key size > increases three things: > time to generate signatures >

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Apr 1, 2014, at 9:05 AM, Nicholas Weaver wrote: > > On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson wrote: >> >> Doing these big jumps is the wrong thing to do, increasing the key size >> increases three things: >> time to generate signatu

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Mar 27, 2014, at 6:54 PM, Bill Woodcock wrote: > > On Mar 27, 2014, at 10:14 AM, Matthäus Wander > wrote: >> Here's a small statistic about RSA key lengths of 741,552 signed >> second-level domains (collected on 2014-01-27, counting KSK and ZSKs): >> >> 1024 bit: 1298238 >> 2048 bit: 6982

Re: [DNSOP] port 0 requests leading to errors

On Mar 23, 2014, at 8:59 PM, Christopher Morrow wrote: > If I have a patch which makes no sense, will you also add it? > > Speaking for Paul, Paul used value judgement based on the persons reputation. If Mark thought it was important enough to submit a patch then there must be a reason, e

Re: [DNSOP] New Version Notification for draft-schmidt-brainpool-dnssec-00.txt

On Mar 21, 2014, at 3:39 AM, "Schmidt, Jörn-Marc" wrote: > Dear all, > > I've just submitted the draft below on using ECDSA with Brainpool Curves for > DNSSEC. > > The rationale behind this submission is the fact that the German electronic > health insurance card (Gesundheitskarte) mand

Re: [DNSOP] my dnse vision

On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer wrote: > On Wed, Mar 05, 2014 at 12:51:52PM +, > Olafur Gudmundsson wrote > a message of 41 lines which said: > >> I NEED confidence that I'm talking to the real 8.8.8.8 if the only >> way to get that is

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

On Mar 5, 2014, at 10:23 AM, fujiw...@jprs.co.jp wrote: > Dear Chairs and WG participants, > > I updated draft-fujiwara-dnsop-ds-query-increase this Janurary. > > http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase > > Recent DS traffic increase seems not high, I did not request

Re: [DNSOP] my dnse vision

On Mar 5, 2014, at 11:07 AM, Francis Dupont wrote: >> From discussions with Stephane Bortzmeyer and Mark Andrews... > > First I come back to the fact there are two different problems > (aka divide and conquer): > * stubs <-> resolver > * resolver <-> auth servers > > I consider the first one t

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

On Mar 3, 2014, at 2:03 PM, Andrew Sullivan wrote: > On Mon, Mar 03, 2014 at 01:56:20PM +, Jelte Jansen wrote: >> I'd think that a domain name is only a domain name when whatever >> protocol it is defined in defines it as a domain name (or whatever >> undefined protocol uses it in actual dns

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

On Feb 17, 2014, at 11:22 AM, Ted Lemon wrote: > On Feb 16, 2014, at 9:03 PM, Paul Wouters wrote: >> DNSOP needs >> to broaden its charter, or we need to revive some kind of DNSEXT group. > > We would need to find some volunteers to act as co-chair. I don't think > adding the work to the DN

  1   2   >