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

2020-06-18 Thread Vladimír Čunát
On 6/19/20 6:20 AM, Martin Thomson wrote: > As long as the space of codepoints isn't too small (2^16 is fine), then I see > no reason not to allow external publications request a value as long as they > don't abuse the privilege. The space for DNSKEY and DS algorithms is one octet, so each of

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

2020-06-18 Thread Martin Thomson
On Fri, Jun 19, 2020, at 01: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. I think you mean "Specification Required". RFC required has the same net

Re: [DNSOP] Hybird Resolver/ DNS invariants

2020-06-18 Thread Davey Song
Dear Paul, On Wed, 17 Jun 2020 at 00:03, Paul Vixie wrote: > > i've described this to you (when you were at BII) several times as a kind > of > microtransfer or lease, where cooperating initiators (RDNS in this case) > and > responders (ADNS in this case) can agree on a NOTIFY TSIG key to be

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

2020-06-18 Thread Paul Vixie
On Thursday, 18 June 2020 16:13:23 UTC Paul Wouters wrote: > ... > It would be very strange to introduce a new algorithm as NOT RECOMMENDED. > The weakest I think we should introduce something is as MAY. +1. -- Paul ___ DNSOP mailing list

[DNSOP] DINR 2020 workshop on July 22 for advancing DNS research

2020-06-18 Thread Wes Hardaker
We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions" (DINR). We will be holding a DINR 2020 (virtually on zoom) on 2020-07-22 from 14:00 to 20:00 UTC. If you're intereseted in DNS-related topics, infrastructure, and have early early work

[DNSOP] RFC 8806 on Running a Root Server Local to a Resolver

2020-06-18 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 8806 Title: Running a Root Server Local to a Resolver Author: W. Kumari, P. Hoffman Status: Informational Stream:

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

2020-06-18 Thread Roy Arends
On 18 Jun 2020, at 16:15, Ted Lemon wrote: > > For what it’s worth, I am in favor of adopting this document. With that said, > however, I do have questions, Roy. Thanks for your support. > If we use these ccTLDs as squatting domains, that means that we’re going to > see a lot of traffic at

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

2020-06-18 Thread Töma Gavrichenkov
Peace, On Thu, Jun 18, 2020, 8:39 PM Daniel Migault wrote: > To my perspective, holding code point allocation is likely to result in > non allocated code points being used which represents a higher threat to > interoperability than adding an algorithm. > +1 >

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

2020-06-18 Thread Philip Homburg
> The root zone and private-use internal zones that anchor private > namespaces might all benefit from a robust trust anchor distribution > strategy. If validators have the ability to be configured elegantly > with all the trust anchors they need without the attention of a > knowledgeable

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

2020-06-18 Thread Ted Lemon
On Jun 18, 2020, at 2:24 PM, Warren Kumari wrote: > ... and I should point out that this was one of the arguments in > https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3 > > for an (insecure)

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

2020-06-18 Thread Warren Kumari
On Thu, Jun 18, 2020 at 1:47 PM Ted Lemon wrote: > > It can be solved with a trust anchor as well, but that relies on there being > a central validating resolver rather than validating stub resolvers on hosts, > and personally I don’t find that deployment model very compelling anymore—I >

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

2020-06-18 Thread Joe Abley
On Jun 18, 2020, at 19:22, Ted Lemon wrote: > What I’m getting at is that the secure denial of existence will mean that a > DNSSEC-aware resolver, when asked to look up a name under .xa, for example, > will always return NXDOMAIN. I think we're speculating about behaviour in software that has

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

2020-06-18 Thread Ted Lemon
It can be solved with a trust anchor as well, but that relies on there being a central validating resolver rather than validating stub resolvers on hosts, and personally I don’t find that deployment model very compelling anymore—I think that stub resolvers should validate. If I get my way,

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

2020-06-18 Thread Daniel Migault
I support adoption of the document. To my perspective, holding code point allocation is likely to result in non allocated code points being used which represents a higher threat to interoperability than adding an algorithm. Standard track and MAY/OPTIONAL status seem reasonable to me Yours,

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

2020-06-18 Thread Vladimír Čunát
On 6/18/20 7:22 PM, Ted Lemon wrote: >> I suspect it will work like every other locally-served domain or >> every other private namespace that exists today, i.e. just fine with >> no configuration changes expected or required on dependent >> (downstream) DNS clients. And if there are new species

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

2020-06-18 Thread Ted Lemon
On Jun 18, 2020, at 12:10 PM, Joe Abley wrote: > > [As an aside, I have some concerns about RFC 8375 and I wish I was paying > more attention at the time it was discussed. Although I can understand some > of the technical arguments for the delegation, I'm not especially convinced > by them in

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

2020-06-18 Thread Eric Rescorla
On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters wrote: > On Thu, 18 Jun 2020, Eric Rescorla wrote: > > > The way that TLS has handled this is to have the registries have a > column called Recommended and we just mark things Y or N. This is slightly > > different from RFC 2119 language. > > > > It's

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

2020-06-18 Thread Paul Wouters
On Thu, 18 Jun 2020, Eric Rescorla wrote: The way that TLS has handled this is to have the registries have a column called Recommended and we just mark things Y or N. This is slightly different from RFC 2119 language. It's not that uncommon to have new stuff introduced with Recommended = N.

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

2020-06-18 Thread Roy Arends
On 18 Jun 2020, at 17:16, Philip Homburg wrote: > >> basically all the domains you list here could have used one of >> their own domains (eg local.telus.com instead of .telus, etc) > > I wonder how that would interact with EU privacy regulations. In the common > case of an ISP providing the

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

2020-06-18 Thread Roy Arends
.gnu and .onion were never intended as private use. Gnu was meant as just another top level domain, and .onion is supposed to work over a (private but remote) network. Maybe “.local” would have been a candidate to use one of the iso3166-1 Alpha-2 user assigned string. On 18 Jun 2020, at

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

2020-06-18 Thread Philip Homburg
>But that problem is independent of the domain names used. If the CPE >sends queries to the ISP, the deed has already been done, regardless of >what the ISP does with the query (send it to the root, to telus.com or >drops it) Sending a query to the root, which is considered a collection of

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

2020-06-18 Thread Eric Rescorla
On Thu, Jun 18, 2020 at 9:13 AM Paul Wouters wrote: > On Thu, 18 Jun 2020, Eric Rescorla wrote: > > > On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski wrote: > > Eric > > > > One of the reasons we've published 8624 was to offer usage > recommendations, > > and especially this table: > > > >

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

2020-06-18 Thread Paul Wouters
On Thu, 18 Jun 2020, Philip Homburg wrote: basically all the domains you list here could have used one of their own domains (eg local.telus.com instead of .telus, etc) I wonder how that would interact with EU privacy regulations. In the common case of an ISP providing the customer with a CPE,

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

2020-06-18 Thread Paul Wouters
On Thu, 18 Jun 2020, Paul Hoffman wrote: On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: The 2nd registry Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1

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

2020-06-18 Thread Philip Homburg
> basically all the domains you list here could have used one of > their own domains (eg local.telus.com instead of .telus, etc) I wonder how that would interact with EU privacy regulations. In the common case of an ISP providing the customer with a CPE, the ISP is resposible for anything that

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

2020-06-18 Thread Joe Abley
Hi Ted, On Jun 18, 2020, at 17:15, Ted Lemon wrote: > If we use these ccTLDs as squatting domains, that means that we’re going to > see a lot of traffic at the root trying to find nonexistent name servers, > right? And these ccTLDs provably do not exist, right? RFC 8198 was implemented in

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

2020-06-18 Thread Paul Wouters
On Thu, 18 Jun 2020, Roy Arends wrote: To me it seems that most dnsop people (me included) do not want to legitimize use unnecessary use of private names as it often causes unnecessary pain down the road - but at the same time I personally recognize the motivation for home.arpa. etc. I

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

2020-06-18 Thread Jim Reid
> 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

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

2020-06-18 Thread Jim Reid
> 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] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

