Keith -
thanks for the careful elaboration. I agree with you that it is very
important to consider the DNS-related issues that you identified when
designing methods that make new use of the DNS. But note that the
hostname-oriented network protocol stack architecture, as proposed in
[1], does not change the semantics of DNS hostnames. It continues using
DNS hostnames as an alias for a set of IP addresses. And as today, for
this is does not matter whether the IP addresses in a set are from a
single host or from multiple hosts. I therefore do consider the use of
the DNS in [1] feasible.
In a nutshell, the hostname-oriented stack architecture functions like
this: It provides a new, backwards-compatible API through which
applications can initiate connections by specifying a pair of service
name and DNS hostname. The service name is a well-known string
replacing the overloading of port numbers for the same purpose, and the
hostname maps to the set of IP addresses through which the service is
currently reachable. (There are further arguments to connection
initiation, but those are not relevant to this discussion.) Similarly, a
DNS hostname can be specified to filter incoming connections based on
the IP addresses that this hostname currently maps to. IP-address-
specific functions are centrally performed further down the stack so
that applications do not (necessarily) have to deal with them. This
includes hostname resolution, address translator traversal and
connectivity verification, address selection, as well as potentially
mobility and multi-homing support.
So the hostname-oriented stack architecture continues with the semantics
of DNS hostnames that we use today: The IP addresses to which a
hostname points do not necessarily have to be of the same physical
machine, even though the terminology "hostname" may suggest that they
do. This flexibility regarding the physical counterpart of a hostname
is actually an attractive feature: It provides a convenient tool for
abstracting from the implementation of a particular service, which
generally is irrelevant to the host connecting to a service. You are
right in that some applications may need to obtain a handle to a
specific service instance in order to be able to resume an intermitted
session. And yes, a hostname-oriented stack architecture should permit
obtaining such a handle, just as it should support legacy applications
that want to know which IP address they are communicating with.
The three main benefits of the hostname-oriented stack architecture are
consequently as follows:
- Application programming becomes potentially easier.
- IP address changes, such as for mobility or multi-homing, do not
disrupt ongoing sessions. (This is the same advantage that
identifier-locator split solutions provide. Yet in the case of a
hostname-oriented stack architecture, this is achieved without the
extra complexity that a new level of indirection requires for
mapping and security purposes, and which e.g. Mobile IP introduces
through its concept of a "stable IP home address".)
- Transition to IPv6 no longer affects applications.
The reason for all of these benefits is that applications use DNS
hostnames exclusively and do not have to deal with IP-address-related
functions. And still, the semantics and the use of DNS hostnames remain
as they are today. And I hope this resolves your concerns.
- Christian
[1] Christian Vogt: Towards A Hostname-Oriented Network Protocol
Stack for Flexible Addressing in a Dynamic Internet,
http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf
On Nov 30, 2008, Keith Moore wrote:
while it's true that IP addresses don't have the right semantics,
neither do DNS names.
What aspects of DNS semantics makes them inappropriate for this
function?
I could have been a bit more precise and said that DNS names as
currently used with A, AAAA, MX, and SRV records don't have the right
semantics. Part of the reason is that we don't distinguish between
DNS
names that are used to name services (which may be implemented on
multiple hosts, each of which has one or more A/AAAA records) and DNS
names that are used to name single hosts (which may have multiple A/
AAAA
records for other reasons). And the same DNS name may be used
sometimes
as a host name (via A or AAAA records, say when using ssh) and
sometimes
as a service name (via MX or SRV records).
In practice DNS names are often sufficient for establishing an initial
association with a service instance (where we don't care which
instance
we're associate with, as long as the name associates us with one
instance of that service), but they're not sufficient for referral
(where it actually matters which instance of a service we associate
with, and talk to).
Another part of the problem is that DNS names are not used
consistently
from one protocol/service to another. A DNS name can be a host, a
service, a collection of email addresses, a collection of resources,
and
several other things. Some protocols use A or AAAA records and a
port #
which is implicitly part of the name, other protocols have a "default
port" which can be overridden if explicitly specified, and in other
protocols the port number must be explicitly specified. A few
protocols
and services use SRV records. Some services want to be zero
configuration so they don't even have names, or the names that they
use
are supposed to resolve differently depending on, say, network
location.
It might seem like SRV records would provide an adequate mechanism for
implementing endpoint names, but many protocols aren't specified to
use
them (or specify a different mechanism for associating a name with an
address). SRV records are also awkward in that they constrain the
names that can be associated with them, and they require port # and
address to be specified in different places in the DNS hierarchy -
or at
least, in different RRs.
I'm often saying that DNS is often out of sync with reality. There
are
lots of reasons why this can happen. One reason is that old
information
which is cached can obscure the fact that the information is changed.
This may happen because TTL was not well chosen. It also happens
because most things that use DNS records don't keep track of TTL, and
the APIs that are usually used don't facilitate doing so. More
generally, TTL isn't always sufficient because often you don't know
when
data will need to be changed. And DNS doesn't have any way of
shooting
down cached entries other than TTL expiration.
Other reasons that DNS is often out of sync with reality are: DNS
servers tend to be managed by parties with a distant relationship to
those managing hosts and services; configuration errors of several
different types can cause queries to be routed to servers that are no
longer being maintained; dynamic update is not universally used, etc.
Could you use DNS names and protocols to build an adequate endpoint
naming and resolution service? Maybe, but I think it would be
necessary
or at least appropriate to (a) define new RRs for this purpose, (b)
define a new naming convention for use by endpoint names that puts
them
in separate zones than for other names (similar to that done with
SRV),
and do that in such a way that it's convenient for those zones to be
managed by the same parties that manage the endpoints themselves, (c)
provision servers for use in answering queries for endpoint names,
differently than for "normal" DNS names, (d) define new APIs for
coining
new endpoint/instance names that can be used by applications to define
new instances on the fly and to maintain their name to location
mappings, and which generate and distribute dynamic update credentials
for use with those endpoint/instance names to whatever application
coined the names, (e) set TTL to a very low value and define a way of
replicating the data that ensures it's always current (and if a
replica
can't be sure that it's current it stops answering queries). etc.
If you could specify an 'ideal' endpoint name, what semantics and
syntax
would it have? (Serious query, in case it wasn't obvious.)
as we discovered during the URN discussions, ideal naming is very
difficult to pin down.
I actually think that some profile of DNS _names_ could be "good
enough"
and that it might not be worth the tremendous effort required to
establish a completely separate naming system and hierarchy for
endpoint
names.
The bigger problem is that we have a large investment in
infrastructure
and (even more importantly) in mindshare that says that DNS servers
are
configured in such a way, provisioned in such a way, replicated in
such
a way, maintained in such a way (and who maintains them), etc. There
are well-entrenched ideas about the granularity of zones and how they
are delegated, and so forth. There is a variety of practice about how
to keep DNS in sync with reality regarding IP addresses (e.g. does the
DHCP server update DNS or does the host?). There is also split DNS to
contend with. All of this practice is adapted (if poorly) to dealing
with DNS names as they are currently used, and using DNS names as
endpoint ids would be a significant departure from this.
I also think that if people in general haven't yet figured out how to
make DNS as it is work reliably and be in sync with reality, they're
going to have an even more difficult time making DNS service work well
enough for endpoint ids. But it might be that this is less of a
protocol issue and more of a human interface issue.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf