Re: [DNSOP] Alternative Special-Use TLD problem statement draft

["Adrien de Croy" <[e-mail]>]

OK, if we look at those 1 at a time.

RFC1918 defines private IP address ranges.

Stating that a reverse lookup for a private IP should never be encoded 
onto a DNS packet and sent to a DNS server flies in the face of 
practice, and there are many many useful scenarios where this is done.

I don't think we are being precise enough when we say "shouldn't hit the 
DNS".  PTR lookups for private IPs is a case where we do it all the time 
on private networks - use DNS to query a local DNS server for the name 
associated with a private IP.  If we took this to heart and prevented 
this by special casing such lookups in our DNS resolver code, we would 
break a lot of legitimate stuff.

It gets more blurred when your ISP assigns you a private IP address.  In 
this case PTR lookups for addresses in the subnet may well be legitimate 
against the ISP's name server.


Looking then at 2606

the top level reserved names

.test
.example
.invalid
.localhost

and

example.com
example.net
example.org

It's clear that the reservation of the second level domains is not 
behaving as we intend with 6761, since I can do a resolution of these 
names with DNS, and connect to the servers with HTTP.

As for the top level ones, localhost is about the only one where you 
typically see actual special code in resolvers AFAICT.

It's one thing to reserve a TLD.  It's another thing to actually use it 
for something non-DNS.

I don't have a problem with necessarily reserving TLDs to never be used. 
  But DNS resolvers should not be making decisions about that, and as 
soon as you reserve one, and then start using it you have these leakage 
problems that TOR is seeing.

I'm also not convinced that there is an "Internet namespace" that's 
usefully different to and a superset of the DNS namespace.  It seems a 
bit of a logical paradox to have the universe being bigger than the tree 
but also being in the tree.  Or is "Internet namespace" the new name for 
the DNS namespace and DNS namespace has been demoted to only being the 
part of the tree that is left after you add these other TLDs.  Seems a 
bit circular to me.

So, we're left with the 1 single TLD that is the problem and that's 
.onion, and regardless of the problems that is demonstrating, we wish to 
roll out more of these.

Adrien



------ Original Message ------
From: "David Conrad" <[e-mail]>
To: "Adrien de Croy" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 7/04/2016 1:19:58 p.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>Adrien,
>
>>  I think we still need to answer the question about whether DNS 
>>namespace should be polluted for non-DNS resolution.
>
>I believe your question is wrong.
>
>The "DNS namespace" can't be polluted for non-DNS resolution because 
>the DNS namespace is, by definition, only comprised of names that can 
>be resolved via the DNS.  The "Internet namespace" is larger than that. 
>  Even before RFC 6761, there were names that should never hit the DNS, 
>specified in RFCs 2606 and 1918. RFC 7686 added "onion". A number of 
>folks want to add more.
>
>In my view, the real question here is what is the distinguishing 
>characteristic(s) and processes by which an "Internet name" is 
>categorized as a "DNS name" (which, at least at the top level, 
>presumably falls under ICANN community-defined policies) and those fall 
>under a different categorization.
>
>Regards,
>-drc
>(speaking only for myself)
>
>
>