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

r + 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 authors certai

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

2 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 "_signal" label. John proposed "_dnssec-signal"

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

atements) 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, but we'd need to pick a s

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

[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

[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 we want to say

[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

[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

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

ong 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 "_signal" lab

[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

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

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 authors certainly don't in

[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

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

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

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

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.

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]

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

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,

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

-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-ietf-dnsop

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

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:

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

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 hints

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

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.

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

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*

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

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

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

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

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,

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 Wisiol

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 very

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 your

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

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

-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 the below WGLC meant to say

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

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

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

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

[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

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

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

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

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 might c

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.

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

hors: 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 authorita

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

anges 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 Aut

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

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

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!

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

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:

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

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

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

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

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 Abstract

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.

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

On 7/19/23 02:42, George Michaelson wrote: So, given it exists, systems are coded to behave against it, and not having SOME ccTLD (and I would posit gTLD) on it, means they don't match as "first class citizens" the behaviour the PSL brings. Actually, the PSL matching algorithm is such that

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Linda, On 7/18/23 01:58, Linda Dunbar wrote: Thanks for the reply. It is very helpful to better understand the draft. See my suggestions below: [...] [Linda] It would be very helpful if you can include those examples in the draft because the information is not really "arbitrary". It's

Re: [DNSOP] Secdir early review of draft-ietf-dnsop-dnssec-bootstrapping-05

Hi Linda, Thank you very much for your review! Comments below. On 7/17/23 22:32, Linda Dunbar via Datatracker wrote: Here are some minor issues with the draft: - What kind of "arbitrary information about the zones"? any examples? I'm not sure if the objective of your question is to have such

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

-Drafts directories. This Internet-Draft is a work item 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-02.txt Pages

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

-Draft 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 Filename: draft-ietf-dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

Hi Scott, On 7/5/23 21:59, Rose, Scott W. (Fed) wrote: Coming up with this terminology was really challenging. The reason that the Signaling Name is only the prefix, without the Signaling Domain, is that it makes the rest of the spec easier. For example, from Section 3.1: To [...]

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Libor, On 6/26/23 13:56, libor.peltan wrote: My concerns are based on following situation. Imagine that:  - two servers publish inconsistent CDNSKEY+CDS records for some reason, e.g. misconfiguration. This is the exact thing that the draft tries to address.  - this persists for quite

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

Hi Scott, Thank you very much for your feedback -- responses inline. You can find the changes here (will submit to datatracker before the upcoming cut-off):

[DNSOP] With multi-algo DS, what to do if an RRSIG is missing?

Dear DNSOP, It's well-known that DNSSEC multi-signer setups are problematic when providers want to sign with different algorithms. In a hypothetical scenario where signing requirements would be relaxed, I have a very specific question about how resolvers should behave. Apologies for the

Re: [DNSOP] Review of draft-ietf-dnsop-dnssec-validator-requirements-06

On 6/30/23 22:15, Paul Wouters wrote: Section 13: [...] an attacker being able to provide a rogue trust anchor is potentially This is not a very realistic attack. The same section says: On the other hand, mishandling Trust Anchor is likely resulting in a validator unable to

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

rnet-Draft is a work item 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-01.txt Pages : 11 Date:

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Libor, On 6/23/23 17:21, libor.peltan wrote: I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. A combination of a nameserver being unreachable and an other one being misconfigured e.g. in the sense of Section

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Libor, all, On 6/22/23 11:42, libor.peltan wrote: here are my comments to draft-thomassen-dnsop-cds-consistency-03. Thank you very much! "In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

On 6/21/23 17:04, Peter Thomassen wrote: The existing documents lack any words on where specifically to query for CDS/CDNSKEY, and also what to do in case of inconsistencies. Section 3.1 says: [...] Does that clarify the issue? To avoid leaving this "hanging open": After a

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Matthijs, On 6/20/23 07:30, Matthijs Mekking wrote: From the draft:    For example, a single provider may (accidentally or    maliciously) cause another provider's trust anchors and/or    nameservers to be removed from the delegation. This is exactly what happened in my test

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

Hi John, On 6/20/23 20:27, John Levine wrote: It appears that Peter Thomassen said: My take is that the parent should create a _signal subdomain (preferably as a delegation). The per-child target can be queried by prepending, e.g. _notify.example._signal.parent. IN NOTIFY CDS scheme

Re: [DNSOP] DNSOPCall for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi Wes, On 6/9/23 19:43, Wes Hardaker wrote: For lame delegations, I think discussion is needed further. It's unclear from the draft at the moment (and I think it needs to be very clear) about what to do with servers that are lame. It discusses whether or not CDS/CDNSKEY/CSYNC are supposed to

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

Hi Mark, On 6/13/23 16:43, Mark Elkins wrote: There are registries doing CDS scanning now, and registrars testing it. I agree that the flow back to the registrar if the registry does it is ugly so registrar is better where possible. We'll probably end up with both since some registrars aren't

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

On 6/20/23 17:48, Paul Wouters wrote: I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). Agreed. That's not what

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

On 6/20/23 17:51, Paul Wouters wrote:    parent.   IN NOTIFY CDS   scheme port scanner.parent. Why a new RRtype ? Why more stuff in the APEX? Why not: _notify_cds.parent. IN CNAME targetservice.parent. targetservice.parent. IN A . targetservice.parent. IN .

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

Hi, On 6/20/23 17:37, Matthijs Mekking wrote: A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at

Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

On 6/15/23 15:32, Viktor Dukhovni wrote: I agree that client-side validation would be ideal. One important aspect here is to save on the latency caused by extra queries; my impression is that this extra cost is generally considered prohibitive. Not sure what you mean by "generally" (is that

Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

Hi Christian, On 6/14/23 11:55, Christian Huitema wrote: In the old model, we are very concerned about third parties spoofing responses and polluting resolver caches. In a secure transport model, the only parties that can spoof responses are the resolvers themselves: authoritative resolvers

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

Hi Daniel, On 5/18/23 02:26, Daniel Migault wrote: On 5/17/23 22:01, Daniel Migault wrote: > I agree but as far as can see the cap of the TTL with a revalidation will only resync the resolver and the zone more often than could be expected otherwise but does not result in the cached

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

Hi Daniel, On 5/17/23 22:01, Daniel Migault wrote: I agree but as far as can see the cap of the TTL with a revalidation will not only resync the resolver and the zone more often than could be expected otherwise but does not result in the cached RRsets differing from those provided by the

  1   2   3   >