wiki:doc/BIND

Hi there!!!

This is my first article about the Domain Name System! In this article, i'll give to you some super very good tips about how do you have to configure your own DNS Server!!

To understand and follow this guide, you don't have to know how the DNS works! All you need is to read this manual, from its begin to its end. Yeah!

This tutorial will tell you how to:

  • Create your own cached DNS server, also useful against DNS Hijacking?
  • Prevent DNS leaking of .onion and .i2p addresses

Requirements

Not much is required!

  • At the very first, you've to install Red Hat Enterprise Linux or a similar linux distribution (like Fedora). I'm sure this tutorial works fine also for different GNU LINUX distributions; but you may have to change some commands, file paths and file names.
  • You also need to know the basic command-lines commands of Linux.

Chapter 1: Installing the required software

You've to install a DNS server: BIND!!

What's BIND?

BIND (Berkeley Internet Name Domain) is an implementation of the DNS (Domain Name System) protocols. BIND includes a DNS server (named), which resolves host names to IP addresses; a resolver library (routines for applications to use when interfacing with DNS); and tools for verifying that the DNS server is operating properly.

In Fedora linux and similar linux distributions, you'd type to install BIND:

# yum install bind bind-utils

NOTE: yum is a specific packet manager for Red Hat, Fedora & CentOS

The package "bind-utils" contains some useful programs like "dig" (it's a simple, yet super tool, to query DNS servers)

Chapter 2: Configuring BIND

The configuration file of BIND is located at: /etc/named.conf

You've to edit it, opening it as root.

This is the text you've to paste into it:

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
	listen-on port 53 { 127.0.0.1; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
	allow-query     { localhost; };
	recursion yes;

	dnssec-enable yes;
	dnssec-validation yes;
	dnssec-lookaside auto;

	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";
};

logging {
        channel default_syslog {
                syslog daemon;
                severity notice;
        };
        channel default_stderr {
                null;
        };
        channel null {
                null;
        };

        // These categories log DNS names                                      
        category dnssec { null; };
        category edns-disabled { null; };
        category lame-servers { null; };
        category resolver { null; };
        category security { null; };
};

zone "." IN {
	type hint;
	file "named.root";
};

include "/etc/named.rfc1912.zones";

zone "onion" IN {
	type master;
	file "named.empty";
	allow-update { none; };
};

zone "i2p" IN {
	type master;
	file "named.empty";
	allow-update { none; };
};

It's a modified version of the original configuration file from RED HAT.

It's very important that you only allow queries from localhost (IPv4 127.0.0.1 or IPv6 ::1)

Ensure all referenced files exist for real in your LINUX distribution.

The dump-file file can also point to a non-/dev/null path, because it's only created if you run: rndc dumpdb The same applies for the statistics-file (rndc stats). These file should not exist, and they won't be created if you don't run the above commands.

The directory option sets the base directory for all configuration files. For example the file "named.ca" is at directory+"named.ca" = "/var/named/named.ca" And it contains the list of the root servers you're going to query. If you want to look at a new list of root servers type:

$ dig @e.root-servers.net . ns

Update the named.root file manually from https://www.internic.net/domain/named.root. Root servers seldom change, therefore it's not required to update the list of root servers more than once per year!!

Chapter 3: Starting the server

To start the server type:

# service named start

NOTE: service is a Red Hat, Fedora & CentOS specific script, elsewhere use /etc/init.d/named start

If you only see

Starting named:                                            [  OK  ]

then everything went fine!!!!!!

Chapter 4: Testing the server

To test if the server works, open a terminal as a normal user and try to launch some DNS resolution queries!

$ dig @127.0.0.1 thepiratebay.org

You'll notice an answer with written on its bottom:

;; Query time: 767 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 22 21:47:09 2010
;; MSG SIZE  rcvd: 122

It's very important to ensure that the SERVER value in the DNS-answer is set to 127.0.0.1!!! Redoing the same lookup a second time will produce a result like this:

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 22 21:47:39 2010
;; MSG SIZE  rcvd: 122

You've to note that this time the "Query time" is zero, because the result of the DNS query was cached after the first run!!

Chapter 5

Are you going to use the computer you're configuring as a TOR EXIT NODE or as a TOR CLIENT? If you're planning to create a TOR EXIT NODE, read the section A; otherwise both!!!

Chapter 5: Section A: Tor exit node

Unlucky, i didn't found a way to configure TOR to use a specified DNS server (although i didn't looked much into it!!) So, what you've to do is to configure your system, through the /etc/resolv.conf file, to use the installed BIND Server to resolve all DNS queries!

This code from the bash will do the job!

# echo -ne "nameserver 127.0.0.1\n" > /etc/resolv.conf

If BIND is set to start as a daemon, and in the case some other programs overwrite the resolv.conf file at the startup (like the DHCP client preinstalled in Fedora), you may write that shell-code on the bottom of this script file: /etc/rc.d/rc.local so that it'll replace the resolv.conf file at every startup after starting the daemons! Another way is to disable or reconfigure the DHCP client (if you use it).

Chapter 5: Section B: Tor client

You now need to configure the NetworkManager, or whatever you use, to point the DNS Server(s) to 127.0.0.1 Only a DNS Server is required, leave all the others (two or one) fields for DNS Servers blank. You may also manually edit the /etc/resolv.conf file like written before.

To configure the DHCP client from a GUI in Fedora, start the Network Configuration Tool of Red Hat:

$ system-config-network

And then:

  • Select your Network Card (perhaps, it's eth0), then click on "Edit".
  • Enter as Primary DNS and Secondary DNS: 127.0.0.1
  • Click OK
  • Click File->Save and close the Network Configuration Tool
  • Restart the network service:
    # service network restart
    
    (or /etc/init.d/network restart)

Using your locally installed BIND to resolve DNS names will help you against the poisoned DNS of your ISP even for your everyday's web surfing!!!

Chapter 6: Fighting DNS leaks

Even with a normal BIND installation, DNS leaks are possible. Executing:

$ dig @127.0.0.1 whatever.onion

Will result in a NXDOMAIN error (domain not found), but the request has been at first sent all over the internet to lookup that "whatever.onion" address!!!!!!!!! Only to then discover that the domain is non-existent!!

If you've a misconfigured software, when you're going resolve DNS names of .onion addresses, BIND will let leak the address you were attempting to resolve!

Now, to avoid DNS leaks, you can configure BIND to block all DNS queries sent to lookup .onion websites!!!!

BIND allows you to resolve DNS names, but it allows you to improve your privacy too, filtering DNS requests!

Fedora has in /var/named a couple of working templates for actions to take on DNS resolutions. It's almost impossible to understand what's written in those files, but the file "named.empty" works returning a failure-error on every DNS resolution!! The file doing this very important job is /var/named/named.empty and this is the content of the file:

$TTL 3H
@	IN SOA	@ rname.invalid. (
					0	; serial
					1D	; refresh
					1H	; retry
					1W	; expire
					3H )	; minimum
	NS	@
	A	127.0.0.1
	AAAA	::1

What you've to do, if you didn't pasted my configuration file at first, is to edit the file: /etc/named.conf and adding this code on its bottom:

zone "onion" IN {
	type master;
	file "named.empty";
	allow-update { none; };
};

zone "i2p" IN {
	type master;
	file "named.empty";
	allow-update { none; };
};

As you could notice the file /etc/named.rfc1912.zones has a lot of entries similar to this one

Now, restart BIND:

# service named restart

(or /etc/init.d/named restart)

Well, do an experiment yourself! You'll see, from WireShark, that no packets at all are sent out when you attempt to resolve a .onion address!!!!!!

$ dig honeybee.onion
...
onion.			10800	IN	SOA	onion. rname.invalid. 0 86400 3600 604800 10800
...

Super!! the "rname.invalid" name is returned as it's written in the "named.empty" configuration file!!!

Chapter 7: Memory limit

The cached information that BIND holds, are saved in the RAM and not in a file on the disk!! This is of course very good for privacy and performance reasons.

Cached items are deleted when they expire, but by default the memory usage has no growing limit!

If you want to limit the memory BIND is allowed to use to cache DNS queries, you've to add in the configuration file the max-cache-size option!

In the options section, add:

options {
    ...
    max-cache-size 16M;
    ...
}

I think there is no reason to limit the size of the cache, especially when you use BIND only for yourself, but it could be useful for TOR EXIT NODES.

(This page was originally started by 'bee')

Last modified 13 months ago Last modified on Aug 17, 2016, 2:10:23 AM