Subject: Re: The internet architecture

From: [email-masked] (Noel Chiappa)
Date: Sun, 30 Nov 2008 10:11:59 -0500 (EST)

> From: Keith Moore <[email-masked]>

    > 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?
If you could specify an 'ideal' endpoint name, what semantics and syntax
would it have? (Serious query, in case it wasn't obvious.)

	Noel
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Nov 2008 11:30:36 -0500

> 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.

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Nov 2008 18:43:55 -0800

> What aspects of DNS semantics makes them inappropriate for this function?

And therein lies what seems to be the challenge in most id/locator discussions: 
  careful specification of the required characteristics for the ID.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf