Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Timothy Mcsweeney]

> On 08/18/2022 10:17 PM EDT Ben Schwartz  
> wrote:
> 
> Perhaps you haven't been following the W3C DID process [1]?  The
> "registrable .alt" proposal closely resembles the functionality of the DID
> "method" system, and you can see the registrations that have poured in
> there [2].  I note that some of the registered names already raise some
> notable potential for trademark collision or user confusion.

How is that DID different than the IETF's URN?  Maybe the W3C registration 
process has less friction or they respond to emails faster.  One thing that 
gives me pause is a note on their DID specification registry page [1] it says:
"  Portions of the work on this specification have been funded by the United 
States Department of Homeland Security's Science and Technology Directorate 
under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T0010, and 
HSHQDC-17-C-00019." That last contract went to Digital Bazaar. 

My guess is they fall under the title Blockchain Applications for Homeland 
Security Analytics [2] which is to design and prototype an ecosystem to help 
law enforcment.

[1]  https://www.w3.org/TR/did-spec-registries/
[2]  https://www.sbir.gov/node/867813

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[George Michaelson]

I pose human factor and UX questions:

Do you think people expect to have to do things at url Point and Click time
to select which namespace is resolved?

If I specified my.domain.gns.alt do I expect the entity behind my.domain to
be the same in gns and in dns?

If I am writing gns resolution code do I remove gns.alt before resolving?

Steven's  "what is in SubjectAlternateName and SNI" is a good one too.

I keep harping on about the omnibar. Start at the omnibar and a URL and
tell me what happens!

G

On Fri, 19 Aug 2022, 12:18 pm Ben Schwartz,  wrote:

>
>
> On Mon, Aug 15, 2022 at 7:36 PM Stephen Farrell 
> wrote:
>
>>
>> Hiya,
>>
>> On 16/08/2022 00:22, Paul Wouters wrote:
>> > it’s a whole new gold rush.
>> I don't get that. The thought experiment(*) is a putative
>> .alt setup with FCFS registration for 2LD equivalents and
>> where recursives and all DNS servers are expected to barf
>> on queries for such names one way or another. I don't see
>> what'd attract many people to register names there myself
>> but maybe I'm naive. What'd be the attraction?
>>
>
> Perhaps you haven't been following the W3C DID process [1]?  The
> "registrable .alt" proposal closely resembles the functionality of the DID
> "method" system, and you can see the registrations that have poured in
> there [2].  I note that some of the registered names already raise some
> notable potential for trademark collision or user confusion.
>
> I agree with Paul Wouters' analysis of this problem space.  I would add
> that the main functionality of "registrable .alt" is already available by
> simply registering the desired names in any open, registrable TLD such as
> ".net".  I question whether any perceived benefits over the existing DNS
> registry system would justify the Very Large Can of Worms that the IETF (or
> IANA) would have to manage.
>
> I haven't fully grasped the DID system yet, but it seems to add a new
> meta-namespacing point under a new URI scheme.  This strikes me as far more
> architecturally sound than trying to claim that a certain slice of domain
> names are both unresolvable in the DNS and yet presumptively safe to use in
> all the myriad URI schemes and other subsystems that make use of domain
> names today.
>
> Also, I think the mental model of a "resolution plugin" needs more
> attention, as it appears to presume the existence of an abstract interface
> that does not exist.  For example, apps that use DNS increasingly rely on
> specific RR Types (e.g. SRV, HTTPS, SSHFP).  Shall we demand that all .alt
> registrations maintain the full semantics of every current and future DNS
> RR Type?
>
>
> [1] https://en.wikipedia.org/wiki/Decentralized_identifier
> [2] https://w3c.github.io/did-spec-registries/#did-methods
>
>
>>
>> Ta,
>> S.
>>
>> (*) To be clear, I'd have no objection to somewhat more
>> onerous registration rules, like RFC required or whatever
>> so the above is just trying to understand what makes you
>> think there'd be enough registrations to be a problem in
>> that particular setup.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Paul Vixie   said:
>+1. noting, there should be a registry of second level domain style 
>names, maintained by IANA, with an RFC for each one describing what 
>protocol (whether Internet or otherwise) is used for names in that 
>"sub-tree", and references to permalinks where the non-tcp/53 non-udp/53 
>system is further described. ("build roads not walls.")

If my goal were to guarantee that people continue to ignore whatever process
we invent and just squat on whatever name they like, this is exactly how I
would ensure that happens.

The cost of writing and publishing an RFC is considerable, and the
benefit to someone with a non-DNS naming system rounds to zero. No,
we cannot promise that other people won't squat on their name. If it's
a good name, it'll get squatted. If not, it won't, but then why waste
time screwing around arguing with the IETF about it?

R's,
John

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

Hiya,

On 16/08/2022 00:22, Paul Wouters wrote:

it’s a whole new gold rush.

I don't get that. The thought experiment(*) is a putative
.alt setup with FCFS registration for 2LD equivalents and
where recursives and all DNS servers are expected to barf
on queries for such names one way or another. I don't see
what'd attract many people to register names there myself
but maybe I'm naive. What'd be the attraction?

Ta,
S.

(*) To be clear, I'd have no objection to somewhat more
onerous registration rules, like RFC required or whatever
so the above is just trying to understand what makes you
think there'd be enough registrations to be a problem in
that particular setup.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Wouters]

On Aug 15, 2022, at 16:48, Paul Vixie  wrote:
> 
> 
> 
>> Meanwhile, IANA will have to host 60M entries in the .alt registry.
> 
> that would be a success disaster, and self limiting. to get traction, a new 
> non-tcp/53 non-udp/53 would have to publish plugins for a lot of browsers and 
> get uptake by libcurl and other places. that won't happen 60M times.

People will pre-emptively “register”, it’s a whole new gold rush. I’ll just get 
paulwouters.alt so others can’t. And especially like three letter ones like 
sex.alt. How are you going to release these ? First come first serve when ?  
What if someone sues over losing “unfairly”.  This is straight up ICANN 
territory.


> in any case the worst case if we do a carve out is a lot better than the 
> worst case if we don't, so the details beyond that aren't important.

I don’t mind carving although I guess i would prefer ICANN to carve out .alt 
over IETF using RFC6761 for it.

But an alt registry to prevent name space clashes ? That is really something 
the IETF or ISNA cannot afford to manage.


>> i had this exact conversation with bob moskowitz some decades ago and he 
>> considered trademarks to be a full-tree issue. i then created host names for 
>> a computer lab which duplicated each and every one of his employer's 
>> trademarks (which were i think automobile names) and invited a lawsuit.

I guess no one cared what ran in your lab. But BMW might care if you run a 
blockchain based name on bmw.alt and if they can’t find or force a handover 
they will come for the level above it, which would be IANA.

Also if a US court demands the transfer of your bmw.alt from the IANA registry, 
does IANA comply? What about a Chinese court ? A Dutch court? Padashar Emperor 
Shaddam IV ?


> 
> and i predict we're not going to let it stop us any more than we would or 
> could prohibit an IPv6 address ending in ::c0ca:c01a.

We don’t have that string in an IANA registry anywhere. (You can try adding it 
to the global underscore registry but we do have Experts there to accept / 
reject strings there)

Paul W

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Peter Thomassen]

On 8/15/22 17:27, Peter Thomassen wrote:

OTOH, if we don't give guidance, people (not GNS specifically) will just 
continue camping on more ASCII TLDs for non-DNS uses. That's the exact thing we 
are aiming to avoid.


Correction: I meant "letter-only TLDs", not ASCII TLDs. (Of course, an 
underscore TLD is also ASCII.)

~P

--
https://desec.io/

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Peter Thomassen]

Hi Martin,

On 8/15/22 14:49, Schanzenbach, Martin wrote:

I do not agree that the registration policy should allow multiple entries for the same 
subdomain or be "free for all" as it is currently in the draft.

...> So, from my authors hat, I would appreciate FCFS

That's a good point, and I agree. However, I think that addressing FCFS is an 
issue that is separate from the carve-out problem.

My take would be: first establish consensus on the carve-out mechanism, then 
let's talk about what the naming allocation policy is within the carve-out.

The first (carve-out process) I consider an IETF task; the second (allocation 
policy within the carve-out) I'm not so sure about. But again, I think that 
question comes later.


; ideally also existing RFC/Other Specification + Implementation(s) for a 
registration in the registry.

Of course, as proposed by someone else, not using any TLD and just allowing us 
to specify a protocol without touching the namespace at all would also be a 
viable option.


How would you feel about using an underscored top level?

For example, _gns instead of gns.alt, or _whatever (perhaps several of those?).

That would give you a top-level mount point in the domain name space, which may feel less 
second-class to GNS users, and you could trade the prescribed "alt" string 
(which is charged with meaning) for a more neutral underscore.


In terms of specification, I think that would be pretty straightforward: To get 
started, we could basically pass a document that says

If you're going to use a top-level name for a non-DNS purpose,
please prepend an underscore to whatever you're using. DNS
stub and full resolvers, stop resolution when you see this.

We wouldn't have to declare an explicit list (registry) of special-use 
top-level names at that point.

It's very simple, and definitely better than giving no guidance. It will be 
within non-DNS proponents' interests to use this convention, as namespace 
collisions are harmful to them as well.

OTOH, if we don't give guidance, people (not GNS specifically) will just 
continue camping on more ASCII TLDs for non-DNS uses. That's the exact thing we 
are aiming to avoid.

Best,
Peter

--
https://desec.io/

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 15, 2022, at 1:22 PM, Paul Wouters  wrote:
> I guess we could prevent draft--alt-name-cocacola if we consult the Trademark 
> Clearing House,

https://tmsearch.uspto.gov/bin/showfield?f=doc=4806:y9m1tz.2.21 
 :)

> but maybe this is a clear signal that we
> are turning the IETF into ICANN and it is time to take a step^Wleap
> back.

My impression is that some folks here believe that the demand for non-DNS 
namespace partitioning won’t be that great, thus a lightweight IETF-managed 
mechanism will be sufficient.  Perhaps I’ve been in the ICANN world too long, 
seen far too much gaming, and far, far too many lawsuits resulting in me having 
a different view: I’m not so confident that a lightweight mechanism will 
survive, particularly given stuff like 
https://techcrunch.com/2022/07/27/web3-digital-identity-startup-unstoppable-domains-raises-funds-at-1-billion-valuation/
 
.

ICANN was specifically intended to be a venue in which naming policy was to be 
made and was explicitly required to include non-technical constituencies 
because the myriad non-technical implications of that policy. The fact that the 
ICANN process did not take this particular use case into account suggests to me 
that that process needs to be fixed, not that the IETF should put itself into 
the same swamp by providing a way by which that process can be short-circuited.

But I’m repeating myself, so I’ll shut up now.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Paul Wouters wrote on 2022-08-15 13:22:

Schanzenbach, Martin wrote on 2022-08-15 11:49:

 ...
 So, from my authors hat, I would appreciate FCFS; ideally also existing
 RFC/Other Specification + Implementation(s) for a registration in the
 registry.


"existing RFC" means all alternative name resolutions have to flow
through either the IETF or ISE. That is not something the IETF would
want to take on I think.


i think otherwise. the IETF exists for the purpose of supporting this 
kind of thing. IANA has to have a higher power to tell it about code 
point assignments. what we don't want, most of all, is to introduce a 
new such authority.


david's read of the timeline is that ICANN has responsibility for the 
whole domain style naming space, and by that interpretation the .ALT 
question would be theirs to grapple. i disagree for many reasons which i 
fear will have to be discussed before this is over, but, not today.



"Other specification" would likely lead to many copy & paste drafts
based on the first draft that is used to get an entry in .alt, with
only the name changed.


i think we should be fine with that; we're enabling it not managing it.


Meanwhile, IANA will have to host 60M entries in the .alt registry.


that would be a success disaster, and self limiting. to get traction, a 
new non-tcp/53 non-udp/53 would have to publish plugins for a lot of 
browsers and get uptake by libcurl and other places. that won't happen 
60M times. in fact long before the natural limits of deployment kicked 
in, the natural limit of namespace pollution would remove the incentive.


in any case the worst case if we do a carve out is a lot better than the 
worst case if we don't, so the details beyond that aren't important.



I guess we could prevent draft--alt-name-cocacola if we consult the
Trademark Clearing House, but maybe this is a clear signal that we
are turning the IETF into ICANN and it is time to take a step^Wleap
back.

The IETF cannot bear the burden of managing or policing a non-IETF
namespace war, even handling a FCFS registry will take too many
resources.


i had this exact conversation with bob moskowitz some decades ago and he 
considered trademarks to be a full-tree issue. i then created host names 
for a computer lab which duplicated each and every one of his employer's 
trademarks (which were i think automobile names) and invited a lawsuit.


coca-cola.alt is not different in its trademark relevance from 
coca-cola.example.com or coca-cola.gns.alt. we're not going to 
differentiate, and i predict we're not going to let it stop us any more 
than we would or could prohibit an IPv6 address ending in ::c0ca:c01a.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Independent Submissions Editor (Eliot Lear)]

On 15.08.22 22:22, Paul Wouters wrote:

Schanzenbach, Martin wrote on 2022-08-15 11:49:

 ...
 So, from my authors hat, I would appreciate FCFS; ideally also 
existing

 RFC/Other Specification + Implementation(s) for a registration in the
 registry.


"existing RFC" means all alternative name resolutions have to flow
through either the IETF or ISE. That is not something the IETF would
want to take on I think.


I truly don't think there are going to be a great many of these, but if 
they are reasonably well specified and don't pose major security 
concerns, they fit the bill for RFCs, either as independent or standard, 
depending on how the authors, the IETF, and the ISE feels in a 
particular situation.


Eliot




"Other specification" would likely lead to many copy & paste drafts
based on the first draft that is used to get an entry in .alt, with
only the name changed.

If an implementation is required, we will see many github forks with
just a name change.

Meanwhile, IANA will have to host 60M entries in the .alt registry.

I guess we could prevent draft--alt-name-cocacola if we consult the
Trademark Clearing House, but maybe this is a clear signal that we
are turning the IETF into ICANN and it is time to take a step^Wleap
back.

The IETF cannot bear the burden of managing or policing a non-IETF
namespace war, even handling a FCFS registry will take too many
resources.

Paul W

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



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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Wouters]

Schanzenbach, Martin wrote on 2022-08-15 11:49:

 ...
 So, from my authors hat, I would appreciate FCFS; ideally also existing
 RFC/Other Specification + Implementation(s) for a registration in the
 registry.


"existing RFC" means all alternative name resolutions have to flow
through either the IETF or ISE. That is not something the IETF would
want to take on I think.

"Other specification" would likely lead to many copy & paste drafts
based on the first draft that is used to get an entry in .alt, with
only the name changed.

If an implementation is required, we will see many github forks with
just a name change.

Meanwhile, IANA will have to host 60M entries in the .alt registry.

I guess we could prevent draft--alt-name-cocacola if we consult the
Trademark Clearing House, but maybe this is a clear signal that we
are turning the IETF into ICANN and it is time to take a step^Wleap
back.

The IETF cannot bear the burden of managing or policing a non-IETF
namespace war, even handling a FCFS registry will take too many
resources.

Paul W

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Schanzenbach, Martin wrote on 2022-08-15 11:49:

...
So, from my authors hat, I would appreciate FCFS; ideally also existing 
RFC/Other Specification + Implementation(s) for a registration in the registry.


+1.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Schanzenbach, Martin]

> On 15. Aug 2022, at 20:25, Ray Bellis  wrote:
> 
> 
> 
> On 15/08/2022 19:17, Paul Vixie wrote:
> 
>> of course i meant that each such namespace would get its own
>> "sub-domain" under .alt (e.g., .GNS.ALT).
> 
> Someone also gets to solve the problem of how you get a CA/Browser Forum
> Approved TLS cert for any system not accessible via "normal" DNS...

Is ".onion" accessible via "normal" DNS?

Anyway. My 2 cents regarding the subnamespace:

I agree with Paul that it would be great if there is a IANA registry for .alt 
subdomains.
I do not agree that the registration policy should allow multiple entries for 
the same subdomain or be "free for all" as it is currently in the draft.
Apart from the arguments here brought forwarded why this is a bad idea for DNS 
and the global namespace (leakage) and this also applies to any namesystem 
using ".alt",
from a draft authors perspective this is kind of silly:
The IETF would require us (we currently do not want a TLD/namespace or apply 
for one; that was in the past) to use a subdomain to separate a carved-out 
namespace (a separation which we do not even discuss yet in the draft) from DNS.
At the same time we need to now tell implementers on how to handle the 
namespace ".gns.alt". But, it is not as simple as "only accept names with 
suffix .gns.alt".
Because, this namespace may be squatted already (or in the future!) by another 
resolution mechanism and we have no normative way to distinguish the names and 
neither does the implementer. So we would have to discuss this as an unsolvable 
security consideration :(
Again, this would not be a problem as-is; this will become a problem as soon as 
we touch the namespace and name issue in the draft beyond [1].
So, from my authors hat, I would appreciate FCFS; ideally also existing 
RFC/Other Specification + Implementation(s) for a registration in the registry.

Of course, as proposed by someone else, not using any TLD and just allowing us 
to specify a protocol without touching the namespace at all would also be a 
viable option.
To throw something out: Maybe consensus could be found on a boilerplate 
statement for drafts such as ours with pitfalls and issues with namespace 
ambiguity with [1] as a starting point. Also maybe to specifically state that a 
standards action would be required to actually "get" a namespace or "replace" 
the "actual DNS resolution protocol"?

BR
Martin

[1] 
https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-namespace-ambiguity

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



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 11:25:



On 15/08/2022 19:17, Paul Vixie wrote:


of course i meant that each such namespace would get its own
"sub-domain" under .alt (e.g., .GNS.ALT).


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...


if there's a market for it (some way that lots of somebodies can make or 
save money or both) that too shall come. but that's not _our_ (IETF or 
DNSOP)'s worry.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

On 15.08.22 20:25, Ray Bellis wrote:


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...


Yes, but not us.

Eliot

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 15/08/2022 19:17, Paul Vixie wrote:


of course i meant that each such namespace would get its own
"sub-domain" under .alt (e.g., .GNS.ALT).


Someone also gets to solve the problem of how you get a CA/Browser Forum
Approved TLS cert for any system not accessible via "normal" DNS...

Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 11:08:

On 15/08/2022 18:55, Paul Vixie wrote:


...
if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. 
that helps me understand the open ended _effective_ intent of STD-13, 
which is to build roads not walls -- in the best tradition of the 
Internet.

...


I have no problem with ".alt" being carved out like that, it's the 
potential proliferation of a multitude of such carve-outs that bothers me.


i think all of us have been squeamish about proliferation of carve-outs, 
which is one reason Jon Postel gave me when i asked him in ~1985 for a 
carve-out for .UUCP -- and while i disagreed at the time i have come 
around to his point of view on the matter.


I also suspect that those specs that need it will in pratice be unable 
to co-exist unless each such namespace then gets its own "sub-domain" 
under .alt (e.g. .gns.alt).


of course i meant that each such namespace would get its own 
"sub-domain" under .alt (e.g., .GNS.ALT). according to david, these 
won't lead to a "land rush" because it would look like a "naming 
ghetto". i'm not concerned about lack of popularity, only whether we 
(IETF) have supplied some mechanism for domain style naming evolution. 
if someone later comes up with a better mechanism we can consider it. we 
need "something" and warren's .ALT draft is "something".



...
Maybe there'll be an opportunity for having "real" domain names that 
effect a namespace switch via a DNAME or CNAME record into .alt? ;)


i think that's inevitable, and i expect to see development of a new RR 
type which can be placed at the apex of "example.com" telling some 
parameters for use of a .EXAMPLE.ALT "sub-domain". the IETF is not the 
protocol experimentation police unless some definite prediction of harm 
becomes the consensus. DNSOP in particular has an "if you want to do 
this, here is one way" rubric for its work. (see EDNS Client Subnet.)


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 15/08/2022 18:55, Paul Vixie wrote:



if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that 
helps me understand the open ended _effective_ intent of STD-13, which 
is to build roads not walls -- in the best tradition of the Internet.




I have no problem with ".alt" being carved out like that, it's the 
potential proliferation of a multitude of such carve-outs that bothers me.


I also suspect that those specs that need it will in pratice be unable 
to co-exist unless each such namespace then gets its own "sub-domain" 
under .alt (e.g. .gns.alt).


Maybe there'll be an opportunity for having "real" domain names that 
effect a namespace switch via a DNAME or CNAME record into .alt? ;)


Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 15, 2022, at 10:14 AM, Ray Bellis  wrote:
> STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire protocols 
> for interrogating that system, mostly surplanting the use of host files.
> 
> On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name System" 
> namespace from the STD-13 one embodied in the ICANN-managed root zone that we 
> have now.  I think they're the same thing.

Exactly.  I’ve tried to ignore the “but hostnames existed before the DNS” 
argument because it’s simply irrelevant — users and applications understand 
there is a single namespace, known as the “domain name” namespace. There are 
partitions of that namespace (see RFC 6761 and 7686) that may or may not be 
resolvable via the DNS, but they all exist within the “domain name” namespace.

In my view, ICANN was established, in part, to deal with the issues involved in 
creating those partitions. I believe the real problem here is that the model of 
operation assumed by the ICANN processes didn’t account for particular corner 
case uses of the namespace. I remain unconvinced that the IETF providing a 
short circuit for that process is the right solution.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Eliot Lear wrote on 2022-08-15 07:41:

...

On 15.08.22 16:11, David Conrad wrote:

...

We have no idea whether GNS will take off in popularity or fade away 
into non-existence. Given the way "configuration is forever”, any 
partitioning of the namespace will be a feature for the foreseeable 
future.


agreed, tails are long. that's why my analysis included guesses at the 
best and worst possible impact of reserving part of the domain style 
namespace for non-udp/53 non-tcp/53 purposes. given other code point 
reservations present in the udp/53 tcp/53 world, this one can at worst 
be harmless to the things IETF is responsible for evolving, and could be 
beneficial to things the IETF is not responsible for evolving. so, QED?


I agree.  We shouldn't bet the Internet name space on something 
failing.  What I like about .alt (or whatever we end up calling it) is 
that it requires a single or small number of changes, not one change per 
name space.  That will help reduce leakage.


+1. noting, there should be a registry of second level domain style 
names, maintained by IANA, with an RFC for each one describing what 
protocol (whether Internet or otherwise) is used for names in that 
"sub-tree", and references to permalinks where the non-tcp/53 non-udp/53 
system is further described. ("build roads not walls.")


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Ray Bellis wrote on 2022-08-15 10:14:



On 13/08/2022 23:56, Paul Vixie wrote:


it's very much worth re-reading RFC 921 and RFC 952 to understand ...


STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire 
protocols for interrogating that system, mostly surplanting the use of 
host files.


On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name 
System" namespace from the STD-13 one embodied in the ICANN-managed root 
zone that we have now.  I think they're the same thing.


your well chosen words ("effectively", "de-facto", and "mostly") are 
important here. it was neither expected not desired that /etc/hosts 
(which many of us autogenerated from HOSTS.TXT and added our local names 
thereto) or YP/NIS or any other non-udp/53 non-tcp/53 name-to-address 
translation capability would go out of use. indeed, there has Never been 
a day since "domain style names" were first described when non-udp/53 
non-tcp/53 naming systems systems were Not in wide use.


effectively + de-facto = 0 in this timeline. mostly > 0, to be sure.

if IETF decides at this late (2022) date to reserve part of the domain 
style namespace for non-udp/53 non-tcp/53 uses, nothing will break. that 
helps me understand the open ended _effective_ intent of STD-13, which 
is to build roads not walls -- in the best tradition of the Internet.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that David Conrad   said:
>-=-=-=-=-=-
>
>Eliot,
>
>On Aug 15, 2022, at 7:41 AM, Eliot Lear  wrote:
>> What I like about .alt (or whatever we end up calling it) is that it 
>> requires a single or small number of changes, not one change per name space.
>
>It creates a new namespace (*.alt), presumably one that is less contentious 
>than the root.  The allocation policy for names in that sub-namespace is
>undefined at this point.

In the discussions I've seen, the assumption is that the allocation
policy is "free for all." It is definitely not FCFS or any kind of
review. Maybe we would set up an IANA registry so people can let us
know about their .alt projects, but it would specifically allow
multiple entries with the same name.

>Leakage occurs because underlying systems are unaware of special handling 
>requirements for a particular name. I believe the assumption is that all
>resolvers (of all kinds) will be aware that they should not forward a name 
>ending with .alt to the DNS. This is a hard problem at Internet scale. As with
>.local, I’ll be surprised if declaring .alt a SUDN will have much impact on 
>the amount of leakage.

Yup. We also have very little basis on which to guess how much leakage
there is or would be and how much it matters to whom. The amount of
leakage to the root doesn't tell us a whole lot since I would expect a
great deal of leakage to end up at places like 8.8.8.8 and various DoH
providers which aren't likely to pass them up to root servers.

R's,
John

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ray Bellis]

On 13/08/2022 23:56, Paul Vixie wrote:

it's very much worth re-reading RFC 921 and RFC 952 to understand how it 
was that domain-style names (an RFC 952 term, which RFC 921 described as 
"structured names" or "hierarchical names") preceded what we today call 
the "domain name system."


I'm struggling slightly on the logic here, although I was not around at 
the time these documents were written so my perspective may be skewed.


RFC 952 and RFC 921, if I read them correctly, define "structured names" 
(or the synonymous "domain style names") as part of a _transition_ from 
a flat namespace to ("a" | "the") "Domain Name System".


STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire 
protocols for interrogating that system, mostly surplanting the use of 
host files.


On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name 
System" namespace from the STD-13 one embodied in the ICANN-managed root 
zone that we have now.  I think they're the same thing.


cheers,

Ray

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Eliot,

On Aug 15, 2022, at 7:41 AM, Eliot Lear  wrote:
> What I like about .alt (or whatever we end up calling it) is that it requires 
> a single or small number of changes, not one change per name space.

It creates a new namespace (*.alt), presumably one that is less contentious 
than the root.  The allocation policy for names in that sub-namespace is 
undefined at this point.  There is an implicit assumption that all the 
unpleasantness that has resulted in the current ICANN process won’t be visited 
upon that sub-namespace.  That’s probably true as there doesn’t seem to be a 
lot of incentive to use .alt (other than ‘for the good of the Internet’).

> That will help reduce leakage.

Leakage occurs because underlying systems are unaware of special handling 
requirements for a particular name. I believe the assumption is that all 
resolvers (of all kinds) will be aware that they should not forward a name 
ending with .alt to the DNS. This is a hard problem at Internet scale. As with 
.local, I’ll be surprised if declaring .alt a SUDN will have much impact on the 
amount of leakage.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Tim Wicinski]

On Mon, Aug 15, 2022 at 9:22 AM Ted Lemon  wrote:

> Do we have any sense of why so many .local queries are escaping?
>
>
Ted

Do you mean escaping to the root nameservers? That I do not know.

As for .local from https://ithi.research.icann.org/graph-m3.html
I would like to see not just the last 3 months but the last 12 months.
(This may be slightly related to something Duane Wessels talked to me about)

tim



On Mon, Aug 15, 2022 at 01:09 Christian Huitema  wrote:
>
>>
>> On 8/14/2022 8:28 PM, Tim Wicinski wrote:
>>
>> On Sun, Aug 14, 2022 at 11:16 PM John Levine  
>>  wrote:
>>
>>
>> It appears that Tim Wicinskisaid:
>>
>> -=-=-=-=-=-
>>
>> as someone who looks at lots of caching resolver logs, you could add
>>
>> .local
>>
>> to this.
>> But even those query loads are not what I consider a problem .
>>
>> It's not the query loads, it's the data leakage.  I gather that the stuff
>> that leaks out to public DNS .CORP queries is quite amazing.
>>
>> R's,
>> John
>>
>>
>>
>> Yes, I agree, and the .local data leakage has become enough
>> of an issue that it is being addressed.
>>
>> According to the stats published here (
>> https://ithi.research.icann.org/graph-m3.html), the following names are
>> among the most frequently seen at the ICANN Managed Root Servers:
>>
>> .local: 7.3%
>> .internal: 4.1%
>> .home: 1.7%
>> .dhcp: 1.5%
>> .bbrouter: 1.4%
>> .ctc: 1.1%
>>
>> The numbers here are % of traffic seen at the root, as in, "out of 100
>> queries to the root, on average 7.3 will be for .local".
>>
>> .corp is also visible, but with 0.3% of root traffic it ranks 13th among
>> the top leaked domains. .onion is barely visible, with 0.01% of root
>> traffic.
>>
>> -- Christian Huitema
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Hi,

On 15.08.22 16:11, David Conrad wrote:

My impression is that there'd be maybe an order of magnitude fewer clients.

This is irrelevant.

We have no idea whether GNS will take off in popularity or fade away into 
non-existence. Given the way "configuration is forever”, any partitioning of 
the namespace will be a feature for the foreseeable future.

I agree.  We shouldn't bet the Internet name space on something 
failing.  What I like about .alt (or whatever we end up calling it) is 
that it requires a single or small number of changes, not one change per 
name space.  That will help reduce leakage.


Eliot

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 15, 2022, at 6:46 AM, Stephen Farrell  wrote:
> On 15/08/2022 06:09, Christian Huitema wrote:
>> .onion is barely visible, with 0.01% of root traffic.
> So that should be significant for the disposition of the GNU stuff, shouldn't 
> it?

No.

> My impression is that there'd be maybe an order of magnitude fewer clients.

This is irrelevant.

We have no idea whether GNS will take off in popularity or fade away into 
non-existence. Given the way "configuration is forever”, any partitioning of 
the namespace will be a feature for the foreseeable future.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 15/08/2022 06:09, Christian Huitema wrote:

.onion is barely visible, with 0.01% of root traffic.


So that should be significant for the disposition
of the GNU stuff, shouldn't it? My impression is
that there'd be maybe an order of magnitude fewer
clients.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Ted Lemon]

Do we have any sense of why so many .local queries are escaping?

On Mon, Aug 15, 2022 at 01:09 Christian Huitema  wrote:

>
> On 8/14/2022 8:28 PM, Tim Wicinski wrote:
>
> On Sun, Aug 14, 2022 at 11:16 PM John Levine  
>  wrote:
>
>
> It appears that Tim Wicinskisaid:
>
> -=-=-=-=-=-
>
> as someone who looks at lots of caching resolver logs, you could add
>
> .local
>
> to this.
> But even those query loads are not what I consider a problem .
>
> It's not the query loads, it's the data leakage.  I gather that the stuff
> that leaks out to public DNS .CORP queries is quite amazing.
>
> R's,
> John
>
>
>
> Yes, I agree, and the .local data leakage has become enough
> of an issue that it is being addressed.
>
> According to the stats published here (
> https://ithi.research.icann.org/graph-m3.html), the following names are
> among the most frequently seen at the ICANN Managed Root Servers:
>
> .local: 7.3%
> .internal: 4.1%
> .home: 1.7%
> .dhcp: 1.5%
> .bbrouter: 1.4%
> .ctc: 1.1%
>
> The numbers here are % of traffic seen at the root, as in, "out of 100
> queries to the root, on average 7.3 will be for .local".
>
> .corp is also visible, but with 0.3% of root traffic it ranks 13th among
> the top leaked domains. .onion is barely visible, with 0.01% of root
> traffic.
>
> -- Christian Huitema
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Christian Huitema]

On 8/14/2022 8:28 PM, Tim Wicinski wrote:

On Sun, Aug 14, 2022 at 11:16 PM John Levine  wrote:


It appears that Tim Wicinski  said:

-=-=-=-=-=-

as someone who looks at lots of caching resolver logs, you could add

.local

to this.
But even those query loads are not what I consider a problem .

It's not the query loads, it's the data leakage.  I gather that the stuff
that leaks out to public DNS .CORP queries is quite amazing.

R's,
John



Yes, I agree, and the .local data leakage has become enough
of an issue that it is being addressed.


According to the stats published here 
(https://ithi.research.icann.org/graph-m3.html), the following names are 
among the most frequently seen at the ICANN Managed Root Servers:


    .local: 7.3%
    .internal: 4.1%
    .home: 1.7%
    .dhcp: 1.5%
    .bbrouter: 1.4%
    .ctc: 1.1%

The numbers here are % of traffic seen at the root, as in, "out of 100 
queries to the root, on average 7.3 will be for .local".


.corp is also visible, but with 0.3% of root traffic it ranks 13th among 
the top leaked domains. .onion is barely visible, with 0.01% of root 
traffic.


-- Christian Huitema

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Tim Wicinski]

On Sun, Aug 14, 2022 at 11:16 PM John Levine  wrote:

> It appears that Tim Wicinski   said:
> >-=-=-=-=-=-
> >
> >as someone who looks at lots of caching resolver logs, you could add
> .local
> >to this.
> >But even those query loads are not what I consider a problem .
>
> It's not the query loads, it's the data leakage.  I gather that the stuff
> that leaks out to public DNS .CORP queries is quite amazing.
>
> R's,
> John
>
>
Yes, I agree, and the .local data leakage has become enough
of an issue that it is being addressed.

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[George Michaelson]

ULA is no different. "its private addressing" except when ip6.arpa
shows that people are trying to use it, to the outside world. Lots of
great theories about things break .. when they meet the DNS.

On Mon, Aug 15, 2022 at 1:17 PM John Levine  wrote:
>
> It appears that Tim Wicinski   said:
> >-=-=-=-=-=-
> >
> >as someone who looks at lots of caching resolver logs, you could add .local
> >to this.
> >But even those query loads are not what I consider a problem .
>
> It's not the query loads, it's the data leakage.  I gather that the stuff
> that leaks out to public DNS .CORP queries is quite amazing.
>
> R's,
> John
>
> >On Sun, Aug 14, 2022 at 11:06 PM John Levine  wrote:
> >
> >> It appears that Stephen Farrell   said:
> >> >Works for whom? I think it's entirely possible for the GNU
> >> >people to come up with something they think works that does
> >> >not break anything. Personally, I'm not convinced they're
> >> >right about the first part, but I'm happy enough about the
> >> >second.
> >>
> >> Depends how you feel about .GNS queries escaping into the
> >> real DNS when they don't anticipate all of the ways people
> >> will use their stuff.
> >>
> >> Dunno if they think that's a problem ("you need to configure
> >> your software right") but I am pretty sure that people who
> >> have seen what leaks from .CORP and .HOME believe it would be
> >> a big problem.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Tim Wicinski   said:
>-=-=-=-=-=-
>
>as someone who looks at lots of caching resolver logs, you could add .local
>to this.
>But even those query loads are not what I consider a problem .

It's not the query loads, it's the data leakage.  I gather that the stuff
that leaks out to public DNS .CORP queries is quite amazing.

R's,
John

>On Sun, Aug 14, 2022 at 11:06 PM John Levine  wrote:
>
>> It appears that Stephen Farrell   said:
>> >Works for whom? I think it's entirely possible for the GNU
>> >people to come up with something they think works that does
>> >not break anything. Personally, I'm not convinced they're
>> >right about the first part, but I'm happy enough about the
>> >second.
>>
>> Depends how you feel about .GNS queries escaping into the
>> real DNS when they don't anticipate all of the ways people
>> will use their stuff.
>>
>> Dunno if they think that's a problem ("you need to configure
>> your software right") but I am pretty sure that people who
>> have seen what leaks from .CORP and .HOME believe it would be
>> a big problem.

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Tim Wicinski]

as someone who looks at lots of caching resolver logs, you could add .local
to this.
But even those query loads are not what I consider a problem .

On Sun, Aug 14, 2022 at 11:06 PM John Levine  wrote:

> It appears that Stephen Farrell   said:
> >Works for whom? I think it's entirely possible for the GNU
> >people to come up with something they think works that does
> >not break anything. Personally, I'm not convinced they're
> >right about the first part, but I'm happy enough about the
> >second.
>
> Depends how you feel about .GNS queries escaping into the
> real DNS when they don't anticipate all of the ways people
> will use their stuff.
>
> Dunno if they think that's a problem ("you need to configure
> your software right") but I am pretty sure that people who
> have seen what leaks from .CORP and .HOME believe it would be
> a big problem.
>
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Stephen Farrell   said:
>Works for whom? I think it's entirely possible for the GNU
>people to come up with something they think works that does
>not break anything. Personally, I'm not convinced they're
>right about the first part, but I'm happy enough about the
>second.

Depends how you feel about .GNS queries escaping into the
real DNS when they don't anticipate all of the ways people
will use their stuff.

Dunno if they think that's a problem ("you need to configure
your software right") but I am pretty sure that people who
have seen what leaks from .CORP and .HOME believe it would be
a big problem.

R's,
John

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that David Conrad   said:
>It seems to me that “the correct handling” of how an operating system or an 
>application distinguishes what protocol to use for domain name lookup
>(other than DNS) is outside of the bailiwick of DNSOP or the IETF.

I think we could have an interesting research project describing the
various levels at which one can switch out from DNS to something else,
e.g. application sockets like .ONION, pseudo A/ RRs like mDNS,
real RRs like split horizon DNS.  But that doesn't have much to do
with the issue at hand.

R's,
John

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

Hiya,

On 15/08/2022 02:07, Mark Andrews wrote:

Most users of Kerberos use the DNS namespace as that authority.


I wonder about that. My experience is that most admins (not
quite typical users:-) setup some kerberos realms that are
named after DNS domains, but also have legacy and non-legacy
realm names that don't map to DNS domains at all well.

Again though, that's anecdotal, and I don't know of a study
that's measured that. Be great to see one if someone's done
the work.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Mark Andrews]

> On 15 Aug 2022, at 00:57, Paul Wouters  wrote:
> 
> On Aug 14, 2022, at 09:16, Stephen Farrell  wrote:
>> 
>> 
>> but otherwise stuff works fine even if it can sometimes be
>> confusing as to how kerberos realms and DNS domains do or
>> don't map to one another.
> 
> But that’s because foo.example in DNS maps to FOO.EXAMPLE in Kerberos in most 
> deployments.
> 
> let’s say I get COCA-COLA.COM, that’s quite a different situation.

Then you will have a problem if you run up against anyone else using 
COCA-COLA.COM as a realm name.  I also expect that if you are anyone other than 
the Coca-Cola Company and run up against the Coca-Cola Company you  will be 
forced to rename your realm.

Kerberos doesn’t have a naming authority but to use it in a federated manner 
there needs to be an authority.  Most users of Kerberos use the DNS namespace 
as that authority.

> We can have all the clever mappings for DNS to support alternative backend 
> systems, but in the end the real issue is that “issued names” in the DNS 
> world won’t map to alternative owners. The only way to guarantee that is to 
> carve out some strings. But it will be unpopular strings because the popular 
> ones are taken or reserved.
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 15/08/2022 00:58, David Conrad wrote:

On Aug 14, 2022, at 3:54 PM, Stephen Farrell
 wrote:

On 14/08/2022 23:37, David Conrad wrote:

It seems to me that “the correct handling” of how an operating
system or an application distinguishes what protocol to use for
domain name lookup (other than DNS) is outside of the bailiwick
of DNSOP or the IETF.

Disagree in part. I think it is entirely within the balliwick of
the IETF to document that e.g. gnu.alt. or gnu. is a SUDN.


Ah.  Well, perhaps this time, after 20+ years, it’ll be possible to
come up with something that works.


Works for whom? I think it's entirely possible for the GNU
people to come up with something they think works that does
not break anything. Personally, I'm not convinced they're
right about the first part, but I'm happy enough about the
second. IMO that "happy enough" ought be the limit of our
concern - we're doing wrong IMO if we try prevent the GNU
folks trying their thing just in case it works better than
expected. And that's how I at least perceive a lot of the
discussion on this topic.

S.




Regards, -drc



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

On Aug 14, 2022, at 3:54 PM, Stephen Farrell  wrote:
> On 14/08/2022 23:37, David Conrad wrote:
>> It seems to me that “the correct handling” of how an operating system or an 
>> application distinguishes what protocol to use for domain name lookup (other 
>> than DNS) is outside of the bailiwick of DNSOP or the IETF.
> Disagree in part. I think it is entirely within the balliwick of the IETF to 
> document that e.g. gnu.alt. or gnu. is a SUDN.

Ah.  Well, perhaps this time, after 20+ years, it’ll be possible to come up 
with something that works.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 14/08/2022 23:37, David Conrad wrote:

It seems to me that “the correct handling” of how an operating system
or an application distinguishes what protocol to use for domain name
lookup (other than DNS) is outside of the bailiwick of DNSOP or the
IETF.


Disagree in part. I think it is entirely within the balliwick
of the IETF to document that e.g. gnu.alt. or gnu. is a SUDN.
And also to specify how such names are used in GNU protocols
so that someone who cares could also implement and achieve
interop, be they an OS vendor or not.

And given how niche the protocols we're discussing are - I
don't think DNS ops folk would notice.


Or are you suggesting the DNS protocol be modified to deal with such
"a niche thing” to facilitate transition? 


No.


(Honest question: e.g., one
could imagine the root servers “knowing” about SUDN and doing special
things when they see queries for (mostly, except for the root query
obviously) non-DNS resolution protocols and DNSOP may be a good place
for that discussion).

I think at this stage dnsop is the wrong place for these
discussions. So Warren's idea of another venue seems worth
a shot.

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 14, 2022, at 1:42 PM, Stephen Farrell  wrote:
> On 14/08/2022 19:32, David Conrad wrote:
>>> But, there are also what ought be almost purely technical parts,
>> Sorry to be dense, but what exactly are those technical parts,
>> specifically those that are relevant to DNSOP and/or the IETF?
> 
> It was the text right after the bit you quoted. In full:

> 
> > But, there are also what ought be almost purely technical
> > parts, and IMO the correct handling of such a niche thing
> > as a namespace the GNU people would like to use (without
> > DNS) is one of those technical discussions.


It seems to me that “the correct handling” of how an operating system or an 
application distinguishes what protocol to use for domain name lookup (other 
than DNS) is outside of the bailiwick of DNSOP or the IETF.

Or are you suggesting the DNS protocol be modified to deal with such "a niche 
thing” to facilitate transition? (Honest question: e.g., one could imagine the 
root servers “knowing” about SUDN and doing special things when they see 
queries for (mostly, except for the root query obviously) non-DNS resolution 
protocols and DNSOP may be a good place for that discussion).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 14/08/2022 19:32, David Conrad wrote:

Stephen,

On Aug 13, 2022, at 7:14 PM, Stephen Farrell
 wrote:

But, there are also what ought be almost purely technical parts,


Sorry to be dense, but what exactly are those technical parts,
specifically those that are relevant to DNSOP and/or the IETF?


It was the text right after the bit you quoted. In full:

> But, there are also what ought be almost purely technical
> parts, and IMO the correct handling of such a niche thing
> as a namespace the GNU people would like to use (without
> DNS) is one of those technical discussions.

Cheers,
S.



Thanks, -drc




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Stephen,

On Aug 13, 2022, at 7:14 PM, Stephen Farrell  wrote:
> But, there are also what ought be almost purely technical parts,

Sorry to be dense, but what exactly are those technical parts, specifically 
those that are relevant to DNSOP and/or the IETF?

Thanks,
-drc




signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Paul,

On Aug 13, 2022, at 7:26 PM, Paul Vixie  wrote:
>> The problem is that every resolver implementation and deployment on the 
>> Internet, which assumes anything that looks like a domain name IS intended 
>> for the DNS, has to be modified to “do something different” when it sees 
>> that reservation and failure to do so mean the name is going to be looked up 
>> via the DNS.
> that's a problem for future innovators.

Just to be clear: you’re saying to carve out namespace and let some future 
innovators figure out how to not dump queries for that namespace to the DNS?  
If so, I’m not sure what innovation you’re talking about -- this appears to 
largely be a solved problem via nsswitch (or equivalent). The actual problem is 
figuring out how to actually do the carve out.

>> It didn’t block research into overloading the domain name namespace into 
>> protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, 
>> Butterfly, etc., all demonstrate), it made it unscalable because of 
>> conventions of operating system vendors and application developers and 
>> assumptions of users.
> if by unscalable you include the idea that if someone experiments with .XXX 
> they run the risk of having IANA later allocate that to some unique purpose, 
> then i agree with your use of that word.

No. By "unscalable" I mean that if you want to use that carve out, you have get 
every stub resolver and every iterative resolver/forwarder on the planet to 
understand that the specified namespace partition is not to be handled by the 
DNS. Failure to do on both sides of any given session means one party won’t be 
able to establish the connection and (typically) the losing party sending 
queries to the root. It might be worth noting that according to 
https://ithi.research.icann.org , .LOCAL, 
which shouldn’t be seen at the root, appears to account for 7% of all queries 
to the root.

As for the concern you describe, the folks at IANA aren’t idiots and ICANN has 
already demonstrated (arguably over-) sensitivity to avoiding name collisions 
(see CORP, MAIL, and HOME). I suspect future name collision risk will be 
handled more or less the way it was handled in the last round, namely 
delegation won’t be done if the number of queries to the root for a particular 
label is above some arbitrary threshold.

>>> warren's .ALT proposal can begin to undo that harm. internet standards 
>>> should describe roads not walls. i am no fan of blockchain naming, but i'd 
>>> like those systems to reach the market rather than be prevented from doing 
>>> so.
>> Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
>> Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And 
>> you also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
>> address the markets they’re trying to address? I’m not against moving 
>> forward with .ALT, but I’ll admit some skepticism that it will work as 
>> intended: it feels to me that it’s more an exercise in “if you build it, 
>> they will come” but without James Earl Jones.
> i think GNU would use it. others can decide what to do. the worst case risk 
> is low, the best case benefit is high. so, to be clear, "yes".

Not suggesting Martin speaks for GNU, but excerpting 
https://mailarchive.ietf.org/arch/msg/dnsop/S1Up3rDLNZi5RWCcMf_kY1clByQ/ 


"tl;dr:
I am a bit ambivalent towards the ".alt" approach.
For alternative name systems that are specified with status
"Informational"  the use of ".alt" seems highly unattractive as there is
absolutely no benefit in using it but at the same time there are
(obvious) disadvantages especially compared to other name systems which
do not (try to) publish in the RFC series.”

I agree with his analysis.

>> As John Levine points out, this isn’t a technology issue: it is 
>> social/politica/economic/bureaucratic. ...
> i'm aware of legal matters which could pertain, but i am not IETF's lawyer so 
> will not seek to advise them.

Fair enough.  I just think it is perhaps inadvisable for DNSOP to promote a 
model that attempts to short circuit efforts the IETF undertook back in 2000 to 
avoid this particular swamp.

> what matters as an engineering question is that the domain name system camps 
> onto the whole of the domain-style / hierarchical / structure space of names, 
> and this was an error, and a carve-out is needed to facilitate innovation.


It seems to me the “engineering question” is largely out of the purview of the 
IETF — folks who need to engineer solutions are operating system vendors and 
resolver implementers to write the code to understand that some TLDs shouldn’t 
be sent to the root.  The real problem I see is how exactly the “carve out” is 
determined.  ICANN’s process to partition the namespace resulted in a 300+ page 
application guide and entailed payment of (at least) US$185,000.  

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Eliot Lear]

Paul,

On 14.08.22 16:57, Paul Wouters wrote:

We can have all the clever mappings for DNS to support alternative backend 
systems, but in the end the real issue is that “issued names” in the DNS world 
won’t map to alternative owners. The only way to guarantee that is to carve out 
some strings. But it will be unpopular strings because the popular ones are 
taken or reserved.


If that's the distance that needs to be covered to close the gap here, 
then by all means "you" should work on that.*  But I suggest *not* being 
presumptuous, especially since one of the GNS people has already offered 
one possibility.


Eliot

* See my previous message about "you".
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 14/08/2022 15:57, Paul Wouters wrote:

On Aug 14, 2022, at 09:16, Stephen Farrell
 wrote:


 but otherwise stuff works fine even if it can sometimes be 
confusing as to how kerberos realms and DNS domains do or don't map

to one another.


But that’s because foo.example in DNS maps to FOO.EXAMPLE in Kerberos
in most deployments.


I don't believe "because" is correct. I've seen many kerberos
realm names that don't map well to DNS domains. Stuff still
works. That said, I've not seen any measurement study on the
topic.



let’s say I get COCA-COLA.COM, that’s quite a different situation.

We can have all the clever mappings for DNS to support alternative
backend systems, but in the end the real issue is that “issued names”
in the DNS world won’t map to alternative owners. The only way to
guarantee that is to carve out some strings. But it will be unpopular
strings because the popular ones are taken or reserved.


My point here is that the Internet can survive two widely-
deployed standards with potentially conflicting uses of the
same names with no need for a guarantee that there's any
particular relationship between some DNS domain and kerberos
realm. (And again, I'm not saying that that "solves the
problem" - all I'm saying is that invalidates some of the
more "absolutist" arguments I've seen used.)

I'm fine that we carve out a .alt or similar and that ICANN
carve out a .internal or similar, as both make sense.

Cheers,
S.





Paul



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Wouters]

On Aug 14, 2022, at 09:16, Stephen Farrell  wrote:
> 
> 
> but otherwise stuff works fine even if it can sometimes be
> confusing as to how kerberos realms and DNS domains do or
> don't map to one another.

But that’s because foo.example in DNS maps to FOO.EXAMPLE in Kerberos in most 
deployments.

let’s say I get COCA-COLA.COM, that’s quite a different situation.

We can have all the clever mappings for DNS to support alternative backend 
systems, but in the end the real issue is that “issued names” in the DNS world 
won’t map to alternative owners. The only way to guarantee that is to carve out 
some strings. But it will be unpopular strings because the popular ones are 
taken or reserved.

Paul

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

Hiya,

On 14/08/2022 03:59, rubensk=40nic...@dmarc.ietf.org wrote:


On Kerberos, we need to note that one use case of Kerberos is
Microsoft Active Directory; MS AD is behind a number of name
collisions that happened in the 2012 root zone expansion, including
one string that will likely never show the light of day in the root
(.corp). So, this might be the telltale sign, not the good fortune
ahead one.


I'd interpret that as a positive still - despite the fact
that kerberos naming is so widely deployed, and has been
for decades, the impact on the DNS isn't serious - one or so
of the labels from the huge namespace of potential new tlds
wasn't usable when ICANN ran their gTLDs-via-money process,
but otherwise stuff works fine even if it can sometimes be
confusing as to how kerberos realms and DNS domains do or
don't map to one another.

Cheers,
S.



We also could think into this in terms of what we can do; .alt, .arpa
and .internal all look feasible and could alleviate potential
collisions(.arpa already succeeded in .home.arpa). Will blockchain
start-ups adopt them ? Likely not, because they just want the end run
around ICANN and couldn't care less about interoperability. But by
providing those that do care with options, we get more friends and
less foes.



Rubens







On 13 Aug 2022, at 23:27, Stephen Farrell
 wrote:

Signed PGP part

So I think this discussion might benefit from also remembering that
we have a decades-long and widely deployed history of IETF standard
name forms that use the same name syntax as domain names that may 
or may not be related to names used in the DNS.


Kerberos [1] does exactly that.

And the sky never fell, nor has anyone had to pay large numbers of
currency units to pick a kerberos realm name afaik.

I'm not saying this solves the conundrum, but I do assert that this
fact invalidates some arguments to the effect that the IETF cannot
standardise another "global" name form using the same syntax
because of problems that may or may not be caused by overlaps in 
the name spaces - we've not had critical problems with doing just

that for nearly 30 years. (Since RFC1510.)

Cheers, S.

[1] https://www.rfc-editor.org/rfc/rfc4120#page-55 







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


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[George Michaelson]

How to privatise the commons in names.

1) release a browser with remotely enable-able features, initially disabled
2) when you hit 95% penetration, enable the feature.

If the omnibar in the dominant browser had a selection logic akin to
nsswitch.conf or resolver.conf config options, this debate moves from a
tech governance space to a vendor decision in 3-6 months. At which point,
the additional TA and equivalence to the public suffix list is strong.

We're lucky we don't seem to have a vendor who wants to try it, because
logistically it would be extremely simple.

My point is that gethostbyname() itself is subject to code if/then/else
decisions, so the idea names are gated by protocol or functional API spec
is really moot. It's a soft agreement only.

My own hosts (laptops) still appear to honour /etc/hosts before DNS. I used
this in China for gfc reasons. So local override is also strong in this.

Would it be a tragedy if unitary namespace ideas die?

Would it be a tragedy if a single dominant vendor had a switch?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[rubensk=40nic . br]

On Kerberos, we need to note that one use case of Kerberos is Microsoft Active 
Directory; MS AD is behind a number of name collisions that happened in the 
2012 root zone expansion, including one string that will likely never show the 
light of day in the root (.corp). So, this might be the telltale sign, not the 
good fortune ahead one.

We also could think into this in terms of what we can do; .alt, .arpa and 
.internal all look feasible and could alleviate potential collisions(.arpa 
already succeeded in .home.arpa). Will blockchain start-ups adopt them ? Likely 
not, because they just want the end run around ICANN and couldn't care less 
about interoperability. But by providing those that do care with options, we 
get more friends and less foes.



Rubens






> On 13 Aug 2022, at 23:27, Stephen Farrell  wrote:
> 
> Signed PGP part
> 
> So I think this discussion might benefit from also
> remembering that we have a decades-long and widely
> deployed history of IETF standard name forms that
> use the same name syntax as domain names that may
> or may not be related to names used in the DNS.
> 
> Kerberos [1] does exactly that.
> 
> And the sky never fell, nor has anyone had to pay
> large numbers of currency units to pick a kerberos
> realm name afaik.
> 
> I'm not saying this solves the conundrum, but I do
> assert that this fact invalidates some arguments to
> the effect that the IETF cannot standardise another
> "global" name form using the same syntax because of
> problems that may or may not be caused by overlaps in
> the name spaces - we've not had critical problems with
> doing just that for nearly 30 years. (Since RFC1510.)
> 
> Cheers,
> S.
> 
> [1] https://www.rfc-editor.org/rfc/rfc4120#page-55
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

So I think this discussion might benefit from also
remembering that we have a decades-long and widely
deployed history of IETF standard name forms that
use the same name syntax as domain names that may
or may not be related to names used in the DNS.

Kerberos [1] does exactly that.

And the sky never fell, nor has anyone had to pay
large numbers of currency units to pick a kerberos
realm name afaik.

I'm not saying this solves the conundrum, but I do
assert that this fact invalidates some arguments to
the effect that the IETF cannot standardise another
"global" name form using the same syntax because of
problems that may or may not be caused by overlaps in
the name spaces - we've not had critical problems with
doing just that for nearly 30 years. (Since RFC1510.)

Cheers,
S.

[1] https://www.rfc-editor.org/rfc/rfc4120#page-55


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

David Conrad wrote on 2022-08-13 18:55:

Paul,

On Aug 13, 2022, at 3:32 PM, Paul Vixie  
wrote:

i suggest that we adopt the technology "domain names (which is a concept that 
precedes DNS itself)" whenever we are trying to talk about the name space as 
distinct from the protocol.


Sorry, which technology are you suggesting we adopt?  Or did you get 
auto-corrected from “terminology”?


oops. yes.


ideally the domain name system would have left a carve-out for domain names that were not 
expected to be served through the first such "domain name system", but were 
rather reserved for future domain name systems.


The domain name namespace (labels separated by dots) is obviously agnostic to 
how it is implemented. The problem isn’t that parts of the namespace can’t be 
reserved: anything can be reserved for anything, regardless of protocol (see 
.ONION or .LOCAL).  The problem is that every resolver implementation and 
deployment on the Internet, which assumes anything that looks like a domain 
name IS intended for the DNS, has to be modified to “do something different” 
when it sees that reservation and failure to do so mean the name is going to be 
looked up via the DNS.


that's a problem for future innovators. many resolvers look for 
domain-style names in other places than DNS (/etc/hosts, YP, etc). i 
think the point of a carve-out is to let people try things. how those 
people get broad adoption for their ideas is not the IETF's immediate 
concern.





by camping onto the whole of the domain name space, DNS (the domain name 
system) has blocked research into new naming systems.


It didn’t block research into overloading the domain name namespace into 
protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, Butterfly, 
etc., all demonstrate), it made it unscalable because of conventions of 
operating system vendors and application developers and assumptions of users.


if by unscalable you include the idea that if someone experiments with 
.XXX they run the risk of having IANA later allocate that to some unique 
purpose, then i agree with your use of that word.





warren's .ALT proposal can begin to undo that harm. internet standards should 
describe roads not walls. i am no fan of blockchain naming, but i'd like those 
systems to reach the market rather than be prevented from doing so.



Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And you 
also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
address the markets they’re trying to address? I’m not against moving forward 
with .ALT, but I’ll admit some skepticism that it will work as intended: it 
feels to me that it’s more an exercise in “if you build it, they will come” but 
without James Earl Jones.


i think GNU would use it. others can decide what to do. the worst case 
risk is low, the best case benefit is high. so, to be clear, "yes".




As John Levine points out, this isn’t a technology issue: it is 
social/politica/economic/bureaucratic. ...


i'm aware of legal matters which could pertain, but i am not IETF's 
lawyer so will not seek to advise them. what matters as an engineering 
question is that the domain name system camps onto the whole of the 
domain-style / hierarchical / structure space of names, and this was an 
error, and a carve-out is needed to facilitate innovation.




Regards,
-drc

yours always,

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

On 14/08/2022 02:55, David Conrad wrote:

As John Levine points out, this isn’t a technology issue: it is
social/politica/economic/bureaucratic


I believe the above statement is incorrect in referring to
"this" issue in the singular. There is more than one thing
in play here and ignoring all but one aspect seems to me
fairly guaranteed to lead to discussion based on premises
that are false, or not agreed among the participants.

There are certainly non-technical parts of these discussions.

But, there are also what ought be almost purely technical
parts, and IMO the correct handling of such a niche thing
as a namespace the GNU people would like to use (without
DNS) is one of those technical discussions.

Cheers,
S.




OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[David Conrad]

Paul,

On Aug 13, 2022, at 3:32 PM, Paul Vixie  
wrote:
> i suggest that we adopt the technology "domain names (which is a concept that 
> precedes DNS itself)" whenever we are trying to talk about the name space as 
> distinct from the protocol.

Sorry, which technology are you suggesting we adopt?  Or did you get 
auto-corrected from “terminology”?

> ideally the domain name system would have left a carve-out for domain names 
> that were not expected to be served through the first such "domain name 
> system", but were rather reserved for future domain name systems.

The domain name namespace (labels separated by dots) is obviously agnostic to 
how it is implemented. The problem isn’t that parts of the namespace can’t be 
reserved: anything can be reserved for anything, regardless of protocol (see 
.ONION or .LOCAL).  The problem is that every resolver implementation and 
deployment on the Internet, which assumes anything that looks like a domain 
name IS intended for the DNS, has to be modified to “do something different” 
when it sees that reservation and failure to do so mean the name is going to be 
looked up via the DNS.

> by camping onto the whole of the domain name space, DNS (the domain name 
> system) has blocked research into new naming systems.

It didn’t block research into overloading the domain name namespace into 
protocols other than DNS (as Onion, mDNS, GNS, Namecoin, Handshake, Butterfly, 
etc., all demonstrate), it made it unscalable because of conventions of 
operating system vendors and application developers and assumptions of users.

> warren's .ALT proposal can begin to undo that harm. internet standards should 
> describe roads not walls. i am no fan of blockchain naming, but i'd like 
> those systems to reach the market rather than be prevented from doing so.


Just to be clear: you believe folks like Handshake, Butterfly, Unstoppable 
Domains, etc., will be willing to be ghettoized into .ALT (or other)?  And you 
also believe this will allow the use of (say) UD.ALT or HANDSHAKE.ALT to 
address the markets they’re trying to address? I’m not against moving forward 
with .ALT, but I’ll admit some skepticism that it will work as intended: it 
feels to me that it’s more an exercise in “if you build it, they will come” but 
without James Earl Jones.

As John Levine points out, this isn’t a technology issue: it is 
social/politica/economic/bureaucratic. Folks (understandably) want to leverage 
THE (singular) Internet’s namespace for fun or profit but existing processes at 
ICANN make this unappealing/impossible. As a result they (understandably) are 
looking to do an end run around those processes.  However, those processes were 
established by an entity outside of the IETF with a very different composition 
than that which participates in the IETF for very good reasons. If the IETF 
were to provide a way to bypass the ICANN processes (as Rubens points out, yet 
another beauty contest: yay), I’d be quite surprised if the myriad 
social/politica/economic/bureaucratic issues faced by ICANN wouldn’t come along 
for the ride. What’s the IETF’s legal budget again?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[George Michaelson]

To paraphrase and bastardise an old saying:

"Domains are powerful. All the good ones are taken"

I think Paul V is right that the powerful concept here is the domain
concept, scope and hierarchy.

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Stephen Farrell]

Hiya,

On 13/08/2022 23:32, Paul Vixie wrote:
warren's .ALT proposal can begin to undo that harm. internet standards 
should describe roads not walls. i am no fan of blockchain naming, but 
i'd like those 
systems to reach the market rather than be prevented from doing so.


A strong +1 to the above and the rest of the message
before that quote.

I've no particular fondness for .alt, nor do I know if
the GNU people could live with gnu.alt but I think the
IETF (and not ICANN) really ought be able to, and should,
carve out something like .alt for folk who want to not
use the DNS for domain names.

Cheers,
S.

PS: I also support Warren's idea for a venue for these
discussions.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

see inline.

Warren Kumari wrote on 2022-08-11 10:20:

Warren’s meta-comment -[ Please read this ]-


thanks for this, it was marvelously clarifying. i have a quibble which 
might best be taken as a potential warning. but first, let me emphasize:


TL;DR: Domain names are older than the DNS protocol and have always been 
used in multiple contexts. DNS naming conventions and protocol are by 
far the most widely used naming system in the public Internet, and have 
provided an extremely useful naming space default for Internet hosts and 
users. ...


it's very much worth re-reading RFC 921 and RFC 952 to understand how it 
was that domain-style names (an RFC 952 term, which RFC 921 described as 
"structured names" or "hierarchical names") preceded what we today call 
the "domain name system." we ought to have built in a carve-out for 
domain-style / hierarchical / structured names explicitly known to not 
be part of the domain name system. it's not too late; see warren's draft 
for a way to fix in 2022 what we broke in 1984.


https://www.ietf.org/id/draft-ietf-dnsop-alt-tld-15.html

i think a lot of us in the 1980's didn't realize that connectivity would 
never be end to end, and that concentric rings of connectivity would 
always exist, and that no universal naming system could encompass it 
all, but that one universal name space absolutely could do so if 
properly future-proofed.


... So, I withdrew my request for presentation time, but I *am* still 
planning on organizing a group to try and get some better focused 
discussions on this entire topic.  So, watch this space!


fingers crossed -- sign me up!


--


now for my quibble, which might be taken as a warning.


FAQ - Namespaces (please also see the meta-comment at the top of this email)
---
1:
...  It also
needs to work with existing applications, like 'ssh' and 'ping' and 
browsers and anywhere else you can realistically expect a name to show 
up ...


it does not. the dns is overwhelmingly used to reach web services, 
whether those are "sites" or API's. the web community eventually lost 
confidence in the evolution of Do53 and pushed DoH and now DoQ, just as 
thry lost confidence in the evolution of TCP and pushed QUIC. if that 
community loses confidence in the evolution of DNS and pushes some new 
web-only naming system, they may succeed but if they fail it won't be 
because of shell commands like ssh or ping. in fact it's more likely 
that shell-containing systems will add support for "W3NS" or whatever.


we must be responsive to the community of interest, or risk losing it.

--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Peter Thomassen wrote on 2022-08-13 13:36:

On 8/13/22 15:26, Paul Vixie wrote:

...

we don't need new terminology ("dotted names") to talk about domain 
names, which are older in concept and implementation than the dns is.


Sure, you're right. I used "dotted name" here only to prevent that when 
I write "domain name", people will think "DNS name". I think that's a 
common mix-up.


i suggest that we adopt the technology "domain names (which is a concept 
that precedes DNS itself)" whenever we are trying to talk about the name 
space as distinct from the protocol.


ideally the domain name system would have left a carve-out for domain 
names that were not expected to be served through the first such "domain 
name system", but were rather reserved for future domain name systems. 
if we'd known at the time that IP was going to beat OSI we'd've planned 
better? i know a lot of us would have liked YP/NIS to have been able to 
live inside YP.ALT or some such. similarly for XNS and DECNet and OSI 
and AppleTalk and so on.


by camping onto the whole of the domain name space, DNS (the domain name 
system) has blocked research into new naming systems. warren's .ALT 
proposal can begin to undo that harm. internet standards should describe 
roads not walls. i am no fan of blockchain naming, but i'd like those 
systems to reach the market rather than be prevented from doing so.


But I did not mean to introduce new terminology. The point of my message 
was that I disagree with
People have projects outside the DNS and want to name them with DNS 
names.


thanks for making that clear. introduction of the new term "dotted 
names" was a distraction from your intent.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Peter Thomassen]

On 8/13/22 15:26, Paul Vixie wrote:

what people want is domain names. right now dns camps onto the whole space of domain 
names, because it expected to be the last and final deliverer of domain names. it's 
called the "domain name system" after all.

dns should decamp from some part of the domain name space, so that naming research using 
domain names can continue beyond dns. warren explained that this was his goal with the 
".alt" name reservation.

we don't need new terminology ("dotted names") to talk about domain names, 
which are older in concept and implementation than the dns is.


Sure, you're right. I used "dotted name" here only to prevent that when I write "domain 
name", people will think "DNS name". I think that's a common mix-up.

But I did not mean to introduce new terminology. The point of my message was 
that I disagree with

People have projects outside the DNS and want to name them with DNS names.


Thanks,
Peter

--
https://desec.io/

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Vixie]

Peter Thomassen wrote on 2022-08-13 09:23:



On 8/13/22 11:57, John R Levine wrote:

...


It's not a technical problem, it's a social or political one.  People 
have projects outside the DNS and want to name them with DNS names.  
Sometimes you can't have what you want.


The issue is *precisely* that they want dotted *names*, *not* DNS names, 
but there is overlap in namespace.


warren explained this. domain names are older than the dns. hosts.txt 
had them. to be a "domain" name just means it has hierarchy in that each 
name is within some domain of other related names. sri-nic.arpa was a 
domain name. its parent domain was arpa. all of this preceded the dns.


what people want is domain names. right now dns camps onto the whole 
space of domain names, because it expected to be the last and final 
deliverer of domain names. it's called the "domain name system" after all.


dns should decamp from some part of the domain name space, so that 
naming research using domain names can continue beyond dns. warren 
explained that this was his goal with the ".alt" name reservation.


we don't need new terminology ("dotted names") to talk about domain 
names, which are older in concept and implementation than the dns is.


--
P Vixie

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Peter Thomassen]

On 8/13/22 11:57, John R Levine wrote:

That said, I believe what Warren is suggesting is more of a ten thousand foot 
view of the namespaces issue; and if that finds a way to allow innovation 
without fragmentation, it would be beneficial for DNS and non-DNS names alike.


That would be swell, but since we've been wrestling with this problem for 25 
years and have made no progress, I don't think a few more rounds is likely to 
provide a breakthrough.

It's not a technical problem, it's a social or political one.  People have 
projects outside the DNS and want to name them with DNS names.  Sometimes you 
can't have what you want.


The issue is *precisely* that they want dotted *names*, *not* DNS names, but 
there is overlap in namespace.

I don't think it's accurate to claim that anyone who wants to use a 
dot-separated namespace wants a DNS name. For the misunderstandings it creates, 
I'd suggest changing the framing.

With this distinction in mind, the problem of non-DNS names is not within the 
remit of the DNS name allocation folk (ICANN). (Unlike the .internal DNS name.)

"Disentangling namespace" and coming up with related proposals/conventions (or 
giving up) is on the protocol folk (IETF).

Warren is trying to motivate continuing the discussion among those who are 
interested, for which he is planning to create some venue. I think that's fair 
for the group of people who wants to talk about that.

I'm not implying that protocol folk could actually find a solution. I don't 
know that. From a 1000-ft perspective, perhaps no solution exists. But I see no 
problem with having a (non-DNS) list on which that is discussed.

Thanks,
Peter

--
https://desec.io/

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John R Levine]

I agree with this for TLD strings but the special use domain names registry is 
also used for registrations under .arpa which we want to keep. Is there an RFC 
other than 6761 that would cover those ? Eg currently resolver.arpa is going 
through 6761.


Good point.  Leaving it open for .arpa subdomains is fine, keeping in mind 
that names in .arpa are managed under RFC 3172, not 6761.


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

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John R Levine]

That said, I believe what Warren is suggesting is more of a ten thousand foot 
view of the namespaces issue; and if that finds a way to allow innovation 
without fragmentation, it would be beneficial for DNS and non-DNS names alike.


That would be swell, but since we've been wrestling with this problem for 
25 years and have made no progress, I don't think a few more rounds is 
likely to provide a breakthrough.


It's not a technical problem, it's a social or political one.  People have 
projects outside the DNS and want to name them with DNS names.  Sometimes 
you can't have what you want.


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

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[Paul Wouters]

Sent using a virtual keyboard on a phone

> On Aug 12, 2022, at 23:36, John Levine  wrote:
> 
>  Given the
> history of failure, I think the sensible thing to do is to stop, which
> means closing the Special-Use Domain Names registry.

I agree with this for TLD strings but the special use domain names registry is 
also used for registrations under .arpa which we want to keep. Is there an RFC 
other than 6761 that would cover those ? Eg currently resolver.arpa is going 
through 6761.

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

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[rubensk=40nic . br]

> On 13 Aug 2022, at 00:35, John Levine  wrote:
> 
> It appears that Warren Kumari   said:
>> -=-=-=-=-=-
>> 
>> Warren’s meta-comment -[ Please read this ]-
>> -
>> I believe that there is still an open-mineshaft problem around Internet
>> domain namespaces - what exactly they are, what is the DNS namespace, how
>> one determines the boundaries of the space, how one switches namespaces,
>> etc. We've take a few cracks at this nut — a partial list includes the IAB
>> ENAME workshop, SUDN problem statement, drafts from Suzanne and Ed, the
>> pain around .onion  (a fuller list is in [0]) -- but we haven't actually
>> solved it. ...
> 
> Having read your message and largely agreed with it, my suggestion is that
> we declare defeat and give up.
> 
> People come to us asking to reserve "good" names for them. As I said a
> few messages ago, I think we could reserve random TLD strings like
> .vhqnckwp without too much trouble, but nobody wants those. They want
> memorable three or four letter strings.
> 
> For better or worse, allocating memorable strings is ICANN's job.
> While I have my doubts about the details of the process, they do have
> a process, and it's allocated over 1200 TLDs. It is not cheap, but
> ICANN says they set the price to cover costs and again, while again I
> have some doubts about the details, it's clearly the right order of
> magnitude since they have spent about 85% of what they collected. I
> don't see any benefit from us short circuiting their evaluation
> process.
> 
> When we have tried to do something about memorable TLD strings, it has
> not turned out well, viz. .corp, .home, and .mail.  (We are lucky that
> the Allium Growers Promotion Board doesn't want .onion.)  Given the
> history of failure, I think the sensible thing to do is to stop, which
> means closing the Special-Use Domain Names registry.


Besides what John mentioned, even ICANN gave up the idea of a beauty pageant 
selection of who gets a string. ICANN tried that in the early 00s, and declared 
defeat on that model.
Since 2012, the tie-breaker is who pays more money among those that promise to 
not break the Internet; what I've seen so far is an attempt to move back to the 
beauty pageant model, disguised by arguments of technical or philosophical 
superiority.

That said, I believe what Warren is suggesting is more of a ten thousand foot 
view of the namespaces issue; and if that finds a way to allow innovation 
without fragmentation, it would be beneficial for DNS and non-DNS names alike.



Rubens







signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

[John Levine]

It appears that Warren Kumari   said:
>-=-=-=-=-=-
>
>Warren’s meta-comment -[ Please read this ]-
>-
>I believe that there is still an open-mineshaft problem around Internet
>domain namespaces - what exactly they are, what is the DNS namespace, how
>one determines the boundaries of the space, how one switches namespaces,
>etc. We've take a few cracks at this nut — a partial list includes the IAB
>ENAME workshop, SUDN problem statement, drafts from Suzanne and Ed, the
>pain around .onion  (a fuller list is in [0]) -- but we haven't actually
>solved it. ...

Having read your message and largely agreed with it, my suggestion is that
we declare defeat and give up.

People come to us asking to reserve "good" names for them. As I said a
few messages ago, I think we could reserve random TLD strings like
.vhqnckwp without too much trouble, but nobody wants those. They want
memorable three or four letter strings.

For better or worse, allocating memorable strings is ICANN's job.
While I have my doubts about the details of the process, they do have
a process, and it's allocated over 1200 TLDs. It is not cheap, but
ICANN says they set the price to cover costs and again, while again I
have some doubts about the details, it's clearly the right order of
magnitude since they have spent about 85% of what they collected. I
don't see any benefit from us short circuiting their evaluation
process.

When we have tried to do something about memorable TLD strings, it has
not turned out well, viz. .corp, .home, and .mail.  (We are lucky that
the Allium Growers Promotion Board doesn't want .onion.)  Given the
history of failure, I think the sensible thing to do is to stop, which
means closing the Special-Use Domain Names registry.

R's,
John

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