BIND (Berkeley Internet Name Domain) is the most widely used DNS server on the Internet, especially on Unix-like systems. It is currently maintained by the Internet Systems Consortium.
A new version of BIND (BIND 9) was rewritten to solve some architectural issues in the initial code and to add support for DNSSEC (DNS Security Extensions).
Transaction signatures (“TSIG”) are a simpler form of DNS security. They use cryptographic hash functions to generate pseudo-signatures of DNS packets. The hash value is a combination of actual DNS data, timestamps to prevent replay attacks, and a shared secret between client and server. Since both entities involved in the DNS lookup must know the shared secret, TSIG signatures can only really be implemented in environments where systems are under common administrative control and where confidentiality of the shared secret can be absolutely guaranteed. In the case of ENUM, this means they can and should be used among ENUM level 0 name servers. For example, they can be used to validate zone transfers or dynamic update requests, with these functions being restricted to trusted clients because they know the shared secret.
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
The acl section allows you to define reusable access lists in other sections of the configuration file. The following definition defines internal clients:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
// Acl definition
acl "zoneinterne"{ // IP range authorized to make DNS requests
192.168.0.0/24;
10.8.0.0/24;
127.0.0.1;
};
acl "srvsecondaires"{ // My secondary server
x.x.x.x;
// Gandi (which offers a secondary DNS) 217.70.177.40;
};
Ideally, build a zone/view file (to include in named.conf for each of your zones). But for simplicity, we’ll leave everything in the same file here.
The view sections define server behaviors based on the IP address of the client sending the request, allowing DNS responses to be differentiated. We define two views:
One corresponding to clients in the internal and DMZ zone: recursion needs to be re-enabled for these requests, and resolving all possible names (zone “.”) needs to be allowed.
Another corresponding to requests from outside (e.g. Internet). Only authorize requests for the zone where the DNS server has authority:
view "interne"{ // These are the clients that see this view
match-clients { zoneinterne;
};
// Recursion permited for zoneinterne ACL subnets
recursion yes;
allow-recursion { zoneinterne;
};
// prime the server with knowledge of the root servers
zone "."{type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "deimos.fr"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.deimos.fr.local";
};
zone "mavro.fr"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.mavro.fr.local";
};
zone "localhost"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.255";
};
zone "0.168.192.in-addr.arpa"{type master;
notify no;
allow-update { none; };
file "/etc/bind/db.0.168.192.inv.local";
};
};
Now let’s move on to our external zone which will be visible to everyone from outside:
options { directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// Force other DNS to answer
//forwarders { // 212.27.32.176;
// 212.27.32.177;
//};
//======================================================================== // If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//======================================================================== // Avoid Bind Cache Poisoning
dnssec-enable yes;
dnssec-validation auto;
allow-query { any;
};
// Security version
// Check with: dig -t txt -c chaos VERSION.BIND @<dns.server.com>
version "Microsoft 2008 DNS Server";
auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };
};
You can add these types of options to improve security:
1
2
3
4
5
6
7
allow-recursion { none; }; // disabling recursive queries (and thus DNS cache Poisoning) allow-transfer { none; }; // disabling zone transfer
notify no; // disabling zone change notifications
zone-statistics no; // disabling statistics
interface-interval 0; // disabling search for new interfaces
max-cache-size 20M; // max cache size
In case you want to redirect domains (e.g., google.com –> a machine on your local network):
1
2
3
4
5
6
7
8
zone "google.com"{type forward;
forwarders { 192.168.0.17; // My primary DNS
192.168.0.30; // My secondary DNS
};
forward only;
};
You can also add this:
1
2
3
4
5
6
7
zone "128.168.192.in-addr.arpa"{type forward;
forwarders { 192.168.128.99;
};
forward only;
};
Here is the content of my file that will be available to everyone:
1
2
$TTL604800@ IN SOA simba.deimos.fr. root.deimos.fr. (
Replace the first field with the FQDN of your machine, and the second corresponds to the admin’s email (here root@deimos.fr). The email address is written in a special way, but it works.
1
2010301201 ; Serial (date + incrementation)
Note: By convention, the serial is in the form YYYYMMDDNN (YYYY: year, MM: month, DD: day, NN: revision).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
7200 ; Refresh
3600 ; Retry
1209600 ; Expire
604800 ; Negative Cache TTL
) NS mufasa.deimos.fr.
A 88.162.130.192
NS ns6.gandi.net.
NS shenzi.deimos.fr.
MX 5 mufasa.deimos.fr.
MX 10 shenzi.deimos.fr.
TXT "v=spf1 ip4:192.168.0.0/24 a mx ~all exp=getlost.deimos.fr" getlost TXT "You are not allowed to send a message from this domain" _deimos.fr TXT "t=y; o=-;" m1._deimos.fr TXT "g=; k=rsa; p=;...IWWiAyklt5FDmS2U7QIDAQAB..."
For the TXT part, I’ll let you check out other articles that deal with SPF.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
localhost A 127.0.0.1
mufasa A 82.232.191.145
shenzi A 88.191.130.125
ns6 A 217.70.177.40
mail CNAME mufasa
jabber CNAME mufasa
server CNAME mufasa
serveur CNAME mufasa
sftp CNAME mufasa
www CNAME mufasa
mytechnotebook CNAME mufasa
infos CNAME mufasa
webmail CNAME mufasa
nagios CNAME mufasa
All of these correspond to your A records, canonical names, etc.
Bind versions from 9.3 now incorporate more precise control over domain name validity. They can no longer contain _ (0x5f in the ASCII table), as stipulated by RFC 1035. This is however quite unfortunate for me because I have several domains containing _.
Error message produced:
Mar 6 07:48:08 dns3 named[25459]: pri/rags.ch.hosts:25: wisteria_lane.rags.ch: bad owner name (check-names)
Mar 6 07:48:08 dns3 named[25459]: zone rags.ch/IN: loading master file pri/rags.ch.hosts: bad owner name (check-names)
zone ‘deimos.fr’ allows updates by IP address, which is insecure link
You may have log errors like this:
Oct 2 17:29:03 star1 named[5120]: zone 'deimos.fr' allows updates by IP address, which is insecure
This simply means that your RNDC key is not being used. To use it with ACLs, just add your secondary servers to the “controls” section and only allow updates (at zone level) with the RNDC key:
Now restart your DNS server and there are no more problems, exchanges are encrypted :-)
too many timeouts resolving ‘mycompany.com/MX’ (in ’eu’?): disabling EDNS link
This error can appear for name resolution that takes too long due to UDP packet size. This can be very annoying, especially for email reception which can take a few hours. The solution is to add this line:
1
2
3
...
edns-udp-size 1460;
...
Then restart the bind service. If the problem persists, try lowering the size (change from 1460 to 500 for example). There are ways to test all this using the dig command. Use it like this until you no longer have timeouts: