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" <d...@virtualized.org>
To: "Adrien de Croy" <adr...@qbik.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
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)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
