On 24 Nov 2015, at 21:40, Patrik Fältström wrote:
I have read this draft and have a number of comments. I can not say
these are the only ones, but at least some :-)
This is only the beginning of the conversation, so: yes. :-)
The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, but which have syntactically-
similar namespaces.
I claim that if it is syntactically similar and the names are used
interchangeable in protocols (see below) we actually DO talk about use
of the same namespace. This is the camel in the tent, and I think we
should just admit, or say clearly whether we do talk about, which I
think we do, one name space with multiple resolution mechanisms.
We need to be *very* careful here. Are names that are
"syntactically-similar" actually "interchangeable". I propose that they
are not; only names that are "syntactically-identical" are
interchangeable. There are different name schemes that are "similar"
that are not interchangeable. For instance, I have heard that some of
the name schemes currently being discussed allow labels over 64 octets
long.
We also need to be very careful to say whether a name scheme is
syntactically-identical to RFC 1035 "domain names" or to RFC 1123 "host
names with the preferred name syntax" (LDH). For the latter, we can
probably say "interchangeable", but we need to think hard about the
former.
When an end-user triggers resolution of a name on a system which
supports multiple, different protocols for name resolution, it is
desirable that the protocol to be used is unambiguous, and that
requests intended for one protocol are not inadvertently addressed
using another.
It is not so much different protocols as different resolution
mechanisms. If you say "protocol" here, it might sounds like if with
the DNS protocol you can not use multiple different resolution
mechanisms (which I think one can -- one of them using the root
managed by ICANN).
+1
Such usage, which a few commenters have referred to as "protocol
switching," is not limited to "protocol switch" in the strict sense
of indicating specific protocols on the wire. It could indicate to
switch to another name space (eg .onion), use a different protocol
(eg tor, or mdns), or indicate to use a local DNS scope by not using
the DNS root for name resolution (eg .home in homenet) or something
else altogether.
It is important (which I think also Stephane indicated) that we talk
about different resolution mechanisms for the name itself. We do not
talk about how to access the service in question.
+1 again.
At the time of writing, three top-level domain names reserved by
inclusion in the Registry are used by name resolution protocols other
than the DNS:
LOCALHOST is used to refer to the host on which the name
resolution takes place, without reference to the DNS;
LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
which is similar in some respects to the DNS, but which uses
different well-known port number and is limited to a particular
multicast scope;
ONION is used to construct names that designate anonymous hidden
services reachable via the Tor network using onion routing.
I think a better text to describe ONION would be:
ONION is used to construct names that designate
services reachable via the Tor network using onion routing.
Unfortunately, I agree. <insert apologies for my federal government
here>
What about EXAMPLE?
Which name resolution protocol uses EXAMPLE? RFC 2606 reserves it for
examples in documentation.
The lack of a more elegant way to specify a
name resolution protocol in (for example) a URI amounts to an
architectural oversight.
Well...in the architecture we have both the URI scheme and if you look
further the URN definition to manage all different kind of switches.
And we do not have to wake up the old discussion again whether
HTTP://EXAMPLE.COM/ in reality should be URI:HTTP://EXAMPLE.COM/
I think the key issue here is that the different "strings" that look
like "domain names" (i.e. are within the same name space) are used
interchangeable wherever in the URI (or even URN) definition where
"domain names" are to be used.
Disagree, and I agree with the text in the draft. It is an oversight on
the part of the URI spec that it does not say "these are only for names
in the DNS namespace; if you want a different name, use URNs".
If we accept the notion that the most significant label of a domain
name is actually a protocol switch, it implies that we are actually
building a catalog of all top level domains that explain which are
are switches.
What about not-yet-allocated strings in this catalog?
Yes, exactly. This is a major problem in this part of the draft. It is
begging us to predict the future, and we suck at that.
I think it is important to say that as of today (at least), the
default resolution mechanism is to use the DNS, although a
non-existing string today imply one apply the search path algorithm to
chase down names.
+1
In the case of [I-
D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
might lead to disclosure of private information that, in some cases,
might pose a risk to the personal safety of end-users.
More, less or similar to leakage when people use non-FQDN and their
search path create surprises?
More, because .onion was designed to provide data- and metadata-hiding,
and the search path mechanism was not.
This document aims to provide a problem statement that will inform
future work. Whilst security and privacy are fundamental
considerations, this document expects that that future work will
include such analysis, and hence no attempt is made to do so here.
See among other places SAC-057
<https://www.icann.org/en/system/files/files/sac-057-en.pdf>
Yes, this should be added as a useful informational reference.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
