207.3. Securing a DNS server

207.3 Securing a DNS server

Weight: 2
Description: Candidates should be able to configure a DNS server to run as a non-root user and run in a chroot jail. This objective includes secure exchange of data between DNS servers.
Key Knowledge Areas:
    BIND 9 configuration files
    Configuring BIND to run in a chroot jail
    Split configuration of BIND using the forwarders statement
    Configuring and using transaction signatures (TSIG)
    Awareness of DNSSEC and basic tools
    Awareness of DANE and related records
Terms and Utilities:
    /etc/named.conf
    /etc/passwd
    DNSSEC
    dnssec-keygen
    dnssec-signzone
When DNS was first implemented, it did not include any security, and soon after being put into use, several vulnerabilities were discovered. As a result, some security solutions was developed in the form of extensions that could be added to existing DNS protocols. This solutions were later tested, modified and approved as a standard by the Internet Engineering Task Force (IETF).

Domain Name Security Extentions (DNSSEC)

The original purpose of DNSSEC was to protect Internet clients from fake DNS data by verifying digital signatures embedded in the data. If the digital signatures in the data match those that are stored in the master DNS servers, then the data is allowed to continue to the client computer making the request.
DNSSEC uses a system of public keys and digital signatures to verify data. These public keys can also be used by security systems that encrypt data as it is sent through the Internet and then decrypt it when it is received by the intended recipient. However, DNSSEC cannot protect the privacy or confidentiality of data because it does not include encryption algorithms. It only carries the keys required to authenticate DNS data as genuine or genuinely not available.

How DNSSEC works?

For explaining how DNSSEC works first we should know about some items. what are RRsets ? ZSK ? RRSIG ? DSKEY?KSK ?

Resource Records sets (RRsets)

The first step towards securing a zone with DNSSEC is to group all the records with the same type into a resource record set (RRset). For example, if you have three AAAA records in your zone on the same label (i.e. label.example.com), they would all be bundled into a single AAAA RRset. Here we omit that as we don't ahve lots of records.
DNSSEC uses two pairs of keys ZSK and KSK.

Zone Signing Keys

Each zone in DNSSEC has a zone-signing key pair (ZSK). the private portion of the key digitally signs each RRset in the zone, while the public portion verifies the signature.

RRSIG

To enable DNSSEC, a zone operator creates digital signatures for each RRset using the private ZSK and stores them in their name server as RRSIG records. This is like saying, “These are my DNS records, they come from my server, and they should look like this.”
When a DNSSEC resolver requests a particular record type (e.g., AAAA), the name server also returns the corresponding RRSIG. The resolver can then pull the DNSKEY record containing the public ZSK from the name server. Together, the RRset, RRSIG, and public ZSK can validate the response.
If we trust the zone-signing key in the DNSKEY record, we can trust all the records in the zone. But, what if the the zone-signing key was compromised? HA HA HA, We need a way to validate the public ZSK. The solution is finding a way to verify the Public ZSK . Lets use KSK!

Key Signing Keys

In addition to a zone-signing key, DNSSEC name servers also have a key-signing key (KSK). The KSK validates the DNSKEY record in exactly the same way as our ZSK secured the rest of our RRsets in the previous section: It signs the public ZSK (which is stored in a DNSKEY record), creating an RRSIG for the DNSKEY.
Just like the public ZSK, the name server publishes the public KSK in another DNSKEY record, which gives us the DNSKEY RRset shown above. Both the public KSK and public ZSK are signed by the private KSK. Resolvers can then use the public KSK to validate the public ZSK.

Validation

Validation for resolvers now looks like this:
    Request the desired RRset, which also returns the corresponding RRSIG record.
    Request the DNSKEY records containing the public ZSK and public KSK, which also returns the RRSIG for the DNSKEY RRset.
    Verify the RRSIG of the requested RRset with the public ZSK.
    Verify the RRSIG of the DNSKEY RRset with the public KSK.

Implementing DNSSEC

For now we partially demonstrate DNSSEC.To start we need two pairs of keys , first KSK (Key Signing Key ) for DNSKEY record it self and another a of ZSK (Zone Signing Key) to sign the zone and zone validation.

dnssec-keygen

dnssec-keygen generates keys for DNSSEC (Secure DNS), first lets generate KSK keys, that is easy:
1
[email protected]:/etc/bind# mkdir dnsseckeys
2
[email protected]:/etc/bind# cd dnsseckeys/
3
[email protected]:/etc/bind/dnsseckeys# dnssec-keygen -a RSASHA256 -b 512 -n ZONE -f KSK myzone.
4
Generating key pair..++++++++++++ .....++++++++++++
5
Kmyzone.+008+44989
6
[email protected]:/etc/bind/dnsseckeys# ls -l
7
total 8
8
-rw-r--r-- 1 root bind 334 Apr 9 00:30 Kmyzone.+008+44989.key
9
-rw------- 1 root bind 624 Apr 9 00:30 Kmyzone.+008+44989.private
10
11
[email protected]:/etc/bind/dnsseckeys# cat Kmyzone.+008+44989.key
12
; This is a key-signing key, keyid 44989, for myzone.
13
; Created: 20180409072341 (Mon Apr 9 00:23:41 2018)
14
; Publish: 20180409072341 (Mon Apr 9 00:23:41 2018)
15
; Activate: 20180409072341 (Mon Apr 9 00:23:41 2018)
16
myzone. IN DNSKEY 257 3 8 AwEAAZkoKDolZNo2nlCxcRYncVQ+U1eg6f+0pAKA9W1GThUWYrnbm/T2 tcOKptbVf3Ly406hiPdSqVx/yhFYfPq2J6M=
17
18
[email protected]:/etc/bind/dnsseckeys# cat Kmyzone.+008+44989.private
19
Private-key-format: v1.3
20
Algorithm: 8 (RSASHA256)
21
Modulus: mSgoOiVk2jaeULFxFidxVD5TV6Dp/7SkAoD1bUZOFRZiudub9Pa1w4qm1tV/cvLjTqGI91KpXH/KEVh8+rYnow==
22
PublicExponent: AQAB
23
PrivateExponent: XbbRroqVBGTpSEza+ohV8wtT6cmfhQReWt3Xzu529rVSg9EyNjDc8qRgCiow5Phf3O4iZwHpZPrJ/ViztqKz+Q==
24
Prime1: ydBI9XugtVxwcPXa+N7jRtE2vuLvyxmLM+g+i4kAycc=
25
Prime2: wkdv2F4vUHqaY1dkSX1vToWJlufRfe3yTSQPXv1KE0U=
26
Exponent1: PbkiV1I0WMOo8COBkVQ6FtKt97vYszlgxcNmPa7tOsk=
27
Exponent2: EKLlZPXLv2yAQ/l70P84xNSSj6WSPuJdWVW5Kz0tVrE=
28
Coefficient: H/1FEkLLkgaxuXntlJ3illIhWvu9u1pD9DW7Qvab7A8=
29
Created: 20180409072341
30
Publish: 20180409072341
31
Activate: 20180409072341
Copied!
Whereas
dnssec-keygen switches
-a
Defines algorithm
-b
keysize
-n
nametype,can be weather ZONE for DNSSEC or HOST for TSIG
-f
Set the specified flag in the flag field of the KEY/DNSKEY record.The only recognized flags are KSK (Key Signing Key) and REVOKE.
dnssec also need a pair of ZSK keys to sign the zone with them:
1
[email protected]:/etc/bind/dnsseckeys# dnssec-keygen -a RSASHA256 -b 512 -n ZONE myzone.
2
Generating key pair....++++++++++++ ..............++++++++++++
3
Kmyzone.+008+63075
4
[email protected]:/etc/bind/dnsseckeys# ls -l
5
total 20
6
-rw-r--r-- 1 root bind 368 Apr 9 00:53 db.myzone
7
-rw-r--r-- 1 root bind 334 Apr 9 00:30 Kmyzone.+008+44989.key
8
-rw------- 1 root bind 624 Apr 9 00:30 Kmyzone.+008+44989.private
9
-rw-r--r-- 1 root bind 335 Apr 9 01:33 Kmyzone.+008+63075.key
10
-rw------- 1 root bind 624 Apr 9 01:33 Kmyzone.+008+63075.private
Copied!

dnssec-signzone

Obviously dnssec-signzone signs a zone and produces a signed version of the zone.
1
[email protected]:/etc/bind/dnsseckeys# cp ../zonedbfiles/db.myzone .
2
3
[email protected]:/etc/bind/dnsseckeys# dnssec-signzone -o myzone. -S db.myzoneFetching ZSK 63075/RSASHA256 from key repository.
4
Fetching KSK 44989/RSASHA256 from key repository.
5
Verifying the zone using the following algorithms: RSASHA256.
6
Zone fully signed:
7
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
8
ZSKs: 1 active, 0 stand-by, 0 revoked
9
db.myzone.signed
Copied!
Lets take a look at inside:
1
[email protected]:/etc/bind/dnsseckeys# cat db.myzone.signed
2
; File written on Mon Apr 9 01:45:42 2018
3
; dnssec_signzone version 9.10.3-P4-Ubuntu
4
myzone. 604800 IN SOA myzone. root.myzone. (
5
51 ; serial
6
604800 ; refresh (1 week)
7
86400 ; retry (1 day)
8
2419200 ; expire (4 weeks)
9
604800 ; minimum (1 week)
10
)
11
604800 RRSIG SOA 8 1 604800 (
12
20180509074542 20180409074542 63075 myzone.
13
eHu3B0s9AcclEMfkaXK+zUcqnhYTRXO2BBoR
14
s4z9DGxbwcTXoy8MbIACkuVOhkM6+tQ8r7pr
15
clIKoUALm4I4mQ== )
16
604800 NS ns1.myzone.
17
604800 NS ns2.myzone.
18
604800 RRSIG NS 8 1 604800 (
19
20180509074542 20180409074542 63075 myzone.
20
f6jD5tilUCY71BOMAWWbsfDQr2CFKOE6NRPs
21
LcQ4blDvxOjwpAXNk0w9b3eInZJESuKBOERB
22
jlPB3FEarNzZdA== )
23
604800 A 192.168.10.129
24
604800 RRSIG A 8 1 604800 (
25
20180509074542 20180409074542 63075 myzone.
26
QyHHXI2o/akKQsm1tSmKkomlnfo0ASTC4Pj5
27
uV1gFMj4Pb9sPGhq6ommZ6xtMOoezJ2sKyql
28
6RvPZeTyxPJHsQ== )
29
604800 NSEC host3.myzone. A NS SOA RRSIG NSEC DNSKEY
30
604800 RRSIG NSEC 8 1 604800 (
31
20180509074542 20180409074542 63075 myzone.
32
ZMUmj8nPWCPRUICoWcS72BmeGOv/mHn9ofIs
33
fFuX8WxDnmIVhGA5sUcz6cmUV9BebqwOGXdw
34
f5U1+5gqyLvydg== )
35
604800 DNSKEY 256 3 8 (
36
AwEAAaSTszWl/atXNh8wJrYaEKAQdJ4b7yyZ
37
aue+io6wOnVIivFgOmMXshGVPHF5CCbomw7L
38
2qzSv4f/vaxmvVStlSc=
39
) ; ZSK; alg = RSASHA256; key id = 63075
40
604800 DNSKEY 257 3 8 (
41
AwEAAZkoKDolZNo2nlCxcRYncVQ+U1eg6f+0
42
pAKA9W1GThUWYrnbm/T2tcOKptbVf3Ly406h
43
iPdSqVx/yhFYfPq2J6M=
44
) ; KSK; alg = RSASHA256; key id = 44989
45
604800 RRSIG DNSKEY 8 1 604800 (
46
20180509074542 20180409074542 44989 myzone.
47
GJ2phK3TxoSGoAYaA9T6Af9mZH4hj/G6rBXk
48
N1x/wmiHiQ2n2vpzUkwb3VJzCWXmYR/TSukw
49
RuNJlcKoPs3g7Q== )
50
604800 RRSIG DNSKEY 8 1 604800 (
51
20180509074542 20180409074542 63075 myzone.
52
G52jVRTYWp/rJME8j/pz/Aw/MKO8nUlDZAla
53
mls2Dniq3z5ySB1dXxQmHVTzwnnvu5BLNlad
54
ok/EzwXqB882Gw== )
55
host3.myzone. 604800 IN A 192.168.10.153
56
604800 RRSIG A 8 2 604800 (
57
20180509074542 20180409074542 63075 myzone.
58
aMgusMuRQORqwrRHPgCW3RROohncCFl7ONQY
59
jqlgDcB1Wyxu59ITLKSv9We6RhTu8PVcj/Si
60
0zBNdTnzlJ6Eyg== )
61
604800 NSEC ns1.myzone. A RRSIG NSEC
62
604800 RRSIG NSEC 8 2 604800 (
63
20180509074542 20180409074542 63075 myzone.
64
LQ/LlsulT95cOl6RGZSoUWzyBJ48EeLisSNQ
65
4lAAQr7pSAOZAawqznFGI4JPGeJvi+RH4L6l
66
ZDRlpyOX78QCtw== )
67
ns1.myzone. 604800 IN A 192.168.10.129
68
604800 RRSIG A 8 2 604800 (
69
20180509074542 20180409074542 63075 myzone.
70
J0w5HnJzXoJvG1tjmbNXkIlOle/9KWgZgCMH
71
Ndm0IPnV25VHsvUtI7PZ5u3uLztoZ6UC5eVW
72
gDyYmJAC9nI8wg== )
73
604800 NSEC ns2.myzone. A RRSIG NSEC
74
604800 RRSIG NSEC 8 2 604800 (
75
20180509074542 20180409074542 63075 myzone.
76
ibN/9JFAAo7fCM8tbkaFKmZMU0ew1elgx7mY
77
+FKfkzVr4Hd/nq6dvBNtRDWAKfcFHeOz5hJs
78
6NC1OcQfFSGT6w== )
79
test.myzone. 604800 IN A 1.1.1.1
80
604800 RRSIG A 8 2 604800 (
81
20180509074542 20180409074542 63075 myzone.
82
mJGjp/M9gAMrbi0MiydDiFiTa2ooTASS+9Dk
83
kKP9hoCohCvk1Dy0TaT5mZ9LOjLYExUNhNat
84
H6zi8+dJtfog3A== )
85
604800 NSEC myzone. A RRSIG NSEC
86
604800 RRSIG NSEC 8 2 604800 (
87
20180509074542 20180409074542 63075 myzone.
88
NIUD/EuZd7NKnEt9CDTLAIOje79JxN62jqSS
89
ObvlER7FKoKH4vOt1sEXaIKghS0g0+T2eJIK
90
lQMwrWWz0+BsEw== )
91
ns2.myzone. 604800 IN A 192.168.10.151
92
604800 RRSIG A 8 2 604800 (
93
20180509074542 20180409074542 63075 myzone.
94
W2yxllU1jAFubmbI0Le2WZOixOA9wObNsN0k
95
4dTtQFedzyVQrRbNWjlQhIp5aBibeKhXUKLA
96
KfiCYpiA4HuVFA== )
97
604800 NSEC test.myzone. A RRSIG NSEC
98
604800 RRSIG NSEC 8 2 604800 (
99
20180509074542 20180409074542 63075 myzone.
100
lSv8Tgiv3AXp4yNbvGrYFLjgcpgcPvnsgWjl
101
RcxL6lmKA4B4/Wg0znEHnhuour8IOrEcnvJ8
102
1Htsc4dURyxltg== )
Copied!
It generates additional required NSEC and RRSIG records :) also. its required to add
1
dnssec-enable yes;
2
dnssec-validation yes;
3
dns-seclookaside auto;
Copied!
in /etc/bind/named.conf.options
include the key files in /etc/bind/named.conf and finally use signed file db.myzone.signed in /etc/bind/named.conf.local .
that is enough for lpic 2 exam.

transaction signatures (TSIG)

Transaction aasignatures (TSIG) is a mechanism used to secure DNS messages and to provide secure server-to-server communication (usually between master and slave server, but it can be extended for dynamic updates as well). TSIG can protect the following type of transactions between two DNS servers:
    Zone transfer
    Notify
    Dynamic updates
    Recursive query messages etc
TSIG is available for BIND v8.2 and above.

How TSIG works ?

In a simplest way we use tsig to secure zone transfer between Master and slave dns server. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages. TSIG is easy and lightweight for resolvers and named.

Configuring TSIG

Configuring TSIG between Master and Slave DNS servers is no that much hard, We just create a shared key and copy it on both severs, and then configure Zone files to use that shared key.
For generating a shared-key we use dnssec-keygen tool.
As we mentioned dnssec-keygen generates keys for DNSSEC (Secure DNS). It can also generate keys for use with TSIG (Transaction Signatures) or TKEY (Transaction Key).
The name of the key is specified on the command line. For DNSSEC keys, this must match the name of the zone for which the key is being generated.
On master server:
1
[email protected]:~# cd /etc/bind
2
[email protected]:/etc/bind# mkdir mykeys
3
[email protected]:/etc/bind# cd mykeys/
4
[email protected]:/etc/bind/mykeys# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST -r /dev/urandom mykey
5
Kmykey.+157+08981
6
[email protected]:/etc/bind/mykeys# ls -l
7
total 8
8
-rw------- 1 root bind 49 Mar 12 04:44 Kmykey.+157+08981.key
9
-rw------- 1 root bind 165 Mar 12 04:44 Kmykey.+157+08981.private
10
11
[email protected]:/etc/bind/mykeys# cat Kmykey.+157+08981.key
12
mykey. IN KEY 512 3 157 b5aPd9u//WDzXeZIfF7vQw==
13
[email protected]:/etc/bind/mykeys# cat Kmykey.+157+08981.private
14
Private-key-format: v1.3
15
Algorithm: 157 (HMAC_MD5)
16
Key: b5aPd9u//WDzXeZIfF7vQw==
17
Bits: AAA=
18
Created: 20180312114414
19
Publish: 20180312114414
20
Activate: 20180312114414
Copied!
For implementing DNS-SEC use -n ZONE but here for TSIG we have used -n HOST.
As we said TSIG use a shared-key so we just need 1 key. We use Key: b5aPd9u//WDzXeZIfF7vQw== item from Kmykey.+157+08981.private for both servers. Lets create our desired key file :
1
[email protected]:/etc/bind# vim named.conf.tsig
2
[email protected]:/etc/bind# cat named.conf.tsig
3
key "mykey" {
4
algorithm HMAC-MD5;
5
secret "b5aPd9u//WDzXeZIfF7vQw=="
6
};
Copied!
now we need to include the key file that we have alredy made inside named.conf :
1
[email protected]:/etc/bind# vim named.conf
2
[email protected]:/etc/bind# cat named.conf
3
// This is the primary configuration file for the BIND DNS server named.
4
//
5
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
6
// structure of BIND configuration files in Debian, *BEFORE* you customize
7
// this configuration file.
8
//
9
// If you are just adding zones, please do that in /etc/bind/named.conf.local
10
11
include "/etc/bind/named.conf.options";
12
include "/etc/bind/named.conf.local";
13
include "/etc/bind/named.conf.default-zones";
14
15
include "/etc/bind/named.conf.tsig";
Copied!
Okey it is time to change zone file configuration and allow zone transfer with with whom has the shared-key. So change
allow-transfer {192.168.10.151;}; to allow-transfer { key "mykey" ; }; like this:
1
[email protected]:/etc/bind# cat named.conf.local
2
//
3
// Do any local configuration here
4
//
5
6
// Consider adding the 1918 zones here, if they are not used in your
7
// organization
8
//include "/etc/bind/zones.rfc1918";
9
10
zone "myzone" {
11
type master;
12
file "/etc/bind/zonedbfiles/db.myzone";
13
allow-transfer { key "mykey"; };
14
};
15
16
zone "10.168.192.in-addr.arpa" {
17
type master;
18
file "/etc/bind/zonedbfiles/db.10.168.192";
19
};
Copied!
okey lets check it
1
[email protected]:/etc/bind# rndc reload
2
rndc: 'reload' failed: failure
3
4
Mar 12 05:10:12 server1 named[4129]: reloading configuration failed: failure
5
Mar 12 05:12:07 server1 named[4129]: received control channel command 'reload'
6
Mar 12 05:12:07 server1 named[4129]: loading configuration from '/etc/bind/named.conf'
7
Mar 12 05:12:07 server1 named[4129]: /etc/bind/named.conf.tsig:4: missing ';' before '}'
8
Mar 12 05:12:07 server1 named[4129]: reloading configuration failed: failure
9
[email protected]:/etc/bind# vim named.conf.tsig
Copied!
opps we have forgot tiny miny ; in named.local.tsig .add it and then check again:
1
[email protected]:/etc/bind# rndc reload
2
server reload successful
Copied!
Now in Slave side, we should have some problems with zone tarnsfer as we haven't inserted shared-key . To test, increase the serial number of db.myzone file on master :
1
[email protected]:/etc/bind/zonedbfiles# cat db.myzone
2
;
3
; BIND data file for local loopback interface
4
;
5
$TTL 604800
6
@ IN SOA myzone. root.myzone. (
7
50 ; Serial
8
604800 ; Refresh
9
86400 ; Retry
10
2419200 ; Expire
11
604800 ) ; Negative Cache TTL
12
;
13
@ IN NS ns1.myzone.
14
@ IN NS ns2.myzone.
15
@ IN A 192.168.10.129
16
host3 IN A 192.168.10.153
17
ns1 IN A 192.168.10.129
18
ns2 IN A 192.168.10.151
Copied!
and see logs on slave:
1
[email protected]:/var/cache/bind# cat /var/log/syslog
2
Mar 12 05:34:12 server2 named[49966]: all zones loaded
3
Mar 12 05:34:12 server2 named[49966]: running
4
Mar 12 05:34:12 server2 named[49966]: zone myzone/IN: sending notifies (serial 49)
5
Mar 12 05:35:34 server2 named[49966]: client 192.168.10.129#40292: received notify for zone 'myzone'
6
Mar 12 05:35:34 server2 named[49966]: zone myzone/IN: notify from 192.168.10.129#40292: serial 50
7
Mar 12 05:35:34 server2 named[49966]: zone myzone/IN: Transfer started.
8
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: connected using 192.168.10.151#47929
9
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: resetting
10
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: connected using 192.168.10.151#56589
11
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: failed while receiving responses: REFUSED
12
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer status: REFUSED
13
Mar 12 05:35:34 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
14
Mar 12 05:35:42 server2 named[49966]: client 192.168.10.129#56251: received notify for zone 'myzone'
15
Mar 12 05:35:42 server2 named[49966]: zone myzone/IN: notify from 192.168.10.129#56251: serial 50
16
Mar 12 05:35:42 server2 named[49966]: zone myzone/IN: Transfer started.
17
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: connected using 192.168.10.151#60793
18
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: resetting
19
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: connected using 192.168.10.151#43951
20
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: failed while receiving responses: REFUSED
21
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer status: REFUSED
22
Mar 12 05:35:42 server2 named[49966]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
Copied!
To solve the problem lets add our shared-key to the Slave Server too:
1
[email protected]:/etc/bind# cat named.conf.tsig
2
key "mykey" {
3
algorithm HMAC-MD5;
4
secret "b5aPd9u//WDzXeZIfF7vQw==" ;
5
};
6
7
server 192.168.10.129 {
8
keys { "mykey" ; };
9
};
Copied!
We defined using the key for zone transfer from the master.
and finally include the key file on named.conf :
1
[email protected]:/etc/bind# cat named.conf
2
// This is the primary configuration file for the BIND DNS server named.
3
//
4
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
5
// structure of BIND configuration files in Debian, *BEFORE* you customize
6
// this configuration file.
7
//
8
// If you are just adding zones, please do that in /etc/bind/named.conf.local
9
10
include "/etc/bind/named.conf.options";
11
include "/etc/bind/named.conf.local";
12
include "/etc/bind/named.conf.default-zones";
13
14
include "/etc/bind/named.conf.tsig";
15
16
[email protected]:/etc/bind# rndc reload
17
server reload successful
Copied!
and check the zone transfer:
1
[email protected]:/etc/bind# cat /var/log/syslog
2
3
Mar 12 06:23:15 server2 named[51324]: all zones loaded
4
Mar 12 06:23:15 server2 named[51324]: running
5
Mar 12 06:25:02 server2 CRON[51405]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
6
Mar 12 06:25:28 server2 named[51324]: client 192.168.10.129#41507: received notify for zone 'myzone'
7
Mar 12 06:25:28 server2 named[51324]: zone myzone/IN: notify from 192.168.10.129#41507: serial 51
8
Mar 12 06:25:28 server2 named[51324]: zone myzone/IN: Transfer started.
9
Mar 12 06:25:28 server2 named[51324]: transfer of 'myzone/IN' from 192.168.10.129#53: connected using 192.168.10.156#38053
10
Mar 12 06:25:28 server2 named[51324]: zone myzone/IN: transferred serial 51: TSIG 'mykey'
11
Mar 12 06:25:28 server2 named[51324]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer status: success
12
Mar 12 06:25:28 server2 named[51324]: transfer of 'myzone/IN' from 192.168.10.129#53: Transfer completed: 1 messages, 9 records, 303 bytes, 0.002 secs (151500 bytes/sec)
Copied!

DNS-based Authentication of Named Entities (DANE)

TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years, a number of CA providers suffered serious security breaches. Like allowing the issuance of certificates for well-known domains to those who don't own those domains!
Trusting a large number of CAs might be a problem because any breached CA could issue a certificate for any domain name. DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.
Additionally DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.

TLSA Resource Record

The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLSA certificate association". In conjunction with DNSSEC signatures, this will permit better and more secure ways for applications to authenticate certificates. Here's an example for the HTTPS service (port 443, TCP) at www.example.com:
1
_443._tcp.www.example.com. IN TLSA ( 0 0 1
2
d2abde240d7cd3ee6b4b28c54df034b9
3
7983a1d16e8a410e4561cb106618e971 )
Copied!

split DNS Server

Split Domain Name System (Split DNS) is an implementation in which separate DNS servers are provided for internal and external networks as a means of security and privacy management. But why we should use split dns servers? Lets see what happens when we use an external dns server for accessing our web server:
Using single external dns having security issues, consume bandwidth, and has dependency to internet connection, while using split DNS servers bring us security and privacy. Split DNS uses two separate DNS servers:
An external DNS contains only small zone files for a domain with information like file transfer protocol (FTP), Web addresses and other server addresses that can be publicly published. An internal DNS server holds DNS records for an internal network.
When internal network users look up host names, the internal DNS answers and externally forwards this information as needed.
External users that lookup hostname from external network are answered by external DNS , which contains data limited to publicly accessible resources.
Also we can configure our Internal DNS server to return external IP address of host name to the guests who are in our internal network ! this prevents internal secrets from being divulged.

split DNS configuration

Implementing split DNS servers is so easy, no matter our internal DNS server is Forwarding requests or it is a Caching only DNS server, its just enough to make a master zone file for desired host name:
1
[email protected]:/etc/bind# ls
2
bind.keys db.empty named.conf named.conf.tsig
3
db.0 db.local named.conf.default-zones rndc.key
4
db.127 db.root named.conf.local zonedbfiles
5
db.255 mykeys named.conf.options zones.rfc1918
6
7
[email protected]:/etc/bind# vim named.conf.local
8
9
[email protected]:/etc/bind# cat named.conf.local
10
//
11
// Do any local configuration here
12
//
13
14
// Consider adding the 1918 zones here, if they are not used in your
15
// organization
16
//include "/etc/bind/zones.rfc1918";
17
18
zone "myzone" {
19
type master;
20
file "/etc/bind/zonedbfiles/db.myzone";
21
allow-transfer { key "mykey"; };
22
};
23
24
zone "mycompany.com" {
25
type master;
26
file "/etc/bind/zonedbfiles/db.mycompany";
27
};
28
29
zone "10.168.192.in-addr.arpa" {
30
type master;
31
file "/etc/bind/zonedbfiles/db.10.168.192";
32
};
Copied!
Now lets use one of our previous zone db files to configure zone file for mycompany.com hostname:
1
[email protected]:/etc/bind# cd zonedbfiles/
2
[email protected]:/etc/bind/zonedbfiles# ls
3
db.10.168.192 db.lo db.myzone
4
[email protected]:/etc/bind/zonedbfiles# cp db.myzone db.mycompany
5
[email protected]:/etc/bind/zonedbfiles# vim db.mycompany
6
[email protected]:/etc/bind/zonedbfiles# cat db.mycompany
7
;
8
; BIND data file for local loopback interface
9
;
10
$TTL 604800
11
@ IN SOA mycompany. root.mycompany. (
12
51 ; Serial
13
604800 ; Refresh
14
86400 ; Retry
15
2419200 ; Expire
16
604800 ) ; Negative Cache TTL
17
;
18
@ IN NS ns1.mycompany.
19
@ IN A 192.168.10.129
20
ns1 IN A 192.168.10.129
21
www IN A 192.168.10.6
22
23
[email protected]:/etc/bind# rndc reload
24
server reload successful
Copied!
Now lets query our local DNS server and compare answers with the answers that google DNS returns to us:
1
[email protected]:/etc/bind# dig @localhost www.mycompany.com
2
3
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost www.mycompany.com
4
; (1 server found)
5
;; global options: +cmd
6
;; Got answer:
7
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25981
8
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
9
10
;; OPT PSEUDOSECTION:
11
; EDNS: version: 0, flags:; udp: 4096
12
;; QUESTION SECTION:
13
;www.mycompany.com. IN A
14
15
;; ANSWER SECTION:
16
www.mycompany.com. 604800 IN A 192.168.10.6
17
18
;; AUTHORITY SECTION:
19
mycompany.com. 604800 IN NS ns1.mycompany.
20
21
;; Query time: 0 msec
22
;; SERVER: 127.0.0.1#53(127.0.0.1)
23
;; WHEN: Sun Mar 18 05:02:21 PDT 2018
24
;; MSG SIZE rcvd: 89
25
26
[email protected]:/etc/bind# dig @8.8.8.8 www.mycompany.com
27
28
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 www.mycompany.com
29
; (1 server found)
30
;; global options: +cmd
31
;; Got answer:
32
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42000
33
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
34
35
;; OPT PSEUDOSECTION:
36
; EDNS: version: 0, flags:; udp: 512
37
;; QUESTION SECTION:
38
;www.mycompany.com. IN A
39
40
;; ANSWER SECTION:
41
www.mycompany.com. 299 IN A 52.5.196.34
42
43
;; Query time: 416 msec
44
;; SERVER: 8.8.8.8#53(8.8.8.8)
45
;; WHEN: Sun Mar 18 05:02:35 PDT 2018
46
;; MSG SIZE rcvd: 62
Copied!
as you can see they are different, that is what we expected!

chroot

The term chroot refers to a process of creating a virtualized environment in a Unix operating system, separating it from the main operating system and directory structure.
This process essentially generates a isolated space, with its own root directory, to run software programs. This virtual environment runs separately from the main operating system's root directory. Any software program run in this environment can only access files within its own directory tree. It cannot access files outside of that directory tree. This confined virtual environment is often called a "chroot jail".
A chroot jail is a way to isolate a process and its children from the rest of the system. It should only be used for processes that don't run as root, as root users can break out of the jail very easily.

Configuring BIND to run in a chroot jail

Confguring BIND DNS server to run in chroot jail can be pretty strait forward. But based on distro that we choose, many configurations might be done automatically. Here we use CentOS6 for demonstartion:
1
[[email protected] ~]# yum install bind bind-utils -y
2
3
[[email protected] ~]# chkconfig --list | grep named
4
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
5
[[email protected] ~]# chkconfig --level 235 named on
6
[[email protected] ~]# chkconfig --list | grep named
7
named 0:off 1:off 2:on 3:on 4:off 5:on 6:off
8
9
[[email protected] ~]# service named start
10
Generating /etc/rndc.key: [ OK ]
11
Starting named: [ OK ]
12
[[email protected] ~]# service named status
13
version: 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5
14
CPUs found: 4
15
worker threads: 4
16
number of zones: 19
17
debug level: 0
18
xfers running: 0
19
xfers deferred: 0
20
soa queries in progress: 0
21
query logging is OFF
22
recursive clients: 0/0/1000
23
tcp clients: 0/100
24
server is up and running
25
named (pid 3321) is running..
Copied!
In CentOS by default all configuration are placed in /etc/named.conf :
1
[[email protected] ~]# cd /etc/named
2
[[email protected] named]# ls
3
[[email protected] named]# cd ..
4
[[email protected] etc]# cat named
5
named/ named.iscdlv.key named.root.key
6
named.conf named.rfc1912.zones
7
[[email protected] etc]# cat named.conf
8
//
9
// named.conf
10
//
11
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
12
// server as a caching only nameserver (as a localhost DNS resolver only).
13
//
14
// See /usr/share/doc/bind*/sample/ for example named configuration files.
15
//
16
17
options {
18
listen-on port 53 { 127.0.0.1; };
19
listen-on-v6 port 53 { ::1; };
20
directory "/var/named";
21
dump-file "/var/named/data/cache_dump.db";
22
statistics-file "/var/named/data/named_stats.txt";
23
memstatistics-file "/var/named/data/named_mem_stats.txt";
24
allow-query { localhost; };
25
recursion yes;
26
27
dnssec-enable yes;
28
dnssec-validation yes;
29
30
/* Path to ISC DLV key */
31
bindkeys-file "/etc/named.iscdlv.key";
32
33
managed-keys-directory "/var/named/dynamic";
34
};
35
36
logging {
37
channel default_debug {
38
file "data/named.run";
39
severity dynamic;
40
};
41
};
42
43
zone "." IN {
44
type hint;
45
file "named.ca";
46
};
47
48
include "/etc/named.rfc1912.zones";
49
include "/etc/named.root.key";
50
Copied!
Lets use CentOS bind-chroot package to put every thing in chroot jail:
1
[[email protected] etc]# yum install bind-chroot
Copied!
This package create chroot environment and create required links for BIND daemon :
1
[[email protected] etc]# cd sysconfig/
2
[[email protected] sysconfig]# ls
3
acpid init network sandbox
4
atd ip6tables networking saslauthd
5
auditd ip6tables-config network-scripts selinux
6
authconfig ip6tables.old nspluginwrapper smartmontools
7
cbq iptables ntpd sshd
8
clock iptables-config ntpdate sysstat
9
console iptables.old prelink sysstat.ioconf
10
cpuspeed irqbalance quota_nld system-config-firewall
11
crond kdump raid-check system-config-firewall.old
12
firstboot kernel readahead system-config-users
13
grub keyboard readonly-root udev
14
htcacheclean modules rngd wpa_supplicant
15
httpd named rsyslog
16
i18n netconsole samba
17
[[email protected] sysconfig]# cat named
18
# BIND named process options
19
# ~~~~~~~~~~~~~~~~~~~~~~~~~~
20
# Currently, you can use the following options:
21
#
22
# ROOTDIR="/var/named/chroot" -- will run named in a chroot environment.
23
# you must set up the chroot environment
24
# (install the bind-chroot package) before
25
# doing this.
26
# NOTE:
27
# Those directories are automatically mounted to chroot if they are
28
# empty in the ROOTDIR directory. It will simplify maintenance of your
29
# chroot environment.
30
# - /var/named
31
# - /etc/pki/dnssec-keys
32
# - /etc/named
33
# - /usr/lib64/bind or /usr/lib/bind (architecture dependent)
34
#
35
# Those files are mounted as well if target file doesn't exist in
36
# chroot.
37
# - /etc/named.conf
38
# - /etc/rndc.conf
39
# - /etc/rndc.key
40
# - /etc/named.rfc1912.zones
41
# - /etc/named.dnssec.keys
42
# - /etc/named.iscdlv.key
43
#
44
# Don't forget to add "$AddUnixListenSocket /var/named/chroot/dev/log"
45
# line to your /etc/rsyslog.conf file. Otherwise your logging becomes
46
# broken when rsyslogd daemon is restarted (due update, for example).
47
#
48
# OPTIONS="whatever" -- These additional options will be passed to named
49
# at startup. Don't add -t here, use ROOTDIR instead.
50
#
51
# KEYTAB_FILE="/dir/file" -- Specify named service keytab file (for GSS-TSIG)
52
#
53
# DISABLE_ZONE_CHECKING -- By default, initscript calls named-checkzone
54
# utility for every zone to ensure all zones are
55
# valid before named starts. If you set this option
56
# to 'yes' then initscript doesn't perform those
57
# checks.
58
ROOTDIR=/var/named/chroot
Copied!
Lets get in /var/named/chroot and say hello :
1
[[email protected] sysconfig]# cd /var/named/chroot/
2
3
[[email protected] chroot]# ls
4
dev etc lib64 usr var
5
6
[[email protected] chroot]# ls *
7
dev:
8
null random zero
9
10
etc:
11
localtime named.conf named.rfc1912.zones pki rndc.key
12
named named.iscdlv.key named.root.key protocols services
13
14
lib64:
15
libnss_files.so.2
16
17
usr:
18
lib64
19
20
var:
21
log named run tmp
22
23
[[email protected] chroot]# ls -l
24
total 20
25
drwxr-x---. 2 root named 4096 Mar 18 06:09 dev
26
drwxr-x---. 4 root named 4096 Mar 18 06:09 etc
27
drwxr-xr-x. 2 root root 4096 Mar 18 06:09 lib64
28
drwxr-xr-x. 3 root root 4096 Mar 18 06:09 usr
29
drwxr-x---. 6 root named 4096 Mar 18 06:09 var
Copied!
bind-chroot package has built every thing.
To do the same thing we have to edit /etc/default/bind9
1
[email protected]:/etc# cd default/
2
[email protected]:/etc/default# cat bind9
3
# run resolvconf?
4
RESOLVCONF=no
5
6
# startup options for the server
7
OPTIONS="-u bind"
Copied!
with -t option, The -t option changes the root directory from which bind operates to be /var/named/chroot :
1
# run resolvconf?
2
RESOLVCONF=no
3
4
# startup options for the server
5
OPTIONS="-u bind -t /var/named/chroot"
Copied!
and then make all required folders under /var/named/chroot directory and copy and link required files.
Last modified 2yr ago