Thoughts on .Tel and WebFinger

Which makes a better architecture for service discovery, XRD lookups on email addresses (a la WebFinger) or DNS NAPTR records (a la Telnic’s .tel domains)? Hot topic. The WebFinger project has Google and Yahoo folks behind it and uses an XML format compatible with OpenID’s work. The .tel domains forego HTTP and take advantage of DNS’s ready-made caching system.

The main functional difference is the caching

Telnic recently posted a graphic showing how much simpler using DNS directly is than finding XRD. Called an “Idiot’s Guide” – I assume tongue-in-cheek – the best argument for using DNS is almost entirely unrepresented. Future library functions could ultimately make both lookup procedures trivial (ignoring for the moment you can’t do DNS lookup from javascript), so the graphical complexity does not represent a practical issue. Using DNS to make an HTTP request and parsing the response is pretty much what the entire web is made of. How often are we doing these lookups to where the overhead would be a problem?

The one advantage of using DNS to identify service endpoints is that DNS gives you a ready and reliable cache. We don’t see this in the graphic, but the authoritative source in the DNS lookup is shielded from repeat requests by DNS’s tiered cache. Better still about this, simple client apps automatically take advantage of DNS’s cache; it’s been the fabric of the internet since 1983.

There are drawbacks. UPDATE: As Blaine Cook points out in the comments below, perhaps the biggest is that DNS has security issues until DNSSEC is widely implemented. Without that, one can’t trust that the distributed cache is providing authoritative information. For storing public keys for digital signatures, that’s important.

The caching also means DNS records can take some time to propagate under normal circumstances. While DNS records can be explicit about their preferred Time-To-Live (TTL) in the cache, it’s ultimately up to the bottom tier name server to decide what minimum values it will allow. Though Telnic seems to be specifying 1 minute TTLs, we can’t be sure this low value will be observed by every bottom tier ISP.

Unpredicatable latency could potentially be an issue for applications that depend on service endpoint registration for a quick setup-and-run operation, like downloading and installing a new chat app and immediately trying to start a chat using the endpoint the app just registered on your DNS-based id.

WebFinger servers, on the other hand, will (I assume) work like the rest of the web and rely on a combination of client-side caching according to HTTP headers and in-memory caches at the authoritative server (or servers, as DNS may specify alternates). At worst, these servers see every request, and of course, no cache can be shared across individual clients without some additional mechanism being built.

So that’s what I take away from the Idiot’s Guide to WebFinger and .tel. DNS comes with free caching to lighten the server load, while HTTPS+XRD uses the web’s caching mechanisms.

Also – and I mentioned this earlier – something that’s not obvious from the diagram is that DNS can’t be directly accessed by javascript web apps. Flash apps can open a socket, but javascript cannot. Presumably this is one reason WebFinger is not using the DNS solution.

Domains can be free

I’ve noticed that critics of the DNS service lookups often point out that domains are not free, but email addresses are. I want to take a second to point out that this is not true. A name server is considerably less expensive to run than a mail system, and if you have a domain, subdomains such as can be given away to end-users “free”. It’s even conceivable that an email provider could create subdomains for every email address and enable WebFinger-like lookups for email addresses through DNS NAPTR records (e.g., should that be desirable. (This is not WebFinger’s plan, though. WebFinger passes the email address as a parameter to an HTTP method on the mail host.)

.Tel is not the only DNS solution

There are three arguments that resonate with me for registering a .tel domain. None seem compelling to the tune of $12/year, especially for people that already have domains.

Argument 1. You get to use Telnic’s nameservers and APIS for privacy controls and editing NAPTR records.

If DNS is the ideal decentralized service discovery system, and we aren’t tied to Telnic Limited, then other name servers should also be implementing these same management APIs, bringing us back to the question, what’s really special about the .tel domain?

Argument 2. If we assume third-party apps will use the Telnic APIs, then [domain].tel is the shortest possible way to express “Hey, I have Telnic conforming NAPTRs and NAPTR-editing and privacy APIs!”.

Might one just as well express the same by adding a tel. subdomain to an existing domain, e.g.

Argument 3. If everyone had a .tel domain, it would be an awesome namespace, where we might silently drop the “.tel” and just have global “usernames” for finding service endpoints.

This would be ideal in a lot of ways, but the current pricing is a barrier such that this is unlikely to happen. The same problem exists for top-level i-names. Email addresses (and phone numbers) are what everybody already has.

One argument against adopting .tel is that Telnic overrides all .tel DNS A records to point to their Telnic webservers. I’ve heard their reasons for doing so – guaranteed usability in old-generation mobile web browsers and to provide a consistent looking directory – but I think this is a mistake. It’s not clear that all service endpoints, especially highly technical ones, should need to be shown on a human-friendly page (example), and as is, only Telnic has the authority to decide how the records will be presented (icons, ordering, etc.) for .tel domains on the web.

Are NAPTR and XRD mappable?

Suppose you think both DNS and HTTP+XRD service listings are cool, .tel completely aside. Could we create a unified service discovery library that allows clients to look up a service for both email and domain ids? There would be some confusion as to whether domain-looking strings provided by a user should be resolved to DNS NAPTR or OpenIDs XRD via HTTP, but we could check both and prefer one.

Secondly, if we want to use DNS sometimes, but think that XRD has the momentum right now, can we transform XRD to a set of NAPTR records, and can we agree to use the same service URIs in both systems? We could get some API compatibility this way.

That said, once the net supports email addresses as ids, how many people are going to get themselves a domain name to do the same thing? Frankly, WebFinger seems likely to obsolete OpenID urls as well.

APIs needed

For both XRD and NAPTR registries to be useful beyond OAuth and single-sign-on, there’s a lot of work still to be done. XRD providers need a standard API to allow authorized third party applications to update a user’s service listing. When I download Skype app, Skype should be able to add its endpoint to my service registry. (I’m hearing that XDI might have a solution.) And while Telnic does have APIs for this that other name servers could mimic (way to go!), cursory inspection indicates they still need improvement: for example, an authorization scheme other than username/password.

All good stuff to watch for.

6 Responses to “Thoughts on .Tel and WebFinger”

  1. Blaine Cook Says:

    Thanks for the writeup, it’s great to see the two approaches compared like this.

    One thought on the DNS caching; for me, DNS caching is a major problem, because it means that you can’t trust the contact information specified in the NAPTR records. For websites, we mitigate this risk by requiring verified SSL certificates for HTTPS requests. For phone numbers, there’s no way to do this verification.

    In the Iranian context, where sites were being shut down by the government, it means that communications can be trivially intercepted without knowledge of the sender or receiver, simply by modifications at the DNS level. With WebFinger, it’s possible (preferable, in fact) to use HTTPS to do the discovery request, which means that you can verify that the discovery information is correct.

    Now, if we had secure DNS this wouldn’t be a question, but I’m sure not holding my breath for that. 😉

  2. Mason Lee Says:

    Thanks, Blaine. This is a great point, I’ll update the post.

  3. Henri Asseily Says:

    Hi Mason,
    I really REALLY enjoyed reading your article. Finally an article with a high signal-to-noise ratio (actually zero noise!).
    Regarding the security of DNS and the “Iranian” context: remember that you can ask any DNS server for any domain info. You are certainly not locked in to your own provider. In fact, when I wrote the free iPhone app called Superbook (that makes your address book dynamic thanks to .tel) I decided to have the user always go to the well-behaved OpenDNS servers for its queries.
    So in the “Iranian” context, you just completely bypass all Iranian DNS servers and go to any other one. And if Iran cuts off the DNS ports, it pretty much kills all Internet access

    Also I’d like to reinforce what you said about .tel: you can do everything .tel does with a .com, except that you’ll need to build the APIs and the privacy system if you need them. For all that you lose the ability to have web sites with .tel, which is a restriction imposed by ICANN.

    But in the end, the real issue is email vs. domains (.tel or otherwise). Is your email address a lifetime one? are you guaranteed that it won’t ever change? That’s the problem that only domains can solve:

    A domain is your own personal persistent online data store.

    Once again, let me commend you on a very thorough article.

  4. Mason Lee Says:

    Thanks very much, Henri. I hope you don’t mind that I used your card as an example 🙂

    I’m thinking about your work-around for the DNS security problem. Seems that for end-user applications, neither having a hard-coded third party name server, nor requiring additional UI for configuring one’s own trusted nameserver is particularly desirable. I’m trying to think if there’s a better solution.

    How about all geeks go on strike until DNSSEC is implemented?

  5. Henri Asseily Says:

    Heh 🙂 True, DNSSEC is something that the Internet as a whole needs.
    Note by the way that the XRD solution isn’t at all immune to the DNS problem. Imagine the DNS being hijacked to change the XRD file location.

    The lower level you are for this stuff, the better. To me, the DNS is the best solution available, and it’s there. It’s just about having your domain (or even subdomain, but then you’re again giving up your independence).

  6. Mason Lee Says:

    HTTPS does have certificate authorities to mitigate DNS-spoofing, and the UIs for presenting CA-verified identities are getting pretty good, as can be seen, for example, in recent Safari and Firefox releases.

    What is Telnic’s position on rolling out DNSSEC for .tel?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: