[DNSOP]Re: Our reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.

Warren, Wes, et al, TL;DR: Yes and No. Yes: Thanks for the initiative to move this into an IANA Registry. This is the right idea, and what I've been advocating for the past many months. No: I don't think the scheme is quite right. In my view, an algorithm moves through seven phases during its

[DNSOP]Further comment re algorithm life cycles

1:11 PM Steve Crocker wrote: > Warren, Wes, et al, > > TL;DR: Yes and No. > > Yes: Thanks for the initiative to move this into an IANA Registry. This > is the right idea, and what I've been advocating for the past many months. > > No: I don't think the scheme

Re: [DNSOP] Proposal: Whois over DNS

John and Bill, Let me offer a slightly different perspective. The proposal would provide a way for domain name owners to publish information that they want published, and it would, of course, be publicly available. The pre-GDPR whois system collected contact information from registrants irrespec

Re: [DNSOP] Proposal: Whois over DNS

> > Folks, Let me share a somewhat broader perspective. I was chair of the ICANN board for several years. During that period, I attempted, without success, to reset the dialog related to whois. After I stepped off the board in late 2017, I decided to take another run at the problem. I've been

[DNSOP] Proposal: Whois over DNS

Folks, Let me share a somewhat broader perspective. I was chair of the ICANN board for several years. During that period, I attempted, without success, to reset the dialog related to whois. After I stepped off the board in late 2017, I decided to take another run at the problem. I've been work

Re: [DNSOP] Special-use TLDs in resolvers

At the risk of revealing that I haven't been following this thread carefully, I don't understand how a resolver is supposed to know all of the special names. Resolvers that are configured to know that invalid, local, onion, and test are special will not know about the next name that's put on the s

Re: [DNSOP] Special-use TLDs in resolvers

Ack. Tnx. On Fri, Aug 16, 2019 at 11:56 AM Joe Abley wrote: > On 16 Aug 2019, at 10:59, Steve Crocker wrote: > > > At the risk of revealing that I haven't been following this thread > carefully, I don't understand how a resolver is supposed to know all of the > sp

Re: [DNSOP] On .ZZ

I too find myself puzzled about trying to assign ZZ for this role. I strongly prefer we stay far away from using two letter codes for anything other than ISO 3166 assignment of country codes for ccTLDs. (I even think we made a mistake in allowing two letter codes in Cyrillic and Greek.) Postel's

[DNSOP] Fwd: Adding DNS providers to the registration

ve -- Forwarded message - From: Steve Crocker Date: Sun, Jan 19, 2020 at 12:16 PM Subject: Adding DNS providers to the registration To: DNSSEC Provisioning I hereby propose that RDDS be extended to include the DNS provider(s). I believe that making DNS providers visible in the

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

Shumon, You're asking the right questions: This also begs the question: should we (in another document) update RFC 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact it is being ignored? Frankly, I've always been a bit perplexed by this text, since it has no accompanying

[DNSOP] Looking for panelists for DNSSEC provisioning session at Cancún ICANN meeting in March

ss that if the registrant could add the names of his DNS providers into the registration details, it would make both of these coordination processes much easier. Thanks, Steve Crocker ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Measuring DNS TTL clamping in the wild

I would be very interested in a bit more precision here. Is there a way to say what is permissible vs impermissible re TTLs, and is there a way to say what is desirable vs undesirable re TTLs? We all understand that longer TTLs reduce the frequency of refresh at the expense of slower response

Re: [DNSOP] Terminology question: split DNS

I haven't been following the current thread but I have encountered this topic before and I have thought about the implications for DNSSEC. The terminology of "split DNS" -- and equivalently "split horizon DNS" -- is, in my opinion, a bit limited. It's not too hard to imagine further carve outs.

Re: [DNSOP] IETF102 Actions and Updates

I've been watching actively but quietly. Stellar work! Congratulations! Steve Crocker On Fri, Jul 20, 2018 at 2:40 PM, Tim Wicinski wrote: > > All > > Thanks for a pretty productive week and thanks for > breaking in our new chair slowly. > > Rough Minutes hav

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

The passage below puzzles me. Why do you want servers to get the root zone from less trusted sources? And why does the source matter if the zone entries are DNSSEC-signed? Thanks, Steve Sent from my iPhone > On Jul 26, 2018, at 7:33 PM, Mark Andrews wrote: > > Additionally most nameserver

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

Let me play Candide and stumble into this naively. If we’re imagining very wide spread distribution of the root zone, say 100,000 or 1,000,000 local copies distributed twice a day, I would expect the evolution of a set of trusted sources and the use of some existing secure transport protocol to pr

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

It feels like this discussion is based on some peculiar and likely incorrect assumptions about the evolution of root service. Progression toward hyper local distribution of the root zone seems like a useful and natural sequence. However, the source of the copies of the root zone will almost ce

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

ot zone from random untrusted sources. Steve On Sun, Jul 29, 2018 at 11:50 AM, Joe Abley wrote: > On Jul 29, 2018, at 12:19, Steve Crocker wrote: > > > It feels like this discussion is based on some peculiar and likely > incorrect assumptions about the evolution of root service

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

> Hi Steve, > > On Jul 29, 2018, at 15:09, Steve Crocker wrote: > > > As an individuals, you, I, or anyone else, can do whatever we like, of > course. On the other hand, as system designers we presumably look at the > overall system and try to put in place an operational str

Re: [DNSOP] DNSSEC threshold signatures idea

How do you prevent compromise of the central service? Steve On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández wrote: > On 23:19 06/09, Mukund Sivaraman wrote: > > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote: > > > Hi Mukund. > > > I talked about this to Davey in

Re: [DNSOP] DNSSEC threshold signatures idea

Let me flag a key point. You said this scheme will *detect* faked signatures. If you want to *prevent* faked signatures, you need additional structure. Steve On Thu, Sep 6, 2018 at 3:22 PM, Hugo Salgado-Hernández wrote: > On 15:08 06/09, Steve Crocker wrote: > > How do yo

Re: [DNSOP] DNSSEC threshold signatures idea

My focus is on preventing the orchestrator from faking the signatures. Steve Sent from my iPhone > On Sep 6, 2018, at 3:52 PM, Hugo Salgado-Hernández wrote: > >> On 15:25 06/09, Steve Crocker wrote: >> Let me flag a key point. You said this scheme will *detect* faked >

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

I won't be in Bangkok, so I won't be able to participate. In my view, there were two specific problems that dominated the rollover problem. The first was the inability to determine the configuration of querying resolver. The second was the in ability to notify resolver operators if it was eviden

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

omever is responsible > for rolling the key. Perhaps the way to eliminate the things that made the > first rollover hard is just to keep doing it until it's officially easy. > > > Joe > > On 29 Oct 2018, at 18:46, Steve Crocker wrote: > > I won't be in Bangkok, so

Re: [DNSOP] [Ext] "The Forgotten Object Lesson Of The Dyn DDoS Attack"

validity. If I can be helpful moving this forward, I’ll be glad to help. Steve Crocker Sent from my iPhone > On Jan 3, 2019, at 9:33 PM, Tim Wicinski wrote: > > Actually draft-huque-dnsop-multi-provider-dnssec was adopted, but the author > (whom I work with and has heard from >

Re: [DNSOP] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

Hugo, et al, I think the experience is exactly the opposite, i.e. these names will *always* show up in the DNS. As a consequence, I would argue that names being used for any of these purposes should not be delegated into the DNS root unless it’s for the same purpose. Thus, if the village of E

Re: [DNSOP] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

. Steve Crocker (Founding chair of ICANN’s SSAC; currently chair of the ICANN board, speaking as an individual not officially on behalf of the ICANN board) On Jul 19, 2015, at 3:26 AM, Hugo Maxwell Connery wrote: > Hi, > > My reflections on this interesting discussion: > >

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

Five years is not enough. Think in terms of 20 to 50 years. On Aug 10, 2015, at 3:10 PM, John Levine wrote: >>> I believe that the registry we have currently defined doesn't do a great >>> job of capturing the actual needs here. > > Agreed. It seems to me that there are two somewhat separat

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

Ok, thanks. Steve On May 10, 2016, at 11:54 AM, 神明達哉 wrote: > At Tue, 10 May 2016 15:04:56 +0200, > Stephane Bortzmeyer wrote: > >>> This is true, but I suspect it would be pretty easy for this type >>> of attacker to circumvent the effect if and when the nxdomain-cut >>> behavior is more

Re: [DNSOP] DNSSEC operational issues long term

I recall a discussion several years about having a site that would have all of the keys accumulated over time. A query to it would return the current key. It's roughly analogous to using a root hints file to find a current root server and from that the full set of current servers. This wouldn

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

I am strongly opposed to unsecured delegations in the root zone. No matter what the problem is, an unsecured delegation is not the answer. Steve > On Dec 14, 2016, at 11:11 AM, Suzanne Woolf wrote: > > Hi all, > > DNSOP participants who are interested in the special use names problem might

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

that you are assuming is so obvious that > you don't need to tell us about it? :) > >> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker wrote: >> I am strongly opposed to unsecured delegations in the root zone. No matter >> what the problem is, an unsecured d

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

ason as it applies to the case of names that are globally > unique. > > On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker <mailto:st...@shinkuro.com>> wrote: > The latter. All DNS answers at all levels should be signed to assure the > querier of the integrity of the answer.

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

to do no delegation from the root for .homenet and just > ensure that that name never gets registered and published. > > "If it's stupid and it works, it's not stupid". > > Mike > >> >> On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker >

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

Ted, I am truly confused by your note. I sense I am missing something fundamental. See specific questions below. Thanks, Steve > On Dec 15, 2016, at 12:20 PM, Ted Lemon wrote: > > On Dec 15, 2016, at 11:05 AM, Jacques Latour > wrote: >> Where do you delegate

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

Are you also expecting ALT will never be delegated in the root? If it were to be delegated in the root, what impact would that have on the uses you have in mind? Steve Crocker [I am having trouble sending from st...@shinkuro.com, but I am receiving mail without trouble. Please continue to

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

And just to stir the pot a bit, what would you have ICANN do if someone applies for .alt as a top level domain? Is it ok if we say yes and delegate the name? If not, what is the basis for us to say no? Steve Crocker [I am having trouble sending from st...@shinkuro.com, but I am receiving

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

We (ICANN) have no mechanism or process for inserting a DNAME record into the root. We do have a process for considering the general issue, but, so far as I know, no one has yet brought that idea into the ICANN/PTI arena. Steve Crocker [I am having trouble sending from st...@shinkuro.com, but

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

scope for the homenet working group. The working group understands that a > process needs to be invented, and I believe that the document says so. > >> Steve Crocker has already stated that he does not believe that entries that >> cannot be DNSSEC signed belong in the DNS root zo

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Thanks for the quick response. > On Mar 20, 2017, at 5:14 PM, Ted Lemon wrote: > > On Mar 20, 2017, at 4:57 PM, Steve Crocker wrote: >> First, neither my opinion as an individual nor my opinion as an official of >> ICANN should be considered definitive, normative or

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Before addressing the questions you've asked, let me about the rest of the picture. How do names get assigned within the local homenet domain? Steve Sent from my iPhone > On Mar 20, 2017, at 9:25 PM, Ted Lemon wrote: > > I'm curious what Russ and Steve think about this as an alternative. I

Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

On the other hand, might there be value in seeing how much errant traffic goes to the root so it can be reported and used to inform vendors, network architects, network administrators, et al? Given the amount of bogus traffic already goes to the root, I’m not immediately worried this will incre

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

On Mar 15, 2013, at 11:21 AM, Hugo Salgado wrote: > > On 03/14/2013 07:44 PM, Joe Abley wrote: >> (Aside: if AS112++ servers were happy to slave the zone, e.g. from ICANN, we >> could sign it and install a DS RRSet in the ARPA zone. This would have the >> side benefit that we could track from

Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor

Tony, Nice post. This reminds me of some thinking along these lines I did several years ago, which was based on the analogy of how stock market prices are published. (Things have shifted quite a bit with the availability of real-time feeds on the Internet, so give me some latitude here.) In

[DNSOP] Signaling Cryptographic Algorithm Understanding (Was: key lengths for DNSSEC)

Perhaps this a good time for me to plug adoption of Signaling Cryptographic Algorithm Understanding, per RFC 6975. The sooner this gets included in the implementation on the query side, the sooner we will have solid information on when it will be ok to phase out an obsolete algorithm. This is

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

Sent from my iPhone > On Jul 16, 2014, at 10:02 PM, "Guangqing Deng" wrote: > > This sounds very needful and useful especially for new comers. And I once had > been puzzled by "DNS recursive server" and "DNS caching server" for a > relatively long time. I still am :) Steve > > Guangqing

Re: [DNSOP] terminology: glue

Glue records are necessary to prevent circular references, i.e. to cut the loop. The most obvious and common situation is where the name server is below the cut. If the address of the name server were not included, the querying system would keep being referred to the parent, i.e. stuck in a lo

Re: [DNSOP] terminology: glue

Vixie wrote: > > > Steve Crocker wrote: >> Glue records are necessary to prevent circular references, i.e. to cut the >> loop. ... > > after kashpureff, circular references are no longer allowed. XYZ.NET > cannot have only nameservers named within within XYZ.O

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

These comments might be more usefully said in the relevant ICANN forums. Steve On May 17, 2015, at 7:07 PM, Paul Vixie wrote: > > > John Levine wrote: >>> ... >> >> I would be much happier with a statement that said "the names are >> blocked indefinitely, and here's the plan for the $4 milli

Re: [DNSOP] Some distinctions and a request - Have some class?

See the end for something provocative. > ICANN do say what strings in the name space should be TLDs. > > IETF do say what strings in the name space should NOT be TLDs. > > The rest are just strings waiting to end up in one of the two groups. > > Patrik Perfectly stated. There is really just

[DNSOP] Thoughts on the top level name space

This note is an attempt to describe how things work today and to bring some precision to the current discussion. Except very mildly under the ISSUES section at the end, this note does not propose anything new. This is quick draft. There might be errors, missing pieces, assumptions, etc. Plea

Re: [DNSOP] Some distinctions and a request - Have some class?

On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer wrote: > On Sat, Jul 04, 2015 at 09:16:17AM -0700, > Steve Crocker wrote > a message of 21 lines which said: > >> except for the additional load it places on the root servers, > > RFC 7535 could be a solution. >

Re: [DNSOP] Some distinctions and a request - Have some class?

ng some tld strings flaky so as to encourage developers to avoid DNS for > those names could be met statelessly. For example delegate them to localhost. > > On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer > wrote: > On Sat, Jul 04, 2015 at 09:16:17AM -0700, > Steve Cr

Re: [DNSOP] Top level names -- precision re categories and where are are the uncertainties?

intended to stimulate a discussion. Thanks, Steve On Jul 7, 2015, at 4:50 AM, Jaap Akkerhuis wrote: > Steve Crocker writes: > >> Folks, >> >> I`ve been watching the dialog on this list regarding to level names. >> Attached is my attempt to clarify the sta

Re: [DNSOP] Thoughts on the top level name space

On Jul 6, 2015, at 5:08 PM, Edward Lewis wrote: > On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker" > wrote: > >> 3. (ICANN) Two letter Latin characters that have not yet been assigned by >> the ISO 3166 maintenance agency but might be in the future. Name

Re: [DNSOP] Thoughts on the top level name space

Thanks. Minor comments in line below. Steve On Jul 7, 2015, at 5:42 AM, Jaap Akkerhuis wrote: > Not taking a stand on this, but some more remarks on these thoughts. > > Edward Lewis writes: > >> >> On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker" >&g

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

On Sun, Oct 6, 2024 at 12:24 PM S Moonesamy wrote: > Hi Steve, > At 11:31 AM 05-10-2024, Steve Crocker wrote: > >Thanks for your comments. This submission was triggered by the Red > >Hat snafu. Red Hat removed an algorithm from the library when they > >determined it

[DNSOP] Re: DNSOPDNSOPdraft-crocker-dnsop-dnssec-algorithm-lifecycle-01

As I said in my immediately previous email, thanks for the support and I'm in complete agreement. Steve On Fri, Oct 11, 2024 at 6:22 PM Wes Hardaker wrote: > Wes Hardaker writes: > > > I believe we must allow for this possibility in the 4 columns even > > when we may wish it won't be used. >

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

Paul, You wrote, "You cannot use two algorithms to sign or delegate at the same time." If there are two or more independent signers for a zone -- see RFC 8901 -- then multiple algorithms might be in use at the same time. I think there is some wording that says the algorithms must be the same, I

[DNSOP] Re: DNSOPdraft-crocker-dnsop-dnssec-algorithm-lifecycle-01

Wes, Thanks for your comments and support. I'm in complete agreement. See inline for an additional comment. Steve On Fri, Oct 11, 2024 at 6:16 PM Wes Hardaker wrote: > Tim Wicinski writes: > > > I do believe the 8624bis authors and the WG are open to updating > the values for the table > >

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

Paul and Tim, Thanks for your comments. This submission was triggered by the Red Hat snafu. Red Hat removed an algorithm from the library when they determined it should not be used. However, as their users discovered quickly, messages signed with that algorithm continued to arrive, with consequ

[DNSOP] Re: draft-crocker-dnsop-dnssec-algorithm-lifecycle-01

but it did NOT advise how to introduce and how to remove an algorithm in coordination with other algorithms. On Sat, Oct 5, 2024 at 2:31 PM Steve Crocker wrote: > Paul and Tim, > > Thanks for your comments. This submission was triggered by the Red Hat > snafu. Red Hat removed

[DNSOP] Lifecyle and deprecation of draft-buraglio-deprecate7050

Folks, Thanks very much for considering Documenting and Managing DNSSEC Algorithm Lifecycles draft-crocker-dnsop-dnssec-algorithm-lifecycle-01 For reference, I was motivated to propose this when I understood how the Red Hat incident evolved. For those who haven't followed that incident, Red Hat

[DNSOP] Re: Lifecyle and deprecation of draft-buraglio-deprecate7050

m the receiving systems. Steve On Tue, Nov 5, 2024 at 2:02 PM Nick Buraglio wrote: > Thanks for the reply, Steve. > > On Tue, Nov 5, 2024 at 12:26 PM Steve Crocker wrote: > >> Folks, >> >> Thanks very much for considering >> >> Documenting and Managi

[DNSOP] Re: Lifecyle and deprecation of draft-buraglio-deprecate7050

Jen, Thanks. Despite the reference to DNSSEC in the title, I think the life cycle concepts apply to the use of algorithms in all settings. Steve On Tue, Nov 5, 2024 at 1:52 PM Jen Linkova wrote: > Hi Steve, > > On Tue, Nov 5, 2024 at 11:26 PM Steve Crocker wrote: > >&g

[DNSOP] Re: Lifecyle and deprecation of draft-buraglio-deprecate7050

, 2024 at 12:59 AM Steve Crocker wrote: > > Despite the reference to DNSSEC in the title, I think the life cycle > concepts apply to the use of algorithms in all settings. > > I'm wondering if you might want to make your draft more generic, and > explicitly expand it to all

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

See our I-D on lifecycle. It addresses this issue squarely. I'm about to to dinner and can't fill in the details. I'll do so later if someone hasn't already. Steve Sent by a Verified sender On Wed, Nov 13, 2024 at 7:04 PM Philip Homburg wrote: > >Tony Finch has correctly identified in SHA

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

It was the red hat situation that led me to write this. Red hat should have gone to phase 6, not phase 7. I recommend moving SHASHA1 to phase 6 for the time being. Steve Sent from my iPhone > On Nov 13, 2024, at 7:55 PM, Philip Homburg > wrote: > >  >> >> See our I-D on lifecycle. It

[DNSOP] Re: Speaking of names that don't exist

Many years ago I ran across a large company that had a large internal network. It purposely used IP addresses that were already assigned to others. They didn't want their internal numbers to conflict with the numbers assigned to their externally visible devices. Sort of a split view approach. S

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

I strongly support this draft and urge its adoption as a Proposed Standard. This is a significant step forward that will make it possible to deploy efficient coordination mechanisms between child zones and parent zones. Steve Crocker -- Sent by a Verified sender

[DNSOP] Re: Retire "white lies"

Preferences vary. I like the idea of a jargon series RFCs. Steve Sent from my iPhone > On Feb 13, 2025, at 5:39 PM, Edward Lewis wrote: > > On Feb 13, 2025, at 12:00, Steve Crocker wrote: >> >> If necessary, an Informational RFC explaining the history of the term

[DNSOP] Retire "white lies"

I'd like to suggest retiring the term "white lies." The term arose when describing minimal enclosing spans in comparison with maximal spans. In the original specification of NSEC3, spans between existing names were used in negative responses. The *purpose* of using the span was to authoritativel