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

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

On 5/12/23 23:09, Viktor Dukhovni wrote: Repost of my belated comments in the thread, apologies about not doing it right the first time... Inspired by Viktor's comments, I spent some time to give the document a thorough review. I'd like to support Viktor's comments on the dependent RRset

Re: [DNSOP] Delegation acceptance checks

Hi Håvard, On 5/7/23 01:10, Havard Eidnes wrote: I guess it depends on what service the registry is actually offering. One way to look at it is that it's offering a service to extend the public DNS name space to registrants. In that scenario it makes perfect sense to do a one-time check on

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

Hi Joe, On 5/5/23 20:45, Joe Abley wrote: Pre-delegation checks add friction to the domain registration process. [...] To look at it another way, why would we give authority to a third party to break our domains just because they are not fully-informed about how we are using them? +1 My

[DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

On 5/4/23 20:07, Havard Eidnes wrote: As an example, it's quite common for people to register a domain and point the DNS at some nameservers which they don't control, and have no relationship with. If this is common, I'm abhorred. Having the delegating party check for service for the

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/2/23 17:52, Joe Abley wrote: On Tue, May 2, 2023 at 11:09, Peter Thomassen mailto:On Tue, May 2, 2023 at 11:09, Peter Thomassen <> wrote: If one of the NS answers non-authoritatively, then it doesn't serve a proper NS RRset, so it's not possible for that server's response to

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/2/23 17:07, Peter Thomassen wrote: On 5/2/23 17:04, Paul Wouters wrote: My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen: A lame delegation is said to exist when one or more authoritative servers designated

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/2/23 17:04, Paul Wouters wrote: My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen: A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS rrset

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On 5/1/23 23:22, Paul Vixie wrote: to be a lame _delegation_ means some error or misconfiguration in the server. normally this means it's supposed to be authoritative but the zone expired or the operator forgot or similar. This, so far, was my understanding of the definition that was

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

-Draft is available from the on-line Internet-Drafts directories. This Internet-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

Re: [DNSOP] Meaning of lame delegation

On 4/12/23 21:17, Havard Eidnes wrote: Reserving the term "a lame delegation" only for the case where none of the delegated-to name servers serve the delegated zone with DNS lookup service does at least not match my current understanding of the term. Much of the discussion of "lame

Re: [DNSOP] [Ext] Meaning of lame delegation

On 4/10/23 15:39, Wessels, Duane wrote: “A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS rrset or by the apex NS rrset answers non-authoritatively for a zone”. ... or by the *child's* apex NS rrset ... (The delegating zone also has

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

On 3/28/23 03:14, Shumon Huque wrote: On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote: On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote: Can we at least state that domains with cyclic dependencies are a bad idea, and may not be

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/15/23 13:48, Shumon Huque wrote: So, if a resolver sends EDNS CompactAnswersOK signal to an authority server, which returns a NODATA+NXNAME proof + RCODE=3 response, then the resolver would have to intelligently manage that answer in its cache. To downstream DO=1 queriers that also set

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/14/23 17:05, Shumon Huque wrote: The NXDOMAIN or NOERROR "state" definitely has to be proven by the signed records inside the message. (...) So, I think the only way we could safely do RCODE replacement for signed responses is by the use of an EDNS signal. I'd like to understand

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/7/23 01:26, Mark Andrews wrote: 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it only has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There appears to be no collision with usage in the NSEC type bitmap,

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

Hi Benno, all, I just went over the updated wording in draft-ietf-dnsop-rfc8499bis-05, and the paragraph https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc8499bis-05.html#section-7-2.36 caught my attention. It uses the term "zone origin", but doesn't say whether it relates to the parent

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/6/23 03:35, Shumon Huque wrote: 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it only has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There appears to be no collision with usage in the NSEC type

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/6/23 02:08, John Levine wrote: The introduction does mention NSEC3. Fair enough! The mention is not part of the compact DoE description, though. It only adds context on how non-compact DoE causes enlarged responses and extra computational load, and is otherwise unrelated to the

Re: [DNSOP] Updated: Compact Denial of Existence

On 3/5/23 23:17, Geoff Huston wrote: 1.) Maybe it's worth pointing out that zones using compact denial SHOULD (MUST?) use NSEC, not NSEC3. Could you please explain your thinking here? In the same way that the ‘compact' NSEC record specifies a minimal span of non-existence across the

Re: [DNSOP] Updated: Compact Denial of Existence

Given that we just abandoned the "lie" moniker, I forgot to mention that Resource Record type to signal the presence of a non-existent name is my favorite sentence in the draft ;-) Cheers, Peter On 3/5/23 18:20, Peter Thomassen wrote: Hi, I like this draft. Some tho

Re: [DNSOP] Updated: Compact Denial of Existence

Hi, I like this draft. Some thoughts: 1.) Maybe it's worth pointing out that zones using compact denial SHOULD (MUST?) use NSEC, not NSEC3. 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it only has meaning for "type covered" fields in signature

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-03.txt

be used to break it ...) Thanks, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-cds-consistency-03.txt Date: Sat, 04 Mar 2023 11:58:16 -0800 From: internet-dra...@ietf.org To: Peter Thomassen A new version of I-D, draft-thomassen-dnso

Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC

On 3/2/23 00:14, Joe Abley wrote: We are not talking about lies. Referring to these kinds of negative responses as lies is confusing and unhelpful. They are signed responses, and the point of signing them is that they are verifiably true. I think "lies" refers to an assumption that a single

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

...@ietf.org To: Johan Stenstam , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-generalized-dns-notify Revision: 01 Title

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

Hi Joe, all, On 2/17/23 21:48, Joe Abley wrote: On Fri, Feb 17, 2023 at 15:03, Peter Thomassen mailto:pe...@desec.io>> wrote: I am not sure whether draft expiry impacts the WG document handling process in any way. I would not worry. You can always reset the timer by bumping the v

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

Hi Michael, Chairs, On 2/17/23 14:10, Michael Bauland wrote: we've recently implemented the DNSSEC bootstrapping as defined in this draft in our registry system TANGO as well as in the CORE registry system. I just realised that the draft is going to expire tomorrow. What are the next steps?

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

Hi Robert, Thanks for your review. On 1/5/23 13:22, Robert Wilton via Datatracker wrote: Minor level comments: (1) p 2, sec 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

Hi Murray, On 1/4/23 23:25, Murray S. Kucherawy wrote: I can see you've added the "no actions" IANA section, which solves part of my DISCUSS.  But I'd also like to understand why it is that handling names via IANA was rejected.  Was this discussed in the WG? I don't know off the top of my

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

Hi Éric, Thank you for your review! On 1/2/23 14:59, Éric Vyncke via Datatracker wrote: -- COMMENT: -- # Éric Vyncke, INT AD, comments for

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

Hi Roman, Thank you for your review. On 12/31/22 00:16, Roman Danyliw via Datatracker wrote: -- COMMENT: -- Thank you to Catherine Meadows for the SECDIR

Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

Hi Lars, Thank you for your review; please see inline. On 12/22/22 13:22, Lars Eggert via Datatracker wrote: -- COMMENT: -- # GEN AD review of

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-catalog-zones-08

Hi David, Thank you for your review. Please see inline. On 12/27/22 18:14, David Blacka via Datatracker wrote: Reviewer: David Blacka Review result: Ready with Nits Reviewer: David Blacka Review Result: Ready with Nits Hi, I'm the designated DNS Directorate (dnsdir) reviewer for this

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

Hi Erik, Thank you for your review! On 12/22/22 21:02, Erik Kline via Datatracker wrote: Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: No Objection ... ## Nits ### S4.3 * "Member-specific properties are described in Section 4.3" ->

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

On 12/15/22 01:59, Martin Schanzenbach wrote: On 14.12.22 12:25, Paul Wouters wrote: On Dec 14, 2022, at 11:29, Eliot Lear wrote: On 14.12.22 17:13, Paul Wouters wrote: "bob.foo.alt" still squarely falls into "my" namespace It is indeed not “yours”. ... from the perspective of DNS.

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

On 12/15/22 15:01, Vladimír Čunát wrote: On 15/12/2022 14.45, Peter Thomassen wrote: In what sense is this document "informational" when it is called "validator requirements", or, conversely, in what sense does it spell out "requirements" when it is only "info

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

Hi, In what sense is this document "informational" when it is called "validator requirements", or, conversely, in what sense does it spell out "requirements" when it is only "informational" and not "standards track"? Best, Peter On 10/19/22 21:21, Tim Wicinski wrote: This starts a

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

Dear DNSOP, I support advancing the document in its current form. There's a broken sentence in Section 5: "Care must be taken to ensure that the mapping of thepseudo-TLD into its corresponding non-DNS name resolution system inorder to get whatever security is offered by that system." -->

[DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)

ion Notification for draft-thomassen-dnsop-generalized-dns-notify-00.txt Date: Mon, 28 Nov 2022 13:10:10 -0800 From: internet-dra...@ietf.org To: Johan Stenstam , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-00.txt has been successfully submitted by Peter Thomas

Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex

Hi Vladimir, Thanks for your feedback! Please see below. On 11/11/22 19:01, Vladimír Čunát wrote: It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g.

Re: [DNSOP] .alt filtering in recursive servers

On 11/8/22 10:33, Mark Andrews wrote: Filtering .alt in recursive servers should be a MUST NOT. Whenever SHOULD or MUST (NOT) is used, or we're making a promise for the indefinite future, or we're (in the case of NXDOMAIN synthesis) altering behavior from the client's perspective (by

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on historical definition of bailiwick

On 11/3/22 17:44, Benno Overeinder wrote: Questions: 1. Move Bailiwick to historical. 1a.  During the interim, there was a (feeling of) consensus to drop a formal definition of "bailiwick", but keep a historical definition (how it was interpreted by) of "bailiwick". Also do not

[DNSOP] draft-thomassen-dnsop-mske

not sure myself if this is how it should be done, but it will be interesting to learn what people think. Best, Peter A new version of I-D, draft-thomassen-dnsop-mske-00.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

On 10/20/22 15:05, Brian Dickson wrote: I fear those challenges mean that GNS simply won't be possible to properly have registry entries, and without GNS, or possibly using GNS as an alternative namespace example, the registry makes no sense. Here's the problem that the GNS draft includes

Re: [DNSOP] IETF 115 Call for Agenda Items DNSOP WG

Hi, On 10/17/22 16:42, Benno Overeinder wrote: This is a Call for Agenda Items for the IETF 115 in London, UK. DNSOP WG is scheduled on Tuesday, 8 November at 09:30-11:30 (GMT/UTC). (See for IETF 115 agenda https://datatracker.ietf.org/meeting/115/agenda) Please email the chairs with your

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

On 10/7/22 19:46, Roy Arends wrote: Perhaps: What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification; [RFC2065] being the first, [RFC2535] being the second. Earlier iterations have not been deployed on a significant scale. Throughout this document, "DNSSEC" means the

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

On 10/7/22 15:41, Warren Kumari wrote: I'm personally fine with Paul's proposed text, minor tweaks on "incarnations", Peter's modifications, whatever. I don't feel very strongly either way. Cheers, Peter -- https://desec.io/ ___ DNSOP mailing

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

On 10/5/22 20:25, Paul Hoffman wrote: On 10/5/22 19:56, Paul Hoffman wrote: I propose to replace that paragraph with: What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}. However, earlier incarnations of DNSSEC were thinly deployed and

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

Hi, On 10/5/22 19:56, Paul Hoffman wrote: I propose to replace that paragraph with: What we today call "DNSSEC" is the DNSSEC specification defined in {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}. However, earlier incarnations of DNSSEC were thinly deployed and significantly less visible than

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-01.txt

'm looking forward to your feedback. Thanks, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-cds-consistency-01.txt Date: Wed, 14 Sep 2022 17:44:59 -0700 From: internet-dra...@ietf.org To: Peter Thomassen A new version of I-D, draft-thomassen

Re: [DNSOP] Use of CNAMEs for NS Records

Hi Tobias, On 8/26/22 07:31, Tobias Fiebig wrote: At least one NS is a CNAME and zone has more than one NS: Months: 83 avg: 0.0713% min: 0.0165% max: 0.8398% median: 0.0387% All NS are CNAME and zone has more than one NS: Months: 83 avg: 0.6690% min: 0.0123% max: 1.7653% median: 0.3242% Isn't

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

Hi Joe, On 8/24/22 10:13, Joe Abley wrote: So the question is not whether to allow mixed capitalisation; the question is why we would intentionally change a fundamental expectation of domain names to accommodate names and resolution protocols that we largely don't have any requirements for

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On 8/23/22 18:37, Joe Abley wrote: On Aug 23, 2022, at 18:07, Peter Thomassen wrote: Unaware applications: yes, perhaps mixed; but as they're unaware, they'll ignore the carve-out regardless of case Aware applications: ... will produce only what's compliant. And the question here

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On 8/23/22 17:43, Paul Hoffman wrote: On Aug 23, 2022, at 2:00 PM, Joe Abley wrote: I may have missed something (I have been trying very hard) but it seems a little weird for the wire format for a definitively non-existent domain name to be specified at all, to be honest; I'm not sure

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

On 8/23/22 12:31, Warren Kumari wrote: But my question would still be: Should the registry pose limitations, then, on the 2LD? Because you cannot really have the one without the other? I don't think that it can (or should). This is just a suggestion… I had considered wording it as  "it

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

On 8/23/22 11:38, Paul Hoffman wrote: On Aug 23, 2022, at 7:47 AM, Warren Kumari wrote: So, I'd think something like: "For compatibility with existing applications and to maximize interoperability, it is recommended that names that end in .alt follow DNS name syntax." (or something similar

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

On 8/23/22 07:02, Ray Bellis wrote: There will be a very long tail of systems out there that do not know about ".alt". How would those systems respond when passed a domain-style name that does not meet domain-style syntax rules (specifically those for total length and label lengths) ?

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

the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors : Peter Thomassen

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

On 8/17/22 10:20, Paul Hoffman wrote: On Aug 17, 2022, at 6:19 AM, Timothy Mcsweeney wrote: Are you proposing dot Alt, or are you proposing dot Alt dot.? Please see , the draft in question. It has already gone through WG Last

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 8/15/22 17:27, Peter Thomassen wrote: OTOH, if we don't give guidance, people (not GNS specifically) will just continue camping on more ASCII TLDs for non-DNS uses. That's the exact thing we are aiming to avoid. Correction: I meant "letter-only TLDs", not ASCII TLDs.

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Hi Martin, On 8/15/22 14:49, Schanzenbach, Martin wrote: I do not agree that the registration policy should allow multiple entries for the same subdomain or be "free for all" as it is currently in the draft. ...> So, from my authors hat, I would appreciate FCFS That's a good point, and I

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 8/13/22 15:26, Paul Vixie wrote: what people want is domain names. right now dns camps onto the whole space of domain names, because it expected to be the last and final deliverer of domain names. it's called the "domain name system" after all. dns should decamp from some part of the

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On 8/13/22 11:57, John R Levine wrote: That said, I believe what Warren is suggesting is more of a ten thousand foot view of the namespaces issue; and if that finds a way to allow innovation without fragmentation, it would be beneficial for DNS and non-DNS names alike. That would be swell,

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

On 8/1/22 12:01, Paul Vixie wrote: I agree and I think publication of these drafts would be a good idea (may be with status Experimental since, as Joe Abley said, there is clearly no IETF consensus). Note that I am skeptical about their use: most people who "preempt" .eth, .bitcoin, .web3 or

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

Dear WG, I'm requesting help with the below issue. It would be great if somebody could advise how to proceed. Thanks! Best, Peter On 6/22/22 13:08, Peter Thomassen wrote: On 6/22/22 12:39, Peter Thomassen wrote: So I agree that strictly "replacing" Section 3 may be too much, but

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

On 7/12/22 15:54, Tim Wicinski wrote: This starts a Call for Adoption for Negative Caching of DNS Resolution Failures The draft is available here: https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/

Re: [DNSOP] Call for Adoption: Using Service Bindings with DANE

On 7/12/22 15:51, Tim Wicinski wrote: This starts a Call for Adoption for Using Service Bindings with DANE The draft is available here: https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/ Please review this draft

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-00.txt

Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-cds-consistency-00.txt Date: Sat, 09 Jul 2022 04:36:46 -0700 From: internet-dra...@ietf.org To: Peter Thomassen A new version of I-D, draft-thomassen-dnsop-cds-consistency-00.txt has been

Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

On 6/28/22 02:56, Paul Wouters wrote: Does the WG think this is a reasonable thing to pursue? I think this could be an excellent super short RFC that Updates: 7344. Reading RFC 7344 more closely, I stumbled upon this paragraph in Section 4.1: o Signer: MUST be signed with a key that is

Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

Hi Bob, On 6/28/22 16:20, Bob Harold wrote: But the parent NS set is not covered by DNSSEC, and thus could be spoofed?? (Wish we could fix that!) The parental agent (registry, registrar) has off-band definite knowledge of the delegation's NS records. As an example, the .edu operator knows

Re: [DNSOP] Updating RFC 7344 for cross-NS consistency

On 6/28/22 02:56, Paul Wouters wrote: I thus propose to update RFC 7344 along the lines of (2), such that it is REQUIRED to retrieve CDS/CDNSKEY records using queries to all authoritative nameservers. The question is now how to phrase this exactly. Do we want the parent to use its

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

On 6/27/22 22:05, John Levine wrote: But there is a great deal of software that expects the names it uses to look like hostnames, and won't work with anything else. The software for new applications which would use a _foo pseudo-TLD namespace is not yet written. It is for future

[DNSOP] Updating RFC 7344 for cross-NS consistency

Dear DNSOP, RFC 7344 describes DS rollovers using CDS/CDNSKEY records. It does not prescribe how the CDS/CDNSKEY records should be retrieved. On the contrary, it is fully left open (Section 6.1): How the Parental Agent gets the CDS/CDNSKEY RRset may differ. Below are two examples of

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-15.txt

I am proposing to reserve all top-level underscore labels (_*) for special use. Why? My understanding of the problem is: (1) There are several naming systems. Some of them can be enabled/disabled via nsswitch; others are completely "disconnected" from OS resolution, but still use dotted

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

On 6/22/22 08:36, Brian Dickson wrote: The whole point of the bootstrap mechanism is to onboard the /initial/ DS record for a particular domain securely. Once the initial DS is present, there is no further need for bootstrap. For a single domain, the only purpose of doing what you propose

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

On 6/22/22 14:40, Paul Wouters wrote: Unfortunately, the reverse zone is very often out of reach for those who use the IP range and trying to do classless reverse delegation (RFC 2317) for those who have less than a /24 is even harder to get. That's exactly right, DNS operators will in

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

Hi Rubens, On 6/22/22 05:29, rubensk=40nic...@dmarc.ietf.org wrote: On 22 Jun 2022, at 00:07, John Levine mailto:jo...@taugh.com>> wrote: In practice, I doubt that enough reverse zones are signed or that the provisoning crudware that people use for reverse zones would work often enough to be

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

On 6/22/22 12:39, Peter Thomassen wrote: So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC 8078 Section 3? I was thinking

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

Libor, On 6/19/22 16:41, libor.peltan wrote: However, I'd like to discuss if it really should *replace* RFC8078, Section 3 whatsoever. Sure, it's definitely more secure than the rather quirky Accept after Delay/Checks/Challenge procedures, but it adds also more limitations, as described in

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

Hi John, On 6/19/22 19:30, John Levine wrote: It appears that libor.peltan said: Alternatively, we may say that the RFC8078 bootstrapping is deprecated, but still, it doesn't mean that we replace it. That seems reasonable. Does anyone actually do the current TOFU-ish bootstrap? Yes:

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

net-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors : Peter Thomassen Nils Wisiol

Re: [DNSOP] [Ext] More input for draft-ietf-dnsop-dnssec-bcp?

On 5/24/22 17:48, Wes Hardaker wrote: However, I noticed that three of the RFCs listed in the draft are from 202x, and likely more will have to be added in the future. That made me wonder: How do we update this collection? That's an excellent question! The likely, not-excellent answer is "we

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

On 4/27/22 15:11, Bob Harold wrote: To avoid (C)DS at an apex under the _boot tree, one could use another _name like: _nsboot.dedyn.io._boot.ns1.desec.io .  CDS ... So the CDS records in this new scheme are never at an apex, but one level down under a new "_nsboot"

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

points out a problem that is implicit in the current draft, and then discusses various possible solutions (the hashed scheme being but one if them). Thanks, Peter On 11/9/21 22:53, Paul Wouters wrote: On Tue, 9 Nov 2021, Peter Thomassen wrote: On 11/9/21 3:56 PM, Paul Wouters wrote:  Now let's

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