2020-06-18 Thread Paul Hoffman
On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky wrote: > The 2nd registry > Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms > (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 >

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

2020-06-18 Thread Ted Lemon
For what it’s worth, I am in favor of adopting this document. With that said, however, I do have questions, Roy. If we use these ccTLDs as squatting domains, that means that we’re going to see a lot of traffic at the root trying to find nonexistent name servers, right? And these ccTLDs

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

2020-06-18 Thread Joe Abley
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 can bring much value to the document itself? > We do have

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

2020-06-18 Thread Valery Smyslov
Hi Paul, > 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 can > bring much value to the > document itself? We do have lots of other things we are working on.

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

2020-06-18 Thread Dmitry Belyavsky
Dear Paul, On Thu, Jun 18, 2020 at 5:48 PM 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 can bring much value to the document itself?

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

2020-06-18 Thread Paul Hoffman
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 can bring much value to the document itself? We do have lots of other things we are working on. There is no

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

2020-06-18 Thread Roy Arends
> On 18 Jun 2020, at 08:03, Petr Špaček wrote: >> >> I support adoption but share opinion that the document should not be >> published as is. Ack. Please help the editors to mold it into the right structure when (if) the idea is adopted. And thank you for your support! > 1. _If possible_

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

2020-06-18 Thread Eric Rescorla
On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski wrote: > Eric > > One of the reasons we've published 8624 was to offer usage recommendations, > and especially this table: > > https://tools.ietf.org/html/rfc8624#page-5 > > I believe I saw that one of the authors mentioned earlier they are looking >

Re: [DNSOP] SVCB ALPN value presentation format

2020-06-18 Thread lcampbel=40akamai . com
OK, I think I now understand the intent, and refactored my code accordingly, and it is now simpler and cleaner. Yay. I think it would be clearer to implementers if section 2.1.1 said that all values are initially parsed as character-strings (allowed to exceed 255 characters), and then further

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

2020-06-18 Thread Tim Wicinski
Eric One of the reasons we've published 8624 was to offer usage recommendations, and especially this table: https://tools.ietf.org/html/rfc8624#page-5 I believe I saw that one of the authors mentioned earlier they are looking to do a -bis update, to update this table. (But hear the rest of the

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

2020-06-18 Thread Eric Rescorla
On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson wrote: > I agree with Olafur on this. The reason we standardize is so that we can > have a single - ideally very small - set of algorithms that are widely > implemented. Because you want every one of those algorithms in every > implementation. > >

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

2020-06-18 Thread Robert Mortimer
On 18/06/2020 08:04:47, Petr Špaček wrote: On 16. 06. 20 13:00, Petr Špaček wrote: > On 12. 06. 20 17:12, Tim Wicinski wrote: >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular calls for adoptions over the next few months.   We are looking

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

2020-06-18 Thread Paul Vixie
On Thursday, 18 June 2020 07:03:23 UTC Petr Špaček wrote: > ... > An off-list reply indicates that I was not clear so I'll attempt to clarify > my previous message. In my mind the document should say: > > 1. _If possible_ use a subdomain you own, it will save you headache later on > (e.g. when

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

2020-06-18 Thread S Moonesamy
Hello, At 02:07 PM 03-06-2020, Tim Wicinski wrote: As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis

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

2020-06-18 Thread Petr Špaček
On 16. 06. 20 13:00, Petr Špaček wrote: > On 12. 06. 20 17:12, Tim Wicinski wrote: >> >> All, >> >> As we stated in the meeting and in our chairs actions, we're going to run >> regular calls for adoptions over the next few months.   We are looking for >> *explicit* support for adoption. >> >>