subject:"\[DNSOP\] Call for Adoption\: draft\-arends\-private\-use\-tld"

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 the root trying to find nonexistent name servers, 
> right?  

“A lot” is relative. 73% of queries to the ICANN managed root servers are for 
domains that do not exist. Close to 50% is done by a single application.

This traffic will likely end up in the margins. When squatted domains are 
traded in for private use domains, there is no difference. 

> And these ccTLDs provably do not exist, right?

Yes, and rightfully so.

> Contrariwise, home.arpa has an un-signed delegation.  Queries for home.arpa 
> are no worse than queries for any other .arpa subdomain, as far as the root 
> is concerned. On the other hand, perhaps they are worse for .arpa, and since 
> in fact .arpa is currently served by the root servers, perhaps this makes no 
> difference.

I have no idea.

> What’s the difference we’ll see in traffic for the root versus traffic for 
> .arpa if people adopt known-unused, securely nonexistent ccTLDs instead of an 
> un-signed delegation under .arpa?

Again, negligible.

> Also, what do you think the operational effect of this will be? Given that 
> these domains are currently provably nonexistent, this means that a resolver 
> looking up names in these domains will have to special-case them.

A resolver has to special provision anything that is used in private, 
regardless of DNSSEC, correct? 

A validating stub resolver needs to have a negative trust anchor for that 
unsigned space, if that unsigned space is actually used privately. 

The inverse is a stunningly bad idea:

If .internal is delegated from the root, there is a security hole that 

(1) is open by default in EVERY network.
(2) every hacker knows about. You can spoof .internal from the outside of the 
victim resolver, in your own time, from your own network. 
(3) every user has to use, since there is no other private space (unless .zz 
and others is a non-delegated, but designated private space). 
(4) every device will be shipped with, because they have been told that 
.internal is the new squatting.

and if you don’t want to be exposed to this security hole EVERYONE has to
(1) redirect .internal elsewhere, even WHEN YOU ARE NOT USING IT. (Some new app 
may be using it, some client on your network may be using it)
(2) deploy a bogus trust anchor on your validating stub resolver everywhere.

And for what? 

For the theoretical validating stub resolver that somehow can't have a negative 
trust anchor for .internal (good luck deploying a signed .internal), while 
having a trust anchor for root. 

But this is just my opinion.

Giving the world an open door into everyone’s private space was not what I had 
in mind when I started working on DNSSEC.

Roy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 administrator (as a validating stub resolver might
> need with the root zone trust anchor) we might find that the DNSSEC
> concerns that led to horrors like home.arpa all disappear.

I think it would be good to have support for more trust anchors. Also 
for public domains. 

However, additional root CAs for X509 certs is quite a mess. DNS would be
slightly better, a trust anchor covers only part of the DNS tree, unlike
installing a root CA. However, ultimately trust in your trust anchor is
limited to the trust in the mechanism used to distribute the trust anchor.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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) delegation (just like home.arpa has). Currently
> operating system vendors (and similar) cannot realistically ship
> validating stub resolvers - having BYOD users suddenly unable to
> resolve www.corp on your shiny new phone/tablet/laptop results in
> outrage, and customers buying your competitors widget instead.

This is another way of framing the issue. What I’m trying to get at is that we 
should be telling people how to do this in a way that doesn’t break validating 
resolvers. At least, I think we should. I think there are two facets to this:

1. If your stub resolver validates, it must be possible to provision a trust 
anchor for a private zone.
2. When you set up a private zone, you should use a zone the existence of which 
isn’t securely denied.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 
> think that stub resolvers should validate.  If I get my way, then we’re going 
> to see these “private” domains start to fail.

... 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) delegation (just like home.arpa has). Currently
operating system vendors (and similar) cannot realistically ship
validating stub resolvers - having BYOD users suddenly unable to
resolve www.corp on your shiny new phone/tablet/laptop results in
outrage, and customers buying your competitors widget instead.

The presentation at
http://slides.com/wkumari/deck-f68ee558-abac-4af2-9357-5669734d3445-5-8#/3/0/0
(slide 6) only briefly touched on it:
Has to be a TLD for non-technical / aesthetic reasons
DNSSEC requires that this be added to the root (with a DNSSEC insecure
delegation).
-happy to cover the reasons off-line
  -no process for this.
- Will require creating one!

People (rightly IMO) said that this isn't DNSOP work, and should be
taken to ICANN instead.

The above presentation also said:
Users want an internal / disconnected namespace
... but we told them not to do this.

Squatting on TLDs causes various issues like:
pollution of the namespace  e.g .home, .corp, .mail, ...
potentially collisions
  excess root / recursive lookups
  somewhat mitigated by Aggressive NSEC
  leaking of "internal" names

Actually we say "Use something under a registered domain"
We are the adults, this is risky behavior, you don't actually want to do this
We also preach abstinence
Regardless of what we think of the behavior, we can't stop people
doing this - but we can make it less risky.

This seems to be related to much of what was said earlier --
regardless of what we think of people using a private/internal name,
there are no protocol police, and we cannot prevent it - but we can
posibly coral the badness into fewer places...

I'm limiting my involvement in this thread - I'm also working on the
SSAC .internal document
(https://mm.icann.org/pipermail/ncap-discuss/2020-June/000432.html),
and take the ICANN SSAC confidentiality agreement seriously.
While I have asked my co-AD to be responsible for the document
(https://mailarchive.ietf.org/arch/msg/dnsop/13iQFI6V3yJ90SxbqSy8UubQ6bU/)
I'm being extra cautious in this thread...

W

>
> Sent from my iPad
>
> On Jun 18, 2020, at 1:36 PM, Vladimír Čunát  
> wrote:
>
> 
> 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 of resolver that need to be accommodated (e.g. 
> validating, hybrid stub/full service resolvers embedded in applications), 
> whatever configuration or auto-discovery mechanisms are required to support 
> those other locally-served zones can surely be easily extended to these 
> ISO-3166-2 codes if they are used in any particular private network.
>
>
> 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.
>
> Yes, but squatting is usually done at root names already, so the issue isn't 
> new.
>
> Modifying DNS past the last validator is generally troublesome.  Modifying it 
> inside the last validating resolver can be fine, as the implementation can 
> "prioritize" the modifications over validation and aggressive caching (but as 
> an implementor I still find this troublesome).
>
> --Vladimir
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 not yet been 
written, software that will have a natural requirement to deal with the 
environment it finds itself deployed in.

But it also occurs to me that if we agree that the great root zone KSK roll 
melodrama illustrated that we have a root zone trust anchor distribution 
problem, it's not much of a stretch to generalise that statement and say that 
we have a trust anchor distribution problem.

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 administrator (as a 
validating stub resolver might need with the root zone trust anchor) we might 
find that the DNSSEC concerns that led to horrors like home.arpa all disappear.

Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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, then we’re going to see 
these “private” domains start to fail.

Sent from my iPad

> On Jun 18, 2020, at 1:36 PM, Vladimír Čunát  
> wrote:
> 
> 
>> 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 of resolver that need to be 
>>> accommodated (e.g. validating, hybrid stub/full service resolvers embedded 
>>> in applications), whatever configuration or auto-discovery mechanisms are 
>>> required to support those other locally-served zones can surely be easily 
>>> extended to these ISO-3166-2 codes if they are used in any particular 
>>> private network.
>> 
>> 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.
> Yes, but squatting is usually done at root names already, so the issue isn't 
> new.
> 
> Modifying DNS past the last validator is generally troublesome.  Modifying it 
> inside the last validating resolver can be fine, as the implementation can 
> "prioritize" the modifications over validation and aggressive caching (but as 
> an implementor I still find this troublesome).
> 
> --Vladimir
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 of resolver
>> that need to be accommodated (e.g. validating, hybrid stub/full
>> service resolvers embedded in applications), whatever configuration
>> or auto-discovery mechanisms are required to support those other
>> locally-served zones can surely be easily extended to these
>> ISO-3166-2 codes if they are used in any particular private network.
>
> 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.

Yes, but squatting is usually done at root names already, so the issue
isn't new.

Modifying DNS past the last validator is generally troublesome. 
Modifying it inside the last validating resolver can be fine, as the
implementation can "prioritize" the modifications over validation and
aggressive caching (but as an implementor I still find this troublesome).

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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 practice, and the decision to make the unsigned delegation also a 
> *lame* unsigned delegation whilst simultaneously directing all leaked queries 
> with potential information about private networks to be sent to nameservers 
> that by design are intended to have anonymous operators is a poor one, I 
> think. I note that the security considerations section doesn't even address 
> the potential for information leakage.]

Ouch. That’s a depressing observation.  I’m can’t think of a way to completely 
mitigate this risk, however, unfortunately.  Any mitigation requires new code 
on the edge router for the provisioning domain in which the locally-served 
domain is being used.

>> Also, what do you think the operational effect of this will be? Given that 
>> these domains are currently provably nonexistent, this means that a resolver 
>> looking up names in these domains will have to special-case them.
> 
> 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 of resolver that need to be accommodated (e.g. 
> validating, hybrid stub/full service resolvers embedded in applications), 
> whatever configuration or auto-discovery mechanisms are required to support 
> those other locally-served zones can surely be easily extended to these 
> ISO-3166-2 codes if they are used in any particular private network.

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.

> This draft describes an existing consequence of existing policy. It may be 
> that Ed and Roy are the first ones to think about using them to anchor 
> private namespaces, but in some sense any corner cases that need special 
> handling today also needed special handling before this draft was written; we 
> just didn't know it yet.

I suspect that a discussion of the DNSSEC issue is in-scope. :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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 customer with a CPE, the ISP is resposible for
> anything that goes wrong.
> 
> We can be sure that there will be plenty of queries that leak out. How does
> an ISP deal with a report that the ISP provided device leads to traffic
> going to the manufacturer of said device?
> 
> The obvious next problem is where the manufacturer registers a domain name for
> a product line and then forgets to renew the domain when the product line 
> is no longer sold.

+1

Roy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

.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 17:00, Paul Wouters  wrote:

> 
> 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 want to recognise two points here:
>> 
>> 1) The lack of a private DNS domain is the main motivation to squat.
> 
> I would say the main motivation is a short and memorable TLD for their
> purpose. The importance here is "their purpose". Do you think tor would
> have settled for .zz instead of .onion ? Or that GNUnet people who
> wanted .gnu will settle for .zz ? And if they did, how would you expect
> browser plugins for these two _different_ uses of .zz to work?

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

> i think people who want a memorable name, will still squat one, and not
> use .zz.

Yes, and folks will cross a red light and there will be collisions, instead of 
using a zebra path.

>> 2) Using a private namespace is sometimes necessary, and its use needs to be 
>> legitimised 
>> Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
>> “gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
>> software is shipped with default configurations like  “openstacklocal”; 
>> renowned companies advise to configure “corp” and “internal” for private 
>> use, and ISPs are shipping home routers with “.telus” and “.home”. We have 
>> all seen those examples, have frowned upon it, and rant on various lists and 
>> fora.
> 
>> These companies all had motivations to choose these labels.
> 
> basically all the domains you list here could have used one of their own
> domains (eg local.telus.com instead of .telus, etc)

You are wilfully ignoring what I wrote. I know that seems convenient, but it is 
unhelpful in this discussion. Read the “bad idea” part below for your answer.

>> I know of two (imho legitimate) reasons, having learned this from a few 
>> organisations about why they prefer a squatted domain over a registered 
>> domain:
>> 
>> They could have shipped with a label under their own brand, but that would 
>> be an astonishingly bad idea, considering the volume (reason one) and type 
>> of traffic that was meant to be private (reason two), they would receive, as 
>> all these configurations will cause something to “phone home” to them.
> 
> So why not have no local domain instead? Or just pickup the DHCP domain
> name. This is just bad software design. But this group isn't going to
> fix that.
> 
> However, if these bad engineers start using .zz for this. What will
> happen is that ISPs are going to specially handle this queries, leading
> to a new set of issues for users. For example, dropping the queries
> instead of answering NXDOMAIN.

Really? No you think you know what ISPs will do?

> Lumping all these users together in .zz is just going to make each
> individual group inside .zz want to not be there. So I don't think
> your premise of letting them squat in one place will actually end up
> happening.

It is clear to me that you haven’t read the latest version of the draft. ZZ was 
an example that I have removed.

>> Additionally, why these organisations could to tell their users to not 
>> “squat”, find a registrar, buy a domain, renew it annually, etc, these users 
>> would move on to an organisation that says “just use .internal and you’ll be 
>> fine.”.
> 
> And those same people would not pick .zz but still pick their own more
> appropriate names.

We can’t help folks wilfully ignoring traffic signs.

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 neutral
parties that try to respect privacy, sounds better on paper than sending
traffic to a random manufacturer without having the relevant contracts for
data processing in place.

Futhermore, for a non-existing TLD, queries don't have to go further than 
the resolver.

Of course, the ISP can try to filter those queries. But a significant 
fraction of users and/or applications use a public resolver which will not
filter.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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, the ISP is resposible for
anything that goes wrong.

We can be sure that there will be plenty of queries that leak out. How does
an ISP deal with a report that the ISP provided device leads to traffic
going to the manufacturer of said device?

The obvious next problem is where the manufacturer registers a domain name for
a product line and then forgets to renew the domain when the product line
is no longer sold.


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)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 goes wrong.

We can be sure that there will be plenty of queries that leak out. How does
an ISP deal with a report that the ISP provided device leads to traffic
going to the manufacturer of said device?

The obvious next problem is where the manufacturer registers a domain name for
a product line and then forgets to renew the domain when the product line 
is no longer sold.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 BIND9.12 and Unbound 1.7.0 and I think in other 
implementations too, although I don't have references immediately to hand. I 
thought I had seen the results of some experiments that tried to measure the 
effectiveness of aggressive negative caching but I can't seem to find anything 
obvious, so maybe I was mistaken.

However, I would expect that as the deployment of 8198 increases in the 
resolver population (it defaults on in BIND9 and I think Unbound too) the extra 
traffic observed at the root should trend downwards. I think it's possible that 
if the question you pose is still a concern, it's at least a concern that is 
tending to decrease over time.

> Contrariwise, home.arpa has an un-signed delegation.

[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 
practice, and the decision to make the unsigned delegation also a *lame* 
unsigned delegation whilst simultaneously directing all leaked queries with 
potential information about private networks to be sent to nameservers that by 
design are intended to have anonymous operators is a poor one, I think. I note 
that the security considerations section doesn't even address the potential for 
information leakage.]

> Also, what do you think the operational effect of this will be? Given that 
> these domains are currently provably nonexistent, this means that a resolver 
> looking up names in these domains will have to special-case them.

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 of resolver that need to be accommodated (e.g. 
validating, hybrid stub/full service resolvers embedded in applications), 
whatever configuration or auto-discovery mechanisms are required to support 
those other locally-served zones can surely be easily extended to these 
ISO-3166-2 codes if they are used in any particular private network.

This draft describes an existing consequence of existing policy. It may be that 
Ed and Roy are the first ones to think about using them to anchor private 
namespaces, but in some sense any corner cases that need special handling today 
also needed special handling before this draft was written; we just didn't know 
it yet.

Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 want to recognise two points here:

1) The lack of a private DNS domain is the main motivation to squat.


I would say the main motivation is a short and memorable TLD for their
purpose. The importance here is "their purpose". Do you think tor would
have settled for .zz instead of .onion ? Or that GNUnet people who
wanted .gnu will settle for .zz ? And if they did, how would you expect
browser plugins for these two _different_ uses of .zz to work?

i think people who want a memorable name, will still squat one, and not
use .zz.

2) Using a private namespace is sometimes necessary, and its use needs to be legitimised 


Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
“gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
software is shipped with default configurations like  “openstacklocal”; 
renowned companies advise to configure “corp” and “internal” for private use, 
and ISPs are shipping home routers with “.telus” and “.home”. We have all seen 
those examples, have frowned upon it, and rant on various lists and fora.



These companies all had motivations to choose these labels.


basically all the domains you list here could have used one of their own
domains (eg local.telus.com instead of .telus, etc)


I know of two (imho legitimate) reasons, having learned this from a few 
organisations about why they prefer a squatted domain over a registered domain:

They could have shipped with a label under their own brand, but that would be 
an astonishingly bad idea, considering the volume (reason one) and type of 
traffic that was meant to be private (reason two), they would receive, as all 
these configurations will cause something to “phone home” to them.


So why not have no local domain instead? Or just pickup the DHCP domain
name. This is just bad software design. But this group isn't going to
fix that.

However, if these bad engineers start using .zz for this. What will
happen is that ISPs are going to specially handle this queries, leading
to a new set of issues for users. For example, dropping the queries
instead of answering NXDOMAIN.

Lumping all these users together in .zz is just going to make each
individual group inside .zz want to not be there. So I don't think
your premise of letting them squat in one place will actually end up
happening.


Additionally, why these organisations could to tell their users to not “squat”, 
find a registrar, buy a domain, renew it annually, etc, these users would move 
on to an organisation that says “just use .internal and you’ll be fine.”.


And those same people would not pick .zz but still pick their own more
appropriate names.

Also, people will get confused about "zee-zee" versus "zed-zed" :)


I’d like to get this space recognised as “better than squatting”.


One bad actor using their space will mark other good actors are
potentially bad ones. I wouldn't want to share my squatting place
with sketchy individuals and protocols.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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 provably do not exist, right?

Contrariwise, home.arpa has an un-signed delegation. Queries for home.arpa are
no worse than queries for any other .arpa subdomain, as far as the root is
concerned. On the other hand, perhaps they are worse for .arpa, and since in
fact .arpa is currently served by the root servers, perhaps this makes no
difference.

What’s the difference we’ll see in traffic for the root versus traffic for
.arpa if people adopt known-unused, securely nonexistent ccTLDs instead of an
un-signed delegation under .arpa?

Also, what do you think the operational effect of this will be? Given that
these domains are currently provably nonexistent, this means that a resolver
looking up names in these domains will have to special-case them. This is not
true for home.arpa. Are we okay with the operational effects of this? Or is it
a gap in the current version of your document that IANA is not instructed to
delegate these domains in the same way that home.arpa is delegated (see section
7 of RFC8375)?

Similarly, is it an omission in the current document that these domains are not
listed in the “transport-independent locally-served zones” IANA registry
(https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml)?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

> 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_ use a subdomain you own, it will save you headache later on 
> (e.g. when you decide to set up VPN to your supplier, but I do not insist on 
> this specific example).
> 2. If you think you need non-unique private subtree read list of problems 
> listed in ... [link to some other document] and think again.
> 3. Never ever squat
> 4. If this document did not change you mind use one of /zz/

I agree with you!

> 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 want to recognise two points here:

1) The lack of a private DNS domain is the main motivation to squat.

Squatting is not a good idea.

2) Using a private namespace is sometimes necessary, and its use needs to be 
legitimised  

Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
“gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
software is shipped with default configurations like  “openstacklocal”; 
renowned companies advise to configure “corp” and “internal” for private use, 
and ISPs are shipping home routers with “.telus” and “.home”. We have all seen 
those examples, have frowned upon it, and rant on various lists and fora. 

These companies all had motivations to choose these labels. 

I know of two (imho legitimate) reasons, having learned this from a few 
organisations about why they prefer a squatted domain over a registered domain:

They could have shipped with a label under their own brand, but that would be 
an astonishingly bad idea, considering the volume (reason one) and type of 
traffic that was meant to be private (reason two), they would receive, as all 
these configurations will cause something to “phone home” to them. 

Additionally, why these organisations could to tell their users to not “squat”, 
find a registrar, buy a domain, renew it annually, etc, these users would move 
on to an organisation that says “just use .internal and you’ll be fine.”. 

So for now, the query stops at the root, and with a carved out space, like the 
one I’m proposing, the query stops at the root, _indefinitely_.

If the intent is that the query should never reach the root, but handled 
internally, then I get that. Maybe RFC6303 or 6761 is an option here, but you’d 
still need a legitimate private space in order not to squat. 

I’d like to get this space recognised as “better than squatting”.

Warmly, and respectfully

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 for 
>> *explicit* support for adoption.
>>
>>
>> This starts a Call for Adoption for draft-arends-private-use-tld
>>
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/
>>
>> Please review this draft to see if you think it is suitable for adoption by 
>> DNSOP, and comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 26 June 2020
>
> I support adoption but share opinion that the document should not be 
> published as is.
>
> Rationale:
> - People are going to squat on global DNS no matter what IETF does.
> - This document is an opportunity to:
> a) Say "squating is a bad idea, see RFC 8244 and think it through" before you 
> decide to squat.
> b) Highlight _already reserved_ (by ISO) TLD strings for people who ignored 
> warning in point [a] above.
> c) I believe that side-effect of getting people _who insist on private TLD 
> anyway_ one of 40-something strings instead of "pick your 
> not-really-random-TLD" can lead to decrassing traffic to root and easier 
> monitoring in practice as caching should work better (either with query name 
> minimization or aggressive use of cache).

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 you decide to set up VPN to your supplier, but I do not insist on 
this specific example).
2. If you think you need non-unique private subtree read list of problems 
listed in ... [link to some other document] and think again.
3. Never ever squat
4. If this document did not change you mind use one of /zz/

+1

-- 
Robm
873

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 you decide to set up VPN to your supplier, but I do not insist
> on this specific example). 2. If you think you need non-unique private
> subtree read list of problems listed in ... [link to some other document]
> and think again. 3. Never ever squat
> 4. If this document did not change you mind use one of /zz/

+1.

-- 
Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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.
>>
>>
>> This starts a Call for Adoption for draft-arends-private-use-tld
>>
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/
>>
>> Please review this draft to see if you think it is suitable for adoption by 
>> DNSOP, and comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 26 June 2020
> 
> I support adoption but share opinion that the document should not be 
> published as is.
> 
> Rationale:
> - People are going to squat on global DNS no matter what IETF does.
> - This document is an opportunity to:
> a) Say "squating is a bad idea, see RFC 8244 and think it through" before you 
> decide to squat.
> b) Highlight _already reserved_ (by ISO) TLD strings for people who ignored 
> warning in point [a] above.
> c) I believe that side-effect of getting people _who insist on private TLD 
> anyway_  one of 40-something strings instead of "pick your 
> not-really-random-TLD" can lead to decrassing traffic to root and easier 
> monitoring in practice as caching should work better (either with query name 
> minimization or aggressive use of cache).

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 you decide to set up VPN to your supplier, but I do not insist on 
this specific example).
2. If you think you need non-unique private subtree read list of problems 
listed in ... [link to some other document] and think again.
3. Never ever squat
4. If this document did not change you mind use one of /zz/

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.

In general I want discourage from using private namespaces _unless absolutely 
necessary_, and this document has potential to make this a conscious choice 
instead of just picking "lan" without thinking about long-term consequences.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Dr Eberhard W Lisse

Michael,

RFC1591 says that the IANA (Function Operator) 

"[...]is not in the business of deciding what is and what is not a
country.

The selection of the ISO 3166 list as a basis for country code
top-level domain names was made with the knowledge that ISO has a
procedure for determining which entities should be and should not be
on that list."

What we call the 'ISO list' and the RFC calls the 'ISO 3166 list' is the
ISO Standard 3166-1 [1] establishing

"[...]an alphabetic 2-character (alpha-2) code[...] 

The alpha-2 code uses combinations, in upper case, of two letters
of the 26-character Roman alphabet (ignoring diacritic signs) in the
range AB to QL, RA to WZ, and YA to ZY. Code elements AA, QM to QZ,
XA to XZ, and ZZ are not part of this part of ISO 3166."


As a ccTLD Manager I am satisfied that as long as the user-assigned code
elements AA, QM to QZ, XA to XZ, and ZZ do not become 'part of this part
of ISO 3166' the IANA Function Operator will NOT delegate (cc)TLDs
corresponding to the user-assigned code elements (into the root).

As it is extremely unlikely that any of the user-assigned code elements
will ever become 'part of this part of ISO 3166', I agree with Roy that
this is good enough for the purposes of this proposal.

I do not believe that it would make sense to select an arbitrary subset
from the user-assigned code elements for the purposes of this proposal.

greetings, el

[1] International Standards Organization: International Standard ISO
3166-1, Codes for the representation of names of countries and their
subdivisions – Part 1: Country codes.  Version: 2013.
https://www.iso.org/iso-3166-country-codes.html


On 2020-06-16 01:16 , Roy Arends wrote:
> Hi Mike,
> 
>> On 14 Jun 2020, at 21:12, Michael StJohns 
>> wrote:
>>
>> Roy et al -
>>
>> Is there a document from ICANN taking a position on the assignment of
>> TLDs based on ISO3166 assignments?
> 
> Yes:
> https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en
> 
> From that page:
> 
> "In 2000, the ICANN Board of Directors recognized the ISO 3166
> Maintenance Agency as the authoritative entity for country code
> designations and officially adopted the use of ISO 3166-1 and the
> 3166-MA exceptional reserved list as the set of eligible designations
> for ccTLD assignment (September 2000)”
> 
> Please note that:
> 
> The ISO/TC46/WG2 “owns” ISO3166.  Any substantial changes to it, need
> to go through TC46.  The user-assigned two letter codes exist since
> the inception of the standard (15 december 1974).
> 
> TC46/WG2 has designated the User-Assigned two letter codes to users of
> the ISO3166-1 standard (not to the Maintenance Agency!)
> 
> TC46/WG2 refers the remaining codes to the Maintenance Agency for the
> assignment (Reserved, Assigned, Re-Assigned, Deleted, etc, etc) of two
> letter codes to country names.
> 
> The ISO3166/MA has no authority over the User-Assigned two letter
> codes.
> 
> It is naive to think that these policies, some of which pre-dates
> ICANN and even the Internet would be ignored by either ICANN or the
> ISO.
> 
> I think it is safe to assume that these codes will never by delegated
> in the root zone.
> 
>> When Jon was doing this he was adamant about following their lead -
>> rather than having to make political decisions about what was a
>> country.  The main role he had was not the selection of the TLDs, but
>> making sure that the delegations went to the right organizations
>> related to the countries indicated by the TLD. I would say that ICANN
>> should probably have the same role.
> 
> I agree.
> 
>> Given that ISO has indicated a range of specifically NOT issued 2
>> letter codes, and that these codes will never (should never?)  be
>> added to the root zone, I would suggest that it's probably not an
>> ICANN role to weigh in on this interpretation.
> 
> I agree.
> 
>> That said, I'd prefer it if the document selected a few (<=10) codes
>> from these ranges so that filtering may be built into various servers
>> and clients to prevent leakage.
> 
> With all due respect, I’ll wait with responding about specifics until
> the WG has adopted the document (if at all).
> 
> Warmly,
> 
> Roy

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht  \  /  If this email is signed with GPG/PGP
10007, Namibia   ;/ Sect 20 of Act No. 4 of 2019 may apply

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Warren Kumari

[ TOP POST ]

As previously noted in
https://mailarchive.ietf.org/arch/msg/dnsop/7AzjYP3XoLaPYKPjPzQzEn6k7L4/
, in July 2017 I published
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00, which
attempted to reserve .internal "for names which do not have meaning in
the global context but do have meaning in a context internal to their
network" and discussed the DNSSEC implications/deployment options. I
presented this at IETF100, and my understanding of the feedback (it
seemed very clear :-)) was that it was not appropriate for DNSOP, and
that I should take it to ICANN instead. I dutifully did so, and so
ICANN SSAC is now working on an advisory on this topic (which SSAC
hopes to have published soon). An update here:
https://mm.icann.org/pipermail/ncap-discuss/2020-June/000432.html

I believe that this places me in a conflicted position, and so I have
asked my co-AD (Robert Wilton, CCed) to please be responsible for the
document (if it progresses), and to oversee these discussions. He has
kindly agreed to do so.
W

On Fri, Jun 12, 2020 at 11:12 AM 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.
>
>
> This starts a Call for Adoption for draft-arends-private-use-tld
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/
>
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 26 June 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Roy Arends

On 16 Jun 2020, at 21:26, John R Levine  wrote:
> 
>> RFC2606: ".example" is recommended for use in documentation or as examples.
> 
> I had my reasons for https://www.mega-xxx-babes.com

That was actually funny :-)

Roy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread John R Levine


RFC2606: ".example" is recommended for use in documentation or as examples.


I had my reasons for https://www.mega-xxx-babes.com

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Roy Arends

On 16 Jun 2020, at 19:52, John Levine  wrote:
> 
> In article <3c1f1023-d17d-4739-8ca3-23f28254a...@internetstiftelsen.se> you 
> write:
>> I have a different use case for private TLDs and that is in teaching 
>> material. We give a DNS class at a university
>> here and in examples you cannot be restricted to .example as TLD because you 
>> need more than one TLD.
> 
> Well, that's what .TEST is for.

No it isn’t. 

RFC2606: ".test" is recommended for use in testing of current or new DNS 
related code.

>> And then you cannot rely on domain names that you can buy.
> 
> When I put domain names in my books as examples, I used real names and
> bought them.  In common domains they're not very expensive.

That is what .example is for.

RFC2606: ".example" is recommended for use in documentation or as examples.

Warmly,

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread John Levine

In article <64f09dbc-d465-4a05-be2f-14c71bec9...@fugue.com> you write:
>-=-=-=-=-=-
>
>On Jun 16, 2020, at 2:52 PM, John Levine  wrote:
>> When I put domain names in my books as examples, I used real names and
>> bought them.  In common domains they're not very expensive.
>
>Have you established a bequest, then, to cover the cost when you are no longer 
>able?

Once the books are out of print, I don't care very much. There are far
more real URLs of other people's web sites where the bits have rotted.

The message I was responding to was about course materials. Again, if
they stop working a year later when nobody's using them to teach, it's
hard to see that as a big problem.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Ted Lemon

On Jun 16, 2020, at 2:52 PM, John Levine  wrote:
> When I put domain names in my books as examples, I used real names and
> bought them.  In common domains they're not very expensive.

Have you established a bequest, then, to cover the cost when you are no longer 
able?

This is the problem with domain name registries as solutions to problems of 
this sort.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread John Levine

In article <3c1f1023-d17d-4739-8ca3-23f28254a...@internetstiftelsen.se> you 
write:
>I have a different use case for private TLDs and that is in teaching material. 
>We give a DNS class at a university
>here and in examples you cannot be restricted to .example as TLD because you 
>need more than one TLD.

Well, that's what .TEST is for.

>And then you cannot rely on domain names that you can buy.

When I put domain names in my books as examples, I used real names and
bought them.  In common domains they're not very expensive.

R's,
John

PS: mega-xxx-babes.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Mats Dufberg

On 15 Jun 2020, at 19:58, Tim Wicinski  wrote:
> 
> or since domains are cheap, why not buy a new domain, and use that for the 
> namespace?
> A wise person liked to remind me "Namespaces are architecture decisions”.

I have a different use case for private TLDs and that is in teaching material. 
We give a DNS class at a university here and in examples you cannot be 
restricted to .example as TLD because you need more than one TLD. And then you 
cannot rely on domain names that you can buy. The private two-letter codes are 
perfect for that.

---
Mats Dufberg
mats.dufb...@internetstiftelsen.se
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Jim Reid

> 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 seems to be about 
the content or metaissues around the I-D. That's premature IMO and should wait 
until the WG has decided to adopt the document. Or at the very least, the 
discussion should be taking place on another thread. And FWIW, the fact there’s 
been so much discussion suggests the WG should adopt the I-D.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Mats Dufberg

I support the adoption and I am willing to review the document.


---
Mats Dufberg
mats.dufb...@internetstiftelsen.se
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/




On 12 Jun 2020, at 17:36, Bob Harold 
mailto:rharo...@umich.edu>> wrote:


On Fri, Jun 12, 2020 at 11:12 AM Tim Wicinski 
mailto:tjw.i...@gmail.com>> 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.


This starts a Call for Adoption for draft-arends-private-use-tld

The draft is available here: 
https://datatracker.ietf.org/doc/draft-arends-private-use-tld/

Please review this draft to see if you think it is suitable for adoption by 
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 26 June 2020

Thanks,
tim wicinski
DNSOP co-chair


Support, will review.
Just read it - quite an exhaustive study of the subject.

--
Bob Harold

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread John R Levine


 - I think it would make sense for non-TLDs to be DNAME'd to AS112++'s
 empty zone (which generates an NXDOMAIN)


You want this in the root?

* IN DNAME EMPTY.AS112.ARPA.

That'd be, um, different.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-16 Thread Petr Špaček

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.
> 
> 
> This starts a Call for Adoption for draft-arends-private-use-tld
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 26 June 2020

I support adoption but share opinion that the document should not be published 
as is.

Rationale:
- People are going to squat on global DNS no matter what IETF does.
- This document is an opportunity to:
a) Say "squating is a bad idea, see RFC 8244 and think it through" before you 
decide to squat.
b) Highlight _already reserved_ (by ISO) TLD strings for people who ignored 
warning in point [a] above.
c) I believe that side-effect of getting people _who insist on private TLD 
anyway_  one of 40-something strings instead of "pick your 
not-really-random-TLD" can lead to decrassing traffic to root and easier 
monitoring in practice as caching should work better (either with query name 
minimization or aggressive use of cache).

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Joe Abley  wrote:
>
> However, given that this document only points out an option that already
> exist and doesn't actually recommend using a TLD versus any other
> anchor, I don't think any of that matters. I think it's up to another
> document to provide that kind of advice. It's hard to see any advantage
> in shoe-horning that advice into this one -- and the chances of such a
> document converging any time soon, regardless of venue. seem slim

The existence of this document and the lack of any better advice will mean
that the IETF recommendation is clear that the best setup for RFC 1918
networks is to use a reserved alpha-2 TLD. It isn't just pointing out
something that's already there, it's a massive shove encouraging people to
occupy this namespace.

As opposed to the current situation where the implicit advice is that you
should only use properly registered domain names, and reserved alpha-2
TLDs are only used by people like JP Mens in his test lab.
https://jpmens.net/2010/09/28/performing-dynamic-dns-updates-on-your-dns/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
democracy, participation, and the co-operative principle

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

On Mon, Jun 15, 2020 at 6:30 PM Tony Finch  wrote:

> Brian Dickson  wrote:
> >   - In addition to leaking information, these names generally should
> >   not have any presence in DNS caches, which makes them excellent
> > candidates
> >   for easy poisoning
>
> These issues happen in exactly the same way whether you squat on a tld or
> use a private subdomain.
>

Actually, no, or rather, it (susceptibility to poisoning) might depend.
Here's why:

The root zone is DNSSEC signed with NSEC.
It is literally impossible for anyone to poison any name at or below a
non-TLD.

A private subdomain of a real domain, only has the same properties if the
real domain is DNSSEC signed (chained from the root), and the public
version of that domain's zone denies the existence of the private subdomain.
I.e. that isn't going to be 100% true ever, and today has only a small
statistical chance of being true (DNSSEC uptake globally being about 1%).

In any case, the argument I'm making is 100% is tautologically optimal, and
the best any single enterprise can do is match that.

It's likely more reliable and easier to go the non-TLD route for all but
the most technically savvy enterprises (who probably won't rely on this
document regardless.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Joe Abley

On Jun 15, 2020, at 21:21, Tony Finch  wrote:

> Yes, that's why I pointed it out. The intro fairly explicitly says it's a
> replacement for .lan (etc.), but that raises questions about how this
> draft relates to other efforts to fix the .lan problem.

I think your reading of the text just indicates that it could be tightened up 
to be clearer, since I read it differently (it's a replacement choice, is my 
understanding).

I think the presence of ambiguity is an indication that a working group could 
improve thiss document.

>> But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that
>> kind of general advice; it provides specific advice for the case where
>> people have decided that a TLD is definitely needed by pointing out that
> 
> Can't we continue to point out that they are wrong and there are better
> ways of solving their problems?

I have wondered that myself, but I suppose there will always be people for whom 
registering a domain and keeping it registered is a worse answer than simply 
configuring something.

I also don't find the technical arguments that apparently make a fake TLD a 
better choice than a registered domain very compelling. I have wondered aloud 
whether there is data to support the asssertion that people are squatting on 
TLDs because of a need, or by accident or for some other reason; whether or not 
using a non-delegated TLD is in fact more common than using a registered domain 
at an anchor today; whether use of non-delegated TLDs is growing along axes 
that strongly indicates that this is a widespread problem and not something 
isolated to a handful of vendors; whether that growth still looks like growth 
when it's normalised against other variables that are trending up and to the 
right, etc, etc, etc.

However, given that this document only points out an option that already exist 
and doesn't actually recommend using a TLD versus any other anchor, I don't 
think any of that matters. I think it's up to another document to provide that 
kind of advice. It's hard to see any advantage in shoe-horning that advice into 
this one -- and the chances of such a document converging any time soon, 
regardless of venue. seem slim

> I also appreciate that this draft is very clever, but speaking as an IOCCC
> winner, very clever things can also be things you should never do in
> production.

I think the most clever thing about it is that it describes what is already 
there and doesn't ask any difficult questions or require any difficult 
decisions to be made. (Maybe your C code does that too, but if it does I 
presume that's not why you wouldn't run it in production :-)

Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Brian Dickson  wrote:
>
> Precisely because you want a non-TLD (we should remember this is NOT an
> actual TLD), for a number of reasons:
>
>- You want to be able to limit the places any leaked traffic goes
>   - Currently this would be the Root Servers

And any resolvers in between there and roaming users.

>   - The typical content of enterprisey internal-only names (the DNS
>queries themselves) are sensitive in nature
>   - I have had the opportunity to view DITL data from ISP resolvers,
>   and the nature of these kinds of queries was unsettling
>   - In addition to leaking information, these names generally should
>   not have any presence in DNS caches, which makes them excellent
> candidates
>   for easy poisoning

These issues happen in exactly the same way whether you squat on a tld or
use a private subdomain.

The draft doesn't talk about random subdomains; instead it says that part
of the point is to make names as short as possible. And our experience
with telling people to use random parts of private address space (as in
RFC 1918, and IPv6 GUA) is that they don't.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Foreland to Selsey Bill: Southerly or southwesterly, becoming variable
at times, 2 or 3, occasionally 4 until later. Smooth, occasionally slight. Fog
patches for a time near shore. Moderate or good, occasionally very poor for a
time near shore.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Joe Abley  wrote:
> On Jun 15, 2020, at 18:46, Tony Finch  wrote:
>
> > The intro to this draft talks about things like x- which has been
> > deprecated since RFC 6648. It mentions some situationw where .test or
> > ..invalid would seem to be the right things to use, but it doesn't say why
> > not. It lists a bunch of TLDs that are being squatted by devices that
> > ought to move to home.arpa instead, but doesn't say why we have given up
> > on that idea after only a couple of years, or why we should expect them to
> > move to ISO 3166 reserved codes when they haven't moved to home.arpa.
>
> I don't remember any text in the document that talked about people
> changing what they are doing.

Yes, that's why I pointed it out. The intro fairly explicitly says it's a
replacement for .lan (etc.), but that raises questions about how this
draft relates to other efforts to fix the .lan problem. I think people
will read this draft as saying, don't do that home.arpa thing, don't do
that .lan thing, do this.

> Personally, I think the right advice for most people is that if you must
> use private namespace you should anchor it at a domain name in the
> global namespace that you control, so that your namespace is both
> private and unique. Someone should write that document. I'll help, if
> someone is interested.

I agree that is the right advice.

> But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that
> kind of general advice; it provides specific advice for the case where
> people have decided that a TLD is definitely needed by pointing out that

Can't we continue to point out that they are wrong and there are better
ways of solving their problems?

I also appreciate that this draft is very clever, but speaking as an IOCCC
winner, very clever things can also be things you should never do in
production.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Mainly westerly or northwesterly, 3 to 5, occasionally 6 in
southeast. Moderate, occasionally slight. Showers in north. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

On Mon, Jun 15, 2020 at 5:59 PM Tony Finch  wrote:

> Brian Dickson  wrote:
>
> > Internal-only use is not only satisfied with non-delegated name spaces,
> it
> > actually is a much better fit for everything.
>
> Yes, I agree, but why does the point of non-delegation have to be a
> squatted collision-prone TLD, rather than a guaranteed collision-free
> subdomain of a properly registered domain?
>

Precisely because you want a non-TLD (we should remember this is NOT an
actual TLD), for a number of reasons:

   - You want to be able to limit the places any leaked traffic goes
  - Currently this would be the Root Servers
  - I think it would make sense for non-TLDs to be DNAME'd to AS112++'s
  empty zone (which generates an NXDOMAIN)
 - Either as specific names, or as a wildcard
  - The typical content of enterprisey internal-only names (the DNS
   queries themselves) are sensitive in nature
  - I have had the opportunity to view DITL data from ISP resolvers,
  and the nature of these kinds of queries was unsettling
  - In addition to leaking information, these names generally should
  not have any presence in DNS caches, which makes them excellent
candidates
  for easy poisoning
   - As I pointed out elsewhere in this thread, collision avoidance without
   revealing information can be done easily enough,
  - E.g. with use of a 12-character random string of letters and digits
  - 36^12 is pretty collision-resistant.
  - Use one of these, enterprise-wide
  - Or even site-wide at a sub-enterprise level if site-site isn't a
  requirement.

You can only squat on a property. This is a non-property, so technically it
is not squatting, appearances notwithstanding.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Brian Dickson  wrote:

> Internal-only use is not only satisfied with non-delegated name spaces, it
> actually is a much better fit for everything.

Yes, I agree, but why does the point of non-delegation have to be a
squatted collision-prone TLD, rather than a guaranteed collision-free
subdomain of a properly registered domain?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, North Thames: Variable 2 to 4. Smooth, occasionally slight. Fog banks.
Moderate, occasionally very poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Joe Abley

On Jun 15, 2020, at 18:46, Tony Finch  wrote:

> The intro to this draft talks about things like x- which has been
> deprecated since RFC 6648. It mentions some situationw where .test or
> ..invalid would seem to be the right things to use, but it doesn't say why
> not. It lists a bunch of TLDs that are being squatted by devices that
> ought to move to home.arpa instead, but doesn't say why we have given up
> on that idea after only a couple of years, or why we should expect them to
> move to ISO 3166 reserved codes when they haven't moved to home.arpa.

I don't remember any text in the document that talked about people changing 
what they are doing. I thought the point of it was to provide some guidance for 
people who have decided (for whatever reason) that they have a use for a 
private namespace anchored by a TLD but who haven't decided what to use yet.

Personally, I think the right advice for most people is that if you must use 
private namespace you should anchor it at a domain name in the global namespace 
that you control, so that your namespace is both private and unique. Someone 
should write that document. I'll help, if someone is interested.

But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that kind 
of general advice; it provides specific advice for the case where people have 
decided that a TLD is definitely needed by pointing out that the 3166 people 
have already reserved a label for them to use and that current ICANN policy is 
that such label will never clash with a real (non-private) TLD.

Note that without this document, the above will still be true. The 
two-character codes mentioned in this document will still be available for use 
for whatever purpose people can dream up, and will still not be delegated by 
ICANN. This document just writes it down so that people don't have to do the 
consderable homework to reach that conclusion themselves.

I continue to think that using policy that already exists to solve a problem 
that apparently some poeple have without asking anybody to change anything at 
all is a thing of great and enduring beauty, and I'm quite surprised that so 
many people are trying to hard to turn it into something more difficult to 
agree with.

Perhaps we've all been deprived of mic lines for long enough that we have some 
pent-up need to make things complicated.

Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

On Mon, Jun 15, 2020 at 3:00 PM Tony Finch  wrote:

> Paul Vixie  wrote:
> > On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> > >
> > > or since domains are cheap, why not buy a new domain, and use that for
> the
> > > namespace?
> >
> > that makes internet viral, and private communications require global
> > allocations for no necessary reason. the above quite describes
> centralization
> > for the sake of centralization. nothing should be centralized unless
> there's
> > no other way to do what needs doing.
> >
> > reserving a corner of the namespace for decentralized operations makes
> sense.
>
> There are perhaps three contexts that you might want a private namespace:
>
> * enterprisey setups
>
> * home setups
>

No. Just No.

At most, home setups may not want dedicated registered domains (that they
pay money for directly to a registrar and indirectly to a registry).
However, they absolutely need to have functioning global DNS ability,
regardless of the parent domain(s) they might use.

As long as they are able to have a workable FQDN, regardless of whether it
is ephemeral or a stable name, that is the minimum requirement.

As your argument below points out, any decentralized thing can't be used
for this (regardless of whether it's anchored in 2-letter ISO space or
underneath some arpa child).

>
> * splendid isolation
>
> For both the enterprise and home case, you're probably going to want to do
> things beyond the DNS that are much easier if you're part of a global
> namespace - TLS certs are probably the main one. For the enterprise case,
> getting a suitable domain is normal. For the home case, it would make
> sense for manufacturers of home gateways / access points to allocate a
> per-customer subdomain. Then you can have IPv6 prefix delegation and
> managed access to your devices at home without everything being proxied
> via some cloud server. (I can dream?)
>

The enterprise case is not a single case, and is the exception that proves
the point.
As much as it may require more technically savvy operations, if there is a
need for both an internet-reachable
and a non-internet-reachable subsection of their infrastructure, having
different name spaces with different properties
is the answer that best fits their needs.

Internal-only use is not only satisfied with non-delegated name spaces, it
actually is a much better fit for everything.
Both DNSSEC and PKIX (or more likely, DANE/TLSA for X.509 certs) are better
fits for the internal-only case.
The goal for internal only, is to ensure it CANNOT work over the internet,
not just that it isn't guaranteed to work over the internet.
You WANT resolution to fail. You WANT certificate validation to fail. You
WANT DNSSEC validation to fail.
Anchoring all of these things in a non-global namespace (which is still
sufficiently well-defined to be highly collision resistant) is the ideal
choice.

This has NOTHING to do with the parts of an enterprisey setup for the parts
that are meant to be internet-reachable.

Trying to force the two things together for some perceived benefit is
unwise in the extreme.
As Randy Bush often says, to paraphrase, I encourage my competitors to do
this.
Except I'm not Randy, and I wouldn't encourage ANYONE to do this. That's
just mean.

>
> For splendid isolation, you're already committing to setting up your own
> CA and distributing keys, so you can probably set up your own fake root
> zone and whatever else. I don't think it's something that should be
> encouraged as a standard thing to do, though. How could it be made to work
> usefully for non-technical home users?
>

You don't want home users doing this, ever.
Even the most extreme cases in homenet WG still envision having their stuff
linked below the DNS equivalent of a prefix delegation, optionally.

If there is any ambiguity in the draft to the effect that anyone other than
the non-internet-reachable enterprisey or the splendid isolation use cases,
let's make the document better to that effect.

Respectfully,
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Roy Arends

> On 16 Jun 2020, at 01:18, Wes Hardaker  wrote:
> 
> Roy Arends  writes:
> 
>> The can never be registered. There is no collision. That is the point
>> of all of this.
> 
> Then why does your draft say "unlikely" in multiple places rather than
> the strength of your wording above: "can never"?

I use unlikely twice (2, two times, not more).

The first time I use the term “extremely unlikely” because the generally 
accepted term for “never", without having to say “never” is “Highly unlikely” 
was not strong enough IMHO.

The second time I use the term unlikely was: "It is unlikely that the 
user-assigned range will change.” which refers to the probability of the range 
changing. 

I had “extremely unlikely” here as well at first, but then noticed that “OO” 
can be utilised to indicate that code elements other than those defined in the 
ISO 3166 are used, If the number of user-assigned code elements in 8.1.3 is not 
sufficient to cover a particular user requirement. I will fix that in the next 
release to say “extremely unlikely”, and explicitly exclude “OO” from the list.

I hope that works for you,

Thanks

Warmly,

Roy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Wes Hardaker

Roy Arends  writes:

> The can never be registered. There is no collision. That is the point
> of all of this.

Then why does your draft say "unlikely" in multiple places rather than
the strength of your wording above: "can never"?
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Christian Huitema

On 6/15/2020 4:30 PM, Geoff Huston wrote:
>> On 16 Jun 2020, at 8:12 am, Paul Wouters  wrote:
>>
>> On Mon, 15 Jun 2020, Suzanne Woolf wrote:
>>
>>> 1. This draft as written takes no formal action to reserve anything for any 
>>> particular purpose. It makes some observations about the administration
>>> of ISO 3166 and its use in the ICANN context, and suggests to operators and 
>>> implementers that the ISO3166 user-assigned 2-letter strings could be
>>> suitable for local use in domain names. It does not include any IANA 
>>> actions to update any registry or protocol element. So claims that this 
>>> draft
>>> reserves names or attempts to override ICANN policy about “TLDs” seem 
>>> premature.
>> In a way, this is even worse. It is "marking" some TLD strings in a
>> special way, without any official IANA registry or ICANN policy anywhere.
>>
>> We have already seen discussion on how this could lead to increased root
>> zone traffic, privacy leaks to public DNS, and the possible requirement
>> of adding things to AS112.
> +1

Geoff,

I am old enough to know that we should never challenge worse, as in
"root traffic cannot possibly get much worse than what it already is".
But then, I truly wonder whether Roy's suggestion would make the problem
worse. At worse, the IETF position would be shifting from "we don't
recognize the need for private domains so use whatever you think of" to
"if you really want to use a private domain, use one of these reserved
2-letter codes." It would seem that using a small set of code would
increase the efficacy of negative caching, and would thus tend to
diminish the traffic to the root.

And now, for a "Carthago delenda est" moment, let's point out that
almost 50% of the traffic to the root comes from the Chrome browser
making up randomly named TLD to probe whether the local ISP is hijacking
NXDomain replies. If we really want to reduce the leaks to the root,
there is that.

-- Christian Huitema

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Paul Vixie  wrote:
>
> > I.e. the proposed use case is already widely deployed and known to be a
> > bad idea.
>
> known by whom, and how? (got URL?)

Gosh well I thought this was widely agreed folklore / common sense since
the 1990s and I'm not in the habit of collecting links to essays on "why X
is a bad idea" when it seems from my perspective that approximately nobody
writes essays like that because X is obviously a bad idea... :-)

But, we know that overlapping name spaces and address spaces are a
nightmare for mergers and acquisitions.

It's incompatible with private interconnects, such as organizations
collaborating without mergeing, or home-to-home VPNs.

We know that non-unique namespaces are incompatible with the web security
model.

We know that it's incompatible with PKIX. (You can do private x.509 but
not public.)

We know it's incompatible with DNSSEC. (You can set up a private root, but
then we're back to splendid isolation and arcane technical expertise.)

Overall it scuppers much of the protocols that support end-to-end
connectivity and security.

And the breakage is unnecessary because we know there are straightforward
alternatives that avoid the problems.

[ I am maybe exaggerating a bit about the 1990s, because back then, when
Microsoft Small Business Server was encouraging everyone and their dog to
squat on .local, domain names were 10x more expensive than now and 100x
more difficult to obtain, so they had a reasonable excuse, but it was
still terrible. ]

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Channel Islands: South to southeast 2 to 4, becoming variable 1 to 3 by early
afternoon, then northwest 1 to 3 by midnight. Smooth or slight. Scattered
thundery showers, mainly near French coasts, risk of mist or fog patches,
mainly in the north of the area. Moderate or good, occasionally poor, perhaps
locally very poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Roy Arends




> On 15 Jun 2020, at 22:51, Wes Hardaker  wrote:
> 
> Suzanne Woolf  writes:
> 
>> 1. This draft as written takes no formal action to reserve anything
>> for any particular purpose.
> 
> No, but it does make the recommendation to use unreserved space.

No.

This is not unreserved space. This is space reserved, for the user. By the ISO, 
blessed by RFC1591.

>  But it
> "proposes that nay of them can be used by a network or application for
> private use." [section 5].

Yes, as designed by the original drafters of the ISO3166 standards and used 
today, as intended, by a wide variety of organisations, including the IETF.

>  Fundamentally, the end effect is the same:
> we recommend you use these "unreserved" code points.

Not unreserved.

>  The net effect in
> real world traffic will likely be the same (by design).

Sure.

>  And the net
> effect in policy will likely be the same: a potential collision that

What?

> forces other organizations to never register them because the defacto
> standard created by this non-registration would be to treat it like it
> was a registration.  [see .onion]

The can never be registered. There is no collision. That is the point of all of 
this.

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Geoff Huston



> On 16 Jun 2020, at 8:12 am, Paul Wouters  wrote:
> 
> On Mon, 15 Jun 2020, Suzanne Woolf wrote:
> 
>> 1. This draft as written takes no formal action to reserve anything for any 
>> particular purpose. It makes some observations about the administration
>> of ISO 3166 and its use in the ICANN context, and suggests to operators and 
>> implementers that the ISO3166 user-assigned 2-letter strings could be
>> suitable for local use in domain names. It does not include any IANA actions 
>> to update any registry or protocol element. So claims that this draft
>> reserves names or attempts to override ICANN policy about “TLDs” seem 
>> premature.
> 
> In a way, this is even worse. It is "marking" some TLD strings in a
> special way, without any official IANA registry or ICANN policy anywhere.
> 
> We have already seen discussion on how this could lead to increased root
> zone traffic, privacy leaks to public DNS, and the possible requirement
> of adding things to AS112.

+1

Geoff

(I must admit to being more confused than enlighted after Suzanne’s post!)


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Paul Vixie

On Monday, 15 June 2020 22:46:17 UTC Tony Finch wrote:
> Paul Vixie  wrote:
> > there are perhaps more than three, and some might not be yet known by
> > those who will want them. the reason why some part of the DNS namespace
> > should be reserved in the form, "shall never be allocated by IANA", is
> > not because we cannot think of a good enough and present cause why such a
> > thing may be desirable.
> 
> Fair enough, but what you are suggesting seems to be quite different from
> what this draft is suggesting. You seem to be talking about reserving for
> future use, or for lab environments that never connects to any other part
> of the Internet, whereas this draft is just suggesting that everyone
> should use these ISO 3166 reserved codes as a 192.168 free-for-all instead
> of .lan or .home or whatever they are currently squatting on.

i expect the problem statement and proposed solution to be subject to the usual 
WG 
process. it's possible that the ISO 3166 reservations _should_ stand. or else, 
that a new 
IETF-reserved code should be created. i'm not using .local at the moment, but i 
remember 
collision studies around .corp and .home. i'm not sure i care how the IETF 
promises never 
to allow some tld to be delegated (other than as a wildcard pointing to AS112, 
or similar), 
but i'd like to see it.

> I.e. the proposed use case is already widely deployed and known to be a
> bad idea.

known by whom, and how? (got URL?) 

-- 
Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Roy Arends

Hi Mike,

> On 14 Jun 2020, at 21:12, Michael StJohns  wrote:
> 
> Roy et al - 
> 
> Is there a document from ICANN taking a position on the assignment of TLDs 
> based on  ISO3166 assignments?   

Yes: https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en

From that page:

"In 2000, the ICANN Board of Directors recognized the ISO 3166 Maintenance 
Agency as the authoritative entity for country code designations and officially 
adopted the use of ISO 3166-1 and the 3166-MA exceptional reserved list as the 
set of eligible designations for ccTLD assignment (September 2000)”

Please note that:

The ISO/TC46/WG2 “owns” ISO3166. Any substantial changes to it, need to go 
through TC46. The user-assigned two letter codes exist since the inception of 
the standard (15 december 1974).

TC46/WG2 has designated the User-Assigned two letter codes to users of the 
ISO3166-1 standard (not to the Maintenance Agency!)

TC46/WG2 refers the remaining codes to the Maintenance Agency for the 
assignment (Reserved, Assigned, Re-Assigned, Deleted, etc, etc) of two letter 
codes to country names.

The ISO3166/MA has no authority over the User-Assigned two letter codes.

It is naive to think that these policies, some of which pre-dates ICANN and 
even the Internet would be ignored by either ICANN or the ISO. 

I think it is safe to assume that these codes will never by delegated in the 
root zone.

> When Jon was doing this he was adamant about following their lead - rather 
> than having to make political decisions about what was a country.  The main 
> role he had was not the selection of the TLDs, but making sure that the 
> delegations went to the right organizations related to the countries 
> indicated by the TLD.   I would say that ICANN should probably have the same 
> role.   

I agree.

> Given that ISO has indicated a range of specifically NOT issued 2 letter 
> codes, and that these codes will never (should never?) be added to the root 
> zone, I would suggest that it's probably not an ICANN role to weigh in on 
> this interpretation.

I agree.

> That said, I'd prefer it if the document selected a few (<=10) codes from 
> these ranges so that filtering may be built into various servers and clients 
> to prevent leakage.  

With all due respect, I’ll wait with responding about specifics until the WG 
has adopted the document (if at all).

Warmly, 

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Paul Vixie  wrote:
>
> there are perhaps more than three, and some might not be yet known by those 
> who will
> want them. the reason why some part of the DNS namespace should be reserved 
> in the
> form, "shall never be allocated by IANA", is not because we cannot think of a 
> good
> enough and present cause why such a thing may be desirable.

Fair enough, but what you are suggesting seems to be quite different from
what this draft is suggesting. You seem to be talking about reserving for
future use, or for lab environments that never connects to any other part
of the Internet, whereas this draft is just suggesting that everyone
should use these ISO 3166 reserved codes as a 192.168 free-for-all instead
of .lan or .home or whatever they are currently squatting on.

I.e. the proposed use case is already widely deployed and known to be a
bad idea.

The intro to this draft talks about things like x- which has been
deprecated since RFC 6648. It mentions some situationw where .test or
..invalid would seem to be the right things to use, but it doesn't say why
not. It lists a bunch of TLDs that are being squatted by devices that
ought to move to home.arpa instead, but doesn't say why we have given up
on that idea after only a couple of years, or why we should expect them to
move to ISO 3166 reserved codes when they haven't moved to home.arpa.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Paul Vixie

On Monday, 15 June 2020 22:00:31 UTC Tony Finch wrote:
> Paul Vixie  wrote:
> > ...
> > 
> > reserving a corner of the namespace for decentralized operations makes
> > sense.
> There are perhaps three contexts that you might want a private namespace:
> 
> ...

there are perhaps more than three, and some might not be yet known by those who 
will 
want them. the reason why some part of the DNS namespace should be reserved in 
the 
form, "shall never be allocated by IANA", is not because we cannot think of a 
good 
enough and present cause why such a thing may be desirable.

setting a wildcard to point at AS112 makes perfect sense to me.

the document can remind that there's no uniqueness among unregistered domains, 
and 
that any name which might be partially or occasionally or eventually visible to 
a supplier, 
customer, partner, or acquirer should not be placed inside the reserved-name 
TLD due to 
unreachability and/or collision problems.

nothing should be centralized that does not have to be.

-- 
Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Paul Wouters


On Mon, 15 Jun 2020, Suzanne Woolf wrote:


1. This draft as written takes no formal action to reserve anything for any 
particular purpose. It makes some observations about the administration
of ISO 3166 and its use in the ICANN context, and suggests to operators and 
implementers that the ISO3166 user-assigned 2-letter strings could be
suitable for local use in domain names. It does not include any IANA actions to 
update any registry or protocol element. So claims that this draft
reserves names or attempts to override ICANN policy about “TLDs” seem premature.


In a way, this is even worse. It is "marking" some TLD strings in a
special way, without any official IANA registry or ICANN policy anywhere.

We have already seen discussion on how this could lead to increased root
zone traffic, privacy leaks to public DNS, and the possible requirement
of adding things to AS112.


3. When several proposals came to the IETF more or less at once regarding 
“special use domain names”, which proponents were insisting had to be
single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB 
and IESG — set those proposals aside in hopes of finding a less
time-consuming, more scalable, and less dramatic way of considering changes to 
the special use names registry than having an open-ended IETF Last
Call, since there’s almost no technical guidance in RFC 6761 to determine 
whether a specific request is useful or even valid. 


This has come up before, and I do feel I need to again correct
this. All but one proposal was set aside. The .onion was given a strange
exception. This came after the WG told the draft authors to split the
single draft into multiple versions for the different TLDs requested,
and so .onion appeared in a separate draft _after_ that instruction.

It seems a bit of rewriting history to now claim "several proposals came
to the IETF more or less at once".


The chairs are reluctant to spend WG time in this area


I concur. The DNSOP WG is not the proper place to discuss this, based
on the previous handling of Special Use Domains brought to the WG.
Furthermore, those discussions caused the WG quite some delay in handling
actual DNS protocol and operational issues.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Paul Vixie  wrote:
> On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> >
> > or since domains are cheap, why not buy a new domain, and use that for the
> > namespace?
>
> that makes internet viral, and private communications require global
> allocations for no necessary reason. the above quite describes centralization
> for the sake of centralization. nothing should be centralized unless there's
> no other way to do what needs doing.
>
> reserving a corner of the namespace for decentralized operations makes sense.

There are perhaps three contexts that you might want a private namespace:

* enterprisey setups

* home setups

* splendid isolation

For both the enterprise and home case, you're probably going to want to do
things beyond the DNS that are much easier if you're part of a global
namespace - TLS certs are probably the main one. For the enterprise case,
getting a suitable domain is normal. For the home case, it would make
sense for manufacturers of home gateways / access points to allocate a
per-customer subdomain. Then you can have IPv6 prefix delegation and
managed access to your devices at home without everything being proxied
via some cloud server. (I can dream?)

For splendid isolation, you're already committing to setting up your own
CA and distributing keys, so you can probably set up your own fake root
zone and whatever else. I don't think it's something that should be
encouraged as a standard thing to do, though. How could it be made to work
usefully for non-technical home users?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lands End to St Davids Head including the Bristol Channel: Variable 2 to 4.
Slight in west, smooth in east. Showers, thundery at times. Good, occasionally
poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Wes Hardaker

Suzanne Woolf  writes:

> 1. This draft as written takes no formal action to reserve anything
> for any particular purpose.

No, but it does make the recommendation to use unreserved space.  But it
"proposes that nay of them can be used by a network or application for
private use." [section 5].  Fundamentally, the end effect is the same:
we recommend you use these "unreserved" code points.  The net effect in
real world traffic will likely be the same (by design).  And the net
effect in policy will likely be the same: a potential collision that
forces other organizations to never register them because the defacto
standard created by this non-registration would be to treat it like it
was a registration.  [see .onion]

> 2. If we want to know what ICANN-the-organization thinks of this
> proposal, there is a mechanism for asking that question. The IAB, on
> behalf of the IETF, maintains a liaison relationship with ICANN, in
> the form of a non-voting liaison to the ICANN Board of Directors, who
> can be asked to convey a question or statement about an issue of
> mutual interest.

Yes, but they didn't do that.  I do suggest we do just that before
accepting this as a viable path forward.
-- 
Wes Hardaker
USC/ISI

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Suzanne Woolf

Dear colleagues,

It will be helpful to the chairs in considering the future of this draft if 
folks could keep a few things in mind as we discuss it.

1. This draft as written takes no formal action to reserve anything for any 
particular purpose. It makes some observations about the administration of ISO 
3166 and its use in the ICANN context, and suggests to operators and 
implementers that the ISO3166 user-assigned 2-letter strings could be suitable 
for local use in domain names. It does not include any IANA actions to update 
any registry or protocol element. So claims that this draft reserves names or 
attempts to override ICANN policy about “TLDs” seem premature.

We’ve heard concerns that by encouraging people to use these strings in local 
DNS contexts, an RFC with no IANA actions could have the effect of constraining 
future ICANN policy. This brings us to:

2. If we want to know what ICANN-the-organization thinks of this proposal, 
there is a mechanism for asking that question. The IAB, on behalf of the IETF, 
maintains a liaison relationship with ICANN, in the form of a non-voting 
liaison to the ICANN Board of Directors, who can be asked to convey a question 
or statement about an issue of mutual interest. We’ve used this capability 
before, and intend to ask the IAB to make use of this liaison relationship 
again if the WG wants to proceed on this draft. 

As one of the draft authors already wrote to the list, the draft does not offer 
an official position or commitment by ICANN as an organization. (Under our 
process, affiliation of a draft author can’t be used to infer such statements, 
either.) That’s literally what liaisons are for: to allow the IETF to interact 
with a standards or policy body as an organization.

3. When several proposals came to the IETF more or less at once regarding 
“special use domain names”, which proponents were insisting had to be 
single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB 
and IESG — set those proposals aside in hopes of finding a less time-consuming, 
more scalable, and less dramatic way of considering changes to the special use 
names registry than having an open-ended IETF Last Call, since there’s almost 
no technical guidance in RFC 6761 to determine whether a specific request is 
useful or even valid. 

This did not happen. RFC 8244 was published in 2017, but several drafts 
attempting to solve parts of the problem it described met with very little 
interest from the WG.

The chairs are reluctant to spend WG time in this area unless there’s 
reasonably clear benefit.  If there is, we’re happy to work with the WG, the 
IAB, ICANN liaison, et. al. to manage any governance issues.

Best,
Suzanne, Tim, and Benno

> On Jun 12, 2020, at 11:12 AM, 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.
> 
> 
> This starts a Call for Adoption for draft-arends-private-use-tld
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 26 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Paul Vixie

On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> (no hats here)
> 
> ...
> > 
> > The obvious question is if an organization is willing to use
> > example.com.zz, why wouldn't they use zz.example.com with split
> > horizon DNS to keep that subtree on their local network?
> 
> or since domains are cheap, why not buy a new domain, and use that for the
> namespace?

that makes internet viral, and private communications require global 
allocations for no necessary reason. the above quite describes centralization 
for the sake of centralization. nothing should be centralized unless there's 
no other way to do what needs doing.

reserving a corner of the namespace for decentralized operations makes sense.

-- 
Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

On Mon, Jun 15, 2020 at 10:47 AM John Levine  wrote:

> In article <
> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
> write:
> >E.g. use an FQDN belonging to you (or your company), so the namespace
> would
> >be example.com.zz under which your private names are instantiated.
>
> The obvious question is if an organization is willing to use
> example.com.zz, why wouldn't they use zz.example.com with split
> horizon DNS to keep that subtree on their local network?
>

There are lots of reasons that are subtle.
The main one is failure modes and the implications.
I.e. Attempting to use a third-party resolver, or if a VPN disconnects,
etc. should only send queries to the root servers (and get NXDOMAIN
responses).
Similarly, any operational failure on the split-brain itself has the same
result (root servers only).

Another one is search lists. Using search lists with domains that terminate
in one of these non-TLDs (e.g. zz) ensures that the same semantics applies
(root only).

This is one place where QNAME minimization is also significantly beneficial.

Independent of this proposal, I think it would be good to delegate these
non-TLDs to the AS112++ servers (RFC 7535), to limit impact on the root
servers.

Also independent of that, I also think it might be worth considering
whether/how to upgrade RFC 7534 to use a signed zone and securely
delegating to that from as112.arpa.

One completely bonkers idea would be to deploy a wildcard delegation in the
root zone to AS112++ servers, rather than doing piecemeal delegations, but
that's not a hill I'm willing to die on. :-)

> For whatever reason, people like short names where short means two
> components.
>

Yes, and people like ponies.

The only time short names have any applicability is when connecting to
hosts directly, e.g. with SSH, and where some form of search list appends
the rest of the name.
That practice is better handled within SSH config files rather than in DNS
search lists.

Someone should write that up as a BCP. :-)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Scott Morizot

On Mon, Jun 15, 2020 at 12:59 PM Tim Wicinski  wrote:

> On Mon, Jun 15, 2020 at 1:48 PM John Levine  wrote:
>
>> In article <
>> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
>> write:
>> >E.g. use an FQDN belonging to you (or your company), so the namespace
>> would
>> >be example.com.zz under which your private names are instantiated.
>>
>> The obvious question is if an organization is willing to use
>> example.com.zz, why wouldn't they use zz.example.com with split
>> horizon DNS to keep that subtree on their local network?
>>
>>
> or since domains are cheap, why not buy a new domain, and use that for the
> namespace?
> A wise person liked to remind me "Namespaces are architecture decisions".
> tim
>
>
Or use a combination of both approaches (separate second level domain and
distinct subdomains in a shared public/private domain tree) if that fits
your needs. The different aspects are for distinct needs. At work, for
instance, we use a completely separate second level domain tree for many of
our primary Active Directory forests and their constituent domains. We use
private subdomain trees under our public second level domain for many other
things. The appropriate internal/external boundaries require some thought
and ongoing management, but it's not especially difficult.

Scott
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread Tim Wicinski

(no hats here)


On Mon, Jun 15, 2020 at 1:48 PM John Levine  wrote:

> In article <
> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
> write:
> >E.g. use an FQDN belonging to you (or your company), so the namespace
> would
> >be example.com.zz under which your private names are instantiated.
>
> The obvious question is if an organization is willing to use
> example.com.zz, why wouldn't they use zz.example.com with split
> horizon DNS to keep that subtree on their local network?
>
>
or since domains are cheap, why not buy a new domain, and use that for the
namespace?
A wise person liked to remind me "Namespaces are architecture decisions".
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-15 Thread John Levine

In article  
you write:
>E.g. use an FQDN belonging to you (or your company), so the namespace would
>be example.com.zz under which your private names are instantiated.

The obvious question is if an organization is willing to use
example.com.zz, why wouldn't they use zz.example.com with split
horizon DNS to keep that subtree on their local network?

For whatever reason, people like short names where short means two components.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

On Mon, Jun 15, 2020 at 8:34 AM Tony Finch  wrote:

> Tim Wicinski  writes:
>
> > This starts a Call for Adoption for draft-arends-private-use-tld
>
> I think this is cute / clever, but a very bad idea.
>
> Experience from IPv4 and IPv6 private use areas shows that there will be
> collisions and they will be painful.
>
>
I think the comparison to v4 private use is flawed, specifically because
IPv4 addresses are a fixed quantity.

Private use DNS space is freeform and limited only by the 255 character
limit in DNS names.
Collisions in private use DNS space can trivially be prevented by use of an
in-fix (like a suffix but before the TLD) designed to be unique.
E.g. use an FQDN belonging to you (or your company), so the namespace would
be example.com.zz under which your private names are instantiated.
(That's an example only, any arbitrary string could be used, even a GUID.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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