Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Bind 9

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 33

Bind9

Translation(s): English - French

Daftar Isi

1. Introduction

2. Definitions

3. Network Layout

4. Server Management

1. Installation

2. Configuration

1. TSIG Signature

2. File /etc/bind/named.conf

3. File /etc/bind/named.conf.default-zones

4. File /etc/bind/named.conf.options

5. File /etc/bind/named.conf.local

6. File /etc/bind/named.conf.log

3. Resource Records (RR)

1. Files in var/cache/bind/

2. Some Explanations :

4. /etc/resolv.conf File

5. Bind Chroot

6. Client Manage

7. Testing tools

Introduction
8. Links and Resources

Putting a DNS server on a network allows for the replacement of IP addresses of


individual machines by a name. As a result, it's even possible to associate multiple
names to the same machine to update the different available services. For example,
www.example.com and pop.example.com, could both point to the primary server
where the mail server and the business intranet reside, and the domain could be
example.com. It's easy to remember that these two services are running on the
same machine whose IP address is 192.168.0.1.

Now imagine that our network administrator decides for some reason or another to
move the mail server to the machine 192.168.0.11. The only thing that has to be
changed is the DNS server configuration file. You could always go and modify the
host configuration for all the users, but that would be time consuming and
inconvenient.
Definitions
DNS : Domain Name System or Domain Name Server
Primary Server :
Secondary server :
Server cache :
Network Layout
We get internet access through an xxxbox (192.168.1.1), two DNS servers provided
by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be
referred to in the configuration because the xxxbox will be in charge of resolving
names if the packet destination isn't known. Consequently, I consider the xxxbox like
a primary server outside of our domain. The sid server (192.168.1.10) is connected
to the xxxbox via its primary network card. It's also connected to the LAN
(192.168.0.0/24) by its secondary network interface(192.168.0.1). It's on this that we
are going to install the primary DNS server for our domain example.com (RFC 2606)
All the computers on the LAN are automatically assigned a single address by the
DHCP service. The DHCP also provides the primary DNS server's address for our
domain, and updatees the host names for the zone example.com so they can be
associated with an ip address.
Server Management
Installation
The package bind9 will be used for installation.

# apt-get install bind9

and then if you want to also install the documentation (very useful):

# apt-get install bind9-doc


Configuration
After installation, you might want to get familiar with some of the configuration files.
They are in the directory /etc/bind/

TSIG Signature

The purpose of this signature is to authenticate transactions with BIND. Thus, the
DHCP server cannot update the example.com domain if it loses this key. Copy and
paste an existing key

# cd /etc/bind/

# cat rndc.key

key "rndc-key" {

algorithm hmac-md5;

secret "QJc08cnP1xkoF4a/eSZZbw==";

};

# cp rndc.key ns-example-com_rndc-key

You can generate a new key with the following options:

algorithm HMAC-MD5 - identifies 157 (required for a TSIG signature and


only algorithm supported by BIND)
length of 512 octets (multiple of 64 with a maximum length of 512 for the
above algorithm)
name : ns-example-com_rndc-key

dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-

example-com_rndc-key

Kns-example-com_rndc-key.+157+53334

The footprint associated with the key is 53334. We get two files, one with an
extension key and the other with a private extension. This substitutes the key in the
file ns-example-com_rndc-key with the one in one of these two files.

# cat Kns-example-com_rndc-key.+157+53334.private

Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5)

Key:

LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx

/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==

Bits: AAA=

# cat ns-example-com_rndc-key

key "ns-example-com_rndc-key" {
algorithm hmac-md5;

secret

"LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxK

x/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";

};

The file ns-example-com_rndc-key should not be made world readable for security
reasons. This should be inserted into the bind configuration by an include because
the bind configuration itself is world-readable. Also, it's a good idea to delete the key
and private files generated before.

File /etc/bind/named.conf

This file is the main configuration file for the DNS file.

// Managing acls

acl internals { 127.0.0.0/8; 192.168.0.0/24; };

// Load options

include "/etc/bind/named.conf.options";

// TSIG key used for the dynamic update


include "/etc/bind/ns-example-com_rndc-key";

// Configure the communication channel for

Administrative BIND9 with rndc

// By default, they key is in the rndc.key file and

is used by rndc and bind9

// on the localhost

controls {

inet 127.0.0.1 port 953 allow { 127.0.0.1;

};

};

// prime the server with knowledge of the root

servers

zone "." {

type hint;
file "/etc/bind/db.root";

};

include "/etc/bind/named.conf.default-zones";

include "/etc/bind/named.conf.local";

Note : with Debian Jessie the 'zone "." {...}' part is inside the file "named.conf.default-
zones". You don't need to add it in the file "named.conf".

File /etc/bind/named.conf.default-zones

Note: as of Debian 7 "Wheezy" bind9 ships with a file containing default forward,
reverse, and broadcast zones.

// be authoritative for the localhost forward and

reverse zones, and for

// broadcast zones as per RFC 1912

zone "localhost" {

type master;

file "/etc/bind/db.local";

};
zone "127.in-addr.arpa" {

type master;

file "/etc/bind/db.127";

};

zone "0.in-addr.arpa" {

type master;

file "/etc/bind/db.0";

};

zone "255.in-addr.arpa" {

type master;

file "/etc/bind/db.255";

};

File /etc/bind/named.conf.options

This file contains all the configuration options for the DNS server
options {

directory "/var/cache/bind";

// Exchange port between DNS servers

query-source address * port *;

// Transmit requests to 192.168.1.1 if

// this server doesn't know how to resolve

them

forward only;

forwarders { 192.168.1.1; };

auth-nxdomain no; # conform to RFC1035

// Listen on local interfaces only(IPV4)


listen-on-v6 { none; };

listen-on { 127.0.0.1; 192.168.0.1; };

// Do not transfer the zone information to

the secondary DNS

allow-transfer { none; };

// Accept requests for internal network

only

allow-query { internals; };

// Allow recursive queries to the local

hosts

allow-recursion { internals; };

// Do not make public version of BIND


version none;

};

The port associated with the query-source option must not in any case be frozen
because it jeopardizes the DNS transactions in the case of a resolver.

Vulnerability Note VU#800113


Bind9 DNS Cache Poisoning

M. Rash wrote an interesting article about this and how to force the source port
randomly via the iptables: Mitigating DNS Cache Poisoning Attacks with iptables

To reduce the delay timeout for UDP connections, and thus highlight the
randomization, which by default is 30s by tuple, simply update the parameter
net.netfilter.nf_conntrack_udp_timeout

# sysctl -w

net.netfilter.nf_conntrack_udp_timeout=10

to get timeout of 10s.

File /etc/bind/named.conf.local

This file contains the local DNS server configuration, and this is where you declare
the zones associated with this server's domain(s).

// Manage the file logs

include "/etc/bind/named.conf.log";
// Domain Management example.com

// ------------------------------

// - The server is defined as the master on the

domain.

// - There are no forwarders for this domain.

// - Entries in the domain can be added

dynamically

// with the key ns-example-com_rndc-key

zone "example.com" {

type master;

file "/var/lib/bind/db.example.com";

//forwarders {};

// If we do not comment the ''forwarders''

"empty" clients of the local subnet in my case

don't have access to the upstream DNS ?

//allow-update { key ns-example-com_rndc-


key; };
allow-update { key rndc-key; };

//confusion between the file name to import

(ns-example-com_rndc-key) and the key label (rndc-

key) ?

};

zone "0.168.192.in-addr.arpa" {

type master;

file "/var/lib/bind/db.example.com.inv";

//see comment below (zone "example.com")

//forwarders {};

//allow-update { key ns-example-com_rndc-

key; };

allow-update { key rndc-key; };

};
// Consider adding the 1918 zones here, if they are

not used in your

// organization

include "/etc/bind/zones.rfc1918";

NOTE: if you create a local non-FQDN and call it .local it clashes with some other
packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the
host line makes .local domains work.

File /etc/bind/named.conf.log

With Debian Jessie, you need to create this file in /etc/bind

logging {

channel update_debug {

file "/var/log/update_debug.log"

versions 3 size 100k;

severity debug;

print-severity yes;

print-time yes;

};
channel security_info {

file "/var/log/security_info.log"

versions 1 size 100k;

severity info;

print-severity yes;

print-time yes;

};

channel bind_log {

file "/var/log/bind.log" versions 3

size 1m;

severity info;

print-category yes;

print-severity yes;

print-time yes;

};
category default { bind_log; };

category lame-servers { null; };

category update { update_debug; };

category update-security { update_debug; };

category security { security_info; };

};

Here we define different log methods for the different categories. The first category
is, as its name indicates the default category that is usually assigned to syslog. All
categories not mentioned, are similar to the default category. For a list of the
different categories, see the bind9 administrator reference manual. In terms of blade-
servers, it ignores all the logs associated with them.

Resource Records (RR)


DNS is made up of several registrations, RR or Resource Records, defining the
various domain information. The first is dedicated to name resolution, in our case, it
is the file db.example.com. The second will be used for reverse name resolution, it is
the file db.example.com.inv.

Files in var/cache/bind/

RR for name reso (db.example.com file)

$TTL 3600
@ IN SOA sid.example.com.

root.example.com. (

2007010401 ; Serial

3600 ; Refresh

[1h]

600 ; Retry

[10m]

86400 ; Expire

[1d]

600 ) ; Negative

Cache TTL [1h]

@ IN NS sid.example.com.

@ IN MX 10 sid.example.com.

sid IN A 192.168.0.1

etch IN A 192.168.0.2
pop IN CNAME sid

www IN CNAME sid

mail IN CNAME sid

RR for inverse name resol ( db.example.com.inv file)

@ IN SOA sid.example.com. root.example.com.

2007010401 ; Serial

3600 ; Refresh

[1h]

600 ; Retry

[10m]

86400 ; Expire

[1d]

600 ) ; Negative

Cache TTL [1h]


;

@ IN NS sid.example.com.

1 IN PTR sid.example.com.

2 IN PTR etch.example.com.

Some Explanations :

$TTL : (Time To Live) expresses the duration (in seconds) validity, by default, of the
information contained in the RRs. Once this time expires, it is necessary to recheck
the data. Types :

SOA : Show romanization

to define information about the area. In this case the name of the primary DNS
server "sid.example.com." and the email address of technical contact
(root.example.com.; the @ is replaced by a dot). It is composed of several fields:

1. Serial : is the whole non-signed 32 bits. This is the serial number to


increment with each change of file. It allows the secondary server to reload
the information they have. The general purpose is to format it this way
YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101,
for the second 2007040102.
2. Refresh : defines the data refresh period.
3. Retry : if an error occurs during the last refresh, it will be repeated at the
end of time Retry.
4. Expires': the server is considered unavailable after the time expires.
5. Negative cache TTL': set the lifetime of a NXDOMAIN response from us.
'NS: information on behalf of nameservers for the domain.
'X.: information on the mail server. Many can be defined. Thus, it is possible
to give them a priority, assigning a number. The lower the number, the higher
the priority.
'A: associates a host name to an IPv4 address (32 bits)
'YYYY: associates a host name to an IPv6 address (128 bits)
'CNAME: identifies the canonical name of an alias (a name that points to
another name)
'PTR: This is simply the inverse resolution (the opposite of type A).

The classes in the association determines the Internet class. Other classes are
available (CH and HS). For more information please consult the RFC 1035

/etc/resolv.conf File

search example.com

It's no more complicated than that !


Bind Chroot
The named daemon is started using the bind user by default.

This option is found in the bind service config file /etc/default/bind9 (NOTE: this is
not valid for jessie who used systemd):

OPTIONS="-u bind"

The bind start script /etc/init.d/bind9 reads this config file when the service is
started.

Starting bind as a non root user is good practice but to run the daemon in a chroot
environment we also need specify the chroot directory. This is done using the same
OPTIONS variable in /etc/default/bind9.

To begin, start by stopping the bind service:

/etc/init.d/bind9 stop

Then edit /etc/default/bind9 (not for jessie):


OPTIONS="-u bind -t /var/bind9/chroot"

For Jessie, create the file /etc/systemd/system/bind9.service with options "-t


/var/bind9/chroot":

[Unit]

Description=BIND Domain Name Server

Documentation=man:named(8)

After=network.target

[Service]

ExecStart=/usr/sbin/named -f -u bind -t

/var/bind9/chroot

ExecReload=/usr/sbin/rndc reload

ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

For Jessie, after creating the above unit file, update the symlink to the unit file with:

systemctl reenable bind9

Now create the chroot directory structure:

mkdir -p

/var/bind9/chroot/{etc,dev,var/cache/bind,var/run/n

amed}

Create the required device special files and set the correct permissions:

mknod /var/bind9/chroot/dev/null c 1 3

mknod /var/bind9/chroot/dev/random c 1 8

chmod 660 /var/bind9/chroot/dev/{null,random}

Move the current config directory into the new chroot directory:

mv /etc/bind /var/bind9/chroot/etc

Now create a symbolic link in /etc for compatibility:


ln -s /var/bind9/chroot/etc/bind /etc/bind

If you want to use the local timezone in the chroot (e.g. for syslog):

cp /etc/localtime /var/bind9/chroot/etc/

Change the ownership on the files you've just moved over and the rest of the newly
created chroot directory structure:

chown bind:bind /var/bind9/chroot/etc/bind/rndc.key

chmod 775

/var/bind9/chroot/var/{cache/bind,run/named}

chgrp bind

/var/bind9/chroot/var/{cache/bind,run/named}

Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:

PIDFILE=/var/bind9/chroot/var/run/named/named.pid

Finally tell rsyslog to listen to the bind logs in the correct place:
echo "\$AddUnixListenSocket

/var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-

chroot.conf

Restart rsyslog and start bind:

/etc/init.d/rsyslog restart; /etc/init.d/bind9

start

Client Manage
As I mentioned at the beginning, the assignment of IP addresses on the LAN is
performed by the DHCP server. Thus, to set our DNS server to different clients, it is
necessary to add the DHCP configuration file the following two lines:

option domain-name "example.com"

option domain-name-server sid.example.com

It must be added to the file (I think) the areas for which DHCP should automatically
perform updates.

Syntax (everything after "=>" is my comments) :

zone [name.of.the.zone.] {

primary 127.0.0.1; => the primary DNS server is on the same machine as the
DHCP
key rndc-key; => it's necessary to provide the security key (via an include) in the
beginning of the DHCP server configuration file,
this must be the same key that secures the allow-update for the zone in the
named.conf.local of Bind9.

Examples de [name.of.the.zone.] (with the "." at the end) :

- example.com. : for the direct zone of this article,


- 0.168.192.in-addr.arpa. : for the inverse zone of this article.

For more information on the implementation of dynamic update of DNS records


through DHCP is here
Testing tools
Dig Command : this can directly search the DNS server of your choice and
get a lot of information in addition to name resolution and contrast resolution.

$ dig nomade-frjo.stones.lan

; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:

15760

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1,

AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:

;nomade-frjo.stones.lan. IN A


;; ANSWER SECTION:

nomade-frjo.stones.lan. 900 IN A

192.168.0.242

;; AUTHORITY SECTION:

stones.lan. 604800 IN NS

emerald.stones.lan.

stones.lan. 604800 IN NS

diamond.stones.lan.

;; ADDITIONAL SECTION:

diamond.stones.lan. 604800 IN A

192.168.0.1

emerald.stones.lan. 604800 IN A

192.168.0.2

;; Query time: 20 msec


;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Fri Mar 28 20:53:09 2008

;; MSG SIZE rcvd: 131

$ dig -x 192.168.0.242

; <<>> DiG 9.4.2 <<>> -x 192.168.0.242

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:

37702

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1,

AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:

;242.0.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:

242.0.168.192.in-addr.arpa. 900 IN PTR

nomade-frjo.stones.lan.

;; AUTHORITY SECTION:

0.168.192.in-addr.arpa. 604800 IN NS

diamond.stones.lan.

0.168.192.in-addr.arpa. 604800 IN NS

emerald.stones.lan.

;; ADDITIONAL SECTION:

diamond.stones.lan. 604800 IN A

192.168.0.1

emerald.stones.lan. 604800 IN A

192.168.0.2

;; Query time: 19 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Fri Mar 28 20:53:31 2008

;; MSG SIZE rcvd: 155

nslookup : Kind of slow but still useful.

$ nslookup etch

Server: 192.168.0.1

Address: 192.168.0.1#53

Name: etch.example.com

Address: 192.168.0.2

$ nslookup 192.168.0.2

Server: 192.168.0.1
Address: 192.168.0.1#53

2.0.168.192.in-addr.arpa name =

etch.example.com.

named-checkconf : Verifies the syntax of the configuration files for Bind9.

# named-checkconf -z

zone localhost/IN: loaded serial 1

zone 127.in-addr.arpa/IN: loaded serial 1

zone 0.in-addr.arpa/IN: loaded serial 1

zone 255.in-addr.arpa/IN: loaded serial 1

zone estar.lan/IN: loaded serial 20080315

zone 0.168.192.in-addr.arpa/IN: loaded serial

20080315

zone 10.in-addr.arpa/IN: loaded serial 1

zone 16.172.in-addr.arpa/IN: loaded serial 1


zone 17.172.in-addr.arpa/IN: loaded serial 1

zone 18.172.in-addr.arpa/IN: loaded serial 1

zone 19.172.in-addr.arpa/IN: loaded serial 1

zone 20.172.in-addr.arpa/IN: loaded serial 1

zone 21.172.in-addr.arpa/IN: loaded serial 1

zone 22.172.in-addr.arpa/IN: loaded serial 1

zone 23.172.in-addr.arpa/IN: loaded serial 1

zone 24.172.in-addr.arpa/IN: loaded serial 1

zone 25.172.in-addr.arpa/IN: loaded serial 1

zone 26.172.in-addr.arpa/IN: loaded serial 1

zone 27.172.in-addr.arpa/IN: loaded serial 1

zone 28.172.in-addr.arpa/IN: loaded serial 1

zone 29.172.in-addr.arpa/IN: loaded serial 1

zone 30.172.in-addr.arpa/IN: loaded serial 1


zone 31.172.in-addr.arpa/IN: loaded serial 1

zone 168.192.in-addr.arpa/IN: loaded serial 1

named-checkzone : Verifies the validity of zone files before resetting the


configuration.

# named-checkzone example.com

/var/lib/bind/db.example.com

zone example.com/IN: loaded serial 20080315

OK

# named-checkzone 0.168.192.in-addr.arpa

/var/lib/bind/db.example.com.inv

zone 0.168.192.in-addr.arpa/IN: loaded serial

20080315

OK

Links and Resources


rfc1035 - Implementation ans specifications
rfc1591 - Domain Name System Structure and Delegation
rfc2606 - Reserved Top Level DNS Names
http://www.bind9.net/manual/bind/9.3.2/Bv9ARM - Bind 9 Administrator
Manual
Services Whois :
Gandhi
AFNIC

?ToDos

End of
To add DNSSEC.

You might also like