[DNSOP] Re: New draft: DNS Servers MUST Shuffle Answers

Hi Shane, On 11/5/24 13:08, Shane Kerr wrote: I did consider the idea of periodic shuffling. That makes sense to me, since I think we can reasonably assume that servers will not be shuffling at exactly the same time and should have different results. It would mean slightly more state on the s

[DNSOP] Re: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-02.txt

On 11/4/24 14:24, Roy Arends wrote: The DS record already indicates if a delegation is secured and, if so, provides a signed digest over the secure entry point of the delegated zone. In theory, the digest function could be as simple as an identity hash function (where pre-image equals the ou

[DNSOP] Fwd: [Pq-dnssec] Agenda for IETF 121 side meeting

: Wed, 16 Oct 2024 00:52:34 +0200 From: Peter Thomassen To: pq-dns...@ietf.org CC: caspar.schutij...@sidn.nl Hi all, We have scheduled the PQ DNSSEC side meeting on Thursday, November 7, 2024 at 10:00-11:30 (local Dublin time) in Wicklow Hall 2A Remote participation: https

[DNSOP] Re: I-D Action: draft-ietf-dnsop-generalized-notify-03.txt

f the IETF. Title: Generalized DNS Notifications Authors: Johan Stenstam Peter Thomassen John Levine Name:draft-ietf-dnsop-generalized-notify-03.txt Pages: 17 Dates: 2024-10-21 Abstract: This document extends the use of DNS NOTIFY [RF

[DNSOP] Re: [Ext] DNSOPPossible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01

Hi Paul, On 10/15/24 20:30, Paul Hoffman wrote: On Oct 15, 2024, at 10:30, Peter Thomassen wrote: On 10/15/24 19:02, Paul Hoffman wrote: In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC Delegation" do not make sense if there is more than one "MUST"

[DNSOP] Re: [Ext] DNSOPPossible breaking inconsistencies in draft-ietf-dnsop-rfc8624-bis-01

On 10/15/24 19:02, Paul Hoffman wrote: In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC Delegation" do not make sense if there is more than one "MUST" in that column. You cannot use two algorithms to sign or delegate at the same time. I think you misread, Paul; the second column is

[DNSOP] Re: Light weight encrypted DNS proposal

Hi Vint, On 8/15/24 00:06, Vint Joseph wrote: The core idea/synopsis We plan to implement a system using elliptic curve cryptography. A preshared key, referred to as the public key G^S, is distributed from the dns server to the client. How? Best, Peter The server retains the private key S

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Hi Mike, On 8/10/24 17:21, Michael StJohns wrote: Paul - this is related directly to the newly specified inclusion of the public key material in this draft (sect 3.2 last para): A KeyDigest element can contain both a Digest and a publickeyinfo named pattern. If the Digest element wou

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

Hi, On 7/30/24 09:41, libor.peltan wrote: 1) I'd very much like to see more exact guidance of how the auth server / signer should prevent keytag collisions. For example, what our Knot DNS does is: (a) on a signle signer, when newly generated key causes collision, discard it and generate anoth

[DNSOP] Re: Introducing Relative Label for DNS

Hi Ben, On 7/26/24 11:07, Ben van Hartingsveldt wrote: @Peter Thomassen: Is it possible to make some list with all interop problems for this draft? I wouldn't know how to do that. Best, Peter -- https://desec.io/ ___ DNSOP mailing list --

[DNSOP] New tool for Authenticated DNSSEC Bootstrapping (RFC 9615)

(bcc: dnsop@ietf.org) Hi, We've just published a new tool that automates generation of RFC 9615 signaling zones (when synthesis is not available). --> https://pypi.org/project/dsboot/ Usage: In its simplest form, feed in zones via stdin (at least their CDS/CDNSKEY/NS records), and signaling

[DNSOP] Fwd: [Pq-dnssec] New Non-WG Mailing List: pq-dnssec

Hi all, Please see the below announcement of pqc-dns...@ietf.org, the creation of which is a result of our Monday side meeting. If you're interested in following or participating in this work, feel free to sign up! We'll reach out on this new list in a bit and gather work that folks are inte

[DNSOP] Re: Introducing Relative Label for DNS

Hi Ben, Welcome to DNSOP! :-) Your proposal reads like you'd like to add relative names to the DNS protocol. Reading this thread, however, I realize that you'd simply like to use the 0x40 label type *within the confines of your system*, and are asking to this added to the DNS Label Types regi

[DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

On 7/19/24 10:34, Philip Homburg wrote: To prevent this discrepancy between how dry-run and real validation is done, the resolver either needs to halve its work bounds (which is a disadvantage for real deployments), or commit to twice the work it is willing to do. This would be a problem is t

[DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

On 7/19/24 08:34, Yorgos Thessalonikefs wrote: I'm also interested in the possibilities for malicious use of this extension.  Can a malicious domain cause a resolver to do an enormous amount of work?  Can a malicious intermediary cause an enormous volume of error reports? For validation work

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

On 7/10/24 20:08, Ben Schwartz wrote: Why? Do we really care if a resolver limits the size of RRsets to 32 KB? Yes.  Unnecessary limits restrict our flexibility even if mainstream use cases don’t exist today. Absolutely agree. Peter ___ DNSOP m

[DNSOP] Re: [Technical Errata Reported] RFC6781 (6692)

Hi Warren, tl;dr: The erratum is correct, and I think can be verified. The situation described in the second-to-last paragraph of RFC 6781 Section 4.3.5.1 (and illustrated in Appendix D) amounts to - adding operator B as a multi-signing party according to RFC 8901 Model, - removing operator A.

[DNSOP] Re: Dnsdir early review of draft-ietf-dnsop-generalized-notify-01

Hi Patrick, First of all, thank you very much for this very comprehensive review. It's been very valuable, and we have incorporate a lot of your feedback into the new revision -02 that was just uploaded. Below some more responses. On 3/14/24 08:32, Patrick Mevzek via Datatracker wrote: §1.2

[DNSOP] Re: [Ext] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis

Hi Paul, On 7/8/24 20:08, Paul Hoffman wrote: OLD The Zone element in the TrustAnchor element states to which DNS zone this container applies. The root zone is indicated by a single period (.) character without any quotation marks. This is underspecified w.r.t. to format, for labels c

[DNSOP] Re: Last Call: (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

On 7/4/24 10:55, Petr Špaček wrote: Only comment I have is that LABELCOUNT could have been TYPE-dependent so a new TYPE could define different mechanism to identify zone, but hey, wasting 1 byte is not a big deal in the age of multi-gigabyte videos playing in the background constantly. Tha

[DNSOP] Re: Last Call: (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

On 7/4/24 10:00, Joe Abley wrote: --- 3.2. Responders ... A name server MAY also include more than one ZONEVERSION option in the response if it is authoritative for more than one zone of the corresponding QNAME. A name server MUST NOT include more than one ZONEVERSION option for a given TYP

[DNSOP] Re: Fwd: I-D Action: draft-zhang-dnsop-ns-selection-00.txt

On 7/3/24 17:19, Ben Schwartz wrote: Hi Davey, To clarify, the "DNS Load Balancing" side meeting will not be concerned primarily with nameserver selection.  Instead, the topic of the side meeting will be about using DNS to perform load balancing of other services and protocols. I think this

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

Hi all, Nice document. Some comments/nits: Section 2.2 --- OLD The Zone element in the TrustAnchor element states to which DNS zone this container applies. The root zone is indicated by a single period (.) character without any quotation marks. This is underspecified w.r.t. t

[DNSOP]Re: Paul Wouters' Yes on draft-ietf-dnsop-dnssec-bootstrapping-10: (with COMMENT)

Hi Paul, On 5/27/24 19:39, Paul Wouters via Datatracker wrote: -- COMMENT: -- Thanks for addressing all my DICSUSS items and comments. I have updated my ballo

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

sn't seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 2

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, but we'd need to pick a suitable replacement for the &qu

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The au

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Paul, We addressed the last open issue (see below) and submitted a new revision (-10). Thanks for the helpful discussion, I feel it's made the draft better! On 5/18/24 03:23, Peter Thomassen wrote: OLD    CDS/CDNSKEY records and corresponding signaling records MUST NOT be    publ

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Paul, On 5/17/24 20:45, Paul Wouters wrote: # Section 2 OLD    The DS enrollment methods described in Section 3 of [RFC8078] are    deprecated and SHOULD NOT be used.  Child DNS operators and parental    agents who wish to use CDS/CDNSKEY records for initial DS enrollment    SHOULD instead s

[DNSOP]Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

Hi Murray, On 5/16/24 12:59, Peter Thomassen wrote: I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document.  Don't

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Joe, On 5/17/24 10:39, jab...@strandkip.nl wrote: The Terminology section says: Signaling domain: A hostname from the child's NS RRset, prefixed with the label _signal. Defining a hostname with an alias containing the word "domain" does not prevent the confusion though (as in my cas

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Paul, Thanks once more. Suggested changes and other comments below. Text edits can be previewed in this PR: https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits On 5/17/24 04:15, Paul Wouters wrote:  Section 2:   The DS enrollment methods described in

[DNSOP]Re: Éric Vyncke's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

Hi Éric, Thank you for your comments. Associated changes will be included in revision -10, and can be previewed at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits/e7bece2158440c5ed5b221fd8a312ac8f171. On 5/16/24 15:52, Éric Vyncke via Datatracker wrote: #

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Paul, Warren, Following up on the telechat: On 5/15/24 20:34, Peter Thomassen wrote: Section 2: The DS enrollment methods described in Section 3 of [RFC8078] are deprecated and SHOULD NOT be used. I find this to be inconsistent with the Update: 8078 clause, as without

[DNSOP]Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-09: (with COMMENT)

Hi Murray, Thank you for your comments, thoughts below. On 5/16/24 06:53, Murray Kucherawy via Datatracker wrote: -- COMMENT: -- I support Paul's DISCUSS espe

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

quot;we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Peter Thomassen wrote: The authors certainly don't insist, b

[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

Hi Paul, Thank you for a thorough review! We've addressed most of your comments and submitted a new revision (-09) so that the IESG can look at an updated document during the telechat tomorrow. Some responses below. On 5/14/24 19:23, Paul Wouters via Datatracker wrote: --

[DNSOP]Re: Genart last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

Hi Peter, Thanks for the review! Your feedback has been addressed in the newest revision (-09). Best, Peter On 4/27/24 02:03, Peter Yee via Datatracker wrote: Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (

[DNSOP]Re: Dnsdir last call review of draft-ietf-dnsop-dnssec-bootstrapping-08

Hi Scott, Thanks for the review! Your feedback has been addressed in the newest revision (-09). Best, Peter On 4/18/24 16:36, Scott Rose via Datatracker wrote: Reviewer: Scott Rose Review result: Ready I believe the draft is ready, with a minor typo/nit that don't change the document: In

[DNSOP]Re: Roman Danyliw's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)

Hi Roman, Thank you for your review. Incorporated changes will show up in the -09 revision (will be published later today) and are part of this PR: https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15 Details below. On 5/12/24 23:43, Roman Danyliw via Datatracker wrote:

[DNSOP]Re: Intdir telechat review of draft-ietf-dnsop-dnssec-bootstrapping-08

Hi Benson, Thank you for your review. On 5/12/24 20:43, Benson Muite via Datatracker wrote: Reviewer: Benson Muite Review result: Ready with Nits I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document edito

[DNSOP]Re: [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

seem to improve the situation. Thanks, Peter + Nils (for the "we"/author statements) Thank you. Best regards, David Dong IANA Services Sr. Specialist On Mon Apr 22 11:42:15 2024, scott.r...@nist.gov wrote: On 20 Apr 2024, at 19:38, Paul Wouters wrote: On Sat, 20 Apr 2024, Pete

[DNSOP]Re: Erik Kline's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)

Hi Erik, Thanks for your review! On 5/5/24 00:18, Erik Kline via Datatracker wrote: ## Comments ### S7 * Should there be some kind of registration or reservation for the "_dsboot" meaning and usage described in this document? The authors were wondering as well. We figured that unlike in

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

Another thought on the below ... On 5/2/24 09:42, Philip Homburg wrote: The IETF is not the protocol police so it seems unlikely that signers are going to suddenly remove all traces of SHA1 signing and leave their users in the dark. Independently of SHA-1, it's a reasonable use case to be able

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On 5/2/24 10:37, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: I'm not following what breaks based on the wording I suggested, and I'm not su re why you keep bringing that up. :-) Let's say I sign my zones using some scripts and ldns-signzone. This has

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On 5/2/24 10:19, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 09:58:43 +0200 you wrote: Right. Their policy may be "it's compliant and it works, so why roll?". It'll be easier to push those SHA-1 signers to switch if one can tell them "look, no w you're not compliant anymore".

Re: [DNSOP] Questions before adopting must-not-sha1

On 5/2/24 10:13, Philip Homburg wrote: is getting people to sign there zones in the first place (and adding transport security). But we have time to just kill 140k signed for no technical reasons? In the end the current draft has a strong negative effect on the direct and indirect

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

On 5/2/24 09:42, Philip Homburg wrote: In your letter dated Thu, 2 May 2024 09:21:29 +0200 you wrote: In my view, it's fine to disallow signing with SHA-1-based algorithms to help push signers towards other algorithms. I appreciate the effort, but I'm curious what that means. As far as I k

Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

I agree with all that Paul said (and also the other Paul). In my view, it's fine to disallow signing with SHA-1-based algorithms to help push signers towards other algorithms. For interoperability reasons, barring a security threat, I do not think it is appropriate to discourage validation. My

Re: [DNSOP] Editorial / OCD nit on draft-ietf-dnsop-generalized-notify

Hi Warren, On 4/24/24 16:29, Warren Kumari wrote: While reading draft-ietf-dnsop-generalized-notify - "Generalized DNS Notifications"  I noticed (in the Abstract): "This document extends the use of DNS NOTIFY ([RFC1996] be

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

Hi Paul, The authors certainly don't insist, but we'd need to pick a suitable replacement for the "_signal" label. John proposed "_dnssec-signal" elsewhere in this thread. The authors would like to note that adding "_dnssec-" eats up 8 more bytes, increasing chances that bootstrapping will fa

Re: [DNSOP] [IANA #1362913] expert review for draft-ietf-dnsop-dnssec-bootstrapping (dns-parameters)

Hi Paul, On 4/12/24 22:36, Paul Wouters wrote: However, I would urge the authors/WG to pick a less generic and more specific name than "_signal", such as "_dnssec-bootstrap". Especially because there is also the well known "Signal" message client. Also, in case of future different signaling, the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-08.txt

nssec-bootstrapping-08.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils Wisiol Name:draft-

Re: [DNSOP] AD Review of: draft-ietf-dnsop-dnssec-bootstrapping

Hi Warren, Thank you for your helpful feedback, pls see below. On 4/5/24 22:42, Warren Kumari wrote: Please SHOUT loudly once you've had a chance to address these, and I'll start IETF LC. SHOUTING! We've included your feedback in the -08 revision that I just submitted. The below essentiall

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

Hi Shumon et al., On 3/5/24 08:15, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. I added a PR with some suggestions here: https://github.com/sh

Re: [DNSOP] I-D Action: draft-ietf-dnsop-generalized-notify-01.txt

d DNS Notifications Authors: Johan Stenstam Peter Thomassen John Levine Name:draft-ietf-dnsop-generalized-notify-01.txt Pages: 16 Dates: 2024-03-04 Abstract: This document extends the use of DNS NOTIFY ([RFC1996] beyond conventional zone transfer

Re: [DNSOP] unrelated name server name recommendation

On 3/4/24 15:14, Paul Wouters wrote: It means every registrant, who doesn’t know about DNS, has to create host objects for glue and whenever the ISP changes nameserver names (eg gets bought, sold or merges), or IP address, the ISP has to talk to the registrant to fix things at their registry

Re: [DNSOP] [Ext] About key tags

On 2/29/24 18:06, Paul Wouters wrote:  (If no action is taken, malicious activity might follow now that it is described, but I have not heard of a historical case of it.) This attack was more or less described five year ago: https://essay.utwente.nl/78777/

Re: [DNSOP] [Ext] About key tags

On 3/1/24 14:44, Philip Homburg wrote: Seriously, while I do believe in the need for a coherent DNSKEY resource record set, there are some multi-signer proposals that do not. If the key set has to be coherent, then someone can guard against two keys being published with the same key tag. The

Re: [DNSOP] [Ext] About key tags

On 2/16/24 17:19, Jim Reid wrote: If a zone's signatures and keys are constructed and published in such a way that it causes indigestion in validators, and as a consequence validators fail to return responses for data in that zone, that's a self-inflicted problem and the zone administrator s

Re: [DNSOP] [Ext] About key tags

On 2/15/24 22:53, Mark Andrews wrote: But we can state that they should be avoided when generating new DNSKEYs. BIND has been avoiding key tag collisions for 2 decades now when generating new keys. Multi-signers all have to have the current published DNSKEY RRset which includes *all* DNSKEY

Re: [DNSOP] Post-quantum algorithms for DNSSEC

Hi Petr, On 2/8/24 11:10, Petr Menšík wrote: I just found a draft regarding DNSSec solving post-quantum algorithms [1]. From a talk about it on csnog.eu site. A very surprising fact for it is seems never been mentioned here, where most DNSSec related standards were done recently. It's a rese

Re: [DNSOP] DELEG and parent only resolution

On 2/1/24 13:55, Havard Eidnes wrote: Stupid question time: The target of a DELEG alias cannot be stored in the child zone. It would not resolve if you do. Doesn't this mean that we can never get to an environment where there only exists DELEG records and no NS records, and still have a wo

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

On 2/1/24 13:34, Edward Lewis wrote: The proper response will depend on the reason - more accurately the presumed (lacking any out-of-band signals) reason - why the record is absent. Barring any other information, the proper response should IMHO not depend on the presumed reason, but assume

Re: [DNSOP] Documenting DELEG design trade-offs

On 1/31/24 15:33, Paul Wouters wrote: A new RRtype has a fairly big cost meassures in years, both in terms of DNS software, DNS deployment and worse, in Registrar deployment for Registrant webui elements. Re-using DS is not nice, but neither was Pseudo OPT, EDNS0, etc. But it gains us a decad

Re: [DNSOP] draft-dnsop-deleg-00

On 1/30/24 16:05, Paul Wouters wrote: DNSSEC is not mandatory, it is recommended. One motivation behind DELEG is the ability to use “Aliasmode” to point to an SVCB record elsewhere, which contains a DS record. This way, DS records in various top level domains can be federated under a single

Re: [DNSOP] [Ext] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

On 1/22/24 17:47, Paul Hoffman wrote: I support the publication of this document. As I told the authors a long time ago, I'm still uneasy with all the capitalization ("Client" and so on) because it disagrees with our Terminology RFC, and still offer to do a massive pull request to fix it, b

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-07.txt

-Draft draft-ietf-dnsop-dnssec-bootstrapping-07.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils W

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

For the record, Paul and I sorted these out off-list (for real, this time!), and I'll push a new revision of the draft shortly. ~Peter On 11/20/23 16:49, Peter Thomassen wrote: Hi Paul,  (off-list) To keep the ball rolling, may I nudge you for your opinion on the below? :) Thank you

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

Hi Paul, (off-list) To keep the ball rolling, may I nudge you for your opinion on the below? :) Thank you very much for your input, Peter On 11/13/23 22:30, Peter Thomassen wrote: Hi Paul, Thanks for your thoughts. I'd like to address your points below and would very much appreciate

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

On 11/14/23 12:50, internet-dra...@ietf.org wrote: Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. The IETF datatracker status pag

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

115_wglc/draft-ietf-dnsop-dnssec-bootstrapping-07.txt Please speak up if you have additional feedback. Thanks, Nils + Peter On 11/10/23 13:46, Peter Thomassen wrote: Dear DNSOP, (This is mainly for those who did not attend today's DNSOP session in Prague.) The chairs announced today that th

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

Hi John, On 11/14/23 20:07, John Levine wrote: The chairs announced today that the below WGLC meant to say that some reactions in support of this draft are needed for the document to move forward. (In contrast to only asking for objections.) I think the document is ready EXCEPT that we really

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

Hi Paul, Thanks for your thoughts. I'd like to address your points below and would very much appreciate your follow-up response. On 11/11/23 12:55, Paul Wouters wrote: I have read the document and I am supportive of the idea, but I find the document not ready. Some issues I have with the docum

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

Dear DNSOP, (This is mainly for those who did not attend today's DNSOP session in Prague.) The chairs announced today that the below WGLC meant to say that some reactions in support of this draft are needed for the document to move forward. (In contrast to only asking for objections.) So, if

Re: [DNSOP] NOTIFY: How to locate the target

On 11/9/23 11:45, Jaap Akkerhuis wrote: > Therefore you need to know what endpoint of the registry you need to > send the NOTIFY to. This would just be a service listening for NOTIFYs > to re-initiate the scanning, but it's not a name server at all. Setting > this endpoint in the TLD z

Re: [DNSOP] NOTIFY: How to locate the target

Hi Libor, On 11/9/23 12:12, libor.peltan wrote: i think this issue shall be considered in two split cases: a) when the *registry* is to be notified. [...] b) when the *registrar* is to be notified. [...] The sender of the NOTIFY does not know whether, for this particular parent, the registr

[DNSOP] NOTIFY: How to locate the target

Dear DNSOP, As laid out at the DNSOP session on Tuesday, draft-ietf-dnsop-generalized-notify (and also draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the parent-side endpoint (target) where the child DNS operator can send a NOTIFY for DS update (or other kind of si

Re: [DNSOP] Automated delegation management via DDNS

On 10/27/23 11:51, Johan Stenstam wrote: Extra vantage points are a mitigation for the (prevalent) lack of signatures during bootstrapping; once authentication is handled, there's no need for it. I get that. But, as you know from both the draft and the presentation I made at OARC some week

Re: [DNSOP] Automated delegation management via DDNS

On 10/25/23 18:19, Johan Stenstam wrote: With “scanners” I refer to CDS scanners and CSYNC scanners. These things issue a gazillion DNS queries, over and over and over, with an extremely small catch of “new CDS” or “new CSYNC” records. They get hit by rate limiting measures from the large DNS pr

Re: [DNSOP] scanning doesn't scale, draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

John, On 10/16/23 18:19, John R Levine wrote: On Mon, 16 Oct 2023, Peter Thomassen wrote: 3. the parent obtains a copy of a signaling zone and walks the signaling records published there (at _signal.$NS, such as _signal.jo.ns.cloudflare.com), If you think about it for a moment, I did

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

Hi all, For others following along: Upon Tim's suggestion towards the end of this WGLC, I had sent notes to a handful of ICANN folks who are involved with DNSSEC, but who may not be subscribed this list. I forwarded the WGLC message to them on Sep 29 and extended Tim's invitation to offer rele

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

tc.pp. Smells like a PSL kind of problem ... Thanks, Peter On 10/16/23 12:37, Peter Thomassen wrote: On 10/13/23 10:05, tirumal reddy wrote: The above attack and possible mitigation is discussed in the security considerations section of the draft, please see the snip below:     A client mi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

On 10/13/23 10:05, tirumal reddy wrote: The above attack and possible mitigation is discussed in the security considerations section of the draft, please see the snip below: A client might choose to display the information in the "c", "j", and "o" fields if and only if the encrypted

Re: [DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

John, On 10/13/23 19:48, John Levine wrote: I was looking at these two drafts. The first one says that scanning for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The second one says to scan for DS bootstrap. No, draft-ietf-dnsop-dnssec-bootstrapping doesn't say that at all. The

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-06.txt

Authors: Peter Thomassen Nils Wisiol Name:draft-ietf-dnsop-dnssec-bootstrapping-06.txt Pages: 17 Dates: 2023-10-02 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative

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

On 9/19/23 21:48, Tim Wicinski wrote: This Document will update  7344 and 8078 if approved. The Document updates brings up something I wanted to raise. Peter and I chatted about some simple nits (remove references from the abstract), but I wasn't sure if the sections updating older documents

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-04.txt

al changes Thanks, Peter On 10/2/23 13:33, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-cds-consistency-04.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03

Hi David, I've merged the below changes into the draft, now available on the datatracker as -04. Thanks, Peter On 9/7/23 18:52, Peter Thomassen wrote: Hi David, First of all, thanks for the review! The changes made in response to it (plus a few minor editorial changes I found useful

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-qdcount-is-one

Hi, On 9/28/23 18:59, Tim Wicinski wrote: Please review this draft to see if you think it is suitable for adoption by DNSOP, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. I support adoption and am willing

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

Hi Patrick, On 9/20/23 23:12, pmev...@godaddy.com wrote: I will probably not be able to contribute a lot, but reading it make me think of the following points: Thank you very much for your feedback; even if you don't feel able to contribute a lot, that's VERY helpful :) - I didn't see disc

Re: [DNSOP] RFC 9476 on The .alt Special-Use Top-Level Domain

On 9/15/23 00:19, rfc-edi...@rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 9476 Title: The .alt Special-Use Top-Level Domain Author: W. Kumari, P. Hoffman Finally! Congratul

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

Hi Benno, On 9/14/23 10:14, Benno Overeinder wrote: As Tim mentioned, the chairs paused WGLC or WG Call for Adoptions in August and are now starting the chairs action points in September.  Your draft-ietf-dnsop-dnssec-bootstrapping document is scheduled immediately after this WGLC.  We will c

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

Missing reference: [1]: https://mailarchive.ietf.org/arch/msg/dnsop/vHltEr8mlxsy2nyscqcCF2ZGz8U/ On 9/14/23 09:53, Peter Thomassen wrote: Hi Tim, On 9/13/23 23:05, Tim Wicinski wrote: We Chairs are back and catching up, and want to get things moving again. This starts a Working Group Last

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

Hi Tim, On 9/13/23 23:05, Tim Wicinski wrote: We Chairs are back and catching up, and want to get things moving again. This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis "Initializing a DNS Resolver with Priming Queries" Current versions of the draft is available here: https

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03

Hi David, First of all, thanks for the review! The changes made in response to it (plus a few minor editorial changes I found useful) are recorded here: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/4 I'd appreciate if you can let me know if you agree with them, so I

Re: [DNSOP] I-D Action: draft-thomassen-dnsop-generalized-dns-notify-02.txt

rafts directories. This Internet-Draft is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title : Generalized DNS Notifications Authors : Johan Stenstam Peter Thomassen John Levine Filename: draft-thom

Re: [DNSOP] Cache refreshes like in DNS over CoAP

On 8/4/23 01:29, Petr Menšík wrote: I started thinking, what if we used EDNS0 extension sending version at the client and asked the server if that has changed in the mean time. Lets call the extension cache-refresh for example. It might use SOA version number, which I think common authoritat

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-03.txt

tem of the Domain Name System Operations (DNSOP) WG of the IETF. Title : Consistency for CDS/CDNSKEY and CSYNC is Mandatory Author : Peter Thomassen Filename: draft-ietf-dnsop-cds-consistency-03.txt Pages : 12 Date: 2023-08-01

Re: [DNSOP] I-D Action: draft-ietf-dnsop-zoneversion-03.txt

Thank you; I think the changes look good. Just one nit: "COULD" is not an RFC 2119 key word. Also, I like the new expansion of the SOA record in the abstract ("Star Of Authority") ;-) Best, Peter On 7/31/23 03:24, Hugo Salgado wrote: Dear Group. Here's the last version of Zoneversion draft.

  1   2   3   >