_____                   _                  _____            _____       _ 
  |     |___ _____ ___ _ _| |_ ___ ___ ___   |  _  |___ ___   | __  |___ _| |
  |   --| . |     | . | | |  _| -_|  _|_ -|  |     |  _| -_|  | __ -| .'| . |
  |_____|___|_|_|_|  _|___|_| |___|_| |___|  |__|__|_| |___|  |_____|__,|___|
  a newsletter by |_| j. b. crawford               home archive subscribe rss

>>> 2021-03-16 can I get your number domain (PDF)

For a little while I've been off my core topic of computers and the problems with them, mostly because I started talking about telephones and once that happens I am unstoppable. But I will fight through the withdrawal symptoms to talk about something other than telephone numbers, which is DNS.

And also telephones.

Starting in the late 1990s and continuing into the 2000s, there was a lot of hype around "unified communications." This unification was the idea that telephones and computers would merge into devices which could serve the same applications. ISDN could be viewed as an early part of this vision, but much of "unified communications" focused on being able to send and receive instant messages and telephone calls between any two devices---computers, phones, etc.

This required bringing telephony technology into the realm of computer technology, thus spanning the substantial divide in technical architectures. Ironically this divide is getting narrower and narrower today due to all-IP and converged network trends, but not by any effort of the unified communications community which, in practice, has been largely limited to large enterprise deployments that work poorly. Consider Exhibit A, Microsoft Lynq, excuse me, Skype for Bidness.

Let's take ourselves back in time, though, to the halcyon days of the early 2000s when telephones and computers seemed ripe for unification.

One of the big challenges that unification of telephones and telephone-like computer applications (voice chat, video chat, etc) have long faced and still faced today is addressing. There is no unified addressing scheme between phones and computer software. Now, today, we've all resolved to just avoid this problem by accepting that it is ludicrous that you could use a service to contact someone who does not use the same service. Sure Facebook Messenger and the Instagram chat are operated by the same vendor and serve apparently identical purposes but, duh, of course you can't send messages between them, they are different apps.

Well, before this particular sort of defeatism completely set in, there was a desire to be able to create a single standard addressing system for telephones and computer applications.

The story starts more or less with E.164. E.164 is an ITU standardization of global telephone numbers. The standard itself is largely uninteresting, but for practical purposes it is pretty much sufficient to say that when you write a phone number that is prefixed by a +, followed by a country code, followed by a national phone number (called the nationally significant number or NSN), and the whole thing does not exceed 15 digits, you are writing the phone number in E.164 format. Although you should also leave out whatever extra formatting characters are conventional in your nation. So if you wanted to call Comcast, for example, the E.164 number would be +18002662278 [1], accepting also that the + has a tenuous connection to the E.164 standard but is still very useful, especially in countries without a fixed number length.

So from a technical perspective, we could say that telephones use E.164 addressing.

What kind of addressing do computers use, for messaging purposes? Well, there are warring standards for computer communications addressing ranging from the ICQ number to the email address to the tripcode. But none of that is really "unified," is it? What we, or at least the engineers of the early 200s, view as a unified addressing scheme is the same one we use at the lower level of networking: DNS.

Perhaps you can see where this is going. The internet may not be a truck that you can just dump things in, but DNS is, so we'll just take E.164 addresses (phone numbers) and shove them into DNS!

This is one of the various and sundry uses of the internet's most mysterious gTLD, .arpa. The .arpa TLD is officially called the Address and Routing Parameter Area, but more usefully I call it the DNS Junk Drawer. .arpa is most widely used for "reverse DNS," where IP addresses are shoved back into the name end of DNS, and so we can do phone numbers basically the same way.

Remember Comcast? +18002662278? We could also write that as, if we were sadists. Every digit is its own level of the hierarchy because global phone numbers are not constrained to any reasonable hierarchy. The digits are reversed for the same reason they are reversed for reverse-DNS PTRs: DNS obviously orders the hierarchy the wrong way (we could say it is little-endian), when everything else does it the right way, so most forms of hierarchical addressing have to be reversed to fit into DNS [2].

These telephone DNS records are typically expected to contain a record with the type NAPTR. NAPTR, generally speaking, is intended to map addresses (more properly URNs) to other types of addresses. For example, E.164 to SIP. So the NAPTR record, typically, would provide an address type of E2U+sip which indicates ENUM (E.164 number mapping) to the SIP protocol.

Fascinatingly, the actual payload of an NAPTR record is... a regular expression. The regular expression specifies a transformation (with capture groups and the whole nine yards) from the original address (the E.164 number) to the new address type. In theory, this allows optimization of NAPTR records at higher levels of the hierarchy if components of the original address are also used in the new address. This is one of many areas of DNS that are trying perhaps too hard to be clever.

The freshly obtained SIP address has a domain component which can then be fed to the NAPTR system once again to discover where to find a SRV record which indicates where to actually connect.

As you might suspect, this system was never meaningfully used. A few countries reportedly actually operate something in their part of the E.164 ENUM architecture, but not on any meaningful basis.

Since that proposal for unifying telephone addressing with DNS was such a success, the industry is naturally doing the same thing again. An enterprising UK company called Telnames but doing business as Telnic or possibly the other way around, that point is oddly confusing, operates the "award winning" gTLD .tel [3].

The .tel TLD is so minor and poorly marketed that it's sort of hard to tell exactly What Their Deal Is, but "tel is the only top level domain (TLD) that offers a free and optional Telhosting service that allows individuals and businesses to create and manage their very own digital profile."

While .tel is described as some sort of vague telecom unification thing of some unspecified nature, the actual implementation is fairly uninteresting. .tel domains basically come with free hosting of a very minimal profile site which lists various contact information. So basically Linktree but less successful. This already seems to be a weakened form of the original, award-winning .tel vision, and Telnic has abandoned the concept almost entirely by announcing a policy change such that .tel domains can be used for any purpose, with .tel essentially becoming a plain-old land grab gTLD.

The DNS system as accumulated quite a bit of cruft like this. Because it is fairly flexible and yet widely supported, it's very tempting to use DNS as an ad hoc database for all kinds of purposes. Further, computer science being the discipline concerned primarily with assigning numbers to things, there is an unending series of proposal for various name-translation schemes that end up in DNS and then are never used because they're too complicated, don't solve a real problem, or both, as was the case with ENUM.

That is, the lack of a unified addressing scheme was never the thing standing in the way of unified communications. The thing standing in the way of unified communications is, put succinctly, capitalism, as in the absence of a large single purchase driving the requirement (e.g. enterprise sales) there is very little financial incentive to make any two systems interoperable with each other, and there is often a clear financial incentive not to. Shoving regular expressions into DNS can do a lot of things, but fundamentally restructuring the Silicon Valley app mill is not one of them.

Of course, contrary to all reason, phone numbers have made the jump to computer addressing in one way that absolutely delights me: telephone number domain names. Some mail order businesses branded themselves entirely around an excellent 1-800 number, and their awkward transition to the internet leads to things like 1800contacts.com. Another example is 1800wxbrief.com, which is the result of a potent combination of a vanity phone number and government contracting.

See? DNS does handle phone numbers!

[1] In practice it's more complicated because E.164 tries to account for dialing prefixes and etc, but none of that is really important, now or ever.

[2] I rarely say that Java and/or Sun Microsystems have gotten anything right, but Java provides a prominent example of how DNS names should go the other way around.

[3] The award, as far as I can tell, is the Infocommerce Group Models of Excellence Award presented at Data Content '09. Infocommerce Group is some "boutique" consulting firm which is presumably in the business of handing out awards, Data Content is presumably some minor conference but I can't find anything about it online. So basically the Nobel Prize for DNS.