Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Wouters]

On Oct 25, 2022, at 10:47, Ben Schwartz  
wrote:
> 
> 
> 
> My favorite idea for ".alt", as mentioned earlier, is to say something like 
> "this is the system's alternate DNS root".  Names under .alt SHOULD act 
> entirely like DNS names, except that they are not directed to the system's 
> main DNS root (which IANA fans will hope is the IANA root).  This doesn't 
> cover all the potential use cases, but it covers a lot of them, and preserves 
> some degree of technical uniformity across the DNS namespace.

I disagree strongly. The point of .alt is not to create an alternative dns 
roots.

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Mon, Oct 24, 2022 at 6:13 PM Timothy Mcsweeney 
wrote:

>
> > On 10/24/2022 10:17 AM EDT Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >
>
> > >- How might or should this be reflected in the browser bar?
> > >
> > > Personally, I would treat an "x+y://" scheme as unrelated to "x://",
> and
> > make the distinction clear to users
> >
> > >
>
>
> Does the foo+alt:// uri only go to the .alt non-dns namespace?  or does it
> go to both dns and non-dns namespces at the same time?
>

My feeling was that "foo+alt:" does whatever the "foo+alt" URI handler
wants.  "alt" means "escape from the standards process at this point", so
while this scheme might be analogous to "foo:" in some fashion, the nature
of the analogy is not standardized.  (As Eliot pointed out, this may not be
the best way to make use of scheme extensions.)

My main point is: the TLD isn't the only place we can put an escape hatch.
(Brian Dickson identified yet another.)  I think that gives us the freedom
to be more prescriptive about what ".alt" is for.  It doesn't have to be a
universal escape hatch.

My favorite idea for ".alt", as mentioned earlier, is to say something like
"this is the system's alternate DNS root".  Names under .alt SHOULD act
entirely like DNS names, except that they are not directed to the system's
main DNS root (which IANA fans will hope is the IANA root).  This doesn't
cover all the potential use cases, but it covers a lot of them, and
preserves some degree of technical uniformity across the DNS namespace.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

"libor.peltan"  writes:

> On the other hand, I agree that an analysis of how heavily the Root
> Server could potentially be impacted by stray .alt queries would be 
> beneficial for deciding if we need to implement a defense and how. But
> I doubt this is possible to estimate.

Well, we do have some past examples of other strange things to call
upon.  There was some oddness with increase queries during the DNSKEY
roll [1].  Then there was the chromium random DNS query string usage,
which I first spoke about at DNS-OARC in 2019 [2] and VeriSign later
wrote about in 2020 [3].  My guess is that queries for .alt would be
less than the chromium "feature", since negative answers for .alt would
be cached by resolvers at least unlike the random unique strings from
Chromium.

Footnotes:
[1]  http://doi.acm.org/10.1145/3355369.3355570
[2]  https://youtu.be/sh9Bbk_1bMQ?t=1365
[3]  https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[libor.peltan]

Dne 24. 10. 22 v 20:18 David Conrad napsal(a):

Libor,

On Oct 24, 2022, at 9:11 AM, libor.peltan  wrote:

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

Well, the modern and well-configured resolvers will protect Root servers by employing 
Aggresive Negative Caching or Root Zone Prefetch (and eventually Query Name Minimisation 
for the sake of querier's privacy); outdated and broken resolvers will keep bombing the 
root's auths with junk queries even if we declare they MUST NOT. As a consequence, those 
arguments for this "MUST NOT" are moot.

We appear to be arguing about wording/capitalization.

I don't think so.


Obviously, simply saying “MUST NOT” in an RFC will have (and has always had) 
zero effect on code behaviors. What matters is what people actually implement. 
If a modern/well-configured iterative resolver/forwarder implements according 
to (the potential future) spec (either “MUST NOT” or “should not”), then all 
queries for .alt sent by outdated/broken stub resolvers will not bomb the root 
as soon as the modern code is deployed.  As applications/operating systems get 
updated over time, even the stub resolvers could behave better.  However, 
implementation of code is all about priorities. I personally believe that, in 
general, a spec that says “MUST NOT” has a slightly higher likelihood of being 
prioritized over a spec that says “should not” but maybe that’s just me.
So far, the modern features like Aggresive Negative Caching and Root 
Zone Prefetch (hereinafter: (*)) are already standardized and being 
implemented by a (hopefully) raising fraction of resolvers. Do you think 
that if we now standardize this explicit blockade of specific TLD for 
resolvers, it will get implemented much faster and broadlier than (*) 
and protect the Root zone in the meantime before (*) is implemented 
sufficiently close-to-everywhere?


The real point here is #3 in the list I provided earlier:

"3) whether the inevitable leakage of .alt queries to the DNS represent potential 
issues, and if so, should there be an effort to address those issues."

Using the AS112 project approach could help address the leakage to the root 
issue (even for outdated/broken resolvers), although it wouldn’t generally 
address the privacy leakage issue. It also has its own implications (e.g., 
delegating an explicitly non-DNS TLD in the DNS). Given the AS112 approach 
doesn’t result in code change, would you be ok with using it with .alt?


I don't like neither lame delegation of non-DNS name in DNS Root Zone, 
nor lame DNAME therein.



I would expect the correct approach is:

1) Put a proper MUST NOT into the piece of software that will be 
responsible for determining DNS and non-DNS queries. It should prevent 
query leakage into DNS as much as possible.


2) If it doesn't, the resolver should be able to avoid any lame queries 
(not limited to .alt) to Root zone with the help of (*). We don't need 
any RFC for this -- this already happens, and frankly: if Quad8 
implements this, half of the problem is gone.


3) If it doesn't, the Root servers shall be solid enough to withstand a 
stream of lame queries (not limited to .alt). We don't need and RFC for 
this, this already happens.



On the other hand, I agree that an analysis of how heavily the Root 
Server could potentially be impacted by stray .alt queries would be 
beneficial for deciding if we need to implement a defense and how. But I 
doubt this is possible to estimate.




Regards,
-drc


Libor

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Timothy Mcsweeney]

> On 10/24/2022 10:17 AM EDT Ben Schwartz  
> wrote:
> 

> >- How might or should this be reflected in the browser bar?
> >
> > Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
> 
> >


Does the foo+alt:// uri only go to the .alt non-dns namespace?  or does it go 
to both dns and non-dns namespces at the same time?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 24, 2022, at 1:23 PM, Brian Dickson  
wrote:
> What this points out is that ".alt" is intended to protect DNS (at the root 
> at least) from the effects of other namespaces.

This seems quite inaccurate. Where in the current draft does it hint at that 
statement? If it is there, we should certainly remove it.

> It is not (or at least has not been explicitly established for) use by other 
> namespaces to protect themselves from errors like this.

Yes, definitely.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Brian Dickson]

On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters  wrote:

> On Mon, 24 Oct 2022, Brian Dickson wrote:
>
> > Just to expand on this idea (which I quite like), the original AS112 was
> enhanced to handle new/arbitrary names, so
> > that AS112 operators don't need to do anything to support being a sink
> for new domains.
> >
> > This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
> target for use via DNAME.
> > (The DNAME bit is so there isn't a delegation for which the AS112
> operator would need to have a zone configured.)
> >
> > Using this via the root zone would be a new kind of entry for the root
> zone, but is otherwise non-controversial
> > (IMHO).
> > It would basically look like:
> >   alt. DNAME empty.as112.arpa
>
> this is dangerous. Anyone who runs an as112 node, or an attacker who
> compromises one, can then serve a "real" .alt to a percentage of
> queriers. Imagine millions being lost in some cryptocurrency .alt
> non-dns scheme.
>
>
This is accurate. It is dangerous to other namespaces if they don't take
appropriate safeguards.

What this points out is that ".alt" is intended to protect DNS (at the root
at least) from the effects of other namespaces.

It is not (or at least has not been explicitly established for) use by
other namespaces to protect themselves from errors like this.

In the jargon of mathematics, "alt" is necessary, but not sufficient.

Any namespace that would fall under the "please use .alt" umbrella, would
be wise to build into the protocol(s) or implementation(s) some guard-rails
against leakage.

So, another reason for "MUST NOT", but perhaps out of scope for dnsop
itself to say (other than to indicate,  "here be dragons".)

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Mon, Oct 24, 2022 at 12:47 PM Timothy Mcsweeney 
wrote:
...

> You can't use the "+" in the scheme component of the uri scheme.  It's a
> reserved sub-delim.
>

RFC 3986, Section 3.1:

   Scheme names consist of a sequence of characters beginning with a
   letter and followed by any combination of letters, digits, plus
   ("+"), period ("."), or hyphen ("-").

Worked example: https://www.rfc-editor.org/rfc/rfc8323.html#section-8

I'm not a URI expert but that seems pretty clear.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[paul=40redbarn . org]

Either we worry about impact on the root servers and consider not reserving the 
name at all because of infinite peaks through ignorance of legacy software... 


... Or we worry about it and consider doing something about it and decide 
whether what we can do will be good enough ... 


... Or we just decide not to worry about it at all. 


We should choose exactly one of those paths. Right now the debate has them all 
in a blender set to Frappe. 


p vixie 


On Oct 24, 2022 12:09, Paul Hoffman  wrote: 

The discussion about AS112 changes the document from "don't ever put this in 
the root zone" to "put this in the root zone this special way". 

I believe the former is wy easier than the latter, particularly for the 
very limited used we expect this name to have. 

--Paul Hoffman 

___ 
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] [Ext] Possible alt-tld last call?

[Paul Wouters]

On Mon, 24 Oct 2022, Brian Dickson wrote:


Just to expand on this idea (which I quite like), the original AS112 was 
enhanced to handle new/arbitrary names, so
that AS112 operators don't need to do anything to support being a sink for new 
domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa" target 
for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator 
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root zone, 
but is otherwise non-controversial
(IMHO).
It would basically look like: 
  alt. DNAME empty.as112.arpa


this is dangerous. Anyone who runs an as112 node, or an attacker who
compromises one, can then serve a "real" .alt to a percentage of
queriers. Imagine millions being lost in some cryptocurrency .alt
non-dns scheme.

Paul

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

The discussion about AS112 changes the document from "don't ever put this in 
the root zone" to "put this in the root zone this special way".

I believe the former is wy easier than the latter, particularly for the 
very limited used we expect this name to have.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Wes,

Mumble. I said I wasn’t going to argue the politics further, but…

On Oct 24, 2022, at 10:49 AM, Wes Hardaker  wrote:
> David Conrad  writes:
>>whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> So, the
> decision made at the time was: once the WG has concluded that something
> is a good idea (a draft passes WG last call), *then* it seems like the
> right time to send a message to ICANN about our plans.

There are really 2 questions here, the second dependent on the first:

1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory; and 
(if not)
2) whether .alt is a good label to reserve.

It makes perfect sense to me to ask the second question after WG LC.  Not 
getting resolution on the first question means the risk of wasting everybody’s 
time if the answer to that question turns out to be “yes.”  Another formulation 
for the first question could be “How or by what process can the IETF and ICANN 
work together to further partition the domain name namespace to meet bona fide 
technical use cases that weren’t envisioned under the ICANN generic TLD model?” 
 The IETF/IAB “sending a message” stating “we’re going to do this, do you have 
any comment” never stuck me as a particularly healthy way to interact.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Joe Abley]

Op 24 okt. 2022 om 14:18 heeft David Conrad  het volgende 
geschreven:

> Given the AS112 approach doesn’t result in code change, would you be ok with 
> using it with .alt?

As Brian mentioned, there are two AS112 approaches. One involves some amount of 
lame delegation, and the other involves DNAME in the root zone. 

I think DNAME in the root zone is a lovely idea and I would very much like to 
see some junk queries handled that way, but it's worth remembering that it does 
involve a new and exciting RRTYPE in the root zone and presumably, therefore, 
multiple years of meetings before it can happen, because Root Zone.

Perhaps there's no rush and meetings are fine. 

I also think trying hard not to send the queries and simultaneously 
acknowledging that there will be some mess so we still need to stock up on 
cleaning supplies is fine. I don't think code changes and as112 are mutually 
exclusive. We can do both. 

All this sounds like a lot of work for something that I think will wind up 
being quite useless, but it would hardly be the first time that has happened. 


Joe

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Libor,

On Oct 24, 2022, at 9:11 AM, libor.peltan  wrote:
>> The root of the DNS is a commons, supported by volunteers who are paying out 
>> of their own pocket to provision a global infrastructure. I’m personally not 
>> comfortable recommending techniques that can add undefined (could be 
>> minimal, might not be: no one knows for sure) load to that infrastructure.
> Well, the modern and well-configured resolvers will protect Root servers by 
> employing Aggresive Negative Caching or Root Zone Prefetch (and eventually 
> Query Name Minimisation for the sake of querier's privacy); outdated and 
> broken resolvers will keep bombing the root's auths with junk queries even if 
> we declare they MUST NOT. As a consequence, those arguments for this "MUST 
> NOT" are moot.

We appear to be arguing about wording/capitalization.

Obviously, simply saying “MUST NOT” in an RFC will have (and has always had) 
zero effect on code behaviors. What matters is what people actually implement. 
If a modern/well-configured iterative resolver/forwarder implements according 
to (the potential future) spec (either “MUST NOT” or “should not”), then all 
queries for .alt sent by outdated/broken stub resolvers will not bomb the root 
as soon as the modern code is deployed.  As applications/operating systems get 
updated over time, even the stub resolvers could behave better.  However, 
implementation of code is all about priorities. I personally believe that, in 
general, a spec that says “MUST NOT” has a slightly higher likelihood of being 
prioritized over a spec that says “should not” but maybe that’s just me.

The real point here is #3 in the list I provided earlier:

"3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues."

Using the AS112 project approach could help address the leakage to the root 
issue (even for outdated/broken resolvers), although it wouldn’t generally 
address the privacy leakage issue. It also has its own implications (e.g., 
delegating an explicitly non-DNS TLD in the DNS). Given the AS112 approach 
doesn’t result in code change, would you be ok with using it with .alt?

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

David Conrad  writes:

> whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
>
> After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison
> discuss this.  My current expectation is that we probably will send ICANN 
> a
> liaison to politely let them know what we are doing, so that they have the
> opportunity to comment, and we would consider any feedback that they give,
> returning the document back to the WG, if needed.
> 
> I guess that’s marginally better than what the IETF did with RFC 6762 (i.e.,
> publish the RFC ‘reserving’ a TLD then, a year and a half later, issue the
> liaison statement to invite discussion). The reluctance to ask the question 
> still
> seems silly to me, particularly if one wishes to maintain good relations, but
> this is clearly deep into the political sphere so I won’t bother arguing 
> further.

Hi David,



The IAB discussed a while back about "when" to send a statement to the
ICANN board about this issue.  The decision was that if the WG didn't
have consensus yet (we have a bit more of one now than then), it sure
seem appropriate to send ICANN a note with a "maybe we might if we can
ever come to internal agreement".  In other words, it's just wasting
their time if we haven't even decided something is a good idea.  So, the
decision made at the time was: once the WG has concluded that something
is a good idea (a draft passes WG last call), *then* it seems like the
right time to send a message to ICANN about our plans.

That being said, the IAB is also aware of this issue and will be further
discussing it in the next few weeks.  If you wish to make arguments
about why the previous decision about whether the question should be
asked immediately, and what the nature of that question should be: I'm
all ears and will pass it on (at least in aggregated consensus form)
during future IAB discussions.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Brian Dickson]

On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie  wrote:

>
>
> David Conrad wrote on 2022-10-23 12:00:
> > Rob,
>
> not rod, but i have three comments.
>
> > On this mailing list, I think there is a pretty good understanding of
> > the intent of .alt and I don’t think there is much in the way of
> > disagreement on that intent. As far as I can tell, the points of
> > contention are:
> >
> > 1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> > 2) whether there will be a registry of .alt uses (i.e., non-DNS name
> > resolution systems) and if so, who will operate that registry.
> > 3) whether the inevitable leakage of .alt queries to the DNS represent
> > potential issues, and if so, should there be an effort to address those
> > issues.
>
> first, +1 to the above and to the elided text formerly below.
>
> second, it's worth a bit of puttering to figure out how to prevent more
> pollution (queries of non-DNS namespaces or non-global-DNS namespaces)
> from hitting the root. delegating .ALT the same way 10.in-addr.arpa is
> delegated (prisoner.iana.org and so on) may be a fine idea.
>
>
Just to expand on this idea (which I quite like), the original AS112 was
enhanced to handle new/arbitrary names, so that AS112 operators don't need
to do anything to support being a sink for new domains.

This was done in RFC7534 and RFC7535, using the new "empty.as112.arpa"
target for use via DNAME.
(The DNAME bit is so there isn't a delegation for which the AS112 operator
would need to have a zone configured.)

Using this via the root zone would be a new kind of entry for the root
zone, but is otherwise non-controversial (IMHO).
It would basically look like:

alt. DNAME empty.as112.arpa

Any query for foo.alt would be rewritten by the resolver doing resolution
to foo.empty.as112.arpa, which would result in an NXDOMAIN from the
topologically closest AS112 instance.

(Separate conversation that might be time to raise: is it time to sign
empty.as112.arpa, so these NXDOMAIN results have full DNSSEC proofs, and to
enable aggressive NSEC support on resolvers?)

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 24, 2022, at 2:13 AM, Rob Wilton (rwilton)  wrote:
>> whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison 
> discuss this.  My current expectation is that we probably will send ICANN a 
> liaison to politely let them know what we are doing, so that they have the 
> opportunity to comment, and we would consider any feedback that they give, 
> returning the document back to the WG, if needed.

I guess that’s marginally better than what the IETF did with RFC 6762 (i.e., 
publish the RFC ‘reserving’ a TLD then, a year and a half later, issue the 
liaison statement to invite discussion). The reluctance to ask the question 
still seems silly to me, particularly if one wishes to maintain good relations, 
but this is clearly deep into the political sphere so I won’t bother arguing 
further.

> If [identifying/dealing with leakage] is a general problem for “special use” 
> TLDs then it would be better to have a separate document that handles those 
> consistently and generically rather than creating a new rule specifically for 
> .alt domains.

I personally believe it is (and maybe Paul Vixie’s idea of using the 
prisoner.iana.org  approach is worth exploring).

> This is a reasonable point to consider, even though it also feels like the 
> world may end up moving to DoH, or DoQ fairly quickly.

I’ll admit skepticism.

> Personally, I think that it is somewhat hard for users to have that general 
> expectation if the name resolution is using a combination of name resolution 
> protocols (including unencrypted DNS).

I agree, however I thought the point of the Security Considerations section was 
to make implementors aware of potential security “gotchas” they or their users 
may experience as a result of implementation. Pointing out that regardless of 
what security/privacy assertions a new non-DNS name resolution system may make, 
unless both parties in communication are participating in that new system, 
security/privacy may be compromised seems like a useful “gotcha” to note.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Timothy Mcsweeney]

> On 10/24/2022 10:17 AM EDT Ben Schwartz  
> wrote:
> 
> >- How might or should this be reflected in the browser bar?
> >
> > Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
> make the distinction clear to users
> 


You can't use the "+" in the scheme component of the uri scheme.  It's a 
reserved sub-delim.

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[libor.peltan]

Hi,

Dne 23. 10. 22 v 21:00 David Conrad napsal(a):


The root of the DNS is a commons, supported by volunteers who are 
paying out of their own pocket to provision a global infrastructure. 
I’m personally not comfortable recommending techniques that can add 
undefined (could be minimal, might not be: no one knows for sure) load 
to that infrastructure.


Well, the modern and well-configured resolvers will protect Root servers 
by employing Aggresive Negative Caching or Root Zone Prefetch (and 
eventually Query Name Minimisation for the sake of querier's privacy); 
outdated and broken resolvers will keep bombing the root's auths with 
junk queries even if we declare they MUST NOT. As a consequence, those 
arguments for this "MUST NOT" are moot.


I personally don't like any suggestions that recursive and/or 
authoritative server software has some hard-wired handling of special 
TLDs. Especially (but not limited to!) RFC7686 (.onion), which requires 
even non-root auth servers to answer NXDOMAIN for names out of their 
configured bailiwicks (which is being ignored by auth software vendors 
AFAIK).


Libor

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear  wrote:

> Hi Ben and Wes,
> On 21.10.22 20:45, Ben Schwartz wrote:
>
>
> Rather than placing "alt" in the TLD position, I think it might be better
> as a scheme modifier: https+alt://...  This is a common pattern  for
> modifications to URI schemes (c.f. git+ssh://), and informs the software
> that this URI is special without overloading the DNS namespace.
>
> How would this work in practice?
>
Thinking about this more, I can imagine having both "+alt" and ".alt".  In
this world, ".alt" would be for "the system's alternate DNS root",
providing DNS-equivalent functionality but not in IANA-controlled space.
"+alt" would be for "the system's alternative interpretations of URI
schemes", with no further requirement that the authority be domain-shaped
at all.

>
>- Would this require a re-registering of each and every URI scheme
>with +alt, and monitoring the URI scheme registry for new ones?
>
>  I don't think so.  We could define it as a universal scheme modifier.

>
>-   (I'll note that git+ssh isn't registered.)
>
> Unfortunately, most URI schemes outside of the RFC process are not
registered.  I think there's a general lack of awareness that registration
is required or easy.

>
>- What is the value of +alt at this point?  Why not use +gns or +onion
>or +eliotsfavoritenamespace?
>
> That sounds like a very intriguing idea, and might be better than +alt.

>
>- How might or should this be reflected in the browser bar?
>
> Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
make the distinction clear to users

>


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Rob Wilton (rwilton)]

Hi David,

Thanks, again with no hats, except for my comment on the first question.  
Please see inline …

From: David Conrad 
Sent: 23 October 2022 20:01
To: Rob Wilton (rwilton) 
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?

Rob,

On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

As I read it, the partitioning of the domain name namespace is really to 
achieve two aims:

On this mailing list, I think there is a pretty good understanding of the 
intent of .alt and I don’t think there is much in the way of disagreement on 
that intent. As far as I can tell, the points of contention are:


  1.  whether the IETF “reserving” a TLD is intruding on ICANN’s territory.

RW:
With a “responsible AD for this document hat on”, I would like to ask the WG to 
consider this question as being out of scope for the moment, and assume that 
this work is within the scope of the IETF.  After WG LC, I propose that the WG 
chairs, ADs, IAB, and ICANN liaison discuss this.  My current expectation is 
that we probably will send ICANN a liaison to politely let them know what we 
are doing, so that they have the opportunity to comment, and we would consider 
any feedback that they give, returning the document back to the WG, if needed.


  1.  whether there will be a registry of .alt uses (i.e., non-DNS name 
resolution systems) and if so, who will operate that registry.

RW:
The document should only define a registry of .alt uses if the registry is 
managed by IANA.


3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues.

RW:
I’ll defer answering that one to the experts, on which I am not one.


FWIW, my views:

1) Ask the stupid question.
2) A voluntary, lightweight registry operated by IANA can help developers avoid 
collision.
3) Identifying leakage to the DNS as a protocol violation can, over time, help 
reduce that leakage.

This is outside my area of expertise, but I'm not convinced that the global DNS 
would see any significant increase in load, because the stub resolver would 
generally not be sending the requests to the DNS assuming that they are valid 
domains, and if they are not valid domains then that would seem to be the same 
as what DNS already handles today.

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

If you look at the ICANN OCTO web page Paul referenced earlier 
(https://magnitude.research.icann.org) and filter for “special use” TLDs, 
you’ll see data related to the number of queries received.  Some of those 
(e.g., .local) are non-trivial and, in my opinion, are indications of 
brokenness that should be fixed — the root shouldn’t be seeing those queries. 
My suggestion of using RFC 2119 “MUST NOT” language (i.e., queries for names in 
.alt MUST NOT be sent to the root server system supported by IANA) is in an 
effort to discourage an increase in that query volume over time.

RW:
If this is a general problem for “special use” TLDs then it would be better to 
have a separate document that handles those consistently and generically rather 
than creating a new rule specifically for .alt domains.


It seems obvious to me that if a namespace is explicitly defined to not be in 
the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
actually surprised that this would be controversial.

And as for the eavesdropping concern, doesn't this equally apply for all domain 
lookups, particularly invalid ones?

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
resolution protocol is specified to not be plain text (presumably any new 
protocol would be encrypted), then users of that protocol have an expectation 
that their queries are protected.  By falling back to DNS, that expectation is 
silently violated.

RW:
This is a reasonable point to consider, even though it also feels like the 
world may end up moving to DoH, or DoQ fairly quickly. Personally, I think that 
it is somewhat hard for users to have that general expectation if the name 
resolution is using a combination of name resolution protocols (including 
unencrypted DNS).

Regards,
Rob


Regards,
-drc

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 23, 2022, at 1:27 PM, Paul Hoffman  wrote:
>> 1) Ask the stupid question.
> Again? It has already been answered many times in the negative. There are 
> even RFCs about it. Asking it again is a waste of people's time.

I’m unaware. Could you point me to the ICANN Board resolution, statement from 
the GNSO, and/or a position from the ICANN CEO on the issue?

>> 2) A voluntary, lightweight registry operated by IANA can help developers 
>> avoid collision.
> True, if we care about collision in namespaces we don't control. I certainly 
> don't care about those namespaces.

OK, but others may. As a precedent: https://www.iana.org/time-zones 
.

>> 3) Identifying leakage to the DNS as a protocol violation can, over time, 
>> help reduce that leakage.
> True, but so what? It is leakage from namespaces we don't control, and 
> many/most of us don't care about them.

I would’ve thought we'd care about (and try to discourage) the leakage into the 
DNS as a result of IETF action.

>> The root of the DNS is a commons, supported by volunteers who are paying out 
>> of their own pocket to provision a global infrastructure. I’m personally not 
>> comfortable recommending techniques that can add undefined (could be 
>> minimal, might not be: no one knows for sure) load to that infrastructure.
> I'm personally happy to defer this to those volunteers instead of speaking 
> for them.

OK. Could you point me to the statement by the RSOs on the topic?

> In the past, they have said that the amount of leakage is not of concern to 
> them, and there is no indication that .alt will increase it perceptibly.

Given the root server infrastructure is shared across the entire Internet 
globally, in the past, the DNS operational community has gone to significant 
efforts in relation to proposed changes that could conceivably affect the load 
on the root servers, e.g., deploying IPv6 or DURZ, even when there was no 
assurance or even a common belief that there would be a perceptible negative 
impact.

But this is somewhat irrelevant: what we’re talking about here is specific 
wording that tries to more strongly discourage traffic going to the root, i.e., 
'MUST NOT’ instead of ‘should not’. I’m confused why such wording would be 
considered controversial.

> I can't tell from this paragraph if you realize that the example you gave 
> (.local) already has a SHOULD NOT for resolvers.

Yep, I’m aware.  I don’t think repeating mistakes is a good idea.

> Are you saying that updating RFC 6762 to make it a MUST NOT would have any 
> noticeable effect?

Are you saying you think it would hurt?  I’m hopeful in the long term, it would 
have a positive impact.

>> It seems obvious to me that if a namespace is explicitly defined to not be 
>> in the DNS, embedding a reliance on the DNS would be a protocol violation.  
>> I am actually surprised that this would be controversial.
> Can you say what you mean by "reliance on the DNS"? Defining .alt as a name 
> that won't appear in the root zone does not have any reliance on the DNS.

For applications that are misconfigured, instead of blocking at the resolver, 
you appear to be arguing queries should use the DNS protocol to query the root 
servers to (presumably) return an NXDOMAIN. I consider this a protocol 
violation, and as such, I think it appropriate to use language that suggests 
implementors must not do that.

>>> And as for the eavesdropping concern, doesn't this equally apply for all 
>>> domain lookups, particularly invalid ones?
>> As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
>> resolution protocol is specified to not be plain text (presumably any new 
>> protocol would be encrypted), then users of that protocol have an 
>> expectation that their queries are protected.
> Why on earth would those users think that?

E.g., "GNS is a decentralized and censorship-resistant domain name resolution 
protocol that provides a *privacy-enhancing* alternative to the Domain Name 
System (DNS) protocols.” (second sentence of the abstract of 
https://lsd.gnunet.org/lsd0001/ , emphasis 
added).  Now, what happens on a machine that is unaware of GNS responds to 
(say) an email from paul@secret_name.alt  (and if 
you don’t think that’s a privacy violation, then what’s the point of DoH/DoT)?

> If the proponents of the non-DNS name resolution protocol suggest that to 
> them, then those proponents are simply lying.


Or, more charitably, they are making an assumption about the environment in 
which the non-DNS name resolution protocol operates.  Pointing this out in the 
Security Considerations section seems like a no-brainer to me.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 23, 2022, at 12:00 PM, David Conrad  wrote:
> On this mailing list, I think there is a pretty good understanding of the 
> intent of .alt and I don’t think there is much in the way of disagreement on 
> that intent. As far as I can tell, the points of contention are:
> 
> 1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
> 2) whether there will be a registry of .alt uses (i.e., non-DNS name 
> resolution systems) and if so, who will operate that registry.
> 3) whether the inevitable leakage of .alt queries to the DNS represent 
> potential issues, and if so, should there be an effort to address those 
> issues.
> 
> FWIW, my views:
> 
> 1) Ask the stupid question. 

Again? It has already been answered many times in the negative. There are even 
RFCs about it. Asking it again is a waste of people's time. 

> 2) A voluntary, lightweight registry operated by IANA can help developers 
> avoid collision.

True, if we care about collision in namespaces we don't control. I certainly 
don't care about those namespaces.

> 3) Identifying leakage to the DNS as a protocol violation can, over time, 
> help reduce that leakage.

True, but so what? It is leakage from namespaces we don't control, and 
many/most of us don't care about them.

> 
>> This is outside my area of expertise, but I'm not convinced that the global 
>> DNS would see any significant increase in load, because the stub resolver 
>> would generally not be sending the requests to the DNS assuming that they 
>> are valid domains, and if they are not valid domains then that would seem to 
>> be the same as what DNS already handles today.
> 
> The root of the DNS is a commons, supported by volunteers who are paying out 
> of their own pocket to provision a global infrastructure. I’m personally not 
> comfortable recommending techniques that can add undefined (could be minimal, 
> might not be: no one knows for sure) load to that infrastructure.

I'm personally happy to defer this to those volunteers instead of speaking for 
them. In the past, they have said that the amount of leakage is not of concern 
to them, and there is no indication that .alt will increase it perceptibly.

> If you look at the ICANN OCTO web page Paul referenced earlier 
> (https://magnitude.research.icann.org) and filter for “special use” TLDs, 
> you’ll see data related to the number of queries received.  Some of those 
> (e.g., .local) are non-trivial and, in my opinion, are indications of 
> brokenness that should be fixed — the root shouldn’t be seeing those queries. 
> My suggestion of using RFC 2119 “MUST NOT” language (i.e., queries for names 
> in .alt MUST NOT be sent to the root server system supported by IANA) is in 
> an effort to discourage an increase in that query volume over time. 

I can't tell from this paragraph if you realize that the example you gave 
(.local) already has a SHOULD NOT for resolvers. Are you saying that updating 
RFC 6762 to make it a MUST NOT would have any noticeable effect?

> It seems obvious to me that if a namespace is explicitly defined to not be in 
> the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
> actually surprised that this would be controversial.

Can you say what you mean by "reliance on the DNS"? Defining .alt as a name 
that won't appear in the root zone does not have any reliance on the DNS. 

>> And as for the eavesdropping concern, doesn't this equally apply for all 
>> domain lookups, particularly invalid ones?
> 
> As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
> resolution protocol is specified to not be plain text (presumably any new 
> protocol would be encrypted), then users of that protocol have an expectation 
> that their queries are protected.  

Why on earth would those users think that? If the proponents of the non-DNS 
name resolution protocol suggest that to them, then those proponents are simply 
lying.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

David Conrad wrote on 2022-10-23 12:00:

Rob,


not rod, but i have three comments.

On this mailing list, I think there is a pretty good understanding of 
the intent of .alt and I don’t think there is much in the way of 
disagreement on that intent. As far as I can tell, the points of 
contention are:


1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name 
resolution systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those 
issues.


first, +1 to the above and to the elided text formerly below.

second, it's worth a bit of puttering to figure out how to prevent more 
pollution (queries of non-DNS namespaces or non-global-DNS namespaces) 
from hitting the root. delegating .ALT the same way 10.in-addr.arpa is 
delegated (prisoner.iana.org and so on) may be a fine idea.


third, in recognition of this concern:

... 

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS 
name resolution protocol is specified to not be plain text (presumably 
any new protocol would be encrypted), then users of that protocol have 
an expectation that their queries are protected.  ...


implementation guidance contained in the .ALT "specification" should 
include the need to detect ".ALT" from the right hand side before 
deciding whether or not to do special non-DNS processing on the 
remaining left hand side. this is because the non-DNS syntax on the left 
hand side might include .ALT for other reasons, or may use "." 
differently than DNS would do. this is messy but inevitable given that 
DNS camped on to the entire domain namespace in its earliest days.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton)  wrote:
> As I read it, the partitioning of the domain name namespace is really to 
> achieve two aims:


On this mailing list, I think there is a pretty good understanding of the 
intent of .alt and I don’t think there is much in the way of disagreement on 
that intent. As far as I can tell, the points of contention are:

1) whether the IETF “reserving” a TLD is intruding on ICANN’s territory.
2) whether there will be a registry of .alt uses (i.e., non-DNS name resolution 
systems) and if so, who will operate that registry.
3) whether the inevitable leakage of .alt queries to the DNS represent 
potential issues, and if so, should there be an effort to address those issues.

FWIW, my views:

1) Ask the stupid question.
2) A voluntary, lightweight registry operated by IANA can help developers avoid 
collision.
3) Identifying leakage to the DNS as a protocol violation can, over time, help 
reduce that leakage.

> This is outside my area of expertise, but I'm not convinced that the global 
> DNS would see any significant increase in load, because the stub resolver 
> would generally not be sending the requests to the DNS assuming that they are 
> valid domains, and if they are not valid domains then that would seem to be 
> the same as what DNS already handles today.

The root of the DNS is a commons, supported by volunteers who are paying out of 
their own pocket to provision a global infrastructure. I’m personally not 
comfortable recommending techniques that can add undefined (could be minimal, 
might not be: no one knows for sure) load to that infrastructure.

If you look at the ICANN OCTO web page Paul referenced earlier 
(https://magnitude.research.icann.org ) 
and filter for “special use” TLDs, you’ll see data related to the number of 
queries received.  Some of those (e.g., .local) are non-trivial and, in my 
opinion, are indications of brokenness that should be fixed — the root 
shouldn’t be seeing those queries. My suggestion of using RFC 2119 “MUST NOT” 
language (i.e., queries for names in .alt MUST NOT be sent to the root server 
system supported by IANA) is in an effort to discourage an increase in that 
query volume over time.

It seems obvious to me that if a namespace is explicitly defined to not be in 
the DNS, embedding a reliance on the DNS would be a protocol violation.  I am 
actually surprised that this would be controversial.

> And as for the eavesdropping concern, doesn't this equally apply for all 
> domain lookups, particularly invalid ones?

As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name 
resolution protocol is specified to not be plain text (presumably any new 
protocol would be encrypted), then users of that protocol have an expectation 
that their queries are protected.  By falling back to DNS, that expectation is 
silently violated.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Martin Schanzenbach wrote on 2022-10-23 04:34:

...
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?


yes.


It is as if we are chasing a moving target where the primary point of
contention always seems to escape us. The goalpost seems to be moving.


building a standards and innovation community out of humans has 
predictable downsides.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Martin Schanzenbach]

On 21.10.22 18:48, Tim Wicinski wrote:
> >
> >
> > Rather than placing "alt" in the TLD position, I think it might be better
> > as a scheme modifier: https+alt://...  This is a common pattern  for
> > modifications to URI schemes (c.f. git+ssh://), and informs the software
> > that this URI is special without overloading the DNS namespace.
> >
> >
> Not putting any hat on, I do like Ben's https+alt:// URI suggestion.
> 
> As a chair, if we see enough interest in this, the WG should find consensus
> 

I am actually surprised by this as the primary concern reason for
a possible conflict was that the names in GNS and DNS can be conflated
by the user.
Name notion of a "user expectation" for names was thrown around a lot.
Using +alt://example.com or +gns://example.com is
actually making it worse with respect to that aspect than .alt as SUTLD, no?
It is as if we are chasing a moving target where the primary pont of
contention always seems to escape us. The goalpost seems to be moving.

BR


> tim

> ___
> 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] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Ben and Wes,

On 21.10.22 20:45, Ben Schwartz wrote:


Rather than placing "alt" in the TLD position, I think it might be 
better as a scheme modifier: https+alt://...  This is a common 
pattern  for modifications to URI schemes (c.f. git+ssh://), and 
informs the software that this URI is special without overloading the 
DNS namespace.


How would this work in practice?

 * Would this require a re-registering of each and every URI scheme
   with +alt, and monitoring the URI scheme registry for new ones? 
   (I'll note that git+ssh isn't registered.)
 * What is the value of +alt at this point?  Why not use +gns or +onion
   or +eliotsfavoritenamespace?
 * How might or should this be reflected in the browser bar?

That last question probably has no pat answer, which is okay so long as 
we are clear that it does not.


Eliot



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Rob Wilton (rwilton)]

Hi David,

[Still with no hats]

> -Original Message-
> From: David Conrad 
> Sent: 22 October 2022 17:40
> To: Rob Wilton (rwilton) 
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?
> 
> Rob,
> 
> On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton)  wrote:
> > If this was a MUST NOT, then at the point that the RFC is published, would
> that not mean that all DNS stub (and maybe recursive) resolvers immediately
> become non complaint with the new standard?
> 
> The draft says “Informational”.  It is (maybe) recommending the partitioning 
> of
> the domain name namespace, explicitly creating a sub-space that is for non-
> DNS use.  It makes no sense to me to then pretend it’s "just fine” to issue 
> DNS
> queries in that sub-namespace.

As I read it, the partitioning of the domain name namespace is really to 
achieve two aims:
 1) to guarantee that .alt, and no domains under .alt, will ever exist in the 
DNS, and hence it will need be impossible for an alternative name resolution 
system to "shadow" valid .alt entries in the DNS (since there can be none).
 2) it gives a place to experiment with alternative naming systems in a way 
that doesn't interfere with the DNS.

As I understand it , some of these alternative name services are squatting on 
unallocated TLDs, and some browsers are resolving names in these alternative 
name services.  This is not ideal, particularly if those unallocated TLDs end 
up getting sold by ICANN to companies that expect to use them with the regular 
DNS rather than any alternative name service.


> 
> > My interpretation of Paul's comment is that nothing bad happens if a client
> does attempt to resolve .alt names in the DNS because they will just fail in 
> the
> same way as any other domain that doesn't exist in the DNS, and that is okay.
> 
> But it is not OK.  Yes, the root servers are surely provisioned to handle the
> additional load the use of .alt might create, but it adds to the useless 
> noise —
> why would the IETF encourage this?  Worse, it exposes .alt traffic to 
> potential
> eavesdroppers.  I’m confused why the IETF would publish an informational
> document that says both of those are not protocol violations.

My assumption is that a browser, application, or even the OS, that supports any 
of these alternative name resolution services will have some code switch that 
decides to either look up the name in the DNS or look the name up in the 
alternative service.

E.g., If my browser supports GNS, then the browser knows to try and resolve 
https://myfunkyname.gns.alt/ using GNS.  If the browser has the code to do 
that, then I would also hope then it wouldn't also try and resolve the same 
domain in the DNS on failure to resolve it using GNS.  But even if they did, I 
don't see that as really being a problem, it will just fail the same way as any 
other unknown domain.

If a user types the same URL into a different browser that doesn’t support GNS, 
then stub resolver would naturally try and resolve https://myfunkyname.gns.alt/ 
in the DNS, which must fail because there can never be any domains in the DNS 
that end with .alt.  It fails in the same way as if I mistype a URL and try and 
resolve "https:://google.con" rather than "https://google.com;.  But I don't 
understand why this alternative browser, that doesn't care about alternative 
name resolution schemes at all, must change their code.

This is outside my area of expertise, but I'm not convinced that the global DNS 
would see any significant increase in load, because the stub resolver would 
generally not be sending the requests to the DNS assuming that they are valid 
domains, and if they are not valid domains then that would seem to be the same 
as what DNS already handles today.

And as for the eavesdropping concern, doesn't this equally apply for all domain 
lookups, particularly invalid ones?

Regards,
Rob


> 
> > Possibly, the draft could have some text that allows stub resolves to 
> > filter out
> DNS requests for .alt names if they wish.
> 
> The point is that DNS resolvers of any kind are explicitly not supposed to see
> .alt queries — .alt is NOT a DNS namespace.  If they do (and they obviously
> will), something is broken and should be fixed.
> 
> Regards,
> -drc

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Rob,

On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton)  wrote:
> If this was a MUST NOT, then at the point that the RFC is published, would 
> that not mean that all DNS stub (and maybe recursive) resolvers immediately 
> become non complaint with the new standard?

The draft says “Informational”.  It is (maybe) recommending the partitioning of 
the domain name namespace, explicitly creating a sub-space that is for non-DNS 
use.  It makes no sense to me to then pretend it’s "just fine” to issue DNS 
queries in that sub-namespace.

> My interpretation of Paul's comment is that nothing bad happens if a client 
> does attempt to resolve .alt names in the DNS because they will just fail in 
> the same way as any other domain that doesn't exist in the DNS, and that is 
> okay.

But it is not OK.  Yes, the root servers are surely provisioned to handle the 
additional load the use of .alt might create, but it adds to the useless noise 
— why would the IETF encourage this?  Worse, it exposes .alt traffic to 
potential eavesdroppers.  I’m confused why the IETF would publish an 
informational document that says both of those are not protocol violations.

> Possibly, the draft could have some text that allows stub resolves to filter 
> out DNS requests for .alt names if they wish.

The point is that DNS resolvers of any kind are explicitly not supposed to see 
.alt queries — .alt is NOT a DNS namespace.  If they do (and they obviously 
will), something is broken and should be fixed.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) 
 wrote:
> 
> If this was a MUST NOT, then at the point that the RFC is published, would 
> that not mean that all DNS stub (and maybe recursive) resolvers immediately 
> become non complaint with the new standard?

