Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 3. Aug 2022, at 16:46, Paul Hoffman  wrote:
> 
> On Aug 3, 2022, at 12:36 AM, Schanzenbach, Martin  
> wrote:
>> 
>> Having now read further I am pretty convinced that the advisory is not 
>> useful in the context of this thread discussion.
>> Ist sais at the end that [1] was the "impetus" for the advisory.
> 
> Reading a five-year old version of a draft is not a good way to determine the 
> current state of thinking. You should only be looking at the current version 
> of the WG document: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
> 

https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00
does not seem to be a predecessor of
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

On the contrary, the first references the second and confirms my analysis:

"
 The [I-D.ietf-dnsop-alt-tld] document reserves a string to be used as
   a pseudo-TLD for non-DNS resolution contexts.  However, it is clear
   that there is a significant use case for a similar string to be used
   for namespaces which are resolved using the DNS protocol, but which
   do not have a meaning in the global DNS context.
"

I do not understand what you are trying to tell me?

BR

> --Paul Hoffman
> 
> ___
> 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] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 4. Aug 2022, at 14:06, Vittorio Bertola 
>  wrote:
> 
> 
> 
>> Il 04/08/2022 08:40 CEST Martin Schanzenbach  ha 
>> scritto:
>> 
>> Anyway, going to ICANN in order to collect a TLD is not a reasonable process 
>> for
>> publishing our draft.
>> We would not even know what the process would be (after the RFC? before
>> writing it? While writing it? What if ICANN denies a request? All the
>> work is moot?)
>> Similarly using "www.example.com!gns" et al. is not a reasonable change.
>> As that impairs usability and is incompatible with applications that
>> expect domain names.
> 
> The problem is that your entire project is conceptually and politically 
> flawed.
> 
> If you want to establish an alternative namespace to the DNS, then you should 
> not use DNS-compatible names.
> 

There are a lot of "DNS compatible" names that are not names in DNS. And 
namespaces. I hope you do not want me to start a list.

> ... and you should be damned.
> 

Oh great.

> If you want to establish a different way to resolve actual DNS names, then 
> you should come here and propose a revision of the DNS protocol, or an entire 
> new protocol to replace it, and have it standardized by the IETF, or rejected 
> if the community disagrees with you.
> 

We went through the proper channels and procedures of the IETF regarding 
deconflicting before going the IS route.

> Also, if you think that your project requires a valid TLD in the existing DNS 
> namespace, then you should get one following the same procedures as everybody 
> else, which means either applying for a string to ICANN, or getting an IETF 
> Standards Action specification as required by RFC 6761 section 4.

We did. Just to refresh everybody's memory: 
https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-04
IETF decided to not follow their own procedures.

> An independent RFC would not meet these requirements, and I do not see why 
> the ISE should ever publish it, except to create more confusion and more 
> arguments.

Why did .onion meet those requirements? In fact, what requirements? .onion does 
not even have a specification for the name system it provides published.

> 
> More generally speaking, the DNS today is both a several billion dollars 
> industry and a fundamental, regulated instrument for the political and 
> socioeconomical stability of the entire world, way more than it is an IETF 
> protocol. People are free to introduce politically motivated attempts to 
> disrupt the current balance, but they should not expect cooperation, not any 
> well-behaved global institution should provide any. Even if some of us may 
> individually like the idea, as an institution the IETF is part of a bigger 
> arrangement that it cannot unilaterally challenge without losing its face.

And IESG is able to identify a conflict right at this moment as part of the 
conflict review and prevent publication.
It is our goal to trigger discussions and show how an alternative protocol to 
resolve domain names could work and possibly how they can be experimentally 
integrated into the Internet infrastructure.
If that has no place in the RFC series (we are not even talking IETF/Standards 
Track here), then so be it. Are you the authority to decide?
I think it is still a matter of discussion if there is a conflict at all. And 
this discussion is currently held here.
You are trying to kill it using, what, political arguments?
Is the DNS namespace and its billion dollar industry so fragile that it cannot 
handle experimental alternative domain name resolution mechanisms that may be 
used for resolve "DNS-compatible" names as well?
And if the IETF is, as you insinuate, some kind of guardian of that industry 
that relies on the existing infrastructure, what chances would any proposal 
have going through the respective processes in the future?

BR

> 
> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy



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

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 4. Aug 2022, at 16:17, Vittorio Bertola 
>  wrote:
> 
>> Il 04/08/2022 14:37 CEST Schanzenbach, Martin  ha 
>> scritto:
>> 
>> You are trying to kill it using, what, political arguments?
> 
> Yes. There is nothing technical in this discussion. We are not arguing over 
> wire formats or algorithms, we are arguing about names and ways to gain 
> control over them, i.e. policy.
> 
> Indeed, many outside of the IETF think that the IETF does not even have the 
> authority to approve anything like what you are proposing. (Don't mention 
> .onion, it was a mistake.)

But the resolution protocol is technology-neutral. I invite you to re-read the 
draft. We are not proposing a namespace.
The possibility for the user to modify local configurations is as benign as a 
modification of /etc/hosts or Nsswitch.

> 
>> Is the DNS namespace and its billion dollar industry so fragile that it 
>> cannot handle experimental alternative domain name resolution mechanisms 
>> that may be used for resolve "DNS-compatible" names as well?
> 
> If your proposal:
> 1. does not allow the creation of new DNS names (TLDs or others) outside of 
> the established registration policies;
> 2. does not allow to redefine, redirect or control names that already exist 
> in the DNS namespace;
> then it is an "alternative domain name resolution mechanism".
> 
> If it allows any of the two functions above, and as I understand it does, and 
> does so in a way that can be shared across the global Internet, then it is 
> not a resolution mechanism but a namespace expansion and even a new name 
> creation policy, and also it does potentially fragment the Internet.

The draft does not "allow to create/redefine" names. Its a protocol for name 
resolution and zone management/publishing.
You can do a 1:1 mapping from the current governance (ICANN) with a GNS 
technical infrastructure.

> 
>> And if the IETF is, as you insinuate, some kind of guardian of that industry 
>> that relies on the existing infrastructure, what chances would any proposal 
>> have going through the respective processes in the future?
> 
> Zero. But you seem to think that the IETF is required to approve whatever 
> proposal it receives, and it is not, even in the independent submission 
> stream.
> 
> Still, you seem to miss my general point, which is not about what I may think 
> of your objectives (indeed, I hate centralization as well, though this is one 
> of the few centralized arrangements for which there are valid reasons).
> 
> My point is that you cannot plan a revolution and at the same time ask parts 
> of the system that you are trying to overturn to rubberstamp it.

We are not asking to rubberstamp.
We proposed this protocol to the IETF and there was no WG interesting in 
technical discussions. Nevertheless be believe (and were told by a lot of 
individuals) that the idea and protocol has technical merit.
Which is why we then brought it to ISE.

> 
> If you want the stamps, then you have to turn the revolution into an 
> evolution and accept some compromises, such as "!gns" or whatever else. It 
> may actually be a more productive strategy in the long term.
> 
> If you want a revolution, then you have to be prepared to fight against the 
> system. I easily see people in several (non-EU) countries getting the police 
> at their door if they start using your system for the purposes that you 
> declare right at the top of your draft. That's just how the world works.
> 

If you say that the security issues DNS (still) has are a feature and not a 
bug, then I have to respectfully disagree.

BR

> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
> 
> ___
> 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] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 4. Aug 2022, at 18:01, Schanzenbach, Martin  
> wrote:
> 
> 
> 
>> On 4. Aug 2022, at 16:17, Vittorio Bertola 
>>  wrote:
>> 
>>> Il 04/08/2022 14:37 CEST Schanzenbach, Martin  ha 
>>> scritto:
>>> 
>>> You are trying to kill it using, what, political arguments?
>> 
>> Yes. There is nothing technical in this discussion. We are not arguing over 
>> wire formats or algorithms, we are arguing about names and ways to gain 
>> control over them, i.e. policy.
>> 
>> Indeed, many outside of the IETF think that the IETF does not even have the 
>> authority to approve anything like what you are proposing. (Don't mention 
>> .onion, it was a mistake.)
> 
> But the resolution protocol is technology-neutral. I invite you to re-read 
> the draft. We are not proposing a namespace.
> The possibility for the user to modify local configurations is as benign as a 
> modification of /etc/hosts or Nsswitch.

(sorry I meant "policy-neutral")


> 
>> 
>>> Is the DNS namespace and its billion dollar industry so fragile that it 
>>> cannot handle experimental alternative domain name resolution mechanisms 
>>> that may be used for resolve "DNS-compatible" names as well?
>> 
>> If your proposal:
>> 1. does not allow the creation of new DNS names (TLDs or others) outside of 
>> the established registration policies;
>> 2. does not allow to redefine, redirect or control names that already exist 
>> in the DNS namespace;
>> then it is an "alternative domain name resolution mechanism".
>> 
>> If it allows any of the two functions above, and as I understand it does, 
>> and does so in a way that can be shared across the global Internet, then it 
>> is not a resolution mechanism but a namespace expansion and even a new name 
>> creation policy, and also it does potentially fragment the Internet.
> 
> The draft does not "allow to create/redefine" names. Its a protocol for name 
> resolution and zone management/publishing.
> You can do a 1:1 mapping from the current governance (ICANN) with a GNS 
> technical infrastructure.
> 
>> 
>>> And if the IETF is, as you insinuate, some kind of guardian of that 
>>> industry that relies on the existing infrastructure, what chances would any 
>>> proposal have going through the respective processes in the future?
>> 
>> Zero. But you seem to think that the IETF is required to approve whatever 
>> proposal it receives, and it is not, even in the independent submission 
>> stream.
>> 
>> Still, you seem to miss my general point, which is not about what I may 
>> think of your objectives (indeed, I hate centralization as well, though this 
>> is one of the few centralized arrangements for which there are valid 
>> reasons).
>> 
>> My point is that you cannot plan a revolution and at the same time ask parts 
>> of the system that you are trying to overturn to rubberstamp it.
> 
> We are not asking to rubberstamp.
> We proposed this protocol to the IETF and there was no WG interesting in 
> technical discussions. Nevertheless be believe (and were told by a lot of 
> individuals) that the idea and protocol has technical merit.
> Which is why we then brought it to ISE.
> 
>> 
>> If you want the stamps, then you have to turn the revolution into an 
>> evolution and accept some compromises, such as "!gns" or whatever else. It 
>> may actually be a more productive strategy in the long term.
>> 
>> If you want a revolution, then you have to be prepared to fight against the 
>> system. I easily see people in several (non-EU) countries getting the police 
>> at their door if they start using your system for the purposes that you 
>> declare right at the top of your draft. That's just how the world works.
>> 
> 
> If you say that the security issues DNS (still) has are a feature and not a 
> bug, then I have to respectfully disagree.
> 
> BR
> 
>> --
>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>> vittorio.bert...@open-xchange.com
>> Office @ Via Treviso 12, 10144 Torino, Italy
>> 
>> ___
>> 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] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 4. Aug 2022, at 21:28, David Conrad  wrote:
> 
> Martin,
> 

Hi David,

> On Aug 4, 2022, at 12:01 PM, Schanzenbach, Martin  
> wrote:
>> But the resolution protocol is technology-neutral. I invite you to re-read 
>> the draft. We are not proposing a namespace.
> 
> Right. If I understand correctly, you are proposing to use the existing 
> domain name namespace, and that’s where the problem lies.

Not quite. We are proposing a protocol that can resolve any domain name. Of any 
name space. Regardless of its governance.

> 
> Because of the way applications have been written and users have been 
> trained, there is precisely one global "domain name” namespace.  It is a 
> series of labels separated by ‘.’s” at the presentation layer. As 
> applications and end users cannot distinguish the underlying protocol by 
> which names are resolved simply from the name, the fact that the protocol is 
> “technology-neutral” (whatever that means) is irrelevant. Since the domain 
> name namespace is hierarchical, there can be only one designated 
> administrator for each branch of the global name space. Note that that 
> administration can be centralized or decentralized, but if it is 
> decentralized, it must be coordinated, i.e., the multiple authorities can’t 
> just go off and partition the namespace by themselves and expect those 
> partitions to have global uniqueness.
> 
>> The possibility for the user to modify local configurations is as benign as 
>> a modification of /etc/hosts or Nsswitch.
> 
> Sure. And to what will those users/applications that do not modify /etc/hosts 
> or use nsswitch, which will undoubtedly be the vast majority, send their 
> queries?  And what happens when someone who “plays by the rules” and goes 
> through the ICANN “global multi-stakeholder defined" process (e.g., the folks 
> who obtained .pet) obtains the same portion of the domain name namespace you 
> have chosen for GNS?
> 

Also not quite. "We" do not choose anything regarding names or TLDs in GNS. 
Think of the draft as the equivalent of the specification of iterative 
resolution in DNS. That is what is specified for GNS.
Not who controls the root zone. And not what is in it.
So, for example, GNS implementations/deployments could ship with a root zone 
defined by ICANN. Of course, ICANN would have to decide to publish such a 
configuration. The configuration could be simple mapping from TLDs to zone keys.
The delegations would point to the TLD owners (which in turn also publish their 
zones) that ICANN considers the owners.
Of course this is at this point a ridiculous proposition as it would mean that 
all stakeholders would have to publish their DNS zones in their equivalent GNS 
zones.
But if that would happen tomorrow, you would have the same namespace, governed 
by the same processes, with a different technical underpinning.
Yes, users could modify the ICANN-default root zone in this world. It would 
effectively be similar (albeit a bit more powerful) to adding a hostname to 
/etc/hosts.
It may destroy a lot of things that would work otherwise (e.g. TLS), it may not 
(if it is the same IP, for example). But at that point the user is in dragon 
country anyway.

Ok, back to the real world: Of course, the above could not happen overnight. So 
the idea is that we *MAY* need a place (a sub-namespace) where this protocol 
can be tested, now.
A special-use TLD may make sense for this.

I hope this makes it clear what we mean by "this is only a protocol and does 
not address governance".

> I believe (and I’m sure I’ll be corrected if I’m wrong) a major reason there 
> is a moratorium on the process defined in RFC 6761 is because of a lack of 
> clarity about who has authority over the administration of the single, global 
> domain name namespace that you want to insert a name into. Some believe that 
> authority is ICANN and others believe your usage would fall under “technical 
> use” (whatever that means) and thus, be in the realm of the IETF. 
> Complicating matters, the existing processes for TLD allocation at ICANN 
> simply did not envision this particular usage and even if it did, the "new 
> round”, known in ICANNland as “Subsequent Procedures”, is still (probably) 
> years off.
> 
> The implication of all of this is the quagmire you find yourself in. In my 
> view, you should be commended for trying to do “the right thing” but that 
> doesn’t solve your problem. Pragmatically speaking, and to perhaps state the 
> obvious, I see 4 options:
> 
> 1) Wait for ICANN to fix their processes
> 2) Wait for the IETF to figure out whether/how to reopen the “Special Use 
> Domains” registry
> 3) Try to bypass (1) and/or (2) by publishing through the ISE (I don’t know 
> enough about the ISE process to guess whethe

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] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Schanzenbach, Martin]

Hi,

> On 16. Aug 2022, at 16:32, David Conrad  wrote:
> 
> Signed PGP part
> On Aug 15, 2022, at 7:07 PM, Stephen Farrell  
> wrote:On 16/08/2022 03:01, John Levine wrote:
>>> Right. If it's FCFS, I am sure I am not the only person who will be
>>> waiting at the gate with thousands of preemptive registrations.
>> Why?
> 
> Because they believe (or are convinced) there is or will be profit in it. My 
> experience has been that the majority of folks who are getting Unstoppable 
> Domains TLDs haven’t the slightest clue what they are or why they’re not 
> particularly useful.  And they’re paying actual money, not merely (say) 
> copying a document and changing a few words or wading through mind-numbing 
> technical process. They are speculators and if the cost of obtaining the 
> “asset” is below what the projected/potential value may be, then they’ll 
> “invest”.
> 

That is exactly why IMO the namespaces under .alt must have a technical merit 
and this merit gives the protocol a shot at a (or a few based on the technical 
design) (free) name under .alt.
It should not be possible to get such a name in the registry without a 
technical justification (e.g. a spec that proposes a new way of doing name 
resolution). No political or policy considerations necessary.
And this is why there must be a registration policy and process.
This merit needs to be established, yes. And I think it should be done through 
review by the IETF or the ISE.
And yes, there is a reason why this sounds a bit like a RFC6761 SU-TLD, because 
the motivation makes sense to me.

I also do not believe that IETF or ISE will be swamped with drafts... I do not 
see any indication why this would be the case.
In fact, you currently have a whopping 1 draft on your table. And nobody in 
line as far as I can see.
There are only a handful of (alive) proposals regarding alternative names and 
not all of those strike me as projects that will consider this at all anyway.

BR
Martin

> Regards,
> -drc
> 
> 
> 



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

Re: [DNSOP] draft-schanzen-gns and namespace mechanisms

[Schanzenbach, Martin]

Hi Brian,

thank you for the feedback.

> On 19. Aug 2022, at 16:46, Brian Dickson  
> wrote:
> 
> One tidbit that might have been overlooked, is that draft-schanzen-gns (and 
> the various documents it references, including stuff in github) has a 
> technical problem.
> 
> The TL;DR: is that nsswitch (and similar systems) depend on individual 
> resolution mechanisms (whatever those may be) returning NXDOMAIN (or the 
> equivalent) in order to fall through to the next mechanism.
> GNS as currently specified will NEVER return NXDOMAIN. The draft says so 
> (about never returning NXDOMAIN) and explains why. The why doesn't matter, 
> the what matters.
> 
> What this means is, if nsswitch.conf has a line that looks like:
> hosts: gns dns files
> then the lookups will NEVER fall through to DNS or /etc/hosts. Changing the 
> order around to put "gns" at the end of the list will work, but would result 
> in DNS queries for GNS names always being done. This appears to not do what 
> the draft says it wants to do (i.e. allowing users to have both GNS and DNS 
> names in use, including allowing GNS to be preferred if a name collision 
> occurs.)
> 
> Here's the longer version:
> If GNS never returns NXDOMAIN, then the only way GNS can interoperate with 
> the name resolution selectors such as nsswitch.conf is to use a namespace 
> identifier of some kind, and return NXDOMAIN for any names that are not 
> actual GNS names. (The identifier could be anything -- a suffix, a prefix, a 
> single character, etc.) This would allow GNS to be a first-class member of 
> the available resolution mechanisms, rather than being forced to always be 
> the last mechanism in a list.


A GNS implementation ships with a default configuration: The "Start Zone" 
(https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-start-zones).
IF the user configured a suffix in the start zone that also exists in DNS, then 
that is the users problem (see also, /etc/hosts).
So, the GNS nsswitch plugins functions similarly to the "files" plugin. It also 
times out, at which point it returns notfound, however.
See also https://docs.gnunet.org/installing.html#nss-plugin-optional

IF the implementation ships a default configuration that has mappings that also 
exist in DNS/others , then this may be a problem.
I would request a suggestion on different wording then (however, I think with 
.alt this would be fixed anyway).

> 
> Using some (any) mechanism that allows GNS names to be identifiable in such a 
> way as to either allow GNS to internally distinguish GNS from DNS (and return 
> NXDOMAIN for DNS names if the query sent to GNS is a DNS name), or for GNS to 
> handle both GNS and DNS names on a similar basis (do a GNS resolve on GNS 
> names, or do a DNS resolve on DNS names and return the result from the DNS 
> call).
> Having DNS vs GNS ordering handled by the os-specific mechanism (such as 
> nsswitch.conf) might be better for linux/unix systems (and servers and 
> desktops generally), while mobile OS set-ups might use their own mechanisms.

We want the DNS vs GNS vs Other handling to be done by the application (the OS 
resolver is an application from the perspective of the GNS implementation). 
This IMO should not be part of our spec beyond some non-normative guidance.
For example, we specifically consider nsswitch to be a crutch for applications 
that cannot (yet) distinguish between name systems as part of *possible* 
migration paths: 
https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#appendix-A.4

> 
> The GNS specification might also want to change its design so that 
> applications make those decisions on resolution directly, and call whichever 
> mechanism is appropriate, ie. call either GNS or DNS for resolution on the 
> basis of the presence/absence of the GNS identifier. Additionally, the 
> applications (e.g. web browsers) might handle the input/UI parts to default 
> to either DNS or GNS, and "hide" the GNS identifier (similar to how the "www" 
> prefix and "https:" service identifier are "hidden", but available for 
> modification by users in the browser bar), allowing advanced users to do "the 
> other thing", as appropriate, or whatever the GNS folks thing makes sense.
> 
> E.g. in the browser UI for the URI, what might appear to the user as 
> "foo.bar" might in fact be "https://www.foo.bar"; (current DNS-as-default 
> browser), or could alternatively be "https://www.foo.bar.gns.alt"; (modified 
> GNS-as-default browser). A user entering "foo.bar" would have that 
> transformation applied by default, but also be editable if the user desires.

Yes, but we have to distinguish between "GNS-aware" and "GNS-unaware" 
applications. For example, applications such as browsers are not really 
"nsswitch files plugin"-aware.
The browser will try the IP and TLS probably will not work if the server IPs in 
DNS and hosts do not match.

So, in order to applications to proactively handle GNS names, they need to 
"know" what it i

Re: [DNSOP] draft-schanzen-gns and namespace mechanisms

[Schanzenbach, Martin]

> On 19. Aug 2022, at 17:06, Schanzenbach, Martin  
> wrote:
> 
> Signed PGP part
> Hi Brian,
> 
> thank you for the feedback.
> 
>> On 19. Aug 2022, at 16:46, Brian Dickson  
>> wrote:
>> 
>> One tidbit that might have been overlooked, is that draft-schanzen-gns (and 
>> the various documents it references, including stuff in github) has a 
>> technical problem.
>> 
>> The TL;DR: is that nsswitch (and similar systems) depend on individual 
>> resolution mechanisms (whatever those may be) returning NXDOMAIN (or the 
>> equivalent) in order to fall through to the next mechanism.
>> GNS as currently specified will NEVER return NXDOMAIN. The draft says so 
>> (about never returning NXDOMAIN) and explains why. The why doesn't matter, 
>> the what matters.
>> 
>> What this means is, if nsswitch.conf has a line that looks like:
>> hosts: gns dns files
>> then the lookups will NEVER fall through to DNS or /etc/hosts. Changing the 
>> order around to put "gns" at the end of the list will work, but would result 
>> in DNS queries for GNS names always being done. This appears to not do what 
>> the draft says it wants to do (i.e. allowing users to have both GNS and DNS 
>> names in use, including allowing GNS to be preferred if a name collision 
>> occurs.)
>> 
>> Here's the longer version:
>> If GNS never returns NXDOMAIN, then the only way GNS can interoperate with 
>> the name resolution selectors such as nsswitch.conf is to use a namespace 
>> identifier of some kind, and return NXDOMAIN for any names that are not 
>> actual GNS names. (The identifier could be anything -- a suffix, a prefix, a 
>> single character, etc.) This would allow GNS to be a first-class member of 
>> the available resolution mechanisms, rather than being forced to always be 
>> the last mechanism in a list.
> 
> 
> A GNS implementation ships with a default configuration: The "Start Zone" 
> (https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-start-zones).
> IF the user configured a suffix in the start zone that also exists in DNS, 
> then that is the users problem (see also, /etc/hosts).
> So, the GNS nsswitch plugins functions similarly to the "files" plugin. It 
> also times out, at which point it returns notfound, however.
> See also https://docs.gnunet.org/installing.html#nss-plugin-optional

Oh and I need to add here: The nsswitch plugin is a "GNS-aware" application. 
Which is why if there is NO "start zone" configuration that matches the suffix 
of the name, it DOES return "NXDOMAIN".

> 
> IF the implementation ships a default configuration that has mappings that 
> also exist in DNS/others , then this may be a problem.
> I would request a suggestion on different wording then (however, I think with 
> .alt this would be fixed anyway).
> 
>> 
>> Using some (any) mechanism that allows GNS names to be identifiable in such 
>> a way as to either allow GNS to internally distinguish GNS from DNS (and 
>> return NXDOMAIN for DNS names if the query sent to GNS is a DNS name), or 
>> for GNS to handle both GNS and DNS names on a similar basis (do a GNS 
>> resolve on GNS names, or do a DNS resolve on DNS names and return the result 
>> from the DNS call).
>> Having DNS vs GNS ordering handled by the os-specific mechanism (such as 
>> nsswitch.conf) might be better for linux/unix systems (and servers and 
>> desktops generally), while mobile OS set-ups might use their own mechanisms.
> 
> We want the DNS vs GNS vs Other handling to be done by the application (the 
> OS resolver is an application from the perspective of the GNS 
> implementation). This IMO should not be part of our spec beyond some 
> non-normative guidance.
> For example, we specifically consider nsswitch to be a crutch for 
> applications that cannot (yet) distinguish between name systems as part of 
> *possible* migration paths: 
> https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#appendix-A.4
> 
>> 
>> The GNS specification might also want to change its design so that 
>> applications make those decisions on resolution directly, and call whichever 
>> mechanism is appropriate, ie. call either GNS or DNS for resolution on the 
>> basis of the presence/absence of the GNS identifier. Additionally, the 
>> applications (e.g. web browsers) might handle the input/UI parts to default 
>> to either DNS or GNS, and "hide" the GNS identifier (similar to how the 
>> "www" prefix and "https:" service identifier are "hidden", but available for 
>> modifica

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 20. Aug 2022, at 03:29, Stephen Farrell  wrote:
> 
> Signed PGP part
> 
> Hiya,
> 
> On 20/08/2022 01:55, Warren Kumari wrote:
>> On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell 
>> wrote:
>>> Hiya,
>>> 
>>> On 19/08/2022 20:43, Warren Kumari wrote:
>>> 
>>> So, it is perfectly acceptable (in my view) for it to have:
>>> 
>>> Reference Name
>>> -
>>> a-cool-document foo.alt
>>> another-document foo.alt
>>> yet-another-doc bar.alt
>>> 
>>> I agree that such duplicate names are acceptable in this registry.
>>> 
>>> I scanned the draft quickly and think it's good. (I'll try do a closer
>>> read in a few days.)
>>> 
>>> Only thing with which I'd argue for now is that I think RFC required is a
>>> much simpler rule for the registry.
>> My concern with this is that we may end up with lots of Internet Drafts
>> which either need to be put in some WG or be AD sponsored, and have to go
>> through IETF LC, and IESG Eval,  and use RFC Editor resources and similar.
>> For an informational only thing that seems like a lot of overhead. I'm also
>> not very sure that IETF participants would really want to review yet
>> another block-chain based name resolution system every N weeks…
> 
> I agree wrt IETF review. My possibly wrong assumption was
> that most drafts looking for names in this registry might
> arrive via the ISE or IRTF, with few desiring all the fun
> of IETF processes.
> 
> I guess I'd generally be ok with there being non-trivial
> hoops that need to be jumped-through for this registry, but
> yes, I know that increases the chances of squatting-like
> behaviour. I also recognise that reasonable people might
> make different predictions about this small bit of the
> future.
> 
>>> Any other option will require some designated experts with some guidance
>>> for those DEs, and I'd expect it to be hard for us to agree what guidance
>>> to include in the draft or not, and I'd expect it to be hard to find DEs
>>> for this registry.
>>> 
>> Yup, that's a valid concern - IANA's site speaketh thusly:
>> "If you choose Expert Review or Specification Required as the registration
>> procedure for your new registry, it can be helpful to provide guidance to
>> the “expert.” The idea is to provide the expert with guidance on naming,
>> allocation and other issues related to the protocol registry. Sometimes
>> Internet-Draft authors include the guidance directly in the draft. Other
>> times, a Working Group will decide to collect guidance for a group of
>> protocols together (for instance, see the PWE3 working group in RFC 4446)."
>> — https://www.iana.org/help/protocol-registration
>> I'd think that the guidance to the experts would be:
>> 1: Is there a specification somewhere? RFC8126 (Spec Required) says that a
>> specification should be a  "document can reasonably be expected to be
>> findable and retrievable long after IANA assignment of the requested value."
> 
> Right. It's the "long after" and stability (for some random
> project) and sufficient detail (for academic pubs) I wonder
> about for the specification-required path. (I've no worries
> about the IESG approval path.) I figure we might be better
> off seeing how an RFC-required setup pans out for a bit,
> then, if it seems right, loosening that to the point where
> some DEs can ok adding entries after we've figured out what
> guidance to provide to those DEs.
> 
>> 2: Does it list a name that they'd be using?
>> Great, done!
>> [ insert the Oprah Winfrey "You get a registration and you get a
>> registration" meme here —
>> https://knowyourmeme.com/memes/oprahs-you-get-a-car ].
>> It is intended to be an informational registry to help people avoid
>> conflicts, and potentially also figure out what to read to know more about
>> foo.alt - IMO they can be handed out like candy. It's better to have it
>> easy for people to get added than just squat…
>> The current IANA Considerations bit says "Expert Review" or "IESG Approval"
>> — the second bit is specifically incase there are issues with getting DEs…
>>> That said, I'd still be ok with progressing the draft if the registration
>>> rules stayed as they are now.
>> Thank you - the registry is something I've gone back and forth on, because
>> there are pros and cons…
> 
> Sure - if it's only me arguing for RFC-required, then I'm
> fine with being in the rough on that aspect.

a question from our side of the fence: How would addition to the registry look 
like in practice?
Would we add this to our "IANA" section in the draft? Or would we write an 
email directly to IANA "out of band"?
I guess that latter as how would others (without IDs) do the former, right?
If so, when? As that would likely affect the wording in any future updates.

In general, and I assume unsurprisingly, I am happy with this version of the 
alt draft.
Of course, I would be perfectly fine with requiring an RFC as well as this is 
within immediate grasp for us.
But, I can also see the issue with setting the b

Re: [DNSOP] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 22. Aug 2022, at 11:41, Andrew McConachie  wrote:
> 
> 
> 
> On 20 Aug 2022, at 2:55, Warren Kumari wrote:
> 
>> On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell 
>> wrote:
>> 
>>> Hiya,
>>> 
>>> On 19/08/2022 20:43, Warren Kumari wrote:
>>> 
>>> So, it is perfectly acceptable (in my view) for it to have:
>>> 
>>> Reference Name
>>> -
>>> a-cool-document foo.alt
>>> another-document foo.alt
>>> yet-another-doc bar.alt
>>> 
>>> I agree that such duplicate names are acceptable in this registry.
>>> 
>>> I scanned the draft quickly and think it's good. (I'll try do a closer
>>> read in a few days.)
>>> 
>>> Only thing with which I'd argue for now is that I think RFC required is a
>>> much simpler rule for the registry.
>>> 
> 
> The draft doesn’t specify if this registry is restricted to ASCII LDH or not. 
> Can I write an RFC and get #&^%&^%)(}{.alt?
> 
> How about ..alt? Or .alt? (My proposed string is NULL)
> 
> Why not allow unicode or at least some subset of it? If we want people to use 
> this registry for their hip new naming system I think we should encourage 
> developers to move away from ASCII LDH.

My interpretation is that there are no restrictions at all after ".alt". (I 
assume ".alt" should be in a format that DNS resolvers / servers understand).
I can see the pros and cons of this approach.
Implementing any kind of restrictions will open pandora's box wrt registration 
policy / reviewer considerations.
Not having any kind of restrictions will leave the registry open to strange 
requests like the ones you highlight.
I think you have pick one of those evils.

Also:
Given that it is unknown what encoding a protocol may use, it may be reasonable 
to consider that instead of Unicode, a byte string is provided with an optional 
encoding hint?
For GNS, Unicode/UTF-8 would work fine, however.

BR

> 
> —Andrew
> 
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 22. Aug 2022, at 19:07, Ray Bellis  wrote:
> 
> 
> 
> On 22/08/2022 15:05, Paul Hoffman wrote:
> 
>> I would prefer that they choose whatever is best for their own
>> non-DNS user community, which might still be ASCII.
> 
> Since this came up earlier in the thread(s), I would also strongly advise 
> that users of .alt do not stray from the DNS standard of
> 
> - 255-octet maximum name length
> - 63-octet maximum label length
> - separated by period/dots (in presentation format)
> - an empty root label.
> 
> To do otherwise might cause havoc with nsswitch mechanisms that expect to be 
> given "domain-style names".

I do not see why names under .alt must be compliant standard DNS names for any 
reason.
In fact, the whole problem and the reason why we are here is because this may 
be the case "coincidentally".
If the name system protocol wants to be backwards-compatible then it must 
define its protocol as such. Then it will "just work".
Otherwise it will not, and that is fine as well?

BR

> 
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 22. Aug 2022, at 20:15, Paul Vixie  
> wrote:
> 
> 
> 
> Schanzenbach, Martin wrote on 2022-08-22 11:02:
>> ...
>>> On 22. Aug 2022, at 19:07, Ray Bellis  wrote:
>>> ...
>>> On 22/08/2022 15:05, Paul Hoffman wrote:
>>>> ...
>> I do not see why names under .alt must be compliant standard DNS names for 
>> any reason.
> 
> +1.
> 
> noting: by describing this as a reserved name subspace, we implicitly expect 
> that the presentation form of any namespace thus enabled will be "compatible 
> enough" with DNS presentation form to allow the reservation keyword (.ALT) to 
> be entered or displayed, and detected. we can in the specification for the 
> subspace reservation even state that implication. however, if someone wants 
> to go rogue on that, we shouldn't try to stop them. (as if we could.)

But I also think that if it is expected that name systems may "go rogue" e.g. 
use a new innovative new string encoding, then the registry might have trouble 
listing/registering the 2LD "byte string" chosen by the name system?
So maybe Unicode provides sensible guide lines for acceptable strings under 
.alt _for the registry_?

BR

> 
> --
> P Vixie
> 
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 22. Aug 2022, at 20:47, Paul Vixie  wrote:
> 
> 
> 
> Schanzenbach, Martin wrote on 2022-08-22 11:24:
>>> On 22. Aug 2022, at 20:15, Paul Vixie  
>>> wrote:
>>> ...
>>> noting: by describing this as a reserved name subspace, we implicitly 
>>> expect that the presentation form of any namespace thus enabled will be 
>>> "compatible enough" with DNS presentation form to allow the reservation 
>>> keyword (.ALT) to be entered or displayed, and detected. we can in the 
>>> specification for the subspace reservation even state that implication. 
>>> however, if someone wants to go rogue on that, we shouldn't try to stop 
>>> them. (as if we could.)
>> But I also think that if it is expected that name systems may "go rogue" 
>> e.g. use a new innovative new string encoding, then the registry might have 
>> trouble listing/registering the 2LD "byte string" chosen by the name system?
> 
> that's not our problem. we're reserving part of the namespace, and that's 
> all. if someone wants to use it in a way that fails, that's totally their 
> affair.
> 
>> So maybe Unicode provides sensible guide lines for acceptable strings under 
>> .alt _for the registry_?
> just... no. if somebody wants to put binary gibberish "under" .ALT, in a way 
> that browser plugins never get to see because it's not valid unicode, that is 
> _their problem_. we can state implications, nothing more.

I agree. It is just unclear to me how the registry itself would support this. I 
am no IANA registry expert. But if any byte string is theoretically allowed as 
a 2LD, then how would this look like?
I mean, https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml 
looks ok because "URN Namespace" is well-defined as a readable string with a 
specific encoding.
But if the registry must support 花 as well as 0x32 0x34 0x23 (no the strings, 
the byte sequence) I wonder how that will look like? Or are we always going to 
register byte sequences instead of readable strings?
Again, not really my problem and will only become a problem with an odd 
encoding, so likely never*.

BR

> 
> --
> P Vixie
> 



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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 22. Aug 2022, at 20:33, Paul Hoffman  wrote:
> 
> On Aug 22, 2022, at 11:24 AM, Schanzenbach, Martin  
> wrote:
>> But I also think that if it is expected that name systems may "go rogue" 
>> e.g. use a new innovative new string encoding, then the registry might have 
>> trouble listing/registering the 2LD "byte string" chosen by the name system?
> 
> This should not be a problem: that's what we have the \DDD notation for. (See 
> the list toward the end of Section 5.1 of RFC 1035.)
> 

I just now read this, sorry. So that was a pointless tangent by me and and 
theoretically byte strings could be registered using \DDD-notations as is.

>> So maybe Unicode provides sensible guide lines for acceptable strings under 
>> .alt _for the registry_?
> 
> It does not. You truly don't want to deal with byte sequences that are not 
> allowed in the various encodings of Unicode. Specifying the names in a format 
> that DNS folks recognize (ASCII and \DDD) should suffice for someone looking 
> at the registry. If they have a further question, there is a link to the 
> specification.

You convinced me.

BR

> 
> --Paul Hoffman
> 



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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 23. Aug 2022, at 13:02, Ray Bellis  wrote:
> 
> 
> 
> On 23/08/2022 10:22, Andrew McConachie wrote:
> 
>> The only restriction that seems reasonable to me is prohibiting zero length 
>> strings. This list convinced me other restrictions would be a bad idea.
> 
> There will be a very long tail of systems out there that do not know about 
> ".alt".
> 
> How would those systems respond when passed a domain-style name that does not 
> meet domain-style syntax rules (specifically those for total length and label 
> lengths) ?
> 
> If the answer is that they return something other than EAI_NONAME (or 
> HOST_NOT_FOUND for gethostbyname) then this needs to be considered further.
> 
> IMHO, if you want to be in a carve-out of the domain name space, you still 
> need to play by the domain name space's technical rules, in a way that's 
> backwards compatible with systems that don't know about the carve-out and 
> will assume that veryverylonglabel.foo.alt _is_ a domain name.

I think the notion that there is strict "format" of a name and that if it is 
not in that format is not actually part of the same namespace is already behind 
us.
If that were the case then we do not need .alt at all.
For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant 
wire format.

I think one way to look at is is that we try to solve a problem with the 
display/presentation of names in alternate name systems and how they can be 
confused by applications but also humans with DNS names.

Applications (to some degree) have to deal with malformed names anyway as part 
of the user input handling.
If they consider the given .alt-name malformed because they only expect DNS 
names, then that is within the expected behaviour.
If the application crashes because of such a name, it would also crash because 
of data corruption or faulty user input.
And that is a bug in the application, possibly even a security issue if it 
leads to a buffer overflow etc.

BR
Martin


> 
> 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] [Ext] draft-ietf-dnsop-alt-tld-16: please review

[Schanzenbach, Martin]

> On 23. Aug 2022, at 16:47, Warren Kumari  wrote:
> 
> 
> 
> 
> 
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen  wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
> 
> There will be a very long tail of systems out there that do not know about 
> ".alt".
> 
> How would those systems respond when passed a domain-style name that does not 
> meet domain-style syntax rules (specifically those for total length and label 
> lengths) ?
> 
> Designers of that other non-DNS protocol will have to consider all kinds of 
> interoperability issues, including what kind of strings are permissible under 
> their branch of .alt, and what consequences would arise from that.
> 
> IMO, that is within the realm of the specification of that other non-DNS 
> protocol, just like any other protocol consideration that occurs when 
> evolving a specification while implementing it; we DNS people don't have to 
> mandate fences for the general case.
> 
> 
> 
> Mandate no, but I do think that we should "helpfully suggest".
> 
> There are many ways to refer to a host — for example, I recently had to ask 
> someone to swap a drive in a server  for me, and I resolved the identity 
> with: "it's the Dell server towards the bottom of the rack near the door." 
> Clearly this is a pathological case, but putting ".alt" at the end of that 
> doesn't really help :-).
> 
> Much of the reason for needing something like .alt is that the context isn't 
> explicit, and so we expect that these names will be used in places that 
> generally expect something like a "DNS name". I think that some text 
> suggesting that for interoperability with existing  applications (which may 
> do some sort of checks or processing on the user input) people may want to 
> constrain themselves to LDH / DNS syntax. There are no protocol police, and 
> so we cannot actually enforce this even if we wanted to — I can technically 
> put  weird looking pyramid thingie emoji>.kumari.net into my zonefile, and there 
> is nothing you can to do stop me…  — but it sure 
> won't work well…
> 
> So, I'd think something like: "For compatibility with existing applications 
> and to maximize interoperability, it is recommended that names that end in 
> .alt follow DNS name syntax." (or something similar but better worded).
> 

Who is this recommendation supposed to be for? The user "registering/creating" 
a name or the protocol?
I think that the specification of the protocol may recommend to users that they 
should carefully consider the name chosen when it is supposed to be used with 
".alt".
But my question would still be: Should the registry pose limitations, then, on 
the 2LD?
Because you cannot really have the one without the other?

BR
Martin

> W
> 
> 
> 
> Best,
> Peter
> 
> --
> https://desec.io/
> 
> ___
> 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



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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

[Schanzenbach, Martin]

Hi,

"

This document uses ".alt" for the pseudo-TLD in the presentation
   format for the DNS, corresponding to a 0x03616c7400 suffix in DNS
   wire format.  The presentation and on-the-wire formats for non-DNS
   protocols might be different.
"

I had to read this 3 times and I am still not sure what is important and what 
not.
Is it important what the DNS wire format specifically is? If yes, for whom?
Also, if the presentation format of ".alt" is the presentation format of DNS 
but the non-DNS protocol presentation format differs then... what?
I think we may need to agree that no matter what the presentation format is 
".alt" is always presented as ".alt", no?
Maybe it is just too late here...

"
If the non-DNS protocol has a wire format like the DNS wire format,
 it might append the null label at the end of the name, but it also
might not.
This document does not make any suggestion for how non-
DNS protocols deal with the wire format of their names.
"

This was already in before but I do not understand the significance of the 
first statement. What is it supposed to tell me?
The second statement is now a duplication of the statement in a paragraph above 
(?)

BR

> On 23. Aug 2022, at 20:52, Paul Hoffman  wrote:
> 
> Thanks again for all the discussion; it is helping the document. You can see 
> from the diff at 
>  that we have 
> tightened the language, particularly around what is display format and what 
> is wire format. More comments are of course welcome.
> 
> --Paul and Warren
> 
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-17

[Schanzenbach, Martin]

Hi,

> On 24. Aug 2022, at 16:28, Peter Thomassen  wrote:
> 
> Hi Joe,
> 
> On 8/24/22 10:13, Joe Abley wrote:
>> So the question is not whether to allow mixed capitalisation; the question 
>> is why we would intentionally change a fundamental expectation of domain 
>> names to accommodate names and resolution protocols that we largely don't 
>> have any requirements for because with one notable exception they don't 
>> exist?
> 
> I would argue that
> 
> - applications that understand a given non-DNS naming scheme under .alt do 
> not necessarily share those "fundamental expectations" (it hasn't been shown 
> that they do, it is being suspected);
> 
> - as to why we would settle on one variant: it would reduce ambiguity of 
> naming for names in the .alt namespace. I don't see why we need to impose on 
> non-DNS protocol designers that they have to mess with case insensitivity 
> just because it's been like that historically.
> 
> It would be interesting to hear an opinion of a non-DNS protocol designer 
> (e.g. GNS), so until that happens I'll stay shut. Soapy ;-)

(This is my third attempt for this mail. It has given me a lot to think about. 
Here is a first try)

In GNS, the application decides what the current user expectation is.
We (I) learned that this is a good approach after conversations with our 
reviewers in particular since it is very difficult to distinguish what "case" 
actually is with respect to i18n.
GNS, as in the protocol, does *not* consider "Example.gns.Alt" and 
"Example.gns.alt" to be the same name.
But, in GNS, we would never resolve ".alt" or ".gns.alt". Those are just 
"suffixes".

GNS users (or implementors) will ship with Root Zone configurations. E.g.

.com.gns.alt = 
.ch.gns.alt = 

and the user will be able to resolve "example.ch.gns.alt"
They will NOT be able to resolve "example.ch.gns.Alt"
But, they may configure

.ch.gns.Alt = 

and then it is resolvable.

If the application decides that the user expectation is that "example.ch.Alt" 
IS "example.ch.alt", then the application is invited to make the user happy 
accordingly.
The same is true for subtle differences in case handlings with respect to i18n.
This is not the (GNS) protocol's business.
Is ".Alt" the same as ".alt"? => Please figure it out application developer!

Will a GNS-unaware application leak "example.ch.gns.alt" into DNS if 
"Example.ch.gns.Alt" was not found by GNS? Probably.
But it will get a NXDOMAIN if the ".alt" TLD is reserved.
Again, applications are invited to mitigate such mistakes accordingly.

I would expect that some applications that ALSO use DNS as a fallback 
resolution mechanism will consider the name as
 and check for the case-insensitive ".gns.alt" label. 
Possibly autocorrecting automatically or notifying the user.

BR


> 
> Best,
> Peter
> 
> --
> https://desec.io/
> 
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-17

[Schanzenbach, Martin]

> On 24. Aug 2022, at 18:46, Paul Wouters  wrote:
> 
> On Aug 24, 2022, at 11:27, Schanzenbach, Martin  
> wrote:
>> 
>> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and 
>> "Example.gns.alt" to be the same name.
> 
> FYI, on many mobile phones, words at the start are automatically capitalized, 
> so you are going to experience many user problems if your protocol sticks 
> with this assumption. Punting this to the application to fix up or punting it 
> to the OS to configure duplicates with case differences is going to fragment 
> how well gns works on various OSes or applications. As Security AD, if this 
> was an IETF protocol I would put up a blocking DISCUSS to address before 
> allowing the document to proceed.
> 
> A well known mistake in this area from within the IETF is that the SMTP 
> protocol considers the LHS of an email address case sensitive, so paul@ and 
> Paul@ are considered two different destinations by the protocol and the 
> entire world of SMTP servers ignore this and treats them as the same.
> 
>> But, in GNS, we would never resolve ".alt" or ".gns.alt". Those are just 
>> "suffixes".
>> 
>> GNS users (or implementors) will ship with Root Zone configurations. E.g.
>> 
>> .com.gns.alt = 
>> .ch.gns.alt = 
>> 
>> and the user will be able to resolve "example.ch.gns.alt"
>> They will NOT be able to resolve "example.ch.gns.Alt"
>> But, they may configure
>> 
>> .ch.gns.Alt = 
>> 
>> and then it is resolvable.
> 
> The average enduser isn’t going to understand or able to change any of this.
> 
>> If the application decides that the user expectation is that 
>> "example.ch.Alt" IS "example.ch.alt", then the application is invited to 
>> make the user happy accordingly.
>> The same is true for subtle differences in case handlings with respect to 
>> i18n.
>> This is not the (GNS) protocol's business.
>> Is ".Alt" the same as ".alt"? => Please figure it out application developer!
> 
> Whether I own a name now depends on the application developer? That will 
> result in endusers giving up on your application and/or protocol as well.
> 
>> Will a GNS-unaware application leak "example.ch.gns.alt" into DNS if 
>> "Example.ch.gns.Alt" was not found by GNS? Probably.
>> But it will get a NXDOMAIN if the ".alt" TLD is reserved.
> 
> Also if .alt is not reserved.
> 
>> Again, applications are invited to mitigate such mistakes accordingly.
> 
> See above. I am ….. perplexed.
> 
> Anyway, we at the IETF are not here to tell you how to do your non-IETF 
> protocol, but this discussion does feel to me that this draft isn’t very 
> useful to your protocol and also doesn’t build up my confidence that later on 
> GNS application developers are told to “help” the user with names not ending 
> in .alt, eg they end up squatting the entire DNS namespace anyway.

Well, maybe we misinterpreted the advice or took it to an extreme, but why was 
Nameprep obsoleted and according to RFC 5891 Section 3.1. (2.) talking about 
specifically NOT case folding U-labels for comparison?
I do not want to derail this conversation with this. We would theoretically 
still be convinced to change this. But that is not relevant to the original 
question.

BR

> 
> Paul
> 
> ___
> 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] [Ext] draft-ietf-dnsop-alt-tld-17

[Schanzenbach, Martin]

> On 24. Aug 2022, at 20:22, Joe Abley  wrote:
> 
> On Aug 24, 2022, at 11:27, Schanzenbach, Martin  
> wrote:
> 
>> We (I) learned that this is a good approach after conversations with our 
>> reviewers in particular since it is very difficult to distinguish what 
>> "case" actually is with respect to i18n.
> 
> Fortunately (at least as far as understanding domain names and IDNA are 
> concerned) you don't have to. A-Labels are case-insensitive in the manner 
> that "Alt" and "alt" are the same domain name. There are no such expectations 
> of U-labels.
> 
>> If the application decides that the user expectation is that 
>> "example.ch.Alt" IS "example.ch.alt", then the application is invited to 
>> make the user happy accordingly:
> 
> Sure, there are no protocol police. All applications are free to ignore user 
> expectations and standards if they want.

No, you misunderstand what I said. What I meant was:

"
In principle, an application ought to take user input of a domain
   name and convert it to the set of Unicode code points that represent
   the domain name the user intends.  As a practical matter, of course,
   determining user intent is a tricky business, so an application needs
   to choose a reasonable mapping from user input.  That may differ
   based on the particular circumstances of a user, depending on locale,
   language, type of input method, etc.  It is up to the application to
   make a reasonable choice.
" -- RFC5894

> 
> 
> Joe



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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

[Schanzenbach, Martin]

> On 24. Aug 2022, at 22:13, Schanzenbach, Martin  
> wrote:
> 
> Signed PGP part
> 
> 
>> On 24. Aug 2022, at 20:22, Joe Abley  wrote:
>> 
>> On Aug 24, 2022, at 11:27, Schanzenbach, Martin  
>> wrote:
>> 
>>> We (I) learned that this is a good approach after conversations with our 
>>> reviewers in particular since it is very difficult to distinguish what 
>>> "case" actually is with respect to i18n.
>> 
>> Fortunately (at least as far as understanding domain names and IDNA are 
>> concerned) you don't have to. A-Labels are case-insensitive in the manner 
>> that "Alt" and "alt" are the same domain name. There are no such 
>> expectations of U-labels.
>> 
>>> If the application decides that the user expectation is that 
>>> "example.ch.Alt" IS "example.ch.alt", then the application is invited to 
>>> make the user happy accordingly:
>> 
>> Sure, there are no protocol police. All applications are free to ignore user 
>> expectations and standards if they want.
> 
> No, you misunderstand what I said. What I meant was:
> 
> "
> In principle, an application ought to take user input of a domain
>   name and convert it to the set of Unicode code points that represent
>   the domain name the user intends.  As a practical matter, of course,
>   determining user intent is a tricky business, so an application needs
>   to choose a reasonable mapping from user input.  That may differ
>   based on the particular circumstances of a user, depending on locale,
>   language, type of input method, etc.  It is up to the application to
>   make a reasonable choice.
> " -- RFC5894
> 

And, to get back on topic, maybe what the alt-draft needs is a similar 
formulation with respect to handling of non-DNS .alt names for non-DNS-aware 
applications.

>> 
>> 
>> Joe
> 
> 
> 
> 



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-15.txt

[Schanzenbach, Martin]

Hi,

FWIW our draft [1] which is currently in IESG conflict review is related to 
this "issue".
Namely, the question of namespace ambiguity is discussed in it [2] as we were 
unable to register a Special-Use TLD in the past [3] (as some of you may 
remember).
There already have been discussions with the ISE regarding this property as 
well.
We currently see three options for our draft:

1. Leave it as is since it is an "informational" document and describes the 
current implementation, possibly leading to a negative conflict review response 
(?).
2. Use a special-use TLD (which would need to be requested again as per RFC 
6761 with uncertain outcome).
3. Use this approach although I am not particularly happy with the lack of a 
registry for the labels beneath ALT and the resulting length of the names.

To me, the purpose of this draft is a bit unclear if RFC6761 exists and can be 
followed and (at least in theory) we could just have special-use TLDs for 
alternative name systems (see 2.).

OTOH, although possibly a bit of sacrilege here, maybe it is also a chance to 
think about a "DNS-NG".
New alternative name systems may be specified and tested without a hard 
requirement on sub-namespaces, but a soft-requirement for namespace unambiguity 
within their deployments.
Because possibly/eventually they may be able to replace the current DNS and 
resolve its names.
For our draft, the question is if a special TLD must/should be specified along 
with the protocol specification or if we can just discuss namespace ambiguity 
and possibly use a "temporary" deployment and testing namespace (e.g. "gns.alt" 
or "whatever you want but beware the DNS dragons").

BR
Martin

[1] https://datatracker.ietf.org/doc/draft-schanzen-gns/
[2] 
https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#name-namespace-ambiguity
[3] 
https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-04

> On 27. Jun 2022, at 22:29, Michael StJohns  wrote:
> 
> It's either time to put a stake through the heart of this DNS vampire that 
> rises from the grave every 6 months, or to push it for publication.  Given 
> that in 8 years it has yet to gain enough traction for publication, perhaps 
> we de-adopt the draft back into the caring hands of its author?  E.g. - back 
> to draft-kumari-something.  Or contribute to some flowers for a final burial?
> 
> In any event, having looked at this for the first time thanks to the 
> announcement, and reading the proposed use, why isn't this reserving 
> something like "%ALT" or some other string containing an illegal DNS 
> character?
> 
> Later, Mike
> 
> 
> On 6/14/2022 3:51 AM, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the 
>> IETF.
>> 
>> Title   : The ALT Special Use Top Level Domain
>> Author  : Warren Kumari
>>  Filename: draft-ietf-dnsop-alt-tld-15.txt
>>  Pages   : 11
>>  Date: 2022-06-14
>> 
>> Abstract:
>>This document reserves a string (ALT) to be used as a TLD label in
>>non-DNS contexts.  It also provides advice and guidance to developers
>>developing alternative namespaces.
>> 
>>[Ed note: Text inside square brackets ([]) is additional background
>>information, answers to frequently asked questions, general musings,
>>etc.  They will be removed before publication.  This document is
>>being collaborated on in Github at: https://github.com/wkumari/draft-
>>wkumari-dnsop-alt-tld.  The most recent version of the document, open
>>issues, etc should all be available here.  The authors (gratefully)
>>accept pull requests. ]
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-15
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-15
>> 
>> 
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> 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] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 2. Aug 2022, at 14:39, Vladimír Čunát  wrote:
> 
> On 02/08/2022 13.53, Martin Schanzenbach wrote:
>> This is not an oversight (altough I have to admin it did not occur to me
>> that this a valid DNS TLD at the time of writing).  [...]
>> 
> Oh, I understood that this DNSOP thread - notably the first post - originated 
> as an attempt to reduce collisions between GNS pet names and DNS names.  
> Probably by standardizing .alt (or similar) as special in DNS and encouraging 
> that GNS pet names nest under it.
> 
> If I got this wrong, I suspect it might be helpful to restate the 
> DNSOP-related intentions more clearly.
> 

You understand correctly and maybe my comments are a bit too exaggerated at 
times.

The draft as it exists now has obvious collisions with the DNS namespace. A 
direct result from our previous efforts wrt RFC6761; there is just no 
sub-namespace to use for us. (See discussions years ago)
So, we mostly separated the technical protocol design from the namespace issue.
This (understandably) lead to discussions with the ISE (and others) and now 
also to (possible) issues in the IESG conflict review as part of our 
independent submission.
The idea was to connect with dnsop in order to establish if the ".alt"-draft 
could help here.
If there was a consensus over the ".alt" draft or other guidance on how to 
specify alternate name systems (and their namespaces), then I would assume this 
would affect the considerations of the conflict review and potentially require 
us to modify the draft accordingly.
Which is why we consulted with ISE whether it makes sense to participate in 
this discussion and possibly offer draft-schanzen-gns as a possible first 
"customer" of a potential new ".alt"-RFC.
So, you probably need to differentiate between the GNS draft as it is defined 
now and how it could potentially look like.
I think this is also why ISE said in another post that it may be wise to 
consider this as an opportunity to settle this issue. However, it seems quite 
entrenched.

BR
Martin

> --Vladimir | knot-resolver.cz
> 

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

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

Having now read further I am pretty convinced that the advisory is not useful 
in the context of this thread discussion.
Ist sais at the end that [1] was the "impetus" for the advisory.
However, [1] states that

"Why not use .alt?
   The proposed .alt presudo-TLD is specifically only for use as a
   pseudo-TLD for non-DNS resolution contexts.  At one point .alt was
   being considered both for DNS and non-DNS resolution contexts, but,
   after much discussion it was decided that the DNSSEC implications
   (and desired behavior) meant that .alt should be reserved
   specifically for non-DNS resolution."

and

"
Why not use something.arpa?
   This is indeed an interesting idea.  I suspect that it fails the
   semantically desirable / understandable case, but is definitely worth
   further discussion.  It may also cause issues when server operators
   override part of the .arpa domain in order to instantiate
   something.arpa.
"

So, I am pretty sure we are back to square one and this advisory (or rather its 
result) is specifically NOT meant for systems like GNS.
In fact, I would even argue that the advisory itself argues that this work is 
supposed to be done by IETF (see page 5 of the document):
"
In this document, the SSAC limits its discussion to private-use TLDs intended 
for use with the DNS protocol and for private use only. Many private-use TLDs, 
such as .onion and .gnu, do not use the DNS protocol or DNS infrastructure. The 
reservation and usage for such TLDs would require special handling and is not 
discussed in this document; there have been efforts in the IETF to address them.
"

While I must admit that I am a bit ignorant when it comes to what is considered 
official ICANN position, at least the authors of this advisory seem to think 
that private TLDs not meant for DNS resolution should be/can be/are(!) worked 
on by the IETF.

[1] 
https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00#section-3

BR

> On 2. Aug 2022, at 22:09, Martin Schanzenbach  wrote:
> 
> Signed PGP part
> I just read it and on page 5 it specifically excludes .onion and .gnu as
> those do not use the DNS protocol (citing also the alt draft here).
> So this is equivalent to the .alt draft only if the private-use TLD is
> not limited to private-use DNS queries as investigated in the document.
> I find this to be quite odd as I thought this is what .arpa was for
> (RFC8375)!
> .home is even listed in the table of the SAC document and one of the
> motivations.
> 
> So, we would have to see what the actual proposed *use* of this private
> TLD would be. If it is limited to DNS, then it is of no use for
> alternative name systems and we would still need .alt.
> 
> Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400:
>> Disclaimer: I work for the Internet Society but I am not speaking for them.
>> 
>> On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
>>> 
>>> recommends that the ICANN board to pick a string that will never be put 
>>> into the DNS root, and thus is usable for systems like GNS.
>> 
>> This was, of course, the whole point of the .alt draft in the first place, 
>> at least when I was involved in preparing it.  I don't think any of us 
>> involved then cared whether it was alt or one of thousands of other strings 
>> that it could have been.  The main point was to come up with something that 
>> would not pad total length too much and that could be a clear "protocol 
>> switch".  The registration in the IANA sutld registry was suppossed to 
>> ensure the same outcome as what is going through SSAC, but it makes no 
>> difference to me what the characters are.  Note that because of the 
>> old-timey restriction, I suspect the characters must all be alphabetic, 
>> though perhaps that rule has been superseded by IDNA.
>> 
>> A
>> 
> 
> 



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