Subject: [DNSOP] private-use in-meeting chat comments

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Nov 2020 22:56:35 -0800

Comments made in the chat, about the private-use presentation/draft:
Me:
One potential approach is to say (in the RFC) that one of the two-letter
reserved codes should avoid name collision by putting a collision-resistant
second-level label, below .zz and above the private use usage (and use that
particular two-letter code in that manner exclusively).

E.g. whatever-i-want.guid-as-label-to-prevent-collisions.zz rather than
whatever-i-want.zz

Warren:
@Brian: Yes, but as you know (being a registrar), people really want
semantically meaningful names... People have seen using www.corp, not
www.dfads3e4r34324rwefe.corp..

Me:
Correct, and I think possibly providing guidance that this private use
SHOULD be generally limited to "magic" things like automation or
automated/negotiated systems. The UI can/should hide the GUID component and
possibly also the zz TLD

Ben:
That could be $guid.guidspace.arpa, no need for .zz
"guidspace.arpa" is not a thing. I'm just suggesting an adjustment to
Brian's proposal.
Me:
That's a good idea, can be pursued independently of the private-use TLDs
like .zz
(possibly addressing different use cases?)

Brian

---

From: Eric Orth <[email-masked]>
Date: Tue, 17 Nov 2020 02:20:54 -0500

guidspace.arpa or similar seems like a good potential solution to any of
the usecases around such "magic" negotiated systems where the user isn't
going to need to type in or see the actual name.  By generating a guid, any
system could easily generate unique names without any registration.

But it doesn't do anything for usecases that want nice names for users to
directly see or enter.  Anything with a guid is unlikely to ever be
considered a "nice" name.  Is this a usecase that also needs to be solved,
or are nice names even more into the territory where the system should be
registering a name first?

On Tue, Nov 17, 2020 at 1:57 AM Brian Dickson <[email-masked]>
wrote:

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Nov 2020 21:45:59 +0000

> particular two-letter code in that manner exclusively).

This kind of thing, or guidspace.arpa, is not that different in terms of
usability / ugliness from assigning a unique subdomain under a domain that
has been registered in the normal way.

There's also a privacy leak: if you assign a unique subdomain then when a
device roams and leaks queries for the private domain, the device can be
tracked and correlated with other devices that use the same private
domain.

I have a terrible mental conflict trying to weigh this privacy issue
against the horrible consequences of encouraging people to squat on
unassigned domains and use colliding hostnames. The privacy leak probably
needs to be fixed regardless, and if it is fixed then there would be a bit
less pressure in favour of unwise squatting.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Southerly 3 to 5, veering westerly 5 or 6 later in northwest.
Moderate, occasionally rough in northwest. Rain later. Good, occasionally
moderate.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 17 Nov 2020 14:19:57 -0800

> less pressure in favour of unwise squatting.

Yep.
Definitely, the "magic" that is involved in using those, should be
self-limiting and automatic.

However, there's also another clever trick (for some value of $clever),
which isn't iron-clad but could help:

guidspace.arpa DNAME empty.as112.arpa
(FTW - qv RFC 7535 and 7534).

Brian DNAME Dickson

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Nov 2020 22:51:45 +0000

> guidspace.arpa DNAME empty.as112.arpa

That's worse than leaving it unregistered :-) AS112 is OK for RFC 1918
reverse DNS because in that case the QNAMEs don't contain much
information, but that isn't true for the forward DNS.

Most of the privacy leak is to the hotspot network's resolvers (and their
passive DNS partners); if the domain is registered then the resolver will
send QNAMEs to its nameservers; if the domain points at AS112 then almost
anyone might receive the QNAME leakage; if the domain is unregistered and
the resolver does qmin then there's less leakage.

This is really a general issue with split horizon DNS: whoever is
assigning or giving advice about local/internal DNS needs to make
it clear that the names aren't private and will leak.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Variable 3 or 4, becoming cyclonic 5 to 7, occasionally gale 8 later.
Rough, becoming very rough later. Rain at times. Moderate or good,
occasionally poor.

---

From: Eric Orth <[email-masked]>
Date: Thu, 19 Nov 2020 03:06:11 -0500

> has been registered in the normal way.

Confirming that I understand your point: You're discussing the case of some
local-network technology using $guid.guidspace.technology-vendor.com?

3 possible advantages I can think of of standardizing a .arpa subdomain:
1) More universally trustworthy that *.guidspace.arpa names will never be
globally resolvable, which would be unexpected behavior.  If using a
normally registered domain, you have to rely on whoever owns that domain,
and I could see usecases where the domain owner and the tech owner creating
a name are not one and the same.
2) In cases different technology vendors have created some standard relying
on guid-generated unique names (not necessarily an IETF standard), it may
be desirable for the generated names to fall under some neutral third-party
domain (in this case .arpa) rather than everyone involved relying on
somebody maintaining a domain.
3) In more general cases where different parties aren't trying to
interconnect, I don't quite understand why everyone can't just register
domains for their uses.  But one of the reasons we keep discussing
potential solutions for local domains is that many people keep refusing to
register names.  This would be a good alternative to hopefully convince
them to stop squatting unowned names.  (Although from a practical
perspective, I have no illusions that this would actually end the practice
of squatting.)

> tracked and correlated with other devices that use the same private

What if, in whatever hypothetical solution is using this, it is reasonable
for devices to always regenerate the names they are using on changing
networks? At least in such hypothetical cases, it seems the privacy danger
would be significantly mitigated, right? (Maybe we're getting too far into
unknown hypotheticals without finding actual usecases or implementors that
want this.)

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Nov 2020 00:10:13 +0000

> unknown hypotheticals without finding actual usecases or implementors that

Ah, oops, I need to clarify: the private domain might be a per-CPE domain
or an enterprise internal domain; the device is someone's phone or laptop
which roams between multiple networks. The private domain is handed to the
roaming device, and the device doesn't know (isn't told, and can't be told
with current protocols) that the domain name is supposed to be private to
the network. So the device is likely to keep asking about names of
services in the private domain regardless of the network it is connected
to, and thereby leak private information.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Southeasterly 6 to gale 8, decreasing 4 or 5, then becoming
cyclonic 7 to severe gale 9, occasionally storm 10 later in south. Rough or
very rough, becoming high or very high later in south. Rain, squally showers
later. Moderate or good, becoming moderate or poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Nov 2020 08:48:37 +0100

On Tue, Nov 17, 2020 at 10:51:45PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 32 lines which said:

> if the domain points at AS112 then almost anyone might receive the
> QNAME leakage; if the domain is unregistered and the resolver does
> qmin then there's less leakage.
> 

Note that this is one of the reasons why draft-bortzmeyer-dname-root
was not a success: some people objected that AS 112 is not to be
trusted with "private" names.