OpenNIC DNS network

DNS look-ups are a very sensible topic. Of course you want very fast name-to-IP resolutions, but should you always use Google’s DNS server? After all they can keep track of all your network motion profile unless you are surfing by IP! Today I read about the OpenNIC Project and ran some speed tests. It’s very interesting and worthy to know about!

The project about itself:

OpenNIC (a.k.a. "The OpenNIC Project") is an organization of hobbyists who run an alternative DNS network. [...] Our goal is to provide you with quick and reliable DNS services and access to domains not administered by ICANN.

Ok, I gave it a try and implemented a Perl-script that checks the speed. It throws a dice to call one of my often used domains and digs1 each of my predefined DNS servers to save the query time. I tested the following DNS server:

  • 178.63.26.173 : one server of the OpenNIC project, located in Germany
  • 217.79.186.148 : one server of the OpenNIC project, located in Germany (NRW)
  • 8.8.8.8 : Google’s public DNS server, proven to be fast and reliable
  • 172.16.20.53 : my ISP’s server
  • 141.48.3.3 : name server of our university

Find the Perl code attached.

And here are the results after 10000 qeuries:

IPProvider10000 queries
172.16.20.53my ISP131989 ms
217.79.186.148OpenNIC259382 ms
8.8.8.8google270300 ms
178.63.26.173OpenNIC304094 ms
141.48.3.3NS of uni-halle.de394134 ms

As you can see, my ISP’s DNS server is the fastest, they may have optimized their internal infrastructure to provide very fast look-ups to its customers. But it is also nice to see, that there is one OpenNIC server that is faster than google! And this server comes with another feature: It doesn’t track any logs! Isn’t that great!?

To find some servers near you just check their server list. Some of them don’t record logs or anonymize them, and of course all of them are independent from ICANN administrations.

I can’t recommend to use any special DNS server, but I want to advise to test them and find the best one for your demands! Feel free to post your own test results via comment or trackback.

1 dig is part of the larger ISC BIND distribution

Download: Perl: pipapo/scripts/dns-bench.pl (Please take a look at the man-page. Browse bugs and feature requests.)

Boot messages to service console

You may have heard about management consoles!? If a server is dead you can revive it via service console without driving the long way to the data center (often miles away).

While logged into the service console you of course have the chance to reboot the machine itself. To get to know what it is doing while booting you may want to see all the messages that are usually prompted to the terminal at the attached monitor. Unfortunately you aren’t next to the machine, and so there is no monitor attached to it, but you can force grub to prompt all messages both to terminal and to service console.

First of all you have to setup the serial console:

serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1

The --unit parameter determines the COM port, here it’s COM1, if you need COM2 you should use --unit=1 . --speed defines a baud rate of 57600 bps, see your manual. To learn more about the other parameter you are referred to the Grub manual for serial. Next you have to tell Grub where to write the output:

terminal --timeout=5 console serial

This line tells grub that there are two devices, the typical console on the attached screen and our previous defined serial console. With this directive Grub waits 5 seconds for any input from serial console or the attached keyboard and will print its menu to that device where the input was generated. That means if you’re at home and press any key, Grub will show you all outputs to your serial connection, but your student assistant (who had to go to the server, by bike while raining!!) isn’t able to see whats happening. But if your assistance is faster than you and hits a key on the physically attached keyboard, he’ll see anything and you’ll look through a black window… If nobody produces any input the output is written to that device that is listed first.

Last but not least you have to modify the kernel sections of the boot menu and append something like that at the end of every kernel line:

console=tty0 console=ttyS0

That tells grub that all kernel messages should be printed to both the real console of the attached screen and the serial console. Keep in mind to modify ttyS0 to match your serial port (here it is COM1). Grub decides for the device that is listed last to also send all stdin/stdout/stderr of the init process, that means only the last device will act as interactive terminal. E.g. checks of fsck are only printed to the last device, so stay calm if nothing happen for a long time on the other one ;-)

Here is a valid example for copy and paste:

# init serial console
serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
# what device to use for grub menu!?
terminal --timeout=5 console serial
# ....
title           Debian GNU/Linux, LOCAL CONSOLE
root            (hd0,0)
kernel          /vmlinuz-SOMEWHAT-openvz-amd64 root=UUID=AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE ro console=ttyS0 console=tty0
initrd          /initrd.img-SOMEWHAT-openvz-amd64

title           Debian GNU/Linux, LOCAL CONSOLE
root            (hd0,0)
kernel          /vmlinuz-SOMEWHAT-openvz-amd64 root=UUID=AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE ro console=tty0 console=ttyS0
initrd          /initrd.img-SOMEWHAT-openvz-amd64

Here both Grub entries are booting the same kernel, but the first one will use the local console as interactive terminal whether the other entry takes the serial console for interactions.

ShortCut[xtrlock]: Avoid Xscreensaver

By default Xfce provides screen-locking via Xscreensaver. Here is how you change it.

Xfce runs a script called xflock4 to lock the screen, to change the default behavior just foist another script on Xfce! The default path settings for searching for this executable shows, that /usr/local/bin has higher priority than /usr/bin (here is the original xflock4 located). The rest should be clear!

E.g. to use xtrlock instead of Xscreensaver you just have to link to the binary:

% ln /usr/bin/xtrlock /usr/local/bin/xflock4

On a multiuser system you may allow each user to use it’s own locking-solution. So just write a script that checks if $HOME/.screenlock is executable and runs it or falls back to a default screensaver:

#!/bin/bash

# default
DO=/usr/bin/xtrlock

# does user want smth else??
[ -x $HOME/.screenlock ] && DO=$HOME/.screenlock

$DO

Save it executable as /usr/local/bin/xflock4 - done…

Homage to floating points

I recently got very close to the floating point trap, again, so here is a little tribute with some small examples!

Because Gnu R is very nice in suppressing these errors, all examples are presented in R.

Those of you that are ignorant like me, might think that 0.1 equals 0.1 and expect 0.1==0.1 to be true, it isn’t! Just see the following:

> a=0.1
> b=0.3/3
> a
[1] 0.1
> b
[1] 0.1
> a==b
[1] FALSE

You might think it comes from the division, so you might expect seq(0, 1, by=0.1) == 0.3 contains exactly one vale that is TRUE !? Harrharr, nothing like that!

> seq(0, 1, by=0.1) == 0.3
 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE

Furthermore, what do you think is the size of unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4)) !? Is it one? Not even close to it:

> unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4))
[1] 0.3 0.3 0.3

Your machine is that stupid, that it isn’t able to save such simple numbers ;) And another example should show you how these errors sum up:

> sum=0
> for (i in 1:100) sum = sum + 0.01
> sum
[1] 1
> print(sum, digits=16)
[1] 1.000000000000001

As you can see, R tells you that you summed up to exactly one, suppressing the small numerical error. This error will increase with larger calculations! So be careful with any comparisons. To not fail the next time, for example use the R build-in function all.equal for comparison:

> unique(c(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4))
[1] 0.3 0.3 0.3
> all.equal(0.3, 0.4 - 0.1, 0.5 - 0.2, 0.6 - 0.3, 0.7 - 0.4)
[1] TRUE

Or, if you’re dealing with integers, you should use round or as.integer to make sure they really are integers.

I hope I could prevent some of you falling into this floating point trap! So stop arguing about numerical errors and start caring for logical fails ;-)

Those of you interested in further wondering are referred to [Mon08].

References

[Mon08]
David Monniaux. The pitfalls of verifying floating-point computations. ACM Trans. Program. Lang. Syst., 30(3):1–41, 2008. http://hal.archives-ouvertes.fr/hal-00128124/en/

ShortCut[R]: locator

Welcome to my new category: ShortCut! Here I’ll shortly explain some smart features, unknown extensions or uncommon pathways of going for gold. Today it’s about the Gnu R tool locator.

With locator you are able to detect the mouse position inside you plot. Just run locator() and click some points, when you’re finished click the right button and locator will print the x - and y -values of the clicked positions. With this tool it’s possible to visually validate some numerical calculation.

With a little bit more code, you can output the coordinates right into you plot:

> x<-seq (0, 10, .01)
> plot (x, dgamma (x, rnorm (1, 2, 0.5), rnorm (1, 1, 0.5)), t='l', main='any curve', ylab='y')
> text (p<-locator (1), paste (p, collapse="\\n"), adj=0)

With a click into the plot you’ll be able to create a result like figure 1.



Martin Scharm

stuff. just for the records.