ft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors : Peter Thoma

Re: [DNSOP] More input for draft-ietf-dnsop-dnssec-bcp?

Hi, On 4/25/22 23:50, Paul Hoffman wrote: Greetings. I posted the -01 about ten days ago, and have not heard anything since then. The chairs indicated that they wanted this fast-tracked, so I'll nudge here for more input, either on the WG mailing list on in the repo

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

On 4/22/22 20:46, Bob Harold wrote: Minor edit: In "1. Introduction", third paragraph, first sentence: " these dependencies result often result " the first "result" should be removed. Thanks for catching this! I pushed a fix that will be included in the next version. Best, Peter --

Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

I reviewed the draft and think it is suitable for adoption. I'm willing to contribute text and reviews. ~Peter On 3/25/22 16:35, Benno Overeinder wrote: As with the previous Call for Adoption today, at this week's DNSOP meeting at IETF 113, we announced that we are initiating a Call for

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

On 3/28/22 20:34, Mark Andrews wrote: About the only part not already specified is matching DS to DNSKEY using PRIVATEDNS but as you can see it is obvious to anyone with a little bit of cryptographic understanding. That creates problems plus complexity, which I find very undesirable.

Re: [DNSOP] [Ext] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

On 3/26/22 02:21, Paul Hoffman wrote: On Mar 25, 2022, at 5:59 PM, Joey Deng wrote: During my reading of DNS and DNSSEC, I found another RFC (RFC 7129) very helpful in understanding the motivation from NSEC to NSEC3, besides RFC 5155, but it is not listed in the draft above (maybe

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

On 11/5/21 1:07 AM, Paul Wouters wrote: In general, the problem is that we need to make it easier for the DNS hoster to enable DNSSEC when their customers are non-technical. I think this draft does properly extend RFC 8078 and even think this document could deprecate the "Accept after wait"

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-03.txt

he meeting - Editorial changes. Looking forward to the next steps! Thanks, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-03.txt Date: Mon, 29 Nov 2021 15:57:25 -0800 From: internet-dra...@ietf.org To: Nils Wisiol , Peter

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

Hi Paul, On 11/9/21 3:56 PM, Paul Wouters wrote: Now let's consider bootstrapping for dedyn.io *itself* (not one of its children!).  The location of the bootstrapping records for this domain would be dedyn.io._boot.ns1.desec.io, which is the same as the name of the *zone* which constains

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

On 11/9/21 3:29 AM, Paul Wouters wrote: - IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73. But would they hit 255 ? No, this was only an illustration: Had there been some standard which prevented such long names, then IPv6 reverse DNS names would not have been possible.

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

-0700 From: internet-dra...@ietf.org To: Nils Wisiol , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-02.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-dnssec-bootstrapping Revision

[DNSOP] DNSSEC Bootstrapping: Draft updated, feedback welcome

ssec-bootstrapping-01.txt Date: Thu, 23 Sep 2021 08:56:37 -0700 From: internet-dra...@ietf.org To: Nils Wisiol , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-01.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name:

Re: [DNSOP] DS glue for NS draft

On 8/19/21 7:57 PM, Brian Dickson wrote: On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen mailto:pe...@desec.io>> wrote: Hi Brian, The proposal aims to authenticate parental NS and glue records by having the parent sign their hash digests, embedded in new types of DS records.

Re: [DNSOP] DS glue for NS draft

Hi Brian, The proposal aims to authenticate parental NS and glue records by having the parent sign their hash digests, embedded in new types of DS records. 1.) The separation of the data which requires authentication (parental NS + glue records) from the place where authentication is provided

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

On 7/7/21 7:54 PM, Warren Kumari wrote: Obviously there is a tradeoff here -- privacy vs deployment. 1: while it's **possible** that there is a delegation point at the underscore label, (IMO) it is unlikely. If there is no delegation, you will simply be coming back to the same server again and

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt

it, and possibly have a discussion about it. Is there any interest in this? Thanks, Peter Forwarded Message Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt Date: Tue, 29 Jun 2021 17:46:53 -0700 From: internet-dra...@ietf.org To: Peter Thomassen

<    1   2   3   >