I’ve started reading John Day’s Patterns in Network Architecture and during the first pages it makes strong references to Saltzer’s 1982 paper. Why would I bring this up? Well, I just heard Surprisingly Awesome‘s episode on Postal codes where they deal with two countries (Lebanon and Mongolia) with almost non-existent addressing plans. Here is what an addressing plan should give you:

  • a name identifies what you want,
  • an address identifies where it is, and
  • a route identifies a way to get there

Day makes the case that we usually use that address of a network element in the same way that we use its name also which is an error, since by moving an element elsewhere in the network, we need to change its name also.  You on the other hand do not change your name when you change your home address. You used to change your phone number, but even that has become equally portable.

In places where no stable addressing system exists the courier is required to build a mental representation of the routes in their area of delivery, based on landmarks, trees, neon signs, whatever can help to make the delivery. In Mongolia this is solved differently: When something arrives at the post office, they call you back and you go and pick it up.

Enter the NAC. What is it exactly? It is an effort to map longitude and latitude to a more memorable representation using the base 30 number system using digits and capital letters. Borrowing from Wikipedia, the NAC for the centre of the city of Brussels is HBV6R RG77T. Compact, accurate, but not quite memorable.

what3words seems to be a service set to solve this since with their solution a unique combination of just 3 words identifies a 3m x 3m square anywhere on the planet. For example, roughly the same place as above is described as october.donor.outlined. I admit, this is much easier to type in a GPS (or tell Siri).

However, I am still surprised that nobody ever thought of using IPv6 for this (maybe somebody has? Please tell me). Given the abundance that the 128bits give us, we could have indexed every square meter on the surface of the planet and make it addressable. Oh, the directories we could have built on top of that. But I have no fear. It is quite probable that much of the inhabited First World’s surface will be pingable in the foreseeable future. The IoT will make sure of that.


I was trying to install a virtual machine using the latest VirtualBox on a Windows 7 Host. The host was also running OpenDNS DNSCrypt 0.0.6 client. The guest operating system should be Debian/LXDE. Installation went fine until the installer tried to contact Debian mirrors to fetch missing packages.

It couldn’t find them. Like the common system administration mantra says:

Everything is a DNS problem.

So at the OpenDNS DNSCrypt client dashboard I (temporarily) disabled the DNS over TCP option and the installation continued smoothly. The same thing does not happen with OS X Mavericks as the host operating system. After the installation is finished, you can reenable DNS over TCP for DNSCrypt. The guest operating system’s resolver sees no issues with this.

I am posting this short note because it may bite others out there.

The Internet Society (ISOC) posted its views on DNS filtering. They are excellently summed up by the ISOC in a single phrase:

The real solution is international cooperation.

The reality though is that DNS filtering is here to stay. And it is here to stay because its initial deployment is far more easier than attacking the problem to its source via international cooperation.

So until DNS filtering (and supporting users mainly) starts costing Service Providers a lot, as in costing that much that it makes international cooperation cost less (even with the bureaucracy involved) it is a fact of everyday life that we have to get used to. Just imagine debugging not being able to access a single site, while at the same time all antivirus vendors run their own private, and allowed to be queried only by machines running their products (a “value added service”), resolvers.

Sad but true.

What is a Domain?


Esther Dyson’sWhat is in a Domain Name?” reminded me of the excellent and classic paper by Mark R. Horton, “What is a Domain?” written back in 1984. Although old, it is a classic you can share with people who want to start learning more.

From time to time I observe the following email setups, from web hosting providers mostly:

$ host -t mx example.com
example.com mail is handled by 5 mail.example.com.

$ host mail.example.com
mail.example.com is an alias for www.example.com.
www.example.com has address

In other words this is a single server that provides web and mail services, The devil is in the details though: mail.example.com is an alias for http://www.example.com. This is a mistake as when something is declared as a CNAME, it cannot have other resource records bound with it. I copy from DNS for Rocket Scientists:

CNAME RRs cannot have any other RRs with the same name, for example, a TXT – well that was true until DNSSEC came along and in this case RRSIG, NSEC and certain KEY RRs can now occupy the same name.

So the above setup is wrong. The correct setup would be the following:

$ host -t mx example.com
example.com mail is handled by 5 mail.example.com.

$ host mail.example.com
mail.example.com has address

$ host www.example.com
www.example.com is an alias for mail.example.com.
mail.example.com has address

That is if you want to use a CNAME at all. Personally I am using A RRs instead of CNAMEs whenever possible. But why cannot a CNAME carry any other information? I copy from RFC1034 (section 3.6.2):

A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

So please people, correct your defaults. Your clients will benefit from that.

Firefox and IPv6


So you’ve set up a tunnel with your favorite tunnelbroker (for example Tunnelbroker.net or SixXS) but Firefox still refuses to “see the light” and insists on an IPv4 web. You simply need to type about:config in the address bar and change network.dns.disableIPv6 to false.

Google Public DNS s a free, global Domain Name System (DNS) resolution service, that you can use as an alternative to your current DNS provider. The service’s DNS servers IP addresses are easily memorable even by end users (who the service aims to help most) and they are:

  • and

There are other uses for the service. Many system administrators use it for troubleshooting DNS problem in their infrastructure as an objective third party with a DNS view from “outside” their network (plus you can say to your manager that hey this is Google’s DNS view of this zone setup when nothing else helps).

Those of us who host domains, web sites and mail infrastructures have at times faced the problem that domains come and go somewhere else. However, domain owners / administrators / subcontractors / etc often neglect to inform the previous infrastructure that the domain has a new home. Then appears the phenomenon that most of the Internet knows how to access the web site (and where to route email) at the new home, with the exception of the previous ISP or hosting provider. Most of the times the previous hosting provider will find out when the contract runs out, which at times may take as long as 6 months (and I’ve seen longer times too).

In a few cases the previous hosting provider will find about the move because of complaints by its current customers who cannot reach the domain, the old customer complaining that there exist people who do not see the new site (but hey did you ever ask us to put it down?) or simply by pure chance.

In such cases as above the objectiveness of the Google Public DNS system can be of use to the DNS master who wants to maintain a clean setup. One can feed the following script with a file that contains one domain per line (the domains that you host) and ask Google who does it see as their designated DNS servers. In the old days one would ask a fellow admin at another ISP for shell access (I use SDF for similar purposes) or for query access. There is no need for that now :)

# This hack assumes that your nameservers are under the example.com domain

$ns = "";
## $ns = "";

while(<>) {
	next if (m/^#/);
	$domain = $_;
	open DIG, "dig \@$ns $domain ns +short|" or die;
	while(<DIG>) {
		next if (m/\.example\.com\.$/);
		print "$domain $_\n";
	close DIG;

As is shown by the small script above the idea is pretty simple and can easily be customized to suite any local setup.