Webnames.ca StaffBy now, you’ve heard about .TEL and how it will revolutionize the way we connect with each other by using the existing DNS architecture to store phone numbers, email addresses, map links, and dozens of other types of contact information.
As you may suspect, .TEL is more than a traditional top-level domain; it is more like a system or a set of standards. I was curious about the system’s technical workings, so I read all the documentation I could get my hands on. My sources were the guides available to accredited registrars like Webnames.ca, the publicly-available RFC’s (request for comments) describing features of the DNS, and various Google/Wikipedia search results.
I will try to summarize what I learned.
Storage of Contact Information
The DNS routinely stores many different types of data for each domain name. These are called Resource Records, and the most common is the A record, which associates a domain name with an IP address. Another common type is the MX record, which tells email programs where to send mail that is addressed to a user at a particular domain.
To store contact information, the .TEL registry mandates the use of NAPTR records. NAPTR records provide a flexible, generic way of storing arbitrary text in the DNS, with more structure than simple TXT records. They do this by specifying a service type which, in the context of .TEL, maps to an ENUM “E2U+” service, and a regular expression that specifies how to rewrite a domain name into a URI that describes how to access the service.
For example, the following record says that for the domain you just looked up, you should replace the entire domain name with the URI “sip:information@pbx.example.com”:
IN NAPTR 100 10 “u” “E2U+sip” “!^.*$!sip:information@pbx.example.com!i”
Of course, in this example, the power of regular expressions goes mostly unused, but it is easy to imagine service URI’s that would demand more complex NAPTR records. See RFC 3403 for a full description of NAPTR records, along with several examples.
Storage of Other Information
The .TEL registry mandates the use of TXT records to store information about a domain that is not contact-related. This can be either:
• free-form text, intended to be displayed to the client as-is
• a “Structured Keyword” list prefixed by “.tkw”, and containing one or more keyword type/value pairs, something like this:
IN TXT “.tkw” “1” “s” “Mr” “fn” “James” “fn” “Fenimore” “ln” “Cooper” “jt” “Technical Author” “g” “male” “dob” “15/09/1789”
• a “Structured System Message” prefixed by “.tsm”
Software Support
Telnic has been hard at work developing free, open-source (FOSS) plugin clients for popular communication platforms, including Microsoft Outlook®, Windows Mobile® and BlackBerry®.
When publicly available, these plugins will allow users of those platforms to simply enter a .TEL domain name – for example, emma.tel – click the Mobile Phone button, and place a call to Emma’s published mobile phone number. If Emma ever changes her phone number, the caching and delegation architecture of the DNS comes into play, and within a few hours, the same procedure would result in a call being placed to her new mobile phone number.
Telnic will also be providing a FOSS platform that implements a TelHosting server, to give registrars some help as they take on a new role.
Administration
The traditional role of a registrar is to allow registrants (end-users) to manage the terms of their domain registrations, update their WHOIS contact information, and specify their DNS servers. Many registrars also allow registrants to point their domains at the registrar’s DNS server, and manage typical addressing, hosting and forwarding scenarios as they please.
With .TEL, the information being stored in the DNS for a domain is much more extensive and complex than with other TLD’s, so the registry has defined another role called a “TelHosting provider”. This entity provides the registrant with the ability to manage their contact information through a web-based front end (or a SOAP API).
The TelHosting provider is also responsible for hosting the web proxy, which displays the contact information for its domains in a clear format, as at http://emma.tel/. For .TEL domains, the A record always points to the IP of the TelHosting provider. (Registrants are not allowed to point the A record at an arbitrary IP address, or to add arbitrary CNAME records to bypass this restriction with aliasing.) It is expected that many .TEL registrars will also perform the TelHosting role but, as with DNS services, there is nothing preventing a registrant from obtaining TelHosting services from another entity.
You might wonder what role the .TEL registry itself plays in this system. From the above information, it would seem that a registrant of any domain, regardless of TLD, could conform to the system standards and store extended information in the DNS. Technically, I suspect this is true, but client software support for TLD’s other than .TEL may be spotty. Also, there is a whole area of contact information publishing that is not addressed by the standards above: privacy.
Privacy
An IETF draft submitted by Benjamin Timms and Jim Reid from Telnic specifies how we can encrypt NAPTR records to prevent contact information from being read by untrustworthy clients. But how do we pass the encryption keys around? That is where the .TEL registry comes in. Telnic, or its delegated registry manager, Neustar , will provide the central infrastructure for a system that tracks consumers of private .TEL contact information.
The system will allow a user to create an account protected by a password and automatically generate a public/private key pair. The user can then send a “friending” request to a .TEL domain. If the administrator of the .TEL domain agrees to the friending request (typically through the TelHosting provider’s web interface), a sub-domain will be created, with the private contact information encrypted using the public key of the friending requester.
As you can see, the NAPTR information can only be decrypted by the friending requester. If the domain administrator no longer wishes to be friends with the requester, they can simply remove the sub-domain (an interface will be provided to do this through the TelHosting provider.)
On the face of it, .TEL looks very promising in its utility. Are there additional aspects workings of .TEL you want to know about that are not covered here? Let us know.
——————————————-
Click here for more information on .TEL