[Top] [All Lists]

outdated thinking about domains and hosts

2008-04-01 22:38:23

Some of the arguments being put forth here about the use of AAAA records as fallback for missing MX records seem to be based on a very old and long-obsolete idea of the relationship between domain names and hosts.

Many years ago, it used to be the case that a domain name was the name of a host. More precisely, a domain name was associated with a host's IP address, and the vast majority of hosts had exactly one network interface and one IP address. In that world, it was easy to think of the host and domain and IP address as all being more-or-less pointers to the same thing.

Of course, in those days the vast majority of hosts were also multi-user timesharing computers. Hosts were expensive and because of this it was generally expected that a host would serve a community of users rather than a single user. So it was natural to think of a community of users as having a host that provided computing resources, and to associate that community with the host's domain name and an IP address. Several of the early Internet services were built around the idea of being able to remotely access a user's resources or information on a host: finger, ftp, telnet, and of course email.

The first nail in the coffin of this idea was RFC 974. The introduction of MX records broke the host=domain=address relationship because MX records allowed email to be sent to hosts that were not even connected to the Internet. More generally, MX records made it possible to create domains for use in email addresses that didn't correspond to any actual host anywhere. All that mattered was that the primary MX servers for a domain knew what to do with mail that was sent to a user at that domain.

Since then a number of things have further weakened the host=domain=address relationship:

- As the Internet grew, in order to make various services scale to handle the demand, it often became necessary to implement a service with large numbers of host that shared a single domain name - or even sharing a single IP address using special-purpose load-sharing NATs.

- Eventually it was realized that it was very convenient to associate a service with a domain name (say for marketing purposes or ease-of-use) even when the service required only a small fraction of the resources available on a single host. The result was what is known as "virtual hosting" where a single host provides services that are associated with a large number of domains, at much lower cost than would have been required to provide a separate host for each domain. Extensions to HTTP made it possible for a web server to handle requests for URLs in different domains even though they were associated with the same IP address. Other workarounds have been found for other protocols (e.g. the common POP/IMAP/FTP convention of using usernames of the form "user(_at_)domain" during login).

For similar reasons, it is now common for a single host to be accessible via multiple IP addresses.

- SRV records further weakened the relationship between domains and hosts by allowing that relationship to be specified on a per-service basis, for application protocols defined to use SRV.

Today, the vast majority of references to a domain name, whether in email or in a URL or otherwise, DO NOT refer to a specific host. Domains are no longer equivalent or even nearly equivalent to host names, and haven't been for a long time.


How does this relate to AAAA fallbacks?  Simply this:

The argument that a host ought to be able to run email without registering an MX record for its domain is specious. In general, a host does not have a designated domain name or even a designated address anymore. Even a host as modest as a typical desktop PC can support an arbitrary number of services that are associated with an arbitrary number of domains.

Yes, there might be a domain associated with a host's IP address via DNS PTR lookup, but that's irrelevant because very few applications care what domain the PTR record points to. Certainly email doesn't care, except for logging. And quite often that domain is meaningless - just something provided by the ISP because certain stupid applications won't work unless there's a PTR record there. (As if having a PTR record pointing to a meaningless domain name were an indicator of anything useful.)

One consequence of this is that the owner of a host isn't really prevented from running an email server on that host by his inability to write an MX record to any particular zone. I see three cases:

1) The owner of the host also owns one or more domains that he can associate with the host, and he has write permission to the DNS zones for those domains. He can create MX records for those domains.

2) Like case (1) but for some reason the interface to those DNS zones is dysfunctional and won't let him create MX records. But since the owner of the host also owns those domain names, he can move them to other DNS hosting providers with less dysfunctional interfaces. And DNS providers will get their act together when they realize they're losing business. problem solved.

3) The owner of the host doesn't own the domain name that someone has associated with that host. In that case, the host owner simply doesn't have the right to create email addresses at that domain. That right belongs to the domain owner. The host owner can still run an email server on his host, he just can't insist that email addresses that are associated with someone else's domain should be handled by his host.


<Prev in Thread] Current Thread [Next in Thread>
  • outdated thinking about domains and hosts, Keith Moore <=