Re: [DNSOP] Some distinctions and a request - Have some class?

[Suzanne Woolf <[e-mail]>]

Hi,

On Jul 3, 2015, at 11:18 AM, Patrik Fältström <[e-mail]> wrote:

> Unfortunately I think we all in this discussion [again] mix up discussion about DNS with the discussion about the name space that is in use for example by what we know as "the domain name system rooted at the root zone managed by IANA".
> 
> I think we just must force ourselves to stay focused on namespace management. A portion of that name space is to be accessed using DNS. Some other portions of that very same name space is access using other mechanisms.

If I've followed the discussion so far-- which has been very good, and exactly what I think we've been working towards for quite awhile now-- this is key to making any kind of progress beyond beauty contests for the IETF to judge about "things that look like TLDs" and confusion for developers of new technology who want to use DNS-compatible names.

> This is not easy, but I think that is the way to attack the problem.
> 
> And given such a view, IETF is to decide what strings are to be used "by other mechanisms" so that [for example] they can and should never ever be accessed by the domain name system.

As long as administrators can configure their own namespaces, the IETF has limited power in this area, and IMHO shouldn't chase more. We can provide advice, however, such as encouraging the use of .alt names in the same kind of "protocol switch signal" names that people are starting to scatter arbitrarily through the namespace.

> This while ICANN have processes for deciding what string should be TLDs, based on the standards created by for example the IETF.

It does seem to me that an important feature here is that "TLD" as we're using it is "name in the root zone (or root zone space), to be managed within a context that assumes DNS protocol and semantics as well as DNS-compatible name space." (That is, people using the term "TLD" to refer to single-label DNS-compatible name are incorrect-- "onion" is not a TLD, and that's largely the point.)
> 
> Maybe a document is needed that describes that namespace? How it is partitioned?

Andrew requested on the list last week that we discuss the possibility of 6761bis in Prague, and the draft agenda (to be posted in the next couple of days) does include a slot for that. In the meantime, let's continue here.


best,
Suzanne

> On 3 Jul 2015, at 16:21, manning wrote:
> 
>> Thanks for that.  The original claim was that these name spaces were global in scope, but not part of the Internet.
>> So I took that as face value.  Your example, while perhaps a valid interpretation, is not what was asked for.
>> If it is, then namespace/class specific applications/extentions need to be developed/deployed, OR folks need to suck it up and just use the Internet portion of the DNS (and its associated rules, e.g. new TLDs are defined by ICANN)
>> 
>> /bill
>> 
>> 
>> On 3July2015Friday, at 7:01, Warren Kumari <[e-mail]> wrote:
>> 
>>> On Fri, Jul 3, 2015 at 9:43 AM, manning <[e-mail]> wrote:
>>>> Actually, there IS an escape method already defined.  We just don’t use it much these days.
>>>> It’s called  “class”
>>>> 
>>>> There is no reason these alternate namespaces should sit in the IN class.  they could/should be in their
>>>> own class, like the old CHAOS protocols.   So  a class  “ONION” or “P2P” would work out very nicely.
>>> 
>>> Yup, but the problem is that people want to be able to enter the
>>> alternate namespace names into existing applications (like browsers,
>>> ssh, etc), just like a "normal" DNS name. They want to be able to
>>> email links around (like https://facebookcorewwwi.onion/ ) and have
>>> others click on them, etc.
>>> 
>>> There is no way that I know of to tell e.g Safari to look this up in a
>>> different class... and, even if there were, they would *still* leak,
>>> because people are lazy...
>>> 
>>> W
>>> 
>>>> 
>>>> After all it’s the Domain Name System.  (can comprehend names in multiple domains, not just the Internet)
>>>> 
>>>> manning
>>>> [e-mail]
>>>> PO Box 12317
>>>> Marina del Rey, CA 90295
>>>> 310.322.8102
>>>> 
>>>> 
>>>> 
>>>> On 2July2015Thursday, at 20:56, manning <[e-mail]> wrote:
>>>> 
>>>>> 
>>>>> On 2July2015Thursday, at 18:21, Robert Edmonds <[e-mail]> wrote:
>>>>> 
>>>>>> manning wrote:
>>>>>>> There in lies the problem.  These systems have no way to disambiguate a local v. global scope.
>>>>>>>   It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets
>>>>>>>   and no way to attempt DNS resolution.   Or they need to ensure that DNS resolution occurs after every other “name lookup technology”
>>>>>>>   which is not global in scope.
>>>>>> 
>>>>>> I don't understand this point.  Since Onion hidden service names are
>>>>>> based on hashes derived from public keys surely they're globally scoped
>>>>>> (barring hash collisions)?
>>>>>> 
>>>>>> --
>>>>>> Robert Edmonds
>>>>> 
>>>>> If they _are_ globally scoped,  what part of the local system decides which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the DECnetV, the IXP, or the DNS…
>>>>> where is search order determined?  Does first match in any namespace win?  What is the tiebreaker when there are label collisions between namespaces?
>>>>> 
>>>>> 
>>>>> /bill
>>>> 
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>>> 
>>> 
>>> -- 
>>> I don't think the execution is relevant when it was obviously a bad
>>> idea in the first place.
>>> This is like putting rabid weasels in your pants, and later expressing
>>> regret at having chosen those particular rabid weasels and that pair
>>> of pants.
>>> ---maf
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop