Recently in DNS Category

My poor much abused laptop tends to get introduced to a lot of networks, most of which happily use DHCP, but a few which need special setup such as static ip addresses etc. In general, Network Manager handles this fairly well, however I've yet to find a way within Network Manager to set a default set of search domains for all connections.

The most reliable method I've found to implement this is the resolvconf package. Install this by running "sudo apt-get install resolvconf" and then edit /etc/resolvconf/resolv.conf.d/base to add the following line:
Tell Network Manager to restart whatever connection your on, and /etc/resolv.conf should have the above line in it.

An added advantage to this method is that resolvconf is smart enough to look at any search domains set via DHCP or that you might have added to the connection in Network Manager and append them to the search line.

DNSSEC Still Pie In The Sky

Affilias recent put a post claiming that DNSSEC is no longer pie in the sky! The post immediately proclaims than DNSSEC would have stopped the issue on Mar 24th where a Chinese root server was leaked outside of China. While this is technically true, they seem to be vastly underestimating how far off we are from seeing this happen.

Starting at the client level, whether it is a browser, mail server or mail client. At the moment very few clients have native support, and most seem to need to be patched which is not something the vast majority of end users would be comfortable doing. Microsoft only seem to be supporting DNSSEC in Windows 7 and Windows 2008, although I could be wrong on this. Then there's the variety of browsers on the variety of mobile devices. In all cases it's more likely that you'll have IPv6 support!

The next step would be the dns resolver that the client talks to. This could be your ISP's resolver, your local router, a third party such as OpenDNS and Google or possibly a dedicated local server. At the moment then chances of them being DNSSEC enabled is minuscule.

In the case of local routers (CPE), Nominet tested a cross section of CPE devices in 2008. The result?
As a consequence, we conclude that just 6 units (25%) operate
with full DNSSEC compatibility "out of the box." 9 units (37%)
can be reconfigured to bypass DNS proxy incompatibilities.
Unfortunately, the rest (38%) lack reconfigurable DHCP DNS
parameters, making it harder for LAN clients to bypass their
interference with DNSSEC use.
Of course even if the router supports DNSSEC, you then have to make sure that the upstream DNS servers support it, which is by no means a given. Comcast are still only testing it which probably puts them well ahead of their competition.

Then you have to make sure that any firewalls between you and the upstream DNS server are correctly setup. It's not unknown for Network Admins to only allow UDP packets over port 53. This will break horribly with DNSSEC as the response to a query will be a lot bigger so it's very likely that the server will have to fall back on TCP. Even if the the Network Admin has opened TCP port 53, it's possibly that the firewall "knows" that a DNS packet can ever be larger than X bytes, and will indiscriminately drop any packets larger than it's set limit.

Then there's the root servers and the various TLD servers. The earliest that we'll see a signed root zone is July 2010, and that's presuming that their testing goes well. PIR have implemented it on .org already, and various other cctlds have either implemented or have testbeds. Verisign have said that Q1 2011 is when they expect to have it rolled out for .net and .com.

Presuming that all the above has been fully implemented, it's possible that DNSSEC would have stopped what happened on Mar 24th. However, then there's the leaking of more specific routes such as what happened Youtube in 2008, but that's a different problem with different fixes.

The above is only a very quick and nasty overview of the issues with DNSSEC at the moment as far as a client is concerned. There's plenty of other issues to be sorted out such as transferring domains and key rollover among others.

Then there's the human element. Phishing won't be cured by DNSSEC, most phishing attacks use absolutely random urls, such as  The deployment of DNSSEC also won't force people to upgrade their browsers, IE 5 and IE 6 still make a good percentage of the the browsers out there!

Unfortunately, DNSSEC is going to remain very much pie in the sky for the time being. 

Whois Tip

alias whois='whois -H'
Put that in your .bashrc (or equivalent) and get rid of the legal disclaimers which usually mean that you have to scroll up two pages to get the actual results! I should have looked at the whois man page ages ago.

Copyright Fun And Games

Michele posted about the fun and games with Domainnews and copyright two months ago. Domainnews seem to have finally realised  and their "Chief Editor" has replied claiming innocence. Unfortunately he still does not seem to realise what he has done wrong, and he still hasn't as much as apologised yet. In fact Michele had to send a DMCA Takedown notice to Google before anything was done. For fun and giggles I had a look at the Domainnews site and spotted a post attributed to "press" which is a copy of the press release here. According to Domainnews: "press is one of our editors and not someone we are trying to credit this to". What's even more fun is that the DotAsia press release is covered by a Creative Commons Attribution License (look at the icon at the bottom left of DotAsia's press release) which probably means that DotAsia would at least like a link back. Even if they didn't have the CC license, it is just a common courtesy to link back to the originating site, even for a press release. There is no point posting about DotAsia starting a new program, if the reader can't click on a link and have a look around to get more details. The whole whole point of the Internet was/is to share information.

Useful DNS Queries

| 1 Comment
I have come across a couple of handy little trick for DNS recently which I'm going to throw up here just to save me searching when I need them in the future :)

Getting The Version Of A DNS Server

To get the version of a DNS server, you can run the following command:
dig @dns_server_you_want_to_check +short version.bind chaos txt
It is very easy for the server administrator to change this to whatever they want, but it's still a handy command.

Getting The Whois Server For A Top Level Domain

I found the following command for finding the whois server for a TLD on the Nominet Blog.
dig +short srv
This should return:
10 0 43
This means that the whois server for .ie is listening to port 43 at Unfortunately, not all TLDs support this, most noticeably .com.

EURid Going Against EU Guidelines

Since ICANN Lisbon, EURid has been taking lots of abuse from all corners due to their business practices. Michele has talked about the conduct of EURid Staff during their session at Lisbon and John McCormac also has plenty to say about EURid Incompetence.

One older post that was pointed out to me has really caught my eye. It is by Phill Parker and is simply entitled EURid Are Pure Evil. One of the EURid registrar rules is that you may only have one connection to the EPP server at any given time. However, certain registrars are gaming the system by getting "Registrars" accredited who haven't even got a website or any trading presence. These virtual accredited registrars are then used for additional connections to the EPP server giving those who follow the rules no chance.

A quick bit of Googling led me to Commission Regulation (EC) No 874/2004 of 28 April 2004 available here. To quote the second paragraph of Article 4 of the above document:

The procedure for the accreditation of registrars shall be deter-
mined by the Registry and shall be reasonable, transparent and
non-discriminatory, and shall ensure effective and fair condi-
tions of competition.

I'm by no means a legal expert, but what Phill describes seems like a very clear cut breach of the above paragraph. This only took me a couple of minutes to find, and I'm betting that it's only the very tip of the iceberg. What other EU Regulations are EURid breaching on a daily basis?

It has become fairly obvious that EURid are totally incapable of handling a gTLD, I'll let Michele tell of why multiyear registrations are out :) Why are the European Commission not stepping in and asking serious questions of EURid?

Graphing Rbldnsd Stats With MRTG

A while ago Michele blogged about generating stats from Rbldnsd. Since then I've had to put it into practice. During the post he mentioned Jeff Chan's script for getting the numbers from rbldnsd's stats file. The only problem with this script was that it rapidly ran out of steam when you went over ten zones. This becomes a problem when you consider that a dnsbl like has over 200 zones.

A new script was created in order to get around this limitation, which is available here. If no argument is passed to the script, it will return the aggregate numbers for all the zones, and if the zone name is passed in as an argument it will give the numbers for that zone. In both cases it will return two lines. The first is the number of positve hits on the zone, the second line is the total number of requests to the zone.

In order to use the script with mrtg you will have to edit the $statfile variable to point at where rbldnsd is outputting it's stats. For each DNSBL, you have to setup a target in your MRTG config. The target for would be:
Target[]: `perl /etc/mrtg/` MaxBytes[]: 4800000
Title[]: RBLDNSD -
PageTop[]: <H1> requests </H1>
MRTG should then be run every five minutes using cron.

Even Google Make Mistakes

Looks like Google managed to forget to renew the domain. Oops :)

About this Archive

This page is an archive of recent entries in the DNS category.

Dell is the previous category.

Gadgets is the next category.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Creative Commons License
This blog is licensed under a Creative Commons License.
Powered by Movable Type 5.02