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

From: Tim Wicinski <[email-masked]>
Date: Fri, 12 Jun 2020 11:12:23 -0400

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

---

From: Bob Harold <[email-masked]>
Date: Fri, 12 Jun 2020 11:36:15 -0400

On Fri, Jun 12, 2020 at 11:12 AM Tim Wicinski <[email-masked]> wrote:

> 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.
>
Support, will review.
Just read it - quite an exhaustive study of the subject.

-- 
Bob Harold

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 12 Jun 2020 18:50:31 +0300

I support the adoption.

On Fri, Jun 12, 2020 at 6:12 PM Tim Wicinski <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
SY, Dmitry Belyavsky

---

From: Roy Arends <[email-masked]>
Date: Fri, 12 Jun 2020 17:24:03 +0100

I want to make a disclaimer here for complete transparency:

I am the editor of this draft.

This draft is my individual submission and does not present an opinion, endorsement or anything like that from ICANN, ICANN affiliate (such as PTI) or the ICANN community.

Warmly,

Roy Arends

> On 12 Jun 2020, at 16:12, Tim Wicinski <[email-masked]> 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.
> 
> 
> 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.
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Jun 2020 09:26:09 -0700

> by DNSOP, and comments to the list, clearly stating your view.

I support adoption by the WG. I am willing to review and contribute text.

Brian

---

From: Erwin Lansing <[email-masked]>
Date: Fri, 12 Jun 2020 18:26:29 +0200

I support the adoption and will review.

Erwin

> On 12 Jun 2020, at 17.12, Tim Wicinski <[email-masked]> wrote:
> 
> 
> 
> All,
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 12 Jun 2020 13:09:44 -0400

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

Have reviewed before. Will review again. I support adoption.

Joe

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 12 Jun 2020 23:26:48 +0200

Tim Wicinski writes:

 > <SNIP>

Reviwed and yes, this is suitable. It addresses operational problems.

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

Willing to contribute.

	jaap

---

From: Shumon Huque <[email-masked]>
Date: Fri, 12 Jun 2020 20:28:26 -0400

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

I support adoption, and will review etc.

Shumon.

---

From: Geoff Huston <[email-masked]>
Date: Sun, 14 Jun 2020 07:39:05 +1000

This is likely to be a Fine Proposal, worthy of serious consideration, but the venue where such topics should be considered is elsewhere, in my view. I realise that explicitly opposing such WG calls for adoption is tantamount to heresy in today’s IETF, but nevertheless I must record my opposition to adoption.

I believe that the IETF passed responsibility for the determination of policy regarding the DNS namespace to what we now call ICANN some decades ago, and in line with that transfer of role and responsibility such discussions should take place within the open policy forums hosted by ICANN (however torturous and dysfunctional that may be), and accepting this document within the remit of the IETF DNSOP working group is contrary to this earlier IETF action. I'm aware that this rationale for my opposition to adoption raises yet again the entire issue of the IETF’s handling .local, .onion and the Special Use names registry, but it reflects my opinion that the delineation of roles and responsibilities between ICANN and the IETF admits various interpretations, which is an unfortunate situation that in my view potentially undermines the coherence of the DNS namespace. My personal opinion of this particular situation is that proposals such as this one that consider name policies have no place in the IETF today.

thanks,

  Geoff

> On 13 Jun 2020, at 1:12 am, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All,
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 13 Jun 2020 18:48:18 -0400

On Jun 13, 2020, at 17:39, Geoff Huston <[email-masked]> wrote:
> 
> 
> I believe that the IETF passed responsibility for the determination of policy regarding the DNS namespace to what we now call ICANN some decades ago, and in line with that transfer of role and responsibility such discussions should take place within the open policy forums hosted by ICANN (however torturous and dysfunctional that may be),

I agree with Geoff.

> and accepting this document within the remit of the IETF DNSOP working group is contrary to this earlier IETF action.

It is not entirely contrary to earlier action. We told some people, like the ones who wanted .gnu not to come to us. That we “froze” handing out special domains. And then we kind of walked back on that.

The clean line for IETF is to not assign names in the DNS space that is not specifically reserved for us, like .arpa.

Additionally, just like I wouldn’t want 4G to start using 192.168.1.1 as requirement for some protocol, I don’t think IETF should formally squat on someone else’s namespace - even if that someone else committed to that section being “free for all”. I feel that the free for all is meant for personal or adhoc things and not for standardization in other standards bodies.

I am not in favour of adoption.

Paul

---

From: Joe Abley <[email-masked]>
Date: Sat, 13 Jun 2020 18:57:04 -0400

> This is likely to be a Fine Proposal, worthy of serious consideration, but the venue where such topics should be considered is elsewhere, in my view. I realise that explicitly opposing such WG call…

I agree that the venue for proposing new uses for parts of the namespace (with the singular exception of the ARPA domain) belongs elsewhere.

However, I think there are a couple of other things to consider with respect to this particular document:

1. whether this document actually does propose a new use for part of the namespace, or whether it is simply documenting consequences of policies that already exist and which already allow a particular use;

2. whether dnsop gets to make these kinds of decisions; I rather think if there are decisions to be made, it's the IAB that should make them.

I appreciate there might be conflicting opinions about both of those, but perhaps the working group is a good place to hold the conversations. Adoption does not seem like an impossible start to those discussions, given that people have put their hands up to review. Asking the IAB to review something also seems like it falls more naturally in the workflow of dealing with a document that is the product of a working group; asking the IAB to express an opinion about whether a working group should be allowed to work on something, on the other hand, seems awkward.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Sat, 13 Jun 2020 23:56:32 +0000

On Saturday, 13 June 2020 21:39:05 UTC Geoff Huston wrote:
> ...
> 
> I believe that the IETF passed responsibility for the determination of
> policy regarding the DNS namespace to what we now call ICANN some decades
> ago, and in line with that transfer of role and responsibility such
> discussions should take place within the open policy forums hosted by ICANN
> (however torturous and dysfunctional that may be), and accepting this
> document within the remit of the IETF DNSOP working group is contrary to
> this earlier IETF action. ...

i understand, but do not share, this point of view. ietf is where protocols 
come from, and dns is a protocol. early on, the decision of what top-level 
domains to create was made outside the ietf, but recorded by iana. later on, 
the iana became a functions contract, currently operated by what we now call 
icann, who then uses a global policy process to get the global economy's input 
on what top level domains to create.

it is for ietf to decide what to reserve directly with the iana, for the needs 
of protocol development. that sets the starting conditions for what icann can 
work with (everything not reserved by the ietf).

we might imagine a new protocol, sdns, which had an extended presentation form 
compared to classic dns, and in which the old namespace was encapsulated under 
some new top level identifier (like .ietf or .iana), and which had a search 
list capability allowing names not found in the sdns namespace to be findable 
in the old namespace. none of this would depend on cooperation from iana, or 
from what we now call icann as the iana functions contractor.

protocol development creates identifier spaces, which have reserved 
identifiers. to me it makes perfect sense that ietf would develop new top 
level identifiers for dns, and instruct iana to reserve them. icann's role in 
that transaction would be as iana functions operator, and their policy 
development process for other parts of the icann corporate mission would not 
be invoked.

i support adoption, and will review.

-- 
Paul

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2020 20:03:54 -0400

In article <[email-masked]> you write:
>This is likely to be a Fine Proposal, worthy of serious consideration, but the venue where such
>topics should be considered is elsewhere, in my view. I realise that explicitly opposing such WG
>calls for adoption is tantamount to heresy in today’s IETF, but nevertheless I must record my
>opposition to adoption.

Agreed. The proposal is technically fine but for better or worse,
ICANN is in charge of the TLD namespace these days.

If something else like .onion that has a technical aspect comes along,
we can probably deal with that, with ICANN's tacit cooperation, but I
wouldn't push it.

R's,
JOhn

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Sun, 14 Jun 2020 02:08:27 +0200

John,

technically ICANN is only really in charge of the gTLD name space as the
ccTLD one depends on the ISO 2 letter alpha code elements over which
ICANN has no control.

el

On 2020-06-14 02:03 , John Levine wrote:
>> This is likely to be a Fine Proposal, worthy of serious
>> consideration, but the venue where such topics should be considered
>> is elsewhere, in my view.  I realise that explicitly opposing such WG
>> calls for adoption is tantamount to heresy in today’s IETF, but
>> nevertheless I must record my opposition to adoption.
>
[...]

-- 
Dr. Eberhard W. Lisse   \         /       Obstetrician & Gynaecologist
[email-masked]             / *      |  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

---

From: "John R Levine" <[email-masked]>
Date: 13 Jun 2020 21:06:10 -0400

> ccTLD one depends on the ISO 2 letter alpha code elements over which

I suppose this might make sense as an informational RFC about here's
what is likely to happen if you squat on these names that probably
will never be in the global DNS.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Jun 2020 16:13:36 +0000

On Jun 13, 2020, at 2:39 PM, Geoff Huston <[email-masked]> wrote:

> I believe that the IETF passed responsibility for the determination of policy regarding the DNS namespace to what we now call ICANN some decades ago, and in line with that transfer of role and responsibility such discussions should take place within the open policy forums hosted by ICANN (however torturous and dysfunctional that may be), and accepting this document within the remit of the IETF DNSOP working group is contrary to this earlier IETF action.

Wearing my terminology hat: what do you mean by "DNS namespace"? That is not a term that the IETF has adopted, but there are other terms that the IETF and this WG have defined, most recently in RFC 8499. I ask because a document about private use names is *explicitly* outside of the "global DNS", the term we adopted for what I think you messily termed "DNS namespace". RFC 8499 defines "domain name" as applying "to systems other than the DNS". It also defines "private DNS", which is exactly what this document is about.

Wearing my "yes, I work for ICANN" hat: why on earth would you want ICANN to have any say in the selection of private use names? There is a good reason that this very community put that outside the scope of our charter.

--Paul Hoffman

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Jun 2020 06:59:59 -0700

Hi Roy, Ed,
At 08:12 AM 12-06-2020, Tim Wicinski wrote:
>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.

It is difficult for me to take a position on the adoption of this 
draft as I don't have enough information to do that.  I have a few questions:

I took a quick look at the draft.  There is a request to Public 
Technical Identifiers in Section 6.  Isn't that beyond DNS operations?

Will the working group consult with the liaisons to other organizations?

Is ICANN experiencing issues developing policies for the DNS Root Zone?

Regards,
S. Moonesamy

---

From: Roy Arends <[email-masked]>
Date: Sun, 14 Jun 2020 18:09:50 +0000

Hi

> On 14 Jun 2020, at 14:59, S Moonesamy <[email-masked]> wrote:
> 
> Hi Roy, Ed,
> It is difficult for me to take a position on the adoption of this draft as I don't have enough information to do that.  I have a few questions:
> 
> I took a quick look at the draft.  There is a request to Public Technical Identifiers in Section 6.  Isn't that beyond DNS operations?

This request has been removed from draft -02.

Warmly,

Roy

---

From: Rubens Kuhl <[email-masked]>
Date: Sun, 14 Jun 2020 16:30:31 -0300

I wonder what would have happened if this RFC was available a time before IDNs were defined, someone decided to use .xn and assume xn was only an internal use thing.

Rubens

> On 12 Jun 2020, at 12:12, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All,
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ <https://datatracker.ietf.org/doc/draft-arends-private-use-tld/>
>

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2020 15:54:17 -0400

In article <[email-masked]> you write:
>
>I wonder what would have happened if this RFC was available a time before IDNs were defined, someone
>decided to use .xn and assume xn was only an internal use thing.

I suppose we would find out how much broken software looked for "xn"
rather than "xn--". I would be surprised if there were a lot of it.
Have you ever run into anything that mishandles xn.examp1e.com ?

Don't forget that RFC 5890 reserved all labels of the form
XX--anything for any XX as R-LDH labels, even though currently only
XN--anything is interpreted specially.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Jun 2020 16:12:59 -0400

Roy et al -

Is there a document from ICANN taking a position on the assignment of 
TLDs based on  ISO3166 assignments?

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.

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.

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.

Later, Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Jun 2020 20:43:54 +0000

> I wonder what would have happened if this RFC was available a time before IDNs were defined, someone decided to use .xn and assume xn was only an internal use thing. 

As the IDN WG was trying to figure out how to make internationalized domain names 20ish years ago, the idea of "make a special TLD for them" was discussed. It was not ultimately chosen, but it was certainly one of the early contenders.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Jun 2020 17:53:47 -0400 (EDT)

On Sun, 14 Jun 2020, Michael StJohns wrote:

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

Then you would expect DNS libraries and recursive servers to treat the
selected ones differently from the non-selected ones? That would only
complicate things further. Now there is an unofficial difference in
these unassigned names, "IETF handled" and "non-IETF handled".

Paul

---

From: Michael StJohns <[email-masked]>
Date: Sun, 14 Jun 2020 18:31:57 -0400

On 6/14/2020 5:53 PM, Paul Wouters wrote:
>> from these ranges so that filtering may be built into

Hi Paul -

What I asked for was some algorithmic way of figuring out which of some 
43 two letter pairs might illegitimately show up.    I didn't specify 
that anyone had to (now) implement a mechanism to filter them, just that 
the possibility should exist to implement filtering if necessary.  But 
you've got a point - why not just include all 43?

AIRC we had a few painful years where "private" address space 
occasionally leaked into the routing system - it was fortunate that 
there were only a few legitimate private blocks and that they could be 
filtered.  43 is probably "small enough".

Later, Mike

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2020 20:09:44 -0400

>you've got a point - why not just include all 43?

I think because on any real network, at least 41 of them will not be
used, and there's no way to guess which.

While I think that these non-ccTLDs are as good a candidate as we're
ever going to find for TLDs on which you can squat without colliding
with a real domain name, after many decades of squattage we're no
closer to having any idea how you can squat safely and without
leaking.

Indeed, with the advent of DoH that deliberately circumvents the
system resolver we're probably farther than we were a decade ago.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 15 Jun 2020 08:27:16 -0700

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

TLDR: As is, I'm afraid I can't support this draft for adoption.  First,
this seems an end-run around two other organizations.  And second, I
think there are potential concerns with how the RSS is expected to
handle this increased load.  Both of these, I think, are fixable but as
is it's a no-go from me.

The more complete version:

I agree with your assessment that it is "extremely unlikely" that ISO
3166 Maintenance Agency or ICANN would change their position on the
usability of these codes.  But, this document still makes use of the
codes without even asking either organization "what do you think if we
do this?". All because asking is difficult?  Why would the IETF take on
this land-grab without even consulting these other two agencies.

You claim that these reservations don't require "special handling", and
are thus not part of the special use namespace.  You state that they're
"special on a policy level, but not on a technical or protocol level",
to which I must disagree.  You're asking for new non/never-TLDs to be
not-created and this requires no technical or code-changes.  That
appears true on the face of the situation, until you consider what
happens when these queries leak to the real DNS, which they assuredly
will (we have piles of data proving this as you know).

What happens when an organization/company full of .zz configured
devices, many mobile, start assuming they can query for something under
.zz and they're not behind their organization's resolver that knows to
forward those requests to somewhere internally-special?  They end up at
the root.

I'm sure you're aware that we already have a code-base out there
generating vast numbers of requests that leak to the root [1].  And
that's only on a network change.  Imagine if all of these devices were
generating queries that leak to the root only based on the negative TTL
cache value and how many more queries those might generate.  Now, the
large negative cache in the root should make me feel better, but there
is also a lot of evidence that many resolvers don't seem to follow that
SOA field guidance. Thus, I have a hard time estimating the impact of
this but I have fears it may be larger than ideal (0).

In the end, I think this proposal *does* require technical changes.
Resolvers should black-hole these types of queries.  Better yet, place
this new domain in a place that has public NS records pointing to
non-routable addresses spaces (127.53.53.53 as an example) so that they
can't leak.  This really is, IMHO, a case of a special-use domain.

Meanwhile, your draft talks about the need for this to be a TLD but
doesn't actually argue for it.  You argue extensively why these 2 letter
codes will never cause problems and are used by many other organizations
in different ways too in attempt to achieve [2] status, but you don't
ever argue why this must be at a TLD rather than under something like
.arpa which the IETF has exclusive control over.  I get that a TLD is
easier, more friendly to-users, etc and I don't even disagree.  But I
think if you want this document with its extensive arguing to succeed,
this argument should be included too.

[1]: https://blog.apnic.net/2020/04/13/whats-in-a-name/
[2]: https://xkcd.com/1170/
-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Mon, 15 Jun 2020 16:34:09 +0100

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

The first line of the abstract is wrong. Every properly registered domain
name is a private-use namespace. The desire for shortness is why the DNS
has search paths and unqualified domain names.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Sole: Cyclonic becoming northwesterly, 3 to 5. Slight, occasionally
moderate. Thundery showers. Good, occasionally moderate.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Jun 2020 10:08:29 -0700

> 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

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2020 13:47:53 -0400

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

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jun 2020 13:58:42 -0400

(no hats here)

On Mon, Jun 15, 2020 at 1:48 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
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

---

From: Scott Morizot <[email-masked]>
Date: Mon, 15 Jun 2020 13:08:31 -0500

> A wise person liked to remind me "Namespaces are architecture decisions".
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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Jun 2020 11:21:11 -0700

> 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

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jun 2020 18:55:29 +0000

> or since domains are cheap, why not buy a new domain, and use that for the

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

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 15 Jun 2020 17:31:54 -0400

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 <[email-masked]> wrote:
> 
> 
> All,
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 15 Jun 2020 14:51:42 -0700

Suzanne Woolf <[email-masked]> 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

---

From: Tony Finch <[email-masked]>
Date: Mon, 15 Jun 2020 23:00:31 +0100

> 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.finch  <[email-masked]>  http://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.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 15 Jun 2020 18:12:22 -0400 (EDT)

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jun 2020 22:14:25 +0000

> 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

---

From: Tony Finch <[email-masked]>
Date: Mon, 15 Jun 2020 23:46:17 +0100

> 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.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Jun 2020 00:16:28 +0100

Hi Mike,

> On 14 Jun 2020, at 21:12, Michael StJohns <[email-masked]> 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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 15 Jun 2020 23:18:49 +0000

On Monday, 15 June 2020 22:46:17 UTC Tony Finch 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.
> 

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

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

-- 
Paul

---

From: Geoff Huston <[email-masked]>
Date: Tue, 16 Jun 2020 09:30:25 +1000

> On 16 Jun 2020, at 8:12 am, Paul Wouters <[email-masked]> wrote:
> 

+1

Geoff

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

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Jun 2020 00:44:05 +0100

> On 15 Jun 2020, at 22:51, Wes Hardaker <[email-masked]> wrote:
> 
> 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
> 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

What?

> was a registration.  [see .onion]

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

Roy

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2020 00:59:02 +0100

> 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.finch  <[email-masked]>  http://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.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Jun 2020 17:03:01 -0700

>> of adding things to AS112.

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 15 Jun 2020 17:18:07 -0700

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

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

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Jun 2020 01:41:22 +0100

> On 16 Jun 2020, at 01:18, Wes Hardaker <[email-masked]> wrote:
> 

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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Jun 2020 17:51:26 -0700

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

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

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

> 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

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Jun 2020 20:58:13 -0400

On Jun 15, 2020, at 18:46, Tony Finch <[email-masked]> wrote:

> ..invalid would seem to be the right things to use, but it doesn't say why

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2020 01:59:41 +0100

> 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.finch  <[email-masked]>  http://dotat.at/
Humber, North Thames: Variable 2 to 4. Smooth, occasionally slight. Fog banks.
Moderate, occasionally very poor.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Jun 2020 18:19:53 -0700

> 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

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2020 02:21:26 +0100

Joe Abley <[email-masked]> wrote:
> 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.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Mainly westerly or northwesterly, 3 to 5, occasionally 6 in
southeast. Moderate, occasionally slight. Showers in north. Good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2020 02:29:50 +0100

>       - Currently this would be the Root Servers

And any resolvers in between there and roaming users.

>       not have any presence in DNS caches, which makes them excellent

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.finch  <[email-masked]>  http://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.

---

From: Joe Abley <[email-masked]>
Date: Mon, 15 Jun 2020 21:37:58 -0400

On Jun 15, 2020, at 21:21, Tony Finch <[email-masked]> wrote:

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

> 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

> winner, very clever things can also be things you should never do in

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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Jun 2020 18:51:23 -0700

> These issues happen in exactly the same way whether you squat on a tld or

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Jun 2020 03:19:17 +0100

Joe Abley <[email-masked]> 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.finch  <[email-masked]>  http://dotat.at/
democracy, participation, and the co-operative principle

---

From: Petr Špaček <[email-masked]>
Date: Tue, 16 Jun 2020 13:00:47 +0200

> 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

---

From: "John R Levine" <[email-masked]>
Date: 16 Jun 2020 09:01:54 -0400

>      empty zone (which generates an NXDOMAIN)

You want this in the root?

* IN DNAME EMPTY.AS112.ARPA.

That'd be, um, different.

Regards,

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 16 Jun 2020 14:51:21 +0000

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

---
Mats Dufberg
[email-masked]<mailto:[email-masked]>
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

On 12 Jun 2020, at 17:36, Bob Harold <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jun 12, 2020 at 11:12 AM Tim Wicinski <[email-masked]<mailto:[email-masked]>> wrote:

All,

Thanks,
tim wicinski
DNSOP co-chair

Support, will review.

--
Bob Harold

_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Jun 2020 16:09:05 +0100

> On 16 Jun 2020, at 15:51, Mats Dufberg <[email-masked]> wrote:
> 

<AOL Mode>Me too!</AOL Mode>

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.

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 16 Jun 2020 15:50:53 +0000

On 15 Jun 2020, at 19:58, Tim Wicinski <[email-masked]> 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
[email-masked]
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2020 14:52:02 -0400

In article <[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Jun 2020 14:56:28 -0400

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

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2020 15:22:53 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

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.

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Jun 2020 21:18:22 +0100

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

> 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

---

From: "John R Levine" <[email-masked]>
Date: 16 Jun 2020 16:26:10 -0400

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

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

Regards,

---

From: Roy Arends <[email-masked]>
Date: Tue, 16 Jun 2020 21:28:51 +0100

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

That was actually funny :-)

Roy

---

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Jun 2020 17:11:43 -0400

[ 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

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

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Wed, 17 Jun 2020 00:10:47 +0200

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:
> 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.
> 
> 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.
> 
>> 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.
> 
> With all due respect, I’ll wait with responding about specifics until
> the WG has adopted the document (if at all).
> 
> Warmly,
> 
> Roy

---

From: Petr Špaček <[email-masked]>
Date: Thu, 18 Jun 2020 09:03:23 +0200

> 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 a…

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Jun 2020 08:05:06 +0000

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

+1.

-- 
Paul

---

From: "Robert Mortimer" <[email-masked]>
Date: Thu, 18 Jun 2020 11:13:13 +0100

On 18/06/2020 08:04:47, Petr Špaček <[email-masked]> wrote:

+1

-- 
Robm
873

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Jun 2020 15:34:17 +0100

> On 18 Jun 2020, at 08:03, Petr Špaček <[email-masked]> 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!

> 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 persona…

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jun 2020 11:15:13 -0400

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)?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 12:00:12 -0400 (EDT)

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

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

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

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…

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 18 Jun 2020 18:10:58 +0200

Hi Ted,

> 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,…

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 18:16:19 +0200

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 12:20:18 -0400 (EDT)

> a product line and then forgets to renew the domain when the product line

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 18:27:45 +0200

>what the ISP does with the query (send it to the root, to telus.com or

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.

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Jun 2020 17:29:50 +0100

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

> 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

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

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

> instead of answering NXDOMAIN.

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

> your premise of letting them squat in one place will actually end up

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

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

We can’t help folks wilfully ignoring traffic signs.

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Jun 2020 17:33:10 +0100

+1

Roy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jun 2020 13:22:30 -0400

> [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,…

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.

> 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 (dow…

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 ca…

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

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 18 Jun 2020 19:36:36 +0200

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jun 2020 13:47:45 -0400

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 <[email-masked]> wrote:
> 
> 
> 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

---

From: Joe Abley <[email-masked]>
Date: Thu, 18 Jun 2020 19:59:05 +0200

> 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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Jun 2020 14:24:13 -0400

> 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 deploymen…

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jun 2020 14:35:03 -0400

On Jun 18, 2020, at 2:24 PM, Warren Kumari <[email-masked]> wrote:
> https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3 <https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3>

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.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 21:27:11 +0200

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

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 Jun 2020 21:32:17 +0100

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

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 t…

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