antecipate: In DNS we trust

It sometimes takes an errand of many lengthy pieces before exposing a valuable concept. I have always wondered what is driving anyone capable of thinking perceptively to justify a legitimate desire of experimenting with new ideas. Well, this latest saga does not really answer my question. But it re-enforces my growing certainty that DNS reliance becomes a weakness and a constraint in any large distributed networking application.

The series of posts I am alluding to is a good example of the adaptive learning process happening when one evolves beyond any established technological conservatism, and makes the illuminating discovery that there might be "something else beyond (add your favorite topic here)". The associated state of excitement often takes us down blind alleys, or leads us to take shortcuts to get to approximate conclusions suiting our subjectivity. For example, the simplistic idea that a globally unique identifier (URI) will solve the "virtual identity" question is characteristic of the former. The confusion between "presence" and "identity" is more a matter of the later. So is the reliance on DNS as the global glue of our ever expanding interaction needs over the Internet.

…there is value in using a real time communication framework to give access to resources referenced by URIs…

In my opening statement, I mentioned a valuable concept. Its value is certainly not the sudden discovery that in an URI may be used to reference a resource in a particular domain of interest-As a matter of fact, I find the emphasis given by the author to this basic URI capability somewhat disconcerting. I was under the impression URIs had been invented to do just this--No, the actual value lies in the use of a real time communication framework to give access at an individual level to the resources referenced by the URIs. At last, after years of obscurantism, the light is finally coming through layers of sediments: there is more to the web than location based (i.e. URL) thinking. A small evolutionary step, but so important by the ever growing number of people embracing the same idea. Furthermore, I am also interested to see XMPP supporting this concept, as this choice further exemplify the protocol's usability beyond mere instant messaging.

The described technological implementation consists simply in a private personal XMPP server aggregating various other protocols (HTTP, SMTP) and using XMPP as a universal communication transport to access both local and remote data using URI references. The URI of choice being a JID. The implementation idea is both realistic and convincing. There is nothing revolutionary in aggregating various protocol endpoints on a XMPP server. I have done this several time in the past five years for WAP (HTTP), a few SMS centers protocols, and more recently for SIP, XCAP (HTTP) and SOAP(HTTP). So I do not foresee major difficulties beyond the time spent in his endeavor … But, by wanting to quickly get to working on the "web application aspect of the private server" the author has taken for granted that the resulting server would be able to communicate outside its private sphere. I see a few shortcomings in his approach and in the protocol that would need to be addressed for the implementation to function as described and be widely adopted.

The first major shortcoming I see is the heavy reliance on DNS, which in my opinion would create a growing single point of failure over time.
The second major obstacle, in the current protocol state, is the mandatory use of public resolvable addresses handles--which may explain why the author insists on everybody owning a "domain name".

I will try to give some substance bellow.

These private XMPP servers will be connecting to other private or public XMPP servers through server-to-server (S2S) communication. In the current state of the XMPP specification the connectivity depends heavily on DNS, and SRV records DNS extensions. The RFC mandates that inter-domain communication only takes place when the DNS host names asserted by the servers have been resolved. The connection must also use TLS, which again use domain names for authenticating the hosts. In addition, further checks must also be in place to ensure that the actual XMPP stanzas flowing between any two servers belong to the proper identified connection. By doing so, and for a number of historical choices, the current specification severely limits widespread deployments beyond the traditional "one domain equal one community" model. This has been a viable short term solution for today's limited number of XMPP servers hosting communities using XMPP clients. But in the described private server scenario, extending the usage of S2S to each and every individual user may be a stretch.

Furthermore, I doubt we will see a rapid spread of individual domain names, but I may be wrong. I am not so much concerned about scalability issues of the current DNS system than by administration issues derived from a wider usage. Moving from a specialized infrastructure product (the community domain name) to a consumer commodity (the individual domain name) implies vastly different organization and arbitrage for which the system was not conceived in the first place.

On another note, DNS administrators will eventually learn over time the benefit of SRV records to allow service discovery. But there is no guarantee they will do it quickly… Similarly, it has taken almost two years to see the first XMPP S2S interoperability testing. And it will certainly be some time until the last XMPP server relying only on S2S dial-back authentication is phased out. And this implementation requires XMPP.

These are just a few points to illustrate what makes me believe too much DNS dependency is not favoring wide adoption of individual private servers of any sort, and XMPP in particular. In the end, because any adoption process is gradual, I believe some users will probably never embrace the described technology. As a result, there will certainly be a co-habitation between a mix of private and shared servers. This simple fact implies that any proposed solution would have to address these two types of usage. The current XMPP specification is not able to provide a working solution to this requirement. I know from facts and real users' needs that the current dependency between XMPP address handles and DNS domain names is a severe pain point when deploying XMPP beyond the current single domain server communities.
I am certain many of us would appreciate an enhanced version of the protocol were servers would for example be able to multiplex several supported domains traffic on a single authenticated trusted communication link, without any of the servers supported URIs being DNS resolvable. This in turn would mean XMPP can provide some of the necessary features to create real overlay networks on top of and independent from DNS domains, with associated XMPP routers. And I believe that in the long run overlay networks with their own addressing space, connected through DNS enabled ingress/egress points are more appropriate to provide an answer to this interesting idea of private XMPP servers. And probably more.

This is probably asking too much at this point in time, when the shift from the location based to the communication based thinking is only starting… But I know for a fact building XMPP based overlay networks is not an utopia.