4 articles in category Tech / Subscribe

Written off the cuff by yours truly. Act One: Groundwork There are two types of adversaries: passive and active. Passive adversaries do not interact with their target. They only monitor. The defense against passive adversaries is encryption. The defense against …

Read more →

I’m managing a small VPS that hosts sites to a couple of domain names. Let’s say that one of those is

For many months now, someone I don’t know has made their domain name a full alias to my domain: every DNS requests to their domain gets the same answer: IN CNAME Which means that everyone trying to connect to their domain, will connect to our VPS.

So now we are getting a lot of connection and login attempts, web requests and all of that which aren’t intended for us. And there’s nothing we can do to stop this from happening. Unfortunately their domain is targeted by its own amount of spiders, bots etc. Costing traffic and resources, sometimes a few, sometimes a lot.

So I wish there was a way to invalidate this CNAME from my own domain. Maybe with something like SPF does for email – SPF is a DNS TXT record in which you specify the hosts and/or IPs that are allowed to deliver email from your domain.

If this would be possible for CNAMES – specifying which other domains (or variants of that) are allowed to point to a target domain, “CNAME abuse” (for lack of a better term) like I’m seeing could be quashed.

TLSA is a new kid in the DNS protocol. Ok, not exactly new, but change comes slowly even on the Internet. TLSA is a DNS record type, which allows a domain owner to specify which certificate is valid for a particular service.

If you read that hastily, read it again, because it’s pretty different from how we currently do things. I’m referring to the old model that wants you to buy a signed certificate for e.g. your website, mail server et cetera.

The commercial incentive for this is not an argument that makes up for the lack of technical alternative approaches. Simply said: everyone has the ability to generate certificates. It’s just that companies like Apple, Mozilla and Google collect a bunch of these, and then decide both for you, and for the owner of the domain you visit, which third parties are allowed to vouch for a verified and encrypted connection.

TLSA, which is part of the DANE specification, is a free (as in beer and libre) alternative. It removes the authority from centralised sources, to you, the owner of a domain. You simply add an SSL certificate’s cryptographic hash, together with a few other options, into the DNS, and the client (browser, etc.) will seek no further to verify the authenticity of its connection.

Although this is not supported by browsers yet, my instincts tell me that will probably change, one day soon. If you already knew about this and just want to find out about how to generate a hash, you’re almost there.

Continue Reading →

You might know the feeling: internet being slow and laggy for no apparent reason. So you get annoyed, you decide to search for reasons and along the path you find people who tell you that the cause of slow loading times might be your ISP’s DNS Server. And so they suggest that you change your DNS server to Google’s aesthetically pleasing IP address

This is not as smart as it seems because this may actually slow your connections down, and it’s not a trivial matter. Here’s why.

When your computer looks up the IP address it contacts whatever you configured as your DNS server. If you didn’t change it, it’s usually the DNS server that belongs to your ISP. Some people change it, for example because they don’t trust their ISP.

This argument is quite nonsensical by itself. Firstly because DNS lookups are done in plain-text and thus, if you use a DNS server on the Internet instead of your ISPs, the packets travel a greater distance. Of course this implies there is a greater chance that your DNS requests are in fact less safe: each hop could easily monitor this activity.

But there’s more.

As an example let’s say you live in the UK and decided to use Google’s DNS servers which are in the USA. You have just received a notice that the new NoAgenda show is available to download and you push the button to save it on your device.

What happens in this case with DNS, is as follows. First your computer asks Google for the IP-address of the NoAgenda MP3. Google has no idea so it looks it up, going all the way back to our DNS. Once corrected, it gets Google’s request: “Hey, what’s the IP for”

Before our server can answer that question, it uses the DNS equivalent of Caller-ID:  it looks at the IP that Google uses to connect, and checks is own database to find the country to which it belongs. Because Google’s IP originates in the US, it answers: “The IP address is a.b.c.d.” Google saves this IP address and consequently passes this IP to you.

So now your computer (still in the UK) will connect to that IP address – the one closest to Google, NOT necessarily closest to you!

If you had used your own provider’s DNS, you’d get a different answer and would be able to connect to a server closer to you. Generally speaking that means less latency, more speed.

Many content providers, like YouTube, Google and even an egghead like me, is using servers that are relatively close to their main audience. In our case we have two servers in Canada and one in Europe. In our case, yeah, we do it with DNS for us this is the only way to do it.

Still, if you want to use a DNS server that doesn’t belong to your ISP I’d suggest you take a look at the OpenNIC project: this is a DNS project, which is free to use for all and has servers that are geographically close to you. And they don’t log your DNS requests. Head on over there and have a look, it’s worth checking out.