[DNSOP] comments on draft-shetho-dnsop-ds-automation

IMO this doc is a good idea in principle but it's premature for WG adoption. It seems too gTLD- and EPP- centric. Which seems fair enough if ICANN is the target. However gTLDs are not the only players. I think the I-D needs to take account of the concerns/issues of ccTLDs and the RIRs. Could the

[DNSOP] Re: DNSSEC in DCV draft-ietf-dnsop-domain-verification-techniques

> On 21 Jul 2025, at 13:58, Erik Nygren wrote: > > DNSSEC signing of zones remains a SHOULD. +1 IMO using an encrypted channel (Do[HQT]) might well be "good enough". ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le.

[DNSOP] Re: DNSOPRoman Danyliw's Block on charter-ietf-dnsop-04-01: (with BLOCK and COMMENT)

> On 11 Jul 2025, at 16:38, Wes Hardaker wrote: > > mohamed.boucad...@orange.com writes: > >> DNS-related I-Ds that don't have an obvious WG which could adopt them >> can be submitted to the DNSOP WG for consideration. The DNSOP WG will >> advise on the ap

[DNSOP] Re: Collision Free Key Tags for DNSSEC draft

> On 9 Jul 2025, at 18:24, Petr Špaček wrote: > > Can you clarify source of your confidence about this 'not causing issues'? Mental arithmetic. There are 2^16 possible key tags => there's a one in 2^15 chance a new tag clashes with an existing one. If a DNSSEC key changes every day, it'll ta

[DNSOP] Re: Collision Free Key Tags for DNSSEC draft

> On 9 Jul 2025, at 15:43, John R Levine wrote: > > I still don't see the point. Me too! Wearing no hats and speaking only for myself: Key tag collisions don't appear to be causing a significant problem. I question if it's worth the WG's time kludging a solution for something that has such

[DNSOP] Re: Mahesh Jethanandani's Block on charter-ietf-dnsop-04-00: (with BLOCK and COMMENT)

> On 25 Jun 2025, at 21:39, Mahesh Jethanandani via Datatracker > wrote: > > "DNSOP", paragraph 0 >> The DNSOP WG is also responsible for maintenance, updates, and extensions to >> the DNS protocol. > > Thanks for the pointer to the email that describes the sentiment behind why > the > WG is

[DNSOP] Re: Roman Danyliw's No Objection on charter-ietf-dnsop-04-00: (with COMMENT)

> On 24 Jun 2025, at 11:04, Roman Danyliw via Datatracker > wrote: > > ** What DNS topics are out of scope in the WG? As framed, it appears that > nearly everything related to the “DNS protocol” would be in scope – BCPs for > “DNS protocols (Sentence 1), documents from DNS operators (Sentence

[DNSOP] Re: [Ext] draft WG chapter: 30/6/25

> On 30 May 2025, at 19:13, Paul Hoffman wrote: > > - "The DNSOP WG is also responsible for maintenance, updates and extensions > to the DNS protocol." There has been growing discussion that there should be > a DNS development (DNSDEV) working group that works on new developments; the > quot

[DNSOP] draft WG chapter: 30/6/25

Here's the proposed new charter for the WG. Please speak up on the list if you have comments or suggestions on how to improve the text. It's intentionally terse in the hope we can avoid rat-holing and spending too many edit cycles over long lists of stuff that's in/out of scope. If the charter

[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

> On 23 Apr 2025, at 17:15, Paul Hoffman wrote: > > I'm 99% sure that there is no policy statement about "will never delegate" > for .home, .corp, and .mail, but I could be wrong. I'm interested in any > references to something official here that says "never", for many reasons. You're pickin

[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

> On 23 Apr 2025, at 16:16, Peter Thomassen > wrote: > > That said, I think it would still be a good idea to invoke the liaison and > ask about ICANN's view on this (potential?) mistake, and how their definition > of "delegation" (to NS? to registry?) plays into this. What's the process for

[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

> On 23 Apr 2025, at 15:15, Philip Homburg wrote: > > So in my opinion this draft should not be adopted. The best solution is > no IETF document at all. That leaves the IETF out of this issue. I agree. Albeit for different reasons. ICANN already has its own list/registry of TLD strings it wil

[DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

> On 17 Apr 2025, at 20:47, David Conrad wrote: > > My understanding is that ICANN (or anybody) needs IETF approval to modify > https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. > If that’s not the case, “never mind”. > > I just think the reliance on l

[DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

> On 17 Apr 2025, at 08:39, Joe Abley wrote: > > Whether or not people use INTERNAL is an entirely untested question. Perhaps > if we had statistically-significant data that showed leaked INTERNAL queries > actually existed and represented some kind of real problem, we could imagine > thinki

[DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

> On 17 Apr 2025, at 16:12, David Conrad > wrote: > >> The root server system is not the part of the DNS infrastructure we need to >> worry about. > > Heh. If this were only true, the decade-long effort to develop a governance > structure for the RSS could be wound down and Jim, Geoff, and

[DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-automation-03

Reviewer: Jim Reid Review result: On the Right Track I am the latest dnsdir stuckee to review the document. I'm sorry to say it needs more work, mostly to correct too many minor niggles. 1) The text in the Introduction does not scan well. I think the following is better/clearer: RF

[DNSOP] Re: Upcoming MAPRG session at IETF-120

> On 17 Jul 2024, at 15:38, Mirja Kuehlewind > wrote: > > I just wanted to point out our upcoming MAPRG agenda to you as we have an > interesting talk on Post-Quantum DNSSEC (see below) There’s also a side meeting on this topic on Monday: https://wiki.ietf.org/meeting/120/sidemeetin

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

> On 10 Jul 2024, at 14:27, Philip Homburg wrote: > > So the question becomes, do we want some limits in an RFC that everybody > agrees on or do we want to keep the current informal system where limits > are not fixed and people can get unlucky if they exceed limits they didn't > know exist. I

[DNSOP] Re: [dnsdir] Dnsdir last call review of draft-ietf-dnsop-zoneversion-09

> On 4 Jul 2024, at 07:45, Nicolai Leymann via Datatracker via dnsdir > wrote: > > Overall I think the document is ready for publication. Thanks Nic. Though the LC comments today suggest we’re not yet done with this doc, :-( ___ DNSOP mailing list

[DNSOP] Re: Side Meeting - DNS Load Balancing

> On 29 Jun 2024, at 18:10, Ray Bellis wrote: > > The DNS was never designed intended to deliver different answers to different > users. DNSSEC solidified that and the practise IMNSHO should be discouraged, > not standardised. While this is undoubtedly true Ray, that ship sailed a *long* ti

[DNSOP]Re: Further comment re algorithm life cycles

> On 19 May 2024, at 18:21, Steve Crocker wrote: > > No: I don't think the scheme is quite right. > > In my view, an algorithm moves through seven phases during its lifecycle. > > 1. Experimental – defined and included in the IANA registry > 2. Adopted – begin inclusion in validation suite >

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

> On 18 Apr 2024, at 15:36, Scott Rose via Datatracker via dnsdir > 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 Section 5.1 second paragraph has "Signaling Zone" while other instances

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-automation-02

> On 18 Mar 2024, at 12:50, David Lawrence via Datatracker > wrote: > > Reviewer: David Lawrence > Review result: On the Right Track > > Early review of draft-ietf-dnsop-dnssec-automation. Thanks *very* much for such a detailed review Tale. I’m sure the authors will appreciate your comments

Re: [DNSOP] unrelated name server name recommendation

> On 4 Mar 2024, at 19: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 Er, no. It’ll be the registant’s registrar who will

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 16:17, Paul Hoffman wrote: > > I keep hoping that this group will focus more on those who go through the > effort to sign their zones than those who write the software. Hmmm. If it wasn’t for those who write the software, there would be nothing for those who sign their z

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 15:19, Joe Abley wrote: > > Resolvers are routinely managed in order to safeguard local resources, harden > themselves against attacks, etc. Not every query gets answered. Seems to me > that limiting the time a validating resolver spends churning its organs over > a part

Re: [DNSOP] [Ext] About key tags

> On 16 Feb 2024, at 12:35, Edward Lewis wrote: > > The potential for abuse does exist, but the potential isn't addressed by > documenting "key collisions should not allowed." Indeed. > I do agree that key collisions should be avoided, for the sake of key > management, but given the diffic

Re: [DNSOP] [Ext] About key tags

> On 14 Feb 2024, at 15:17, Paul Hoffman wrote: > > On Feb 14, 2024, at 07:10, Jim Reid wrote: >> That said, I think a minor tweak to the core DNSSEC specs would be a good >> idea. For instance, whenever a validator comes across a key tag collision, >> it MUST

Re: [DNSOP] [Ext] About key tags

> On 14 Feb 2024, at 14:47, Edward Lewis wrote: > > I raise the key tag issue in the sense of "let's not do this again" and not > to try to change what it is now. Clearly, changing it (to avoid collisions) > would be difficult. And, given the relative rarity of any problem stemming > from

Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01

> On 17 Jan 2024, at 20:42, Matt Brown via Datatracker via dnsdir > wrote: > > Reviewer: Matt Brown > Review result: Ready > > I have been selected as the DNS Directorate reviewer for this draft. > The draft itself is clear and understandable. Both the language and the > substance of th

Re: [DNSOP] [dnsdir] Dnsdir telechat review of draft-ietf-dnsop-dns-error-reporting-07

> On 10 Dec 2023, at 22:28, James Gannon via Datatracker via dnsdir > wrote: > > I have reviewed 07 against the feedback on both the -04 and -06 and the > document seems to be in good shape to move forward at this time. Thank you for > the comprehensive feedback to all the reviewers and god e

Re: [DNSOP] [dnsdir] Dnsdir early review of draft-ietf-dnsop-compact-denial-of-existence-01

> On 29 Nov 2023, at 12:43, Nicolai Leymann via Datatracker via dnsdir > wrote: > > I found no major or minor issues and think the draft is in a good > shape and can be progressed. Great stuff Nic! Many thanks. ___ DNSOP mailing list DNSOP@ietf.or

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

> On 5 Nov 2023, at 14:04, David Lawrence via Datatracker > wrote: > > Hi Roy and Matt, this is my review on behalf of the DNS Directorate. Many thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Automated delegation management via DDNS

> On 30 Oct 2023, at 13:00, Johan Stenstam > wrote: > > But let’s ensure that we have identified the correct scope of the problem > rather than cherry-picking the two simplest cases. +1 IMO the discussion of this I-D has lost focus. Let’s find it and get back on track. :-) ___

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-15

> On 14 Oct 2023, at 08:41, Vladimír Čunát via Datatracker > wrote: > > > I've already posted about -15, though not with dnsdir hat. So, I see nothing > wrong with the current version. (The complaint about DF=1 in current > implementations has been addressed.) Many thanks for the prompt rev

[DNSOP] Dnsdir early review of draft-ietf-dnsop-domain-verification-techniques-02

Reviewer: Jim Reid Review result: Not Ready Since this I-D was submitted for early dnsdir review, the draft is essentially a work in progress and much remains to be done. I doubt this I-D will be a valuable addition to the DNS oeuvre that merits WG attention. As written, it's a mixtu

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

> On 23 Feb 2023, at 22:36, Ted Lemon wrote: > > How much DNS traffic is even still inspectable these days? Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of pcaps and query logs from the DITL project. Whether that data could be good enough to meaningfully measure the inc

Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9

> On 20 Jan 2023, at 15:20, Paul Hoffman wrote: > > Given the long list of things in this document that ISC has thought about and > actively decided not to do, is it a good idea that we call it a "best current > practice"? Maybe. Though a BCP should go beyond documenting what BIND9 does. In

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

> On 14 Dec 2022, at 16:28, Eliot Lear wrote: > > We're off in the woods again. Let's keep these two principles in mind: > > • The DNS resolution mechanisms are not expected to resolve, let alone > secure names ending in .ALT. > • How other resolution mechanisms secure names is t

[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-rfc5933-bis-13

Reviewer: Jim Reid Review result: Ready The issues raised in the previous dnsdir reviews about the content of the I-D have been addressed. The meta-issue about an Informational RFC updating a Standards Track RFC still exists, though this remains out of scope for the I-D and dnsdir. I have no

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

> On 20 Oct 2022, at 13:01, Eliot Lear wrote: > > ducking that says that when the IETF faces tough problems, others must step > in. IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF gets handed non-IETF problems, it keeps well away (perhaps after a discussion o

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

> On 17 Oct 2022, at 15:12, Joe Abley wrote: > > Since it's not clear, my favoured approach to this entire subject is to do > whatever is the quickest way to resolve the conversation so that this working > group can get on with work that, in my opinion, no disrespect intended, is > less poin

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

> On 17 Oct 2022, at 13:00, Independent Submissions Editor (Eliot Lear) > wrote: > > I don't want to adjudicate names, but I have no problem adjudicating naming > systems, including transparent attempts to get vanity names. Since none of > those are naming systems, they would all get the of

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-rfc5933-bis-10

Reviewer: Jim Reid Review result: Ready with Nits The I-D is a no brainer. It requests a code point for a new crypto algorithm for Secure DNS and deprecates one for an algorithm that has been obsoleted. Some language nits. 1) The text in 4.1 "algorithm number 23 is used here as an ex

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

> On 14 Aug 2022, at 04:55, Wes Hardaker wrote: > > Something like: > > # Deprecating SHA-1 algorithms in DNSSEC > > The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records. > Validating resolvers MUST treat DS records as insecure. If no other DS > records of accepted cryp

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

> On 13 Aug 2022, at 13:48, Mark Andrews wrote: > > So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber > which is what is required to actually get rid of SHA1 or do you mean retire > RSA-SHA1. Neither. I said the I-D needs to say something about not using crypto re

[DNSOP] draft-hardaker-dnsop-must-not-sha1

Wes, I'm all for killing SHA1. Though the mechanism might need a rethink. We probably should have a simpler way to add/remove DNSSEC crypto algorithms. IIRC Paul Hoffman explained the problem a year or so ago when new code points were needed for the latest GOST algorithms: something about that c

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

> On 8 Aug 2022, at 11:16, Independent Submissions Editor (Eliot Lear) > wrote: > > I caution against those approaches that would set such a high bar that they > would require researchers to fork out hundreds of thousands of dollars on > application fees alone plus who knows how much else fo

Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice

> On 11 Apr 2022, at 14:01, Masataka Ohta > wrote: > > I can't see any as discussion is still ongoing. There is no discussion, just you arguing with yourself. Please stop. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo

Re: [DNSOP] DNSSEC as a Best Current Practice

> On 21 Mar 2022, at 14:36, Masataka Ohta > wrote: > > How can you say I must provide some draft for some protocol by > myself even though an alternative of DNS cookie already is an rfc? Modulo the IETF's code of conduct, I can say whatever I like - as can you or anyone else. If you're say

Re: [DNSOP] DNSSEC as a Best Current Practice

> On 21 Mar 2022, at 14:12, Masataka Ohta > wrote: > > No implementation or code is necessary to say DNSSEC is > fundamentally hopeless. That might or might not be true. But where's your draft and code for an alternative? ___ DNSOP mailing list D

Re: [DNSOP] IANA Policy for SVCB

> On 21 Mar 2022, at 09:19, Ben Schwartz > wrote: > > Personally, I favor #3. What do you think? Ben, I think 2 (Expert Review) is the right approach. This would hopefully ensure any specifications are complete/valid and raise the threshold to discourage bad or frivolous SrvParamValues "

Re: [DNSOP] How Slack didn't turn on DNSSEC

> On 1 Dec 2021, at 18:49, Andrew Sullivan wrote: > > Wouldn't that create a vicious circle in which the only way to start > operating DNSSEC is already to have operated DNSSEC? I think we’ve been in that vicious circle (or downward spiral) for several years now. ___

Re: [DNSOP] Draft-ietf-dnsop-private-use-tld and the ISO

> On 27 Jul 2021, at 01:56, Donald Eastlake wrote: > > Looks like initial query from IAB to ISO is > https://datatracker.ietf.org/liaison/1720/ > > Maybe I'm blind but I don't see a response... It can take a day or so for inbound Liaison Statements from other SDOs to make their way to the d

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

> On 28 Apr 2021, at 13:24, Roy Arends wrote: > > The working group can (after a potential clarification from the ISO about the > future status of code elements) decide if a subset suffices and if so, the > composition of the subset. I agree with this approach. IMO it’s reasonable for the W

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

On 19 Mar 2021, at 02:42, Viktor Dukhovni wrote: > > On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote: > >> Measuring the MTU to well-known locations on the Internet won’t be >> appropriate for some use cases. For instance inside private nets that >> aren’t c

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

> On 15 Mar 2021, at 04:16, fujiw...@jprs.co.jp wrote: > > Dear DNSOP participants, > > Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation. > > These are my proposal of Section 3.3. Default Maximum DNS/UDP payload size. > > I'm not sure what to do with "MAY, "SHOULD"

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

> On 11 Mar 2021, at 15:38, Paul Hoffman wrote: > > The size of the namespace isn't all that relevant in that, for any namespace, > if it is filling up "too fast", one can quickly change the requirements to be > more stringent. I'm pretty sure that has happened in the thousands of IANA > reg

[DNSOP] signalling mandatory DNSSEC in the parent zone

> On 1 Mar 2021, at 13:29, Ulrich Wisser > wrote: > > 100% signed would mean unsigned zones do not get delegated, going insecure is > no longer an option. > I would like the protocol to be able to handle that case. Ulrich, that seems to be a (registry-specific?) policy matter => probably ou

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 6 Jan 2021, at 20:48, Ben Schwartz > wrote: > >> > Telling validators to "insist" that all signatures are valid would resolve >> > this dilemma. Zone owners could add algorithms without weakening anything. >> >> How do you deploy a new signing algorithm alongside an established one >>

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 4 Jan 2021, at 16:18, Paul Wouters wrote: > > You want to see a Status column at the IANA registry for marking > something "NOT RECOMMENDED" / "DEPRECATED" etc ? Yes! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

> On 4 Jan 2021, at 15:27, Stephen Farrell wrote: > > On 04/01/2021 14:23, Paul Wouters wrote: >> On Mon, 4 Jan 2021, Stephen Farrell wrote: >>> WRT GOST, we're not really talking about an algorithm but >>> rather a national crypto standards scheme that selects sets >>> of algorithms. For such

Re: [DNSOP] [Ext] Authoritative servers announcing capabilities

> On 14 Sep 2020, at 17:07, Paul Hoffman wrote: > > On Sep 14, 2020, at 2:33 AM, Peter van Dijk > wrote: >> In general, this document appears to suffer from a disconnect between >> 'information published by an auth about itself' and 'information published >> in a zone'. > > You and others

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On 18 Jun 2020, at 16:01, Joe Abley wrote: > > On Jun 18, 2020, at 16:48, Paul Hoffman wrote: > >> Why is this WG considering making this document Standards Track instead of >> Informational? Also, why is the WG considering putting the document in our >> work stream at all? Can the WG ca

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

> On 18 Jun 2020, at 16:30, Paul Hoffman wrote: > > It might be better, and faster, for this WG to adopt a one-paragraph draft > that makes the DS registry "RFC required", like the other DNSSEC-related > registries. +1 signature.asc Description: Message signed with OpenPGP ___

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

> On 16 Jun 2020, at 15:51, Mats Dufberg > wrote: > > I support the adoption and I am willing to review the document. Me too! I wish everyone else commenting on this thread just indicated if they supported adoption (or not). Too much of the discussion that’s taking place at the moment seem

Re: [DNSOP] data at delegation points

> On 14 Apr 2020, at 16:43, Paul Vixie wrote: > > so instead of example.com DS, it should have been example._dnssec.com DS. Sadly, that wouldn’t work for thisisaveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain.name Which really exists. :-) _

Re: [DNSOP] on private use TLDS

> On 26 Nov 2019, at 10:18, Roy Arends wrote: > > "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned > range as top level domains for my own private use?" > > ... > It is my understanding that the ISO3166 Maintenance Agency can not re-assign > codes from the User Assi

Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter

> On 1 Aug 2019, at 18:04, Paul Wouters wrote: > > In favour of adoption. Simple, short and clear document. +1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [Add] [dns-privacy] Do53 vs DoT vs DoH Page Load Performance Study at ANRW

> On 22 Jul 2019, at 21:52, Paul Vixie wrote: > > apparently ECS creates problems for privacy, but _how could we have > suspected_? IIRC the ECS privacy issues were recognised at the time. They lost out to the argument that CDNs were already doing (or about to do) ECS and it would be bette

Re: [DNSOP] Proposal: Whois over DNS

> On 10 Jul 2019, at 14:24, Philip Homburg wrote: > > As far as I know, there is no issue with whois and the GDRP when it comes > to voluntarily publishing information in whois. Nope. It’s OK for you to publish your Personal Data. For anything else, you need to get informed consent first. And

[DNSOP] dictionary of registration data elements

> On 9 Jul 2019, at 17:26, Steve Crocker wrote: > > I would strongly support an effort within the IETF to create and maintain a > dictionary of registration data elements. This would probably be in the form > of an IANA-maintained registry, with oversight from DNSOP. Hmmm. That might be a b

Re: [DNSOP] Proposal: Whois over DNS

On 9 Jul 2019, at 17:43, John Bambenek wrote: > > I guess I'm not understanding the risks of people accidentally disclosing > what they don't intend to. I suggest you learn more about GDPR. The penalties for non-compliance can hurt - up to 4% of global turnover. Some CIOs are learning this t

Re: [DNSOP] Proposal: Whois over DNS

> John Bambenek wrote: > > > Why? GDPR applies to IP addresses that, doesn't impact DNS yet. GDPR applies to *any* data which identifies a living European citizen. If you think it only applies to IP addresses you are very badly mistaken. GDPR will also apply to anything in the DNS which happ

Re: [DNSOP] Proposal: Whois over DNS

> On 9 Jul 2019, at 15:50, John Bambenek > wrote: > > I'm not married to any name, I chose WHOIS for historical reasons. We can > call it _hamsandwich if it builds consensus. The concern here isn't what the label is called. Prepending a label won't work with absurdly long domain names beca

Re: [DNSOP] Proposal: Whois over DNS

> On 9 Jul 2019, at 15:15, Bjarni Rúnar Einarsson wrote: > > I think having a technical specification like this would be quite interesting > from the point of view of automatically updates to existing Whois databases, > without requiring the registrant directly (or indirectly) interact with

Re: [DNSOP] Proposal: Whois over DNS

On 8 Jul 2019, at 22:38, John Bambenek wrote: > > In response to ICANN essentially removing most of the fields in WHOIS for > domain records, Richard Porter and myself created a draft of an > implementation putting these records into DNS TXT records. It would require > self-disclosure which m

Re: [DNSOP] Obsoleting DLV

> On 2 Jul 2019, at 19:12, Matthijs Mekking wrote: > > I think it is time to move the protocol to Historic status as a clear signal > to > everyone that it should no longer be implemented or deployed. Agreed. Kill it with fire! ___ DNSOP mailing l

Re: [DNSOP] Verifying TLD operator authorisation

> On 18 Jun 2019, at 14:56, Shane Kerr wrote: > >> Being able to control a zone’s SOA record (or whatever) means just that. No >> more, no less. It doesn’t mean someone who has that ability also has the >> authority to change the zone’s delegation even though they can manipulate >> the zone

Re: [DNSOP] Verifying TLD operator authorisation

> On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson wrote: > > The SOA record for a TLD contains two DNS names which should be > under the control of the NIC ... > People on this list can probably comment on whether my above > assumption is correct, and whether those are good candidates for > wh

Re: [DNSOP] Verifying TLD operator authorisation

> On 14 Jun 2019, at 14:13, Dr Eberhard W Lisse wrote: > > Would (GPG encrypted) email to the registered address to the authority > not be sufficient? That would make sure the recipient is authorized and > must then cause the token to be 'delegated' as the second factor. If there was a secure

Re: [DNSOP] Verifying TLD operator authorisation

> On 14 Jun 2019, at 03:18, Nick Johnson > wrote: > > I'm working on a system that needs to authenticate a TLD owner/operator in > order to take specific actions. We had intended to handle this by requiring > them to publish a token in a TXT record This assumes someone who is able to update

Re: [DNSOP] Deprecating the status opcode

> On 15 May 2019, at 12:55, Shane Kerr wrote: > > This seems like the most non-controversial document ever in the history of > documents. A non-controversial DNS doc at the IETF? That’ll be a first. :-) ___ DNSOP mailing list DNSOP@ietf.org https:/

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

> On 13 May 2019, at 09:22, Joe Abley wrote: > > I would prefer documented agreement about what is obsolete and what is not. +1 Though a definition of what is meant by obsolete might be needed too: "no longer seen in the wild but could still be alive in closed environments", "deader than E

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

On 13 May 2019, at 05:06, Ondřej Surý wrote: > > But I do have a question for the WG - should we add a text that would allow > the “Expert Review” to formally DEPRECATE (as defined in this I-D) other > RRTYPEs? I'm not sure an expert reviewer could or should be in a position to make that dete

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

> On 21 Mar 2019, at 22:29, Brian Dickson wrote: > >> On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour >> wrote: >> Plus! >> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC? So >> the local resolver and apps and browsers can go the _appropriate_ name >> resolution reso

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer wrote: > > I still do not understand why people have a problem with DoH whch did > not already exist before with my-own-name-resolution-protocol-over-HTTPS. It’s a question of scale/ubiquity. These “alterate” resolution tricks have up until now

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer wrote: > > the case of a commercial > Internet access provider is clear in the other direction: a client is > not an employee, and is entitled to a free, open and neutral Internet > access. Stephane, that’s simply not true. A client of an Interne

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

> On 15 Feb 2019, at 09:02, Stephane Bortzmeyer wrote: > > I really think it is important to make the difference between: > > * I blocked your request because that's _my_ policy > * I blocked your request because I'm compelled to do so, don't > complain, it would be useless. Why? From the c

Re: [DNSOP] extension of DoH to authoritative servers

> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote: > > the premise is the recursive server should completely trust an Authenticated > server You’ve already made that clear. The problem with that premise is it’s a false one. It represents a naive/unrealistic view of how the DNS is used. Your

Re: [DNSOP] extension of DoH to authoritative servers

On 14 Feb 2019, at 06:36, zuop...@cnnic.cn wrote: > > i think both DNSSEC and DoH(or DoT) can protect DNS data It depends on your definition of “protect”. For some threats/attacks, DoH or DoT by themselves can’t protect DNS data - for instance a DoH or DoT server that intentionally or accidenta

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

> On 21 Jan 2019, at 10:26, Ondřej Surý wrote: > > We can’t be removing EDNS workarounds and at the same time slap another > workaround into the DNS. +1 I think the WG should drop this draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.

Re: [DNSOP] Fundamental ANAME problems

> On 5 Nov 2018, at 15:38, Ray Bellis wrote: > > The cost to the DNS community of *trying* my proposed HTTP record is pretty > negligible. Worst case, as Brian put it, is we burn a code point, add a > trivial amount of code to DNS servers, but the browsers don't adopt it. It > wouldn't be

Re: [DNSOP] KSK rollover choices

> On 31 Oct 2018, at 00:27, Mark Andrews wrote: > > Bootstrap is still a issue. Over fast TA rolling makes it more of a issue. Indeed. And that's the underlying problem that needs to be fixed IMO - for instance when/if there's an emergency rollover.

[DNSOP] KSK rollover choices

On 30 Oct 2018, at 22:31, Mark Andrews wrote: > > Ultra frequent key rolls are not necessary. It takes years the latest > releases of name servers to make it into shipping OS’s. So what? Key rollover policies cannot and should not be driven by vendor OS release schedules. Or the BIND/whatever

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 21 Aug 2018, at 16:23, Vittorio Bertola wrote: > > And I have yet to see a statement from the DoH community that Mozilla's idea > of making DoH the default and disregarding whatever resolver is being > configured in the system via DHCP is not a good one. Why would/should the DoH community

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

> On 27 Jul 2018, at 12:17, Tony Finch wrote: > > Ah, the obvious solution is to deprecate zone files and just ship update > journals instead! Why not go for distributed hash tables? :-) Says he running away to watch the fireworks from a safe distance...

Re: [DNSOP] [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

> On 18 Jul 2018, at 00:43, Shane Kerr wrote: > > I took some random notes at the meeting. Apologies for any errors or > misstatements. Many thanks Shane! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New WG for document/protocol cleanup?

> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker wrote: > ... long rant snipped ... > Well that is how I plan to go forward at any rate. Good for you. Please come back to the IETF once you've figured it all out and have running, interoperable code.

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 24 Mar 2018, at 20:20, Ondřej Surý wrote: > >> It might be a different story if one of those zombie RRtypes required >> additional processing. None spring to mind though. > > But (most of) those I picked actually *DO*: > > a) compression is allowed, so compliant and non-compliant servers ca

  1   2   3   >