Outsourced Clue

UPDATE: Modified for some changes and the latest version of Unbound (this includes 1.3.0)

NOTE: – If you are upgrading from a previous version, I would delete your *.pem files, regenerate them, and make sure to chown them to the unbound user/group.

There is a lot of noise out lately about the recently published DNS Caching Server vulnerability (and with good reason). A lot of patching of BIND and other vulnerable resolvers has commenced. Unbound, an open source recursive/caching resolver from the NLNetlabs guys doesn’t have the problem, and is just a good all around caching server. In this tutorial, I will show you how to setup a reliable and secure caching server.

Unbound 1.2.1 is the latest version. As with everything on Redhat/CentOS, I install packages via RPM. The Unbound tarball comes with spec file, so let’s use that (this is sort of a mini-tutorial of how to build RPM’s as well). I am using yum here, for the purposes of this document, you can substitute yum with up2date-nox if you are using Redhat 4.

1. Install rpm-build: yum install -y rpm-build

2. Create the directory tree needed for building RPM’s (I use $HOME/rpm):
mkdir -p ~/rpm/RPMS ~/rpm/SRPMS ~/rpm/SPECS ~/rpm/SOURCES ~/rpm/BUILD

3. Tell rpmbuild where to find it’s top level dir:
echo “%_topdir $HOME/rpm” > $HOME/.rpmmacros

4. Download unbound into the $HOME/rpm/SOURCES directory:
cd $HOME/rpm/SOURCES && wget http://unbound.net/downloads/unbound-latest.tar.gz

5. Now we want to extract the spec file and edit it:
tar zxf unbound-latest.tar.gz && cp unbound-1.2.1/contrib/unbound.spec $HOME/rpm/SPECS && rm -rf unbound-1.2.1. You need to edit the spec file and update the Version directive to 1.2.1

5. Let’s build the RPM now, it only requires flex and openssl-devel to be installed:
cd $HOME/rpm/SPECS && rpmbuild -bb unbound.spec

6. After lots of output, you should have a shiny new RPM in $HOME/rpm/RPMS/$arch where $arch is either i386 or x86_64

7. Now let’s install it, this will also create the “unbound” user and group:
rpm -ivh unbound-1.2.1-1.i386.rpm (or unbound-1.2.1-1.x86_64.rpm)

OK – we are all done with installation, it created a few directories and files

1. /var/unbound – this is the main directory for all of the files. The configuration we are going to setup is for a chroot’d instance running in this directory
2. /etc/init.d/unbound – The startup script
3. /etc/unbound.conf – a symlink to the main config file in /var/unbound/unbound.conf
4. The binary files, docs etc.

Let’s configure the thing now. There are a TON of configuration items, which can be viewed at this link, but we don’t need to worry about all those now (feel free to review at a later date). Here is the config I am using on most of my machines:

server:
    verbosity: 1
    interface:
    interface: 127.0.0.1
    do-ip6: no
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow_snoop
    access-control: 1.2.3.0/24 allow_snoop
    chroot: /var/unbound

remote-control:
    control-enable: yes

The key items are interface and access-control. A secure recursive server is NOT open to the world, only your internal/controlled networks. So what we do with the access-control items is by default, refuse all queries (you can use a firewall for this too, but I chose the config items in this case). Then, we allow queries from localhost ( access-control: 127.0.0.0/8 allow) and from our local network (access-control: 1.2.3.0/24 allow). Nobody else can query this new recursive server. The interface option tells the system which IP address to listen on (for example, if you run an authoritative server on this same machine, they will both use port 53.

Also – allow_snoop allows you support dig +trace.

Let’s fire this bad boy up (first let’s verify the config file – need to run this under sudo as root) and set it to run at boot:
root# cd /var/unbound && unbound-checkconf unbound.conf
unbound-checkconf: no errors in unbound.conf
root# unbound-control-setup
root# chkconfig –on unbound
root# /etc/init.d/unbound start

We should be all good to go now, let’s test it:
dig google.com @localhost

You should have gotten the results back for google.com etc. If it didn’t work, check /var/log/messages, it will show if unbound started properly or not. Good luck!

I posted this before on an old blog, thought I would repost it here:

Catchy title eh? I have decided that all of the issues of global warming can be attributed to programmers. Lazy programmers. “What is he talking about?” I hear shouted from the fourth row. I am talking about the extremely common mantra of “just throw hardware at the problem”. Instead of spending time to actually plan and optimize software, people throw up a quick piece of crap, and hope that it scales. When it doesn’t, they just buy bigger and more hardware. Problem solved.

I spoke about “How can see many people outgrow their data centers” before, this is really a follow up to that entry. The gist of it is that there is a LOT of electricity being wasted by half-ass solutions. This wasted electricity in turn releases carbon in the atmosphere, which causes global warming (this is of course a very watered down scientific analysis of global warming, but I am simple man that thinks in simple terms).

I was at the San Jose NANOG conference a few months ago, and sat in on a interesting panel titled Hot Time in the Big IDC: Power, cooling, and the data center. It was a round table discussion about what can be done about the severe lack of power and cooling that is affecting data centers around the world. This shortage affects their customers all too often (speaking from experience as well as talking to buddies who have similar challenges). It has become a nightmare to get sufficient power in data centers. Most will make you commit to a full cage if you need more breakers than are allocated for a single rack. Anyways, back to the panel. There were some pretty influential representatives from some large organizations, Cisco, Sun and Switch and Data (which purchased PAIX), to name a few. These individuals discussed some of the challenges facing IDC’s these days, and ways to solve them. The hardware people discussed how they are working to develop faster machines that draw less electricity and need less cooling. The data center/exchange people discussed some of their plans for bringing in more advanced cooling solutions. All of the topics were definitely paths they should take, but NO one touched on the most logical way to alleviate the problem. I wanted to stand up and yell “Hey Chuckos! If programmers and systems engineers just spent more time designing a proper system, then you would have AT LEAST a 50% reduction in cooling and capacity needs”. I say at least cause there is no hard numbers or facts I can point at to come up with a truly accurate number.

I can tell you from experience, I am amazed at some applications I have seen and how poorly they scale. Sometimes it’s as simple as slapping an index on column properly (I have seen an application that ran for years with the main sales report taking 4-5 minutes to run. A single index was placed on the proper column, and the time went down to 2 seconds. Larger database systems were purchased for this customer just so the system wouldn’t be “so slow”). This is an all too common issue that I know some of the more astute readers of this entry (if there are any readers of this entry) come across often.

So what do we do you ask? To help yourself and to help the world (give a man a fish and he eats for a day, show a man how to fish, and he eats forever or something like that), just sit down and think before your project starts where the bottlenecks could be, and how you can alleviate them. Then, understand how a computer and network actually work. Armed with this information, you should be able to design and develop a scalable system that doesn’t require 10 web servers, 5 database servers, and 5 application servers. And that my friends, would help save the world.

UPDATE: – Dan Prichett, from eBay, takes the discussion a step further.