That is exactly right. My bigger concern is the recursive resolvers you have in 
parentheses. The more new things that we say they must or should do, the more 
fragmented the DNS becomes because some will and some won't and many won't 
ever. Equally important: adding these new fragmenting rules have absolutely no 
effect on DNS users.

>  E.g., if I try and access https://somedomain.alt in my browser today then it 
> attempts to lookup the domain and fails because it doesn't exist.

> My interpretation of Paul's comment is that nothing bad happens if a client 
> does attempt to resolve .alt names in the DNS because they will just fail in 
> the same way as any other domain that doesn't exist in the DNS, and that is 
> okay.

Exactly right. The definition of the .alt SUDN is that it will not appear in 
the root zone, so that lookups will always just fail in the normal failure 
fashion. No new rules on resolvers are needed.

> Possibly, the draft could have some text that allows stub resolves to filter 
> out DNS requests for .alt names if they wish.  I.e., filtering does no harm, 
> performing the DNS lookup also does no harm, and the implementations can 
> decide if they want to add a special code path for this case or just follow 
> the standard code path.

Decades of experience with RFCs has shown that MAY-level text like that 
confuses some implementers. Implementers that understand the protocol might 
already put in such a rule, possibly behind a configuration switch, as some do 
for names that they consider special. Implementers that don't understand the 
protocol are more likely to make mistakes if we say "you MAY $action", and in 
this case, $action will have no effect on DNS users.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Rob Wilton (rwilton)]

Hi David,

If this was a MUST NOT, then at the point that the RFC is published, would that 
not mean that all DNS stub (and maybe recursive) resolvers immediately become 
non complaint with the new standard?  E.g., if I try and access 
https://somedomain.alt in my browser today then it attempts to lookup the 
domain and fails because it doesn't exist.

My interpretation of Paul's comment is that nothing bad happens if a client 
does attempt to resolve .alt names in the DNS because they will just fail in 
the same way as any other domain that doesn't exist in the DNS, and that is 
okay.

Possibly, the draft could have some text that allows stub resolves to filter 
out DNS requests for .alt names if they wish.  I.e., filtering does no harm, 
performing the DNS lookup also does no harm, and the implementations can decide 
if they want to add a special code path for this case or just follow the 
standard code path.

Regards,
Rob
// No hats.
// Also not a DNS expert, so apologies if I'm using the wrong terms/words ...


> -Original Message-
> From: DNSOP  On Behalf Of David Conrad
> Sent: 22 October 2022 00:55
> To: Paul Hoffman 
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] [Ext] Possible alt-tld last call?
> 
> Paul,
> 
> On Oct 21, 2022, at 3:34 PM, Paul Hoffman 
> wrote:
> >> If the intent here is that .alt names should never be looked up via the
> DNS, then MUST NOT is the expected behavior, no?
> > There is no such intent of the draft.
> 
> Ah.  Then I guess I don’t support the draft and the rest of my input is
> irrelevant.
> 
> Regards,
> -drc

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Independent Submissions Editor (Eliot Lear)]

I'm with Dave on this.  There is nothing wrong with telling endpoints, 
“Don't transmit queries for .ALT."  That is indeed the whole point.  
Paul, you're right: we can't stop applications from not doing this, but 
we can tell them what Good looks like.


Eliot

On 21.10.22 23:39, David Conrad wrote:

This is true for all IETF protocols/specifications.  Are you arguing RFC 2119 
“MUST” is pointless?  As far as I understand, the point of 2119 language is to 
be explicit in expected behaviors, not to imply that the Internet Police will 
hunt you down if you violate them.  If the intent here is that .alt names 
should never be looked up via the DNS, then MUST NOT is the expected behavior, 
no?


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 21, 2022, at 3:34 PM, Paul Hoffman  wrote:
>> If the intent here is that .alt names should never be looked up via the DNS, 
>> then MUST NOT is the expected behavior, no?
> There is no such intent of the draft.

Ah.  Then I guess I don’t support the draft and the rest of my input is 
irrelevant.

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

On Oct 21, 2022, at 3:48 PM, Tim Wicinski  wrote:
> Not putting any hat on, I do like Ben's https+alt:// URI suggestion.
> As a chair, if we see enough interest in this, the WG should find consensus

All the world is not a URI, e.g.,

% ping https://www.ietf.org
ping: cannot resolve https://www.ietf.org: Unknown host
%

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 21, 2022, at 3:48 PM, Tim Wicinski  wrote:
> As a chair, if we see enough interest in this, the WG should find consensus

Creating new URI schemes seems far outside the charter for the DNSOP WG. 
Someone interested in this idea should probably approach the GENDISPATCH WG 
instead.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

Stephen Farrell  writes:

> FWIW I don't understand why people seem so down on the idea
> of enabling other people to experiment with other ways of
> playing with names.

Actually, it seems to me that much of the argument has turned away from
"this is a bad idea" to simply "should we have a registry and how will
this work?"  Based on the last week of mail, the general concept of "we
need a carve-out" (to use Paul's terminology) seems generally agreed
upon.  It's just the details that aren't agreed to yet.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Tim Wicinski]

>
>
> Rather than placing "alt" in the TLD position, I think it might be better
> as a scheme modifier: https+alt://...  This is a common pattern  for
> modifications to URI schemes (c.f. git+ssh://), and informs the software
> that this URI is special without overloading the DNS namespace.
>
>
Not putting any hat on, I do like Ben's https+alt:// URI suggestion.

As a chair, if we see enough interest in this, the WG should find consensus

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 21, 2022, at 2:39 PM, David Conrad  wrote:
> 
> Paul,
> 
> On Oct 21, 2022, at 1:46 PM, Paul Hoffman  wrote:
>>> The document says domain names in .alt “should not” be looked up in a DNS 
>>> context.  The whole point of .alt is that it isn’t to be used in the DNS 
>>> context. Why is this not RFC 2119 “MUST NOT”?
>> Because we cannot force applications or APIs to do anything.
> 
> This is true for all IETF protocols/specifications.  Are you arguing RFC 2119 
> “MUST” is pointless?

Yes.

>  As far as I understand, the point of 2119 language is to be explicit in 
> expected behaviors, not to imply that the Internet Police will hunt you down 
> if you violate them.  

Also yes.

> If the intent here is that .alt names should never be looked up via the DNS, 
> then MUST NOT is the expected behavior, no?

There is no such intent of the draft. If you find words that lean toward that 
intent, please let us know so we can remove them. The intent is that .alt will 
always not be in the global DNS. Looking up those name in the global DNS is as 
acceptable as is looking up any name that's going to lead to an NXDOMAIN for 
the first label.

>> If they look up a .alt name in a DNS context, that's just fine, as long as 
>> they want to get an NXDOMAIN.
> 
> No, it is not "just fine":
> a) it leaks potentially sensitive information
> b) it adds load to the root servers

Both are true for all names with TLDs that are not in the root zone. For (a), 
that's a problem with using the DNS. For (b), the RSOs have repeatedly said 
that they have plenty of capacity for the kruft they get.

> 
>> The draft says "should not" in two places: "should not be resolved using the 
>> DNS protocol" and "should not attempt to be resolved using the global DNS". 
>> Would it be clearer to say "will never be resolved in the global DNS" in 
>> both places?
> 
> It is marginally clearer, but misses the point.  .alt is defining a technique 
> by which a non-DNS name resolution system can make use of domain name syntax 
> that applications expect.  Given that it is explicitly non-DNS, I feel the 
> wording should be explicit in stating that the DNS protocol MUST NOT be used.

We disagree here. Adding per-name rules to resolvers causes more fragility and 
possibly wrong outcomes than letting the DNS continue to be the DNS.

> 
>>> Section 2, paragraph 6:
>>> 
>>> “  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.”
>>> 
>>> The sentence preceding the last is pointless. Just use the last sentence.
>> 
>> This was discussed earlier in the WG. The preceding paragraph is useful 
>> because some readers of the draft forgot that there is a difference between 
>> the DNS presentation format and wire format.
> 
> Sorry if I was unclear: I said “sentence preceding last", not paragraph.  
> Simply saying “This document does not make any suggestion for how non-DNS 
> protocols deal with the wire format of their names” is sufficient — you don’t 
> need the “it can be X or not X” tautology.

Ah, got it. I still think the explanatory sentence for why we don't make any 
suggestions helps the reader.

>>> Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or 
>>> query the global DNS root name servers for names in .alt”?
>> No, it shouldn't, unless you can say why resolvers and caching DNS servers 
>> should treat .alt any differently than any of the other zillion popular 
>> non-delegated TLD?
> 
> Because .alt is being set up to be for use in non-DNS contexts.  If not, then 
> what is the point of this draft?

The point is to say "here's a name that will not be in the root zone that you 
can use for non-DNS contexts". Setting up a bunch of rules for DNS resolvers to 
support that, when they already support that now, adds fragility to the DNS.

> 
>>> DNS server operators don’t register names.
>> According to RFC 6761, they do, or at least they act like what a registry 
>> does after it registers a name.
> 
> No.  RFC 6761, section 5.6 talks about configuring, not registering.  I 
> believe what 6761 was getting at is whether or not the server should reject a 
> name as a configuration error.  This is different than administratively 
> rejecting a name for registration.  E.g., I can easily imagine a registrar 
> creating a registration for the equivalent of ‘*.alt’ to block anyone from 
> even bothering to register a .alt name by indicating it is already registered 
> (as is hinted at in RFC 6761 section 5.7).

Ah. I can see your logic, although I can also see mine. Given your logic, what 
should I say about "DNS server operators" with respect to .alt?

>>> "Currently deployed projects and protocols using pseudo-TLDs are encouraged 
>>> to move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
>>> 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Stephen Farrell]

Hiya,

On 21/10/2022 22:25, Paul Vixie wrote:



Joe Abley wrote on 2022-10-21 13:51:
On Oct 21, 2022, at 12:52, Paul Vixie 
 wrote:


it's a registry of carve-outs for use inside DNS, which happens to 
facilitate client development by giving agents such as browser 
plugins a clear activation signal that's unambiguous with respect to 
the DNS.


...

In that context, what we are talking about is defining a carve-out 
from the namespace that is not for use by the DNS, but instead 
intended for other naming systems.


+1.


Also +1

FWIW I don't understand why people seem so down on the idea
of enabling other people to experiment with other ways of
playing with names. (I do understand the arguments being made
so don't need them explained yet another time; what I don't
get is the attitude behind those.)

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] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

On Oct 21, 2022, at 1:46 PM, Paul Hoffman  wrote:
>> The document says domain names in .alt “should not” be looked up in a DNS 
>> context.  The whole point of .alt is that it isn’t to be used in the DNS 
>> context. Why is this not RFC 2119 “MUST NOT”?
> Because we cannot force applications or APIs to do anything.

This is true for all IETF protocols/specifications.  Are you arguing RFC 2119 
“MUST” is pointless?  As far as I understand, the point of 2119 language is to 
be explicit in expected behaviors, not to imply that the Internet Police will 
hunt you down if you violate them.  If the intent here is that .alt names 
should never be looked up via the DNS, then MUST NOT is the expected behavior, 
no?

> If they look up a .alt name in a DNS context, that's just fine, as long as 
> they want to get an NXDOMAIN.

No, it is not "just fine":
a) it leaks potentially sensitive information
b) it adds load to the root servers

> The draft says "should not" in two places: "should not be resolved using the 
> DNS protocol" and "should not attempt to be resolved using the global DNS". 
> Would it be clearer to say "will never be resolved in the global DNS" in both 
> places?

It is marginally clearer, but misses the point.  .alt is defining a technique 
by which a non-DNS name resolution system can make use of domain name syntax 
that applications expect.  Given that it is explicitly non-DNS, I feel the 
wording should be explicit in stating that the DNS protocol MUST NOT be used.

>> Section 2, paragraph 6:
>> 
>> “  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.”
>> 
>> The sentence preceding the last is pointless. Just use the last sentence.
> 
> This was discussed earlier in the WG. The preceding paragraph is useful 
> because some readers of the draft forgot that there is a difference between 
> the DNS presentation format and wire format.

Sorry if I was unclear: I said “sentence preceding last", not paragraph.  
Simply saying “This document does not make any suggestion for how non-DNS 
protocols deal with the wire format of their names” is sufficient — you don’t 
need the “it can be X or not X” tautology.

>> Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or 
>> query the global DNS root name servers for names in .alt”?
> No, it shouldn't, unless you can say why resolvers and caching DNS servers 
> should treat .alt any differently than any of the other zillion popular 
> non-delegated TLD?

Because .alt is being set up to be for use in non-DNS contexts.  If not, then 
what is the point of this draft?

>> DNS server operators don’t register names.
> According to RFC 6761, they do, or at least they act like what a registry 
> does after it registers a name.

No.  RFC 6761, section 5.6 talks about configuring, not registering.  I believe 
what 6761 was getting at is whether or not the server should reject a name as a 
configuration error.  This is different than administratively rejecting a name 
for registration.  E.g., I can easily imagine a registrar creating a 
registration for the equivalent of ‘*.alt’ to block anyone from even bothering 
to register a .alt name by indicating it is already registered (as is hinted at 
in RFC 6761 section 5.7).

>> "Currently deployed projects and protocols using pseudo-TLDs are encouraged 
>> to move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
>> collision with TLDs allocated via ICANN processes or other future 
>> modifications to the global DNS root zone.”
> Because encouraging those parties seems pointless. They're gonna do what they 
> want to do regardless of what some RFC says.

Then what is the point of this draft?

>> Section 4:
>> 
>> There is no explanation as to why leakage will “undoubtedly occur" or why it 
>> represents a privacy consideration.
> 
> See the URL above for why leakage undoubtably occurs. Some such leakage will 
> include labels below the TLD that some might consider a privacy concern. 
> Further, leakage can be worse than just full names: if you paw through the 
> queries received by root server operators, you will see some queries that 
> contain full URLs as the QNAME.

This may surprise you, but I’m aware of why leakage occurs :).  My point was 
that the reader, i.e., someone implementing a non-DNS name resolution system, 
may need a bit more explanation as to why leakage happens and the privacy 
implications of that leakage.

>> AFAICT, the primary security consideration is that .alt name lookups can 
>> receive unanticipated or malicious responses due to incorrect mapping of the 
>> non-DNS name resolution system to the .alt pseudo-TLD.
> 
> Isn't that true for any TLD, pseudo or not?

If it is not a pseudo-TLD, presumably DNSSEC validation may be able to provide 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

see inline.

Brian Dickson wrote on 2022-10-21 14:17:



On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie > wrote:


...
can you say more about why you think this? (what incompatibilities
lurk?)


The different anchor points are (would be?) tied to different purposes, 
intended behavior for namespaces and resolvers (including leaked 
queries), and relatively low level-of-effort for DNS-friendly 
experimentation.


ah.



So, my read on the general sentiment is:

  * "alt" => not DNS, or at least not DNS-friendly, including has DNSSEC
preventing resolution via validating resolvers.
  * "alt.arpa" => extending DNS without conflicting with existing
ICANN-regulated namespaces, is DNS-friendly, has DNSSEC unsigned
delegation point included (so won't be made unuseable when slightly
modified validating caching resolvers are involved)



i only care about the first bullet-point above. extending DNS may be 
important but it's not the same as the carve-out i am looking for.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Joe Abley wrote on 2022-10-21 13:51:

On Oct 21, 2022, at 12:52, Paul Vixie  wrote:


it's a registry of carve-outs for use inside DNS, which happens to facilitate 
client development by giving agents such as browser plugins a clear activation 
signal that's unambiguous with respect to the DNS.


...

In that context, what we are talking about is defining a carve-out from the 
namespace that is not for use by the DNS, but instead intended for other naming 
systems.


+1.

--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Brian Dickson]

On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie  wrote:

>
>
> Brian Dickson wrote on 2022-10-21 12:42:
> >
> >
> > On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie
> >  > > wrote:
> >
> > ...
> >
> > it's not a fight, and the internet standards community should
> > facilitate such carve-outs whenever possible.
> >
> > ...
> >
> > I think your suggested carve-out would need a different anchor point in
> > the DNS namespace, ...
> can you say more about why you think this? (what incompatibilities lurk?)


The different anchor points are (would be?) tied to different purposes,
intended behavior for namespaces and resolvers (including leaked queries),
and relatively low level-of-effort for DNS-friendly experimentation.

So, my read on the general sentiment is:

   - "alt" => not DNS, or at least not DNS-friendly, including has DNSSEC
   preventing resolution via validating resolvers.
   - "alt.arpa" => extending DNS without conflicting with existing
   ICANN-regulated namespaces, is DNS-friendly, has DNSSEC unsigned delegation
   point included (so won't be made unuseable when slightly modified
   validating caching resolvers are involved)

What I mean by the term "DNS-friendly" is: includes specification-defined
guardrails against collisions, squatting, land rush, abuse, etc., is opt-in
(delegation or namespace won't work unless hosts or software have
explicitly enabled functionality), and can't be used as a global free
end-user registry of domains that work from unmodified clients/resolvers.

Mostly the different anchor points are required due to different DNSSEC
policies (which are needed to prevent bad end-user experiences for leaked
queries with respect to "alt", or are need to enable experimentation
without getting blocked by validating resolvers).

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Joe Abley]

On Oct 21, 2022, at 12:52, Paul Vixie  wrote:

> it's a registry of carve-outs for use inside DNS, which happens to facilitate 
> client development by giving agents such as browser plugins a clear 
> activation signal that's unambiguous with respect to the DNS.

I think the conversation is easier if we think of the namespace and the DNS not 
being the same thing, and take care not to use the terms interchangeably. 
(Perhaps you were doing that, but it seems possible you were not.) (Also 
perhaps this paragraph is just my own private delusion.)

The namespace is older than the DNS; the DNS isn't the only naming system to 
use it, although it is the prevalent naming system; responsibility for its 
stewardship arguably lies with different sets of actors than responsibility for 
the DNS (contentious, and perhaps the two sets have a non-empty intersection).

In that context, what we are talking about is defining a carve-out from the 
namespace that is not for use by the DNS, but instead intended for other naming 
systems.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

On Oct 21, 2022, at 12:49 PM, David Conrad  wrote:
> Throughout the document:
> 
> The document says domain names in .alt “should not” be looked up in a DNS 
> context.  The whole point of .alt is that it isn’t to be used in the DNS 
> context. Why is this not RFC 2119 “MUST NOT”?

Because we cannot force applications or APIs to do anything. If they look up a 
.alt name in a DNS context, that's just fine, as long as they want to get an 
NXDOMAIN.

The draft says "should not" in two places: "should not be resolved using the 
DNS protocol" and "should not attempt to be resolved using the global DNS". 
Would it be clearer to say "will never be resolved in the global DNS" in both 
places?

> Section 1, paragraph 4:
> 
> Two of the quoted terms “Experimental Squatting Problem” and “Land Rush 
> Problem” are NOT defined in RFC 8244 — those terms do not exist in RFC 8244.  
> It would be helpful if those terms were defined.

Good catch; will fix.

> Section 2, paragraph 3:
> 
> Namespaces aren’t actors. They can't "differentiate themselves".  
> Applications differentiate namespaces by the uniqueness of the label for each 
> namespace (something the draft suggests but makes no provision for).

Good catch; will fix.

> Section 2, paragraph 6:
> 
> “  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.”
> 
> The sentence preceding the last is pointless. Just use the last sentence.

This was discussed earlier in the WG. The preceding paragraph is useful because 
some readers of the draft forgot that there is a difference between the DNS 
presentation format and wire format.

> Section 2, paragraph 7:
> 
> “Caching DNS servers and 
> authoritative DNS
>   servers will treat all names in the .alt pseudo-TLD just as they
>   would any other name whose TLD does not appear in the global DNS
>   root.”
> 
> This guarantees the root will receive queries for .alt.

Yes, just like the root service receives queries for all sorts of stuff. (See 
 for a list of the TLDs that one root 
server operator sees.)

> Shouldn’t it say “Resolvers and caching DNS servers MUST NOT forward or query 
> the global DNS root name servers for names in .alt”?

No, it shouldn't, unless you can say why resolvers and caching DNS servers 
should treat .alt any differently than any of the other zillion popular 
non-delegated TLD?

> 
> Same paragraph:
> 
> “  DNS server operators and DNS registries/registrars for the
>   global DNS will never register names in the .alt pseudo-TLD because
>   .alt will not exist in the global DNS root.”
> 
> DNS server operators don’t register names.

According to RFC 6761, they do, or at least they act like what a registry does 
after it registers a name.

> Section 2, last paragraph:
> 
> “  Currently deployed projects and protocols that are using pseudo-TLDs
>   may choose to move under the .alt pseudo-TLD, but this is not a
>   requirement.  Rather, the .alt pseudo-TLD is being reserved so that
>   current and future projects of a similar nature have a designated
>   place to create alternative resolution namespaces that will not
>   conflict with the regular DNS context."
> 
> Why not encourage movement and explain why, e.g.:
> 
> "Currently deployed projects and protocols using pseudo-TLDs are encouraged 
> to move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
> collision with TLDs allocated via ICANN processes or other future 
> modifications to the global DNS root zone.”

Because encouraging those parties seems pointless. They're gonna do what they 
want to do regardless of what some RFC says.

> Section 4:
> 
> There is no explanation as to why leakage will “undoubtedly occur" or why it 
> represents a privacy consideration.

See the URL above for why leakage undoubtably occurs. Some such leakage will 
include labels below the TLD that some might consider a privacy concern. 
Further, leakage can be worse than just full names: if you paw through the 
queries received by root server operators, you will see some queries that 
contain full URLs as the QNAME. 

> Section 5:
> 
> It is unclear what “re-use the chosen label” means or what “special host 
> name” is being referenced.

Noted. This sentence is quite hard to parse, now that I (a co-editor) read it. 

> AFAICT, the primary security consideration is that .alt name lookups can 
> receive unanticipated or malicious responses due to incorrect mapping of the 
> non-DNS name resolution system to the .alt pseudo-TLD.

Isn't that true for any TLD, pseudo or not?

> 
>> We note that there are still some people who want a registry of some sort 
>> for names that would appear under .alt, but it feels like the number of 
>> people who 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

Ben Schwartz  writes:

> Conversely, I think an alternate URI-scheme is actually _more_ likely to have
> good compatibility with non-alt-aware software.

First, for the record: I think a URI approach is a far better solution.
And I'm trying to guess at the motivations of others not using it (which
I probably shouldn't do; but I will point out that all the other systems
aren't proposing alternate-URI schemes but I'm sure at least some of
them have thought about it.  If you're one of those, please speak up!)

I will note that of all my binaries in /usr/bin on my random linux
system, 199 of them have references to either gethostbyname or
getaddrinfo.  It may be that you could mess with the base C library that
implements those to accept a URI instead (yay), but I think it may be
harder to fix all the UIs on top of it that may be doing regexp matches
to ensure the user input is valid before accepting a submit button.
Maybe.  Maybe not.  It feels like a hope, not an assured solution.  Even
though it's the *right* thing to do.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

Brian Dickson wrote on 2022-10-21 12:42:



On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie 
> wrote:


...

it's not a fight, and the internet standards community should
facilitate such carve-outs whenever possible.

...

I think your suggested carve-out would need a different anchor point in 
the DNS namespace, ...

can you say more about why you think this? (what incompatibilities lurk?)

--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Fri, Oct 21, 2022 at 3:03 PM Wes Hardaker  wrote:

> Ben Schwartz  writes:
>
> > Rather than placing "alt" in the TLD position, I think it might be
> better as a
> > scheme modifier: https+alt://...  This is a common pattern  for
> modifications to
> > URI schemes (c.f. git+ssh://), and informs the software that this URI is
> special
> > without overloading the DNS namespace.
>
> I suspect many of us would agree that's the best ideal way forward,
> except that the proponents of the alternate names want their names to be
> as DNS-like as possible so it works with *all* applications.  All new
> ones may support extensions and URIs, etc.  I'm not sure telnet, nntp
> readers, etc do/will.  I don't even know how to enumerate all the places
> where a domain name is expected (endless GUIs) that don't have an
> appropriate name space selector option.  Certainly a "too bad for you"
> approach for situations like that, but I suspect that's going against
> what the alternate name space proponents want: minimal upgrades to
> existing software [right or wrong as that may be -- no judgment here].


I think this mindset is based on what I'll call the "getaddrinfo
assumption", that DNS provides a name->IP mapping interface whose
implementation can be replaced.  This assumption can fail on both ends:

1. Many altname schemes (e.g. .onion, IPFS) do not represent IP addresses
at all.
2. Existing DNS-reliant applications increasingly rely on
beyond-getaddrinfo capabilities (e.g. SRV, HTTPS-records, stub DNSSEC,
etc.) or implement their own stub resolvers for performance reasons.

The .alt draft seems to be based on this assumption, although it doesn't
say so.  If this assumption fails, it's hard for me to see how .alt helps.

Conversely, I think an alternate URI-scheme is actually _more_ likely to
have good compatibility with non-alt-aware software.  For example, if a
non-alt-aware web browser encounters an unknown URI scheme, it will
generally defer to the operating system for how to handle it.  This means a
user can (today!) install a system-wide "https+alt://" handler, and expect
to be able to open such URIs if they're encountered in the browser, mail
client, etc.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[David Conrad]

Paul,

> On Oct 21, 2022, at 10:34 AM, Paul Hoffman  wrote:
> Warren and I believe that the changes in draft-ietf-dnsop-alt-tld-18 meet all 
> of the concerns in the message that started this thread, and thus it is ready 
> for WG Last Call.

I disagree that the document is ready for WG Last Call.  I will try again:

Throughout the document:

The document says domain names in .alt “should not” be looked up in a DNS 
context.  The whole point of .alt is that it isn’t to be used in the DNS 
context. Why is this not RFC 2119 “MUST NOT”?

Section 1, paragraph 4:

Two of the quoted terms “Experimental Squatting Problem” and “Land Rush 
Problem” are NOT defined in RFC 8244 — those terms do not exist in RFC 8244.  
It would be helpful if those terms were defined.

Section 2, paragraph 3:

Namespaces aren’t actors. They can't "differentiate themselves".  Applications 
differentiate namespaces by the uniqueness of the label for each namespace 
(something the draft suggests but makes no provision for).

Section 2, paragraph 6:

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

The sentence preceding the last is pointless. Just use the last sentence.

Section 2, paragraph 7:

“Caching DNS servers and authoritative 
DNS
   servers will treat all names in the .alt pseudo-TLD just as they
   would any other name whose TLD does not appear in the global DNS
   root.”

This guarantees the root will receive queries for .alt.  Shouldn’t it say 
“Resolvers and caching DNS servers MUST NOT forward or query the global DNS 
root name servers for names in .alt”?

Same paragraph:

“  DNS server operators and DNS registries/registrars for the
   global DNS will never register names in the .alt pseudo-TLD because
   .alt will not exist in the global DNS root.”

DNS server operators don’t register names.

Section 2, last paragraph:

“  Currently deployed projects and protocols that are using pseudo-TLDs
   may choose to move under the .alt pseudo-TLD, but this is not a
   requirement.  Rather, the .alt pseudo-TLD is being reserved so that
   current and future projects of a similar nature have a designated
   place to create alternative resolution namespaces that will not
   conflict with the regular DNS context."

Why not encourage movement and explain why, e.g.:

"Currently deployed projects and protocols using pseudo-TLDs are encouraged to 
move under the .alt pseudo-TLD.  Doing so will reduce the chance of name 
collision with TLDs allocated via ICANN processes or other future modifications 
to the global DNS root zone.”

Section 4:

There is no explanation as to why leakage will “undoubtedly occur" or why it 
represents a privacy consideration.

Section 5:

It is unclear what “re-use the chosen label” means or what “special host name” 
is being referenced. AFAICT, the primary security consideration is that .alt 
name lookups can receive unanticipated or malicious responses due to incorrect 
mapping of the non-DNS name resolution system to the .alt pseudo-TLD.

> We note that there are still some people who want a registry of some sort for 
> names that would appear under .alt, but it feels like the number of people 
> who want no registry is larger, and it also is clear that the people who want 
> a registry don't agree on the rules or location for that potential registry. 
> During WG Last Call, if there is a consensus (decided by the chairs, not the 
> authors) for one proposal for a registry, we can add it to the draft.

Without a registry, how is a non-DNS name resolution developer supposed to 
"choose a label that they expect to be unique”?

Regards,
-drc



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Brian Dickson]

On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie  wrote:

> see inline.
>
> Wes Hardaker wrote on 2022-10-21 09:09:
> > Joe Abley  writes:
> >
> >>> Normally, a registry is created when it will help the operation of
> >>> the protocol.  The problem here is that there's an _anti_-protocol,
> >>> and therefore it's mystifying to me how a registry helps anything,
> >>> since there is no way to know whether a registry will actually help
> >>> or in some cases even hurt.
> >>
> >> Yes. This.
>
> -1.
>
> > To put this another way: the proponents of the currently active non-DNS
> > naming systems are creating these systems with an active desire to avoid
> > a centralized form of control over the name space they're creating.  And
> > by having a registry, it would re-insert some level of control that
> > they're explicitly fighting against.
> it's a registry of carve-outs for use inside DNS, which happens to
> facilitate client development by giving agents such as browser plugins a
> clear activation signal that's unambiguous with respect to the DNS.
>
> it's not a fight, and the internet standards community should facilitate
> such carve-outs whenever possible.
>

That would be an interesting use case, for a different "thing", IMNSHO.

What you describe would be different from the use cases of GNS or other
similar systems, which either have no need to directly coexist with the
ICANN-root DNS, or enable name conflicts by overloading DNS without
enforcing guard rails.

I think your suggested carve-out would need a different anchor point in the
DNS namespace, might need a registry, and if a registry were created, would
need very strict enforcement on the cooperative augmentation to DNS by
those things.

I don't think the suggested carve-out fit into the current proposed draft
(alt-tld), but would probably be a similar document, possibly simple in
nature and as long as alt-tld was published first or at the same time,
would avoid land-rush issues or abuse.

As to what place to put the carve-out, I think its requirements would be
quite similar to the homenet thing, which has 'home.arpa'.
So, maybe 'alt.arpa' with insecure delegation (which would facilitate both
adding trust anchors and/or having local namespaces that are intended to
sit underneath the alt.arpa namespace safely)?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

Ben Schwartz  writes:

> Rather than placing "alt" in the TLD position, I think it might be better as a
> scheme modifier: https+alt://...  This is a common pattern  for modifications 
> to
> URI schemes (c.f. git+ssh://), and informs the software that this URI is 
> special
> without overloading the DNS namespace.

I suspect many of us would agree that's the best ideal way forward,
except that the proponents of the alternate names want their names to be
as DNS-like as possible so it works with *all* applications.  All new
ones may support extensions and URIs, etc.  I'm not sure telnet, nntp
readers, etc do/will.  I don't even know how to enumerate all the places
where a domain name is expected (endless GUIs) that don't have an
appropriate name space selector option.  Certainly a "too bad for you"
approach for situations like that, but I suspect that's going against
what the alternate name space proponents want: minimal upgrades to
existing software [right or wrong as that may be -- no judgment here].
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Fri, Oct 21, 2022 at 2:31 PM Paul Hoffman  wrote:

> >> .alt will be treated like any other pseudo-TLD regardless of the
> context.
> >
> > Sorry, I don't understand.  I believe "pseudo-TLD" here means "a name
> that resolves to NXDOMAIN".
>
> It is defined in this very document as "A label that appears in a
> fully-qualified domain name in the position of a TLD, but which is not part
> of the global DNS."
>
> >  Most URI schemes are pretty clear about what happens in this case: the
> resource cannot be accessed.
>
> That seems like the right thing for them to specify.
>
> >> If you think that URIs that have names that are not part of the global
> DNS should be treated differently by URI consumers, by all means write a
> draft about it.
> >
> > This is not about "global DNS" vs. some view of the DNS.
>
> It really is. See the definition in the draft.


Firstly, I don't think it makes sense to define "DNS context" as limited to
the IANA root.  I would prefer a term like "non-IANA-root context".

Secondly, the draft contradicts itself.  For example, it says ".alt is
always used to denote names that are to be resolved by non-DNS protocols".
But surely one can speak to non-IANA DNS roots using the DNS protocol?

Rather than placing "alt" in the TLD position, I think it might be better
as a scheme modifier: https+alt://...  This is a common pattern  for
modifications to URI schemes (c.f. git+ssh://), and informs the software
that this URI is special without overloading the DNS namespace.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

>> .alt will be treated like any other pseudo-TLD regardless of the context.
> 
> Sorry, I don't understand.  I believe "pseudo-TLD" here means "a name that 
> resolves to NXDOMAIN".

It is defined in this very document as "A label that appears in a 
fully-qualified domain name in the position of a TLD, but which is not part of 
the global DNS."

>  Most URI schemes are pretty clear about what happens in this case: the 
> resource cannot be accessed.

That seems like the right thing for them to specify.

>> If you think that URIs that have names that are not part of the global DNS 
>> should be treated differently by URI consumers, by all means write a draft 
>> about it.
> 
> This is not about "global DNS" vs. some view of the DNS.

It really is. See the definition in the draft. 

>  This is about "resolvable names" vs. "non-resolvable names".  Every URI 
> scheme I'm aware of relies on "name resolution" of any hostname specified in 
> the authority section.  But "name resolution" is not defined except within 
> "the DNS".

Applications and APIs can sometimes invoke their own name resolution outside 
the DNS.

>  If .alt names are "not DNS names", then they are not subject to "name 
> resolution".  

Correct.

> I conclude that they cannot be used in any existing URI scheme.

Above, you said "Most URI schemes...". Yes, I know that some of this stems from 
the lack of a stable, widely-believed URI spec.

> If you agree, that should go in the draft.  If not ... personally I think 
> you'll need to add some text, and possibly update some RFCs.

URIs are just one user of DNS names, albeit an important one. I'm not sure they 
should be called out separately, but a suggested addition to the new draft is 
welcome.

> As a practical matter, I see three types of "pseudo-TLDs":
> 1. Alt-root names: Those that actually _are_ DNS names, offering the same set 
> of RR types but resolving to an alternate DNS root.  (Example: Handshake 
> "HNS")
> 2. New class names: These come with their own new universe of URI schemes, 
> and cannot be used with existing schemes that assume name resolution.  
> (Example: dweb://)
> 3. Retrofit names: These names reuse some existing scheme strings but 
> substantially modify the interpretation of the scheme.  (Example: https: and 
> .onion).
> 
> I would like the draft to be a lot clearer about which of these are in-scope 
> for .alt.

The current text says it is up to the application and API. If we can be 
clearer, suggested text is definitely welcome.

--Paul Hoffman




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Wed, Oct 19, 2022 at 9:31 PM Paul Hoffman  wrote:
...

> On Oct 17, 2022, at 1:16 PM, Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >
> > While we're talking about this draft, I would like to suggest that the
> draft discuss the interpretation of URIs containing ".alt" hostnames.  I
> have great difficulty understanding what "https://example.foo.alt/; means
> ... but most of the interest in alternative naming systems seems to be
> based on the idea that this sort of URI is meaningful.
>
> .alt will be treated like any other pseudo-TLD regardless of the context.


Sorry, I don't understand.  I believe "pseudo-TLD" here means "a name that
resolves to NXDOMAIN".  Most URI schemes are pretty clear about what
happens in this case: the resource cannot be accessed.


> If you think that URIs that have names that are not part of the global DNS
> should be treated differently by URI consumers, by all means write a draft
> about it.


This is not about "global DNS" vs. some view of the DNS.  This is about
"resolvable names" vs. "non-resolvable names".  Every URI scheme I'm aware
of relies on "name resolution" of any hostname specified in the authority
section.  But "name resolution" is not defined except within "the DNS".  If
.alt names are "not DNS names", then they are not subject to "name
resolution".  I conclude that they cannot be used in any existing URI
scheme.

If you agree, that should go in the draft.  If not ... personally I think
you'll need to add some text, and possibly update some RFCs.

As a practical matter, I see three types of "pseudo-TLDs":
1. Alt-root names: Those that actually _are_ DNS names, offering the same
set of RR types but resolving to an alternate DNS root.  (Example:
Handshake "HNS")
2. New class names: These come with their own new universe of URI schemes,
and cannot be used with existing schemes that assume name resolution.
(Example: dweb://)
3. Retrofit names: These names reuse some existing scheme strings but
substantially modify the interpretation of the scheme.  (Example: https:
and .onion).

I would like the draft to be a lot clearer about which of these are
in-scope for .alt.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

Warren and I believe that the changes in draft-ietf-dnsop-alt-tld-18 meet all 
of the concerns in the message that started this thread, and thus it is ready 
for WG Last Call.

We note that there are still some people who want a registry of some sort for 
names that would appear under .alt, but it feels like the number of people who 
want no registry is larger, and it also is clear that the people who want a 
registry don't agree on the rules or location for that potential registry. 
During WG Last Call, if there is a consensus (decided by the chairs, not the 
authors) for one proposal for a registry, we can add it to the draft.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

Timothy Mcsweeney  writes:

> > Sadly, we almost
> > need two .alt name spaces: one which is explicitly
> > not-registry-controlled, and one which is.
> >
> 
> Who is 'we' in the above sentence?

There are two camps of people that want to play in the alternate naming
space:

1. Those that want to figure out a way to inter-operate such that
conflicts don't occur and that an end-user can likely get the answer
that they're looking for, even with multiple naming systems in place.
How this happens, and where the magic flag occurs that says "you're
leaving the DNS naming system but still using a DNS like name" is left
to be decided, including whether one or multiple boundaries include a
1. "but you can now consult this alternate naming system registration
table" or 2. "beyond here you're on your own" [not intending to be
negative here].

2. Those that deliberately want to collide because the nature of their
solution may be to "replace" the DNS because they detest centralization
based solutions, or think theirs is simply better, or 

The "we" was referring to 1.  The definition and examples could, of
course, be a lot longer and more refined.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Vixie]

see inline.

Wes Hardaker wrote on 2022-10-21 09:09:

Joe Abley  writes:


Normally, a registry is created when it will help the operation of
the protocol.  The problem here is that there's an _anti_-protocol,
and therefore it's mystifying to me how a registry helps anything,
since there is no way to know whether a registry will actually help
or in some cases even hurt.


Yes. This.


-1.


To put this another way: the proponents of the currently active non-DNS
naming systems are creating these systems with an active desire to avoid
a centralized form of control over the name space they're creating.  And
by having a registry, it would re-insert some level of control that
they're explicitly fighting against.
it's a registry of carve-outs for use inside DNS, which happens to 
facilitate client development by giving agents such as browser plugins a 
clear activation signal that's unambiguous with respect to the DNS.


it's not a fight, and the internet standards community should facilitate 
such carve-outs whenever possible.


--
P Vixie

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Timothy Mcsweeney]

> On 10/21/2022 12:09 PM EDT Wes Hardaker  wrote:
> 
> Sadly, we almost
> need two .alt name spaces: one which is explicitly
> not-registry-controlled, and one which is.
>


Who is 'we' in the above sentence?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Wes Hardaker]

Joe Abley  writes:

> > Normally, a registry is created when it will help the operation of
> > the protocol.  The problem here is that there's an _anti_-protocol,
> > and therefore it's mystifying to me how a registry helps anything,
> > since there is no way to know whether a registry will actually help
> > or in some cases even hurt.
> 
> Yes. This.

To put this another way: the proponents of the currently active non-DNS
naming systems are creating these systems with an active desire to avoid
a centralized form of control over the name space they're creating.  And
by having a registry, it would re-insert some level of control that
they're explicitly fighting against.

I don't think Eliot is wrong when he said:

> > > As a matter of practicality, a registry surely will be form.

Any registry that the current designers would be most happy with would
also be not a centralized registry.  Who knows, maybe it'll be "last
edit on wikipedia" or "king of the hill" or "will get put as a default
in the GNS" (which, ironically, becomes a central point of control if no
one deviates from it).

The point is: if these systems want a complete decentralized space to
play in and know the risks of toe-stepping, then that's fine.

Now, the problem we'll run into is along comes a new name space system
that wants to be more centrally controlled, but is still not the DNS.
Clearly, .alt won't be the perfect solution for them.  And they'd prefer
something like .reg.alt where conflict doesn't occur.  Sadly, we almost
need two .alt name spaces: one which is explicitly
not-registry-controlled, and one which is.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Martin Schanzenbach]

On 20.10.22 12:05, Brian Dickson wrote:
> On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear  wrote:
> 
> > Hi,
> >
> > First, I would like us to continue to consult on the registry matter at
> > least through the London IETF, and would ask the chairs for some time in
> > London for this purpose.  I would also be available for side meetings
> > with any interested party, before or during the IETF.  If people would
> > like, we can grab a room for this purpose, if we can do so in the
> > morning so that Martin can participate remotely (he is far to the east
> > of London).
> >
> > As a matter of practicality, a registry surely will be form.  It is
> > simply a matter of whether the IANA will host it.  If the IANA does not
> > host it, then by shifting it elsewhere this group is actually weakening
> > the IANA function, and that would be sad.
> >
> 
> I spent quite a bit of time in the last couple of days reading all the
> threaded posts, as well as the two relevant drafts: the alt-tld one, and
> the gns one.
> 
> The latter (quite a large document, with lots of important nuances
> including additions related to dotALT conceptually) has some major
> challenges for whether/how it would even fit in such a registry.
> 
> I fear those challenges mean that GNS simply won't be possible to properly
> have registry entries, and without GNS, or possibly using GNS as an
> alternative namespace example, the registry makes no sense.
> 
> Here's the problem that the GNS draft includes (and maybe doesn't highlight
> well enough): GNS is not a namespace. There is no central administration of
> namespace(s) under GNS, or even a central anything. GNS has no global
> "anything", and no concept of global per se. At best, entities can publish
> their own equivalent of "root zone"s that assert to a population of
> consumers as to what namespace entities exist, without any authority over
> any aspect of namespaces. It is anarchy embodied.
> 
> Everything in GNS relies on mappings, and "petnames". While those can
> potentially be placed under some parent label, the existence of such a
> parent label (either ".alt" or ".gns.alt") is neither necessary nor
> sufficient to achieve any kind of global consistency.
> 
> There is also no ability to enforce any rules on using any parent label, or
> to prevent conflicting intra-GNS "petnames", or to prevent conflicts
> between GNS "petnames" and any other TLD namespaces (including DNS). GNS
> allows anyone (with local context) to instantiate any namespace (tree
> anchored anywhere), including instantiating new TLDs (contrary to ICANN's
> current role as exclusive entity responsible for administering the DNS
> namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs,
> or anything beneath those.

In GNS, you can expect that there will be default configurations of TLDs
(e.g. example.gns.alt with the alt suffix).
Those defaults (=root) will have to be governed similarly to what ICANN
does. And rules will, of cource, have to be enforced contractually, not
through the protocol. As is the case with DNS.

Yes the user can create local mappings, but you can do the same in DNS
(split horizon, RFC8375 etc etc)

> 
> The question that hasn't been addressed is, who SHOULD actually do
> registrations in this proposed registry?

Experts well versed in name system design?

> I don't believe the authors of the GNS draft have the actual authority to
> do so, as they do not administer any name space per se.

Not exclusively, no.

> If someone did want to instantiate a local namespace, or a kind-of, sort-of
> bigger-than-local namespace (with delegations) as the GNS draft generally
> describes, would they be the entities registering their namespace?
> Those namespaces are not required to be unique within GNS, as well, so even
> having an FCFS registry would not mirror the reality of GNS. There could
> easily be 1000 different instances of "lotr.gns.alt" within GNS, each with
> its own zone(s) with names like "frodo", "bilbo", "gandalf" etc.
> 

I do not understand the question. Isn't that exactly how home.arpa
works?
Names in .home.arpa are only locally unique. In practice, GNS will
actually have unique(r) deployments than .home.arpa.
But even if it does not, calling global uniqueness/consistency a
requirement is calling home.arpa not a namespace.

BR
Martin

> And if the GNS draft isn't included in the registry (because it does not
> administer ANY namespace), I don't see how the registry can function as
> envisioned.
> 
> It may possibly be reduced to definitions: what is a namespace? If it is
> not something that is global and consistent, I don't think it could
> accurately be called a namespace.
> 
> It basically suffers from the "Woody Allen" problem ("I wouldn't want to be
> a member of any club that would accept me as a member.")
> Creating a registry as a place to put GNS would be self-contradicting if
> GNS cannot be added to the registry.
> 
> Brian
> 
> 
> 
> >
> > Two more points below.

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Wouters]

On Oct 20, 2022, at 04:16, Eliot Lear  wrote:
> 
> 
> As a matter of practicality, a registry surely will be form.

Wikipedia is a great reference to list them all. 

Even the costs of maintaining the page is decentralized without a single 
authority that has ownership over the page content. It’s almost a fit too good 
to be true 

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Joe Abley]

Hi Andrew,

On Oct 20, 2022, at 15:57, Andrew Sullivan  wrote:

>> On Thu, Oct 20, 2022 at 09:40:01PM +0200, Eliot Lear wrote:
>> 
>> They're asking for the registry.
> 
> Who is asking for it?  And more importantly, what will a registry do?  As I 
> pointed out already in this thread, the registry won't be complete, it won't 
> be accurate, and it won't solve in any way the problem of collision.  So what 
> does the registry do such that anyone cares about it?
> 
> Normally, a registry is created when it will help the operation of the 
> protocol.  The problem here is that there's an _anti_-protocol, and therefore 
> it's mystifying to me how a registry helps anything, since there is no way to 
> know whether a registry will actually help or in some cases even hurt.

Yes. This.

I think this is difficult because this working group is chartered to work on 
this related to the DNS. To the arguable extent that any of this relates to the 
DNS, it's surely concerned with the boundary between the DNS and these other 
naming systems, some known and some imagined, not the details of any how any of 
those other naming systems should work.

The operational, DNS concern here is that perhaps some of these other naming 
systems might step on the DNS in a way that causes some problem for someone 
involved in using or operating the DNS. Carefully specifying the boundary is 
surely the limit of what this group should be working on. (Even that is 
debatable. I have argued against it.) If that involves a registry, it's a 
non-extensible, closed-as-soon-as-it's-opened registry of precisely one entry 
which is "ALT", which is to say we clearly don't need a registry at all.

Non-DNS naming system A and non-DNS naming system B may well need to make 
arrangements between themselves about how not to step on each other as well. Or 
perhaps they won't. Either way, I don't think it is any business of this 
working group (or the IETF at all, to be honest) to be involved in those 
arrangements.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Peter Thomassen]

On 10/20/22 15:05, Brian Dickson wrote:

I fear those challenges mean that GNS simply won't be possible to properly have 
registry entries, and without GNS, or possibly using GNS as an alternative 
namespace example, the registry makes no sense.

Here's the problem that the GNS draft includes (and maybe doesn't highlight well enough): GNS is 
not a namespace. There is no central administration of namespace(s) under GNS, or even a central 
anything. GNS has no global "anything", and no concept of global per se. At best, 
entities can publish their own equivalent of "root zone"s that assert to a population of 
consumers as to what namespace entities exist, without any authority over any aspect of namespaces. 
It is anarchy embodied.

[...]

There is also no ability to enforce any rules on using any parent label, or to prevent 
conflicting intra-GNS "petnames",

[...]

GNS allows anyone (with local context) to instantiate any namespace (tree 
anchored anywhere), including instantiating new TLDs (contrary to ICANN's 
current role as exclusive entity responsible for administering the DNS 
namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs, or 
anything beneath those.


DNS allows all the same things, you can just set up a local root or local co.uk 
or whatever split-horizon scenario you want.

The conventional root zone is the authority because it has been accepted as 
such, not because the DNS contains a mechanism for it that GNS lacks.


The question that hasn't been addressed is, who SHOULD actually do 
registrations in this proposed registry?
I don't believe the authors of the GNS draft have the actual authority to do 
so, as they do not administer any name space per se.
If someone did want to instantiate a local namespace, or a kind-of, sort-of 
bigger-than-local namespace (with delegations) as the GNS draft generally 
describes, would they be the entities registering their namespace?

[...]

There could easily be 1000 different instances of "lotr.gns.alt" within GNS, each with its own zone(s) with 
names like "frodo", "bilbo", "gandalf" etc.


Of course (and again, same with DNS). But having a carve-out suffix would open 
up the possibility of telling people who are creating namespaces to do so in a 
way that doesn't collide with the DNS namespace as it is used so far. (It's a 
possibility; it may get ignored, but there's no harm to it either.)

That carve-out is entirely independent of any mechanisms that record 
potentially conflicting names under it. To agree on what the carve-out is, we 
don't need to decide whether such record keeping could be done via a IANA 
registry, or an ICANN GNS department, or something entirely different, or not 
at all.

I thus reiterate [0] that there are two separate things at hand, namely (1) the 
carve-out, (2) conflict mitigation below the carve-out.

The second problem can be solved *after* the first, and also doesn't really 
concern the DNSOP WG, as long as the solution to the first provides a means to 
point non-DNS implementors to some recipe that helps avoid collisions with DNS. 
That's the .alt TLD (or _* wildcard TLDs or whatever).

I think we should focus on the first problem exclusively.

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 names that look like domains names for a
non-DNS purpose, please append the "alt" label to whatever
you're using.  DNS stub and recursive resolvers, stop
resolution when you see this.

... and add whatever extra text that is necessary for RFC-ization reasons.

(When settling on some other carve-out, the approach would be similar. For 
example, for _* underscore TLDs:
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 recursive resolvers, stop resolution when you see this.)

Right now, we need consensus on the carve-out (if any). After that, let's 
decide if DNSOP cares about the registry, and settle that.

Best,
Peter

--
https://desec.io/

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Andrew Sullivan]

Hi,

[ObDisclaimer]

On Thu, Oct 20, 2022 at 09:40:01PM +0200, Eliot Lear wrote:


They're asking for the registry.


Who is asking for it?  And more importantly, what will a registry do?  As I 
pointed out already in this thread, the registry won't be complete, it won't be 
accurate, and it won't solve in any way the problem of collision.  So what does 
the registry do such that anyone cares about it?

Normally, a registry is created when it will help the operation of the 
protocol.  The problem here is that there's an _anti_-protocol, and therefore 
it's mystifying to me how a registry helps anything, since there is no way to 
know whether a registry will actually help or in some cases even hurt.


which is whether there should be a protocol switch inside .ALT.


There will be, almost by definition, exactly as many protocol switches as 
anyone wants inside alt.  What alt does is itself a protocol switch.  I think 
that imagining that such a protocol switch will then proceed in an orderly, 
hierarchical way flies in the teeth of the evidence.  I fully expect more than 
one use to attempt to colonize the entire alt space, and to do exactly no 
registration in any registry as a matter of principle.  Do you have some reason 
to suppose otherwise?

I don't think the registry follows the Internet-cops approach, but it sure 
sounds like a registry as Internet hall monitor.  I think the reasons to create 
alt give us every reason to suppose that appointing such a hall monitor is a 
mistake, and I strongly oppose the creation of such a registry.  As ever, I 
think it's possible I'm in the rough. But I also don't think you or other 
proponents of a registry have offered anything like good reasons why this 
registry is a good idea.

reason for these people to continuously pay money to anyone for 
something that benefits others.


So there's a reason instead that IANA should pay to maintain this registry 
without clear evidence that there is a benefit?

Best regards,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

On 20.10.22 21:13, Andrew Sullivan wrote:

Hi Eliot,

Still employed and still not speaking for them, I have a question:

On Thu, Oct 20, 2022 at 10:15:22AM +0200, Eliot Lear wrote:


As a matter of practicality, a registry surely will be form.


What evidence do you have for this assertion? 


They're asking for the registry.  Do you think IANA hold some special 
value to them?  And it's a common coding pattern to provide a code 
switch.  You're asking the wrong question: why would they not?



As a practical matter, after all, if a registry function were wanted 
there _already is one_ in the form of any trivial name you can think 
of in the DNS (I think Joe Abley has made this point rather well on 
the list already).


We are rehashing, and that's a non-sequitor to the argument at hand, 
which is whether there should be a protocol switch inside .ALT.   But to 
answer your question anyway, as was answered previously, there's no 
reason for these people to continuously pay money to anyone for 
something that benefits others.


Eliot




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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Andrew Sullivan]

Hi Eliot,

Still employed and still not speaking for them, I have a question:

On Thu, Oct 20, 2022 at 10:15:22AM +0200, Eliot Lear wrote:


As a matter of practicality, a registry surely will be form.


What evidence do you have for this assertion?  As a practical matter, after 
all, if a registry function were wanted there _already is one_ in the form of 
any trivial name you can think of in the DNS (I think Joe Abley has made this 
point rather well on the list already).  So, if you want to give IANA or anyone 
else a new duty, you are going to need a better argument for it than insisting 
that it's bound to happen anyway.

Best regards,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Brian Dickson]

On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear  wrote:

> Hi,
>
> First, I would like us to continue to consult on the registry matter at
> least through the London IETF, and would ask the chairs for some time in
> London for this purpose.  I would also be available for side meetings
> with any interested party, before or during the IETF.  If people would
> like, we can grab a room for this purpose, if we can do so in the
> morning so that Martin can participate remotely (he is far to the east
> of London).
>
> As a matter of practicality, a registry surely will be form.  It is
> simply a matter of whether the IANA will host it.  If the IANA does not
> host it, then by shifting it elsewhere this group is actually weakening
> the IANA function, and that would be sad.
>

I spent quite a bit of time in the last couple of days reading all the
threaded posts, as well as the two relevant drafts: the alt-tld one, and
the gns one.

The latter (quite a large document, with lots of important nuances
including additions related to dotALT conceptually) has some major
challenges for whether/how it would even fit in such a registry.

I fear those challenges mean that GNS simply won't be possible to properly
have registry entries, and without GNS, or possibly using GNS as an
alternative namespace example, the registry makes no sense.

Here's the problem that the GNS draft includes (and maybe doesn't highlight
well enough): GNS is not a namespace. There is no central administration of
namespace(s) under GNS, or even a central anything. GNS has no global
"anything", and no concept of global per se. At best, entities can publish
their own equivalent of "root zone"s that assert to a population of
consumers as to what namespace entities exist, without any authority over
any aspect of namespaces. It is anarchy embodied.

Everything in GNS relies on mappings, and "petnames". While those can
potentially be placed under some parent label, the existence of such a
parent label (either ".alt" or ".gns.alt") is neither necessary nor
sufficient to achieve any kind of global consistency.

There is also no ability to enforce any rules on using any parent label, or
to prevent conflicting intra-GNS "petnames", or to prevent conflicts
between GNS "petnames" and any other TLD namespaces (including DNS). GNS
allows anyone (with local context) to instantiate any namespace (tree
anchored anywhere), including instantiating new TLDs (contrary to ICANN's
current role as exclusive entity responsible for administering the DNS
namespace at the TLD level) and instantiating conflicting TLDs, SLDs, 3LDs,
or anything beneath those.

The question that hasn't been addressed is, who SHOULD actually do
registrations in this proposed registry?
I don't believe the authors of the GNS draft have the actual authority to
do so, as they do not administer any name space per se.
If someone did want to instantiate a local namespace, or a kind-of, sort-of
bigger-than-local namespace (with delegations) as the GNS draft generally
describes, would they be the entities registering their namespace?
Those namespaces are not required to be unique within GNS, as well, so even
having an FCFS registry would not mirror the reality of GNS. There could
easily be 1000 different instances of "lotr.gns.alt" within GNS, each with
its own zone(s) with names like "frodo", "bilbo", "gandalf" etc.

And if the GNS draft isn't included in the registry (because it does not
administer ANY namespace), I don't see how the registry can function as
envisioned.

It may possibly be reduced to definitions: what is a namespace? If it is
not something that is global and consistent, I don't think it could
accurately be called a namespace.

It basically suffers from the "Woody Allen" problem ("I wouldn't want to be
a member of any club that would accept me as a member.")
Creating a registry as a place to put GNS would be self-contradicting if
GNS cannot be added to the registry.

Brian



>
> Two more points below.
>
> Paul wrote:
> >
> >> This proposes two significant changes to the draft: make the registry
> FCFS and make entrance to it be by RFC. Those are both pretty heavy-weight
> for things *that are not part of our naming system*.
>
> Heavy for who?  Those wanting to create an entire naming systems for the
> Internet?  Look, from my perspective I am comfortable with ANY registry
> policy.  I've already provided a number of options to put the brakes on,
> if people are worried about a sudden rash of people building entire new
> name systems for the Internet.  So let's discuss.
>
> Martin followed up to Paul:
>
> >>   I strongly prefer "drop the registry" and let the non-DNS folks
> figure out how to deal with their own issues. After you see the next draft,
> if you think the registry with your two changes is needed, you can propose
> to add it back in.
> >>
> > The consequence of this (and I am looking at ISE here) will be that our
> > document will not be able to clearly define how to "use" alt as 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Timothy Mcsweeney]

Sounds like some people want .alt to be the internet police.  Nobody wants it 
except like 5 people not the entire world.



> On 10/20/2022 8:01 AM EDT Eliot Lear  wrote:
> 
>  
> Hi Vittorio
> 
> On 20.10.22 13:19, Vittorio Bertola wrote:
> > But IANA is not the registry for everything under the sun, it is the 
> > registry for things that fall under the purview of the IETF and are part of 
> > IETF standards. If we agree that names under .alt do not belong to and at 
> > the IETF, then it makes no sense for IANA to register them, nor this would 
> > be a wound to its role.
> 
> The flaw with that argument is that the registry would belong to no one 
> else.  The best we have is us, and ducking that says that when the IETF 
> faces tough problems, others *must *step in. And *that* weakens the IANA 
> function.
> 
> Eliot
> 
> ___
> 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] [Ext] Possible alt-tld last call?

[Eliot Lear]

Joe,

On 20.10.22 14:44, Joe Abley wrote:


To be clear, Eliot, you're not suggesting that these topics shouldn't be 
discussed here, right?


It's a working group mailing list.  Of course things can be discussed 
here.  My issue is that we are suffering from that lack of high bandwidth.


Eliot



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Joe Abley]

On Oct 20, 2022, at 08:26, Eliot Lear  wrote:

> On 20.10.22 14:14, Jim Reid wrote:
>> IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the 
>> IETF gets handed non-IETF problems, it keeps well away (perhaps after a 
>> discussion of the merits and/or scope of that problem).
> 
> As I wrote, we should discuss this in London, but I don't think that is a 
> fairer point of view.  Such a registry would naturally attach to the ALT TLD. 
>  Not doing this means half a job done, and nature abhors a vacuum.

To be clear, Eliot, you're not suggesting that these topics shouldn't be 
discussed here, right?

High-bandwidth face-to-face conversations over beer in the shadow of a 
collapsing quasi-imperial government are no doubt valuable, but it'd be a shame 
if anybody not travelling there interpreted comments about London to mean that 
their opinions aren't welcome.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Jim,

On 20.10.22 14:14, Jim Reid wrote:

IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF 
gets handed non-IETF problems, it keeps well away (perhaps after a discussion 
of the merits and/or scope of that problem).


As I wrote, we should discuss this in London, but I don't think that is 
a fairer point of view.  Such a registry would naturally attach to the 
ALT TLD.  Not doing this means half a job done, and nature abhors a vacuum.


Eliot

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Jim Reid]

> On 20 Oct 2022, at 13:01, Eliot Lear  wrote:
> 
> ducking that says that when the IETF faces tough problems, others must step 
> in.

IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF 
gets handed non-IETF problems, it keeps well away (perhaps after a discussion 
of the merits and/or scope of that problem).

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi Vittorio

On 20.10.22 13:19, Vittorio Bertola wrote:

But IANA is not the registry for everything under the sun, it is the registry 
for things that fall under the purview of the IETF and are part of IETF 
standards. If we agree that names under .alt do not belong to and at the IETF, 
then it makes no sense for IANA to register them, nor this would be a wound to 
its role.


The flaw with that argument is that the registry would belong to no one 
else.  The best we have is us, and ducking that says that when the IETF 
faces tough problems, others *must *step in. And *that* weakens the IANA 
function.


Eliot



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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Vittorio Bertola]

> Il 20/10/2022 10:15 CEST Eliot Lear  ha scritto:
> 
> As a matter of practicality, a registry surely will be form.  It is 
> simply a matter of whether the IANA will host it.  If the IANA does not 
> host it, then by shifting it elsewhere this group is actually weakening 
> the IANA function, and that would be sad.

But IANA is not the registry for everything under the sun, it is the registry 
for things that fall under the purview of the IETF and are part of IETF 
standards. If we agree that names under .alt do not belong to and at the IETF, 
then it makes no sense for IANA to register them, nor this would be a wound to 
its role.

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Eliot Lear]

Hi,

First, I would like us to continue to consult on the registry matter at 
least through the London IETF, and would ask the chairs for some time in 
London for this purpose.  I would also be available for side meetings 
with any interested party, before or during the IETF.  If people would 
like, we can grab a room for this purpose, if we can do so in the 
morning so that Martin can participate remotely (he is far to the east 
of London).


As a matter of practicality, a registry surely will be form.  It is 
simply a matter of whether the IANA will host it.  If the IANA does not 
host it, then by shifting it elsewhere this group is actually weakening 
the IANA function, and that would be sad.


Two more points below.

Paul wrote:



This proposes two significant changes to the draft: make the registry FCFS and 
make entrance to it be by RFC. Those are both pretty heavy-weight for things 
*that are not part of our naming system*.


Heavy for who?  Those wanting to create an entire naming systems for the 
Internet?  Look, from my perspective I am comfortable with ANY registry 
policy.  I've already provided a number of options to put the brakes on, 
if people are worried about a sudden rash of people building entire new 
name systems for the Internet.  So let's discuss.


Martin followed up to Paul:


  I strongly prefer "drop the registry" and let the non-DNS folks figure out 
how to deal with their own issues. After you see the next draft, if you think the 
registry with your two changes is needed, you can propose to add it back in.


The consequence of this (and I am looking at ISE here) will be that our
document will not be able to clearly define how to "use" alt as we are
not an authority on how to do things in the "non-DNS folks" community and
there is not way how to do that to date obviously.


There exist a number of possibilities to establish an external 
registry.  What is important is that one of them be mentioned in the ALT 
draft, so that others know where to look.  But let's get through London.


Eliot


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Martin Schanzenbach]

On 20.10.22 01:31, Paul Hoffman wrote:
> (Well, *that* will teach me not to go on vacation and not look at work email. 
> Or maybe I should do that more often!)
> 
> > The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
> > draft-ietf-dnsop-alt-tld.
> > 
> > We’ve reviewed the current draft closely and have some concerns that we 
> > feel need to be resolved before any effort to move the draft forward. 
> > (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
> 
> Warren and I will put out a new document before the draft submission cutoff 
> next week to resolve the concerns given in the message and thus move the 
> draft forward.
> 
> > 1. As far as I can tell, this draft does not comply with RFC 6761.
> 
> Correct.
> 
> > This is a problem for two reasons. First, this creates a process problem in 
> > that RFC 6761 is the standards-track document that specifies how the SUDN 
> > registry is to be administered, so a request that doesn’t meet the 
> > requirements in 6761 can’t (or at least shouldn’t) go into the registry. 
> 
> As we have seen, the IESG seems happy to publish standards-track documents 
> for items that will go in the Special-Use Domain Names registry that do not 
> comply with RFC 6761. There is no reason to believe that this draft will have 
> a different fate.
> 
> Having said that, we can add the text required by RFC 6761 in a way that 
> meets the 6761 requirements that the IESG has been ignoring, but doesn't say 
> anything more interesting than what is in the draft now. The IESG can then 
> decide if it meets their requirements.
> 
> > RFC 6761 section 4 asserts:
> > 
> > The specification also MUST state, in each of the seven "Domain Name 
> > Reservation Considerations" categories 
> > below, what special treatment, if any, is to be applied. 
> > 
> > The alt-tld draft ignores this MUST, without explanation (unless I missed 
> > it).
> 
> That's a fair point; we can add that.
> 
> > The substantive issue is that the questions in Section 5 are there to make 
> > sure there’s a full description of the expected handling of a proposed name 
> > by the assorted components that take part in DNS operations and protocol. 
> > The draft answers at least some of the Section 5 questions, but the answers 
> > are largely implied.
> > 
> > For example, the draft says that DNS resolvers seeing .alt names "do not 
> > need to look them up in the DNS context”, but a big part of the point of 
> > codifying these names is the assumption that queries will leak and DNS 
> > servers will see them.
> 
> Exactly right. Because .alt will not be in the global DNS root, those 
> requests will be treated like every other request with a TLD that is not in 
> the global DNS root: resolvers do not need to look them up in the DNS 
> context. When I became co-editor on the draft, I removed Warren's 6761ish 
> text because  saying "treat this like every other name". I see now that I 
> should have instead fixed the 6761ish text; we'll do that soon in the next 
> draft.
> 
> > (“Do not need to” isn’t even “SHOULD not”.)
> 
> Exactly right. More importantly, it is not "MUST NOT". In the case of a TLD 
> that is not in the global DNS root, RFC 1035 is already completely clear, and 
> this document should not update RFC 1035. RFC 6761 does not require 
> SHOULD/MUST language.
> 
> > It’s implied that .alt is simply not in the public DNS root zone
> 
> That is not an "implication", it is explicit because the zone will be part of 
> the RFC 6761 registry. We will add a redundant sentence in the introduction 
> to make this clearer.
> 
> > and the root servers (or better yet, any intermediate resolver) should 
> > answer “name error”/NXDOMAIN for such queries.
> 
> Can you show where there is that implication? If so, we will certainly nuke 
> it from the draft. .alt should be treated by all systems just like any TLD 
> that is not in the global DNS root, and this draft should not update RFC 1035 
> to list the dos and don'ts for those systems. This is the same for every 
> other TLD in the 6761 registry.
> 
> > But this should probably be said explicitly, because people who configure 
> > DNS servers and services shouldn’t have to guess what’s being implied here. 
> > (The WG discussed the possibility that such queries should be blackholed 
> > and not answered at all, which is in some ways an obvious answer. 
> > Clarification of why this was discarded might also be helpful.)
> 
> I fully disagree that adding a section of "something we discussed that we 
> decided not to do" will be helpful: it will be confusing.
> 
> > So, the current draft isn’t meeting the requirements for the registry, and 
> > also doesn’t clearly answer substantive questions about what DNS operators 
> > are expected to do.
> 
> It meets the requirements of the IESG; it does not meet the requirements of 
> the RFC because those requirements in that RFC is being actively ignored (for 
> good reason, 

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Paul Hoffman]

(Well, *that* will teach me not to go on vacation and not look at work email. 
Or maybe I should do that more often!)

> The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
> draft-ietf-dnsop-alt-tld.
> 
> We’ve reviewed the current draft closely and have some concerns that we feel 
> need to be resolved before any effort to move the draft forward. (Suzanne 
> wrote this but it’s been discussed among all of the co-chairs.)

Warren and I will put out a new document before the draft submission cutoff 
next week to resolve the concerns given in the message and thus move the draft 
forward.

> 1. As far as I can tell, this draft does not comply with RFC 6761.

Correct.

> This is a problem for two reasons. First, this creates a process problem in 
> that RFC 6761 is the standards-track document that specifies how the SUDN 
> registry is to be administered, so a request that doesn’t meet the 
> requirements in 6761 can’t (or at least shouldn’t) go into the registry. 

As we have seen, the IESG seems happy to publish standards-track documents for 
items that will go in the Special-Use Domain Names registry that do not comply 
with RFC 6761. There is no reason to believe that this draft will have a 
different fate.

Having said that, we can add the text required by RFC 6761 in a way that meets 
the 6761 requirements that the IESG has been ignoring, but doesn't say anything 
more interesting than what is in the draft now. The IESG can then decide if it 
meets their requirements.

> RFC 6761 section 4 asserts:
> 
> The specification also MUST state, in each of the seven "Domain Name 
> Reservation Considerations" categories 
> below, what special treatment, if any, is to be applied. 
> 
> The alt-tld draft ignores this MUST, without explanation (unless I missed it).

That's a fair point; we can add that.

> The substantive issue is that the questions in Section 5 are there to make 
> sure there’s a full description of the expected handling of a proposed name 
> by the assorted components that take part in DNS operations and protocol. The 
> draft answers at least some of the Section 5 questions, but the answers are 
> largely implied.
> 
> For example, the draft says that DNS resolvers seeing .alt names "do not need 
> to look them up in the DNS context”, but a big part of the point of codifying 
> these names is the assumption that queries will leak and DNS servers will see 
> them.

Exactly right. Because .alt will not be in the global DNS root, those requests 
will be treated like every other request with a TLD that is not in the global 
DNS root: resolvers do not need to look them up in the DNS context. When I 
became co-editor on the draft, I removed Warren's 6761ish text because  saying 
"treat this like every other name". I see now that I should have instead fixed 
the 6761ish text; we'll do that soon in the next draft.

> (“Do not need to” isn’t even “SHOULD not”.)

Exactly right. More importantly, it is not "MUST NOT". In the case of a TLD 
that is not in the global DNS root, RFC 1035 is already completely clear, and 
this document should not update RFC 1035. RFC 6761 does not require SHOULD/MUST 
language.

> It’s implied that .alt is simply not in the public DNS root zone

That is not an "implication", it is explicit because the zone will be part of 
the RFC 6761 registry. We will add a redundant sentence in the introduction to 
make this clearer.

> and the root servers (or better yet, any intermediate resolver) should answer 
> “name error”/NXDOMAIN for such queries.

Can you show where there is that implication? If so, we will certainly nuke it 
from the draft. .alt should be treated by all systems just like any TLD that is 
not in the global DNS root, and this draft should not update RFC 1035 to list 
the dos and don'ts for those systems. This is the same for every other TLD in 
the 6761 registry.

> But this should probably be said explicitly, because people who configure DNS 
> servers and services shouldn’t have to guess what’s being implied here. (The 
> WG discussed the possibility that such queries should be blackholed and not 
> answered at all, which is in some ways an obvious answer. Clarification of 
> why this was discarded might also be helpful.)

I fully disagree that adding a section of "something we discussed that we 
decided not to do" will be helpful: it will be confusing.

> So, the current draft isn’t meeting the requirements for the registry, and 
> also doesn’t clearly answer substantive questions about what DNS operators 
> are expected to do.

It meets the requirements of the IESG; it does not meet the requirements of the 
RFC because those requirements in that RFC is being actively ignored (for good 
reason, IMHO). It does not currently answer those substantiative questions 
because the answer is already in RFC 1035, but we will add them to the next 
draft to help move this along.

> This makes me uncomfortable doing a WGLC without a new rev. It would