Noel Chiappa wrote: > > From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> > > > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf