Connect by Name

Library for easy connection setup

• The project's own website: https://nlnetlabs.nl/projects/connectbyname/about/

Why does this actually matter to end users?

You mobile phone doesn't really understand what for instance "NLnet.nl" or "www.wikipedia.org" mean, when you type either name into a web browser. Being a web browser, it will not come as a surprise that the software will assume you want to visit some website. But it doesn't really know where that website is located on the internet. It doesn't need the physical place of course, but it needs the number that unique identifies the web server so it can connect.

All your mobile phone does know, is how to ask that question to other, specialised computers. These computers actually also probably don't know, unless they have recently answered the same question for another user. Names can change really fast for good reasons, so you would need to refresh this data a lot - otherwise users would end up on the wrong computer. The computers you send your question to, will have a good working understanding how the so called "domain name system" of the internet works. More in particular, the name we asked for needs to be cut up in smaller pieces that need to be read backwards.

There is a short code at the end, which points to a country - or provides some other meaningful clue as to where more information can be learned about the still unknown parts of the name. The short code (which people tend to call a "top level domain") is uniquely managed by a single professional organisation. It is actually called a registry because that is literally what it does: it registers all the names people use. One organisation registers names which end in ".nl", others take care of ".org" or ".eu". There is an invisible list that has all the top level domains on it. This list is called the "root zone" of the internet, and it is quite important because everything that uses a name will need to start its search there.

It is the registry organisation which can provide additional details about the segment next up, in this case "wikipedia" or "NLnet". But it will still not know all the answers itself, so your question will travel to yet more computers. We are getting close now to the computers that these organisations have selected to take care of their domain name. In the case of NLnet this computer will be able to give the right answer straightaway, and this answer needs to be sent back across the entire chain of computers. In the case of wikipedia, the fact we still have a "www" part to look for, could mean that inside Wikimedia foundation there would still be another computer which could be responsible for everything under that label. The same could go for fr.wikipedia.org or ro.wikipedia.org - the label www is only meant for human consumption, but computers actually don't need it. After just a few steps, we started getting part of the answer we were looking for, and all of these parts are sent back to your phone. And at some point in time, we have the entire answer.

Now how do we know that the answer we obtained in this recursive way really can be reliably traced back to the right computers running the root zone of the internet - the so called root servers? Simple, because there are digital signatures on each part of the answer. For the root zone, there is a so called cryptographic key which is distributed widely - there is only one for the whole world. Chances are you have that key on your phone or computer, and your internet provider certainly has. When the question arises where .org is, this digital signature will make sure you know the right internet address to go to. There you can ask the organisation that is responsible for the next part of the answer. For each computer that gives another level of detail, new signatures are added. So in the end you should have a complete proof for every step: or in other words, a trust chain.

Those signatures on the answers are really important: your computer has nothing else to underpin trust. If someone is able to falsify these signatures, they could use this to manipulate answers for everything "below". This includes not just domain names, but also other things people have put into the DNS like certificates. So great effort is spent on making sure everything happens in a really safe way, leaving nothing to chance. And as a matter of technical hygiene, the cryptographic key needs to be changed regularly. For the root of the internet, there is in fact a grandiose ceremony which involves flying in people from all over the world to closely watch how the keys are replaced. The event is attended by journalists and observers. Of course this kind of public event is really expensive, but there is only one root zone of the internet and it only happens once every couple of years - so it is kind of a special event.

Organisations running a top level domain, also need a thorough procedure. They may not have the same budget, however. True, some of the larger organisations may have multi-million euro annual budgets, but others certainly do not. So far there was not a canonical procedure shared among these organisations, meaning that there was room for ambiguity and misinterpretation that could have serious consequences for the economy and society alike. Also, policy makers responsible for national and regional policies were unsure what was expected from them.

Luckily, there are seasoned experts hard at work to develop tools and services that make such procedures easy, or even better, practically invisible. That is what this project contributes to with a new interface for software developers that need to connect their app or program to the internet. You simply state what domain name your service connects to and the interface makes sure any lookup follows the trust chain through a secure, private connection. This way following best practices and adhering to existing standards becomes 'plug and play', something that happens under the hood and any app or technology can simply plug in and use, ultimately making internet connections everywhere a lot safer.

Run by NLnet Labs