This blog can't be viewed on LiveJournal. Instead see

Why OpenID discovery for email addresses must use DNS

29th Oct 2008

I'm getting some pushback from my proposal to use DNS as the primary means of OpenID discovery for email addresses. I think this is largely because I've not done a good job of explaining my reasons for it. Aside from some idea of technical purity, what's the practical reason for using DNS for OpenID? Who would use it that way?

My previous employer provided, amongst other things, a hosted content management system product. The usual setup would be that our customer would either have an in-house IT department or they'd outsource their IT stuff to a third-party. These IT folks would generally be responsible for DNS and email in some capacity, even if that capacity was just clicking some buttons on someone else's control panel. When the customer bought a CMS-based website from us, we'd get their IT folks to point the A record for the domain at one of our CMS server clusters and configure a mapping of that domain to the appropriate site in the system.

In this scenario, the customer's pretty limited in what they can do to their website. In the interests of usability, the site is presented as a tree of pages which are edited via a WYSIWYG editor and munged into a complete page using a site-wide HTML template. There is no way that such a customer could set up Yadis discovery on their site; creating arbitrary files and arbitrarily fiddling with the contents of <head> are not things the software provides. Even if it did, it certainly doesn't provide an OpenID provider that recognises email addresses for the domain.

Lest you consider this an isolated case, consider some other examples of such an arrangement. The domain this blog is running on has its A record pointing at who host my blog. They don't allow me to override the Yadis document returned at the root of my site, but I do own and control my domain. Users of Six Apart's hosted blogging service TypePad can't add the necessary bits for Yadis discovery without switching to "advanced templates", at which point they lose some of the easy blog design features. Google provides a similar hosted CMS service as part of its "Google Apps for your Domain" package which can't support Yadis, though we could also come at this from the other direction and see that most folks using the Google Apps version of GMail for their domain have their website hosted somewhere else, because -- let's face it -- Google Sites is kinda limited.

It's been my experience, then, that it's far more often the case that DNS and email are controlled by the same team than are email and web. In the case of my previous employer, the IT folks can readily add new records to DNS without involving the CMS provider. In the case of Google Apps For Your Domain, being able to edit your DNS is already a prerequisite to deploy GMail, so if Google were to provide a hosted OpenID-for-email service as part of Apps they could just instruct administrators to add an additional DNS record to enable it.

While I don't disagree that publishing the discovery information over HTTP should be an option, DNS should not only be supported but should override whatever's published over HTTP. The compromise of using DNS TXT records as the transport for this discovery information rather than a more "correct" record type, we make it possible to deploy these records in domain management tools that exist today.

I hope the above will serve to show that my wish to use DNS for discovery is in fact for pragmatic reasons, not for reasons of theoretical purity. That it comes with a side-order of theoretical purity (for some definition of purity) is just a nice side-effect!


  • Interesting Points...

    Very compelling post -- I'm inclined to agree with your conclusions, but want to hash this out a bit more with you.

    1.) With regard to paragraph three, was that CMS system in the root of the customer's domain? It would seem like a better-practice to place that in a sub-domain (e.g.,, and maintain control over the HTML contents of their root -- don't they have a public facing website? Or was your CMS system their public facing website?

    2.) Doesn't the same hold true for this blog? If you wanted to, you could make point to LiveJournal, and make be a page with a link to your blog, but with a
    By ext_129897 at 04:17 pm on 30th Oct 2008
    • Re: Interesting Points...

      Yes, the CMS system is the customer's main website. I glossed over some of the details in the interests of brevity, but my former employer was in the business of selling customers a website design and the tools necessary to build and maintain a website within it. The usual setup was that the domain's own A record and the record for www would both point at our systems, and our systems would redirect the former to the latter.

      I guess what you're indirectly proposing is that www would point at the CMS cluster and the domain itself would point at whatever server provides the first step of OpenID discovery and that could do a redirect (in some sense) to www. While I don't disagree that this could work, it's an extra complication and another thing that can go wrong. If the server at stops redirecting to for some reason, the customer's probably going to complain to the wrong provider.

      Also, some DNS providers -- including the one I host on, in fact -- will not allow www to point at something other than what the base domain points at. Now, I could easily do the DNS for that domain myself to avoid that limitation, but I'm trying to be pragmatic here and make this work for as many folks as possible. Once you get past the big email providers, companies and other organisations with their own domains are probably the next biggest group with email addresses, so it'd be a mistake not to give careful consideration to how we can make implementation as easy as possible for them.

      By Martin Atkins at 06:14 pm on 30th Oct 2008
  • (comment with no subject)

    I definitely better understand your argument for discovery via DNS, however I'm concerned about defining this at the EAUT level. I think it makes a lot of sense to simply use XRDS-Simple for EAUT service discovery. Pretty much every existing and emerging Open Stack technology uses XRDS-Simple for discovery, and I don't think it makes any sense to deviate from that. It allows consumers to use a single discovery mechanism for all services... EAUT, OpenID, OAuth, PoCo, whatever.

    Given that you do make an interesting argument for DNS here, perhaps it is worth pursuing DNS as an option for discovery the XRDS-Simple document for a domain. This has already been discussed at least some about a month ago[0]. Not sure if anything came of that conversation, but do you not think it would be better to implement this there? If it's useful for EAUT, it could certainly be useful for others.

    By ext_130993 at 08:20 pm on 30th Oct 2008
    • (comment with no subject)

      If the URL of the XRDS document for a domain were published in DNS, that would fix one of the main qualms I have with EAUT as it exists today. However, I'd like to see someone pin down exactly how this works with existing OpenID models, including support for canonicalization of the OpenID identifier (as is done with redirects in HTTP-based discovery today) and support for delegation. Both of these are just as important/useful for email addresses as they are for HTTP URLs, and I don't want to lose them. Delegation doesn't seem too difficult when using EAUT -- just publish the delegation information at the target URL -- but I'm not sure how normalization would work, especially if you consider the ability to "normalize" an email address into a URL or vice-versa.

      By Martin Atkins at 08:48 pm on 30th Oct 2008