1 |
generally using something like ISC BIND you can set filters and easily |
2 |
create an external view and internal view, so that you can do split dns |
3 |
based on network connection. if doing something like this test it and |
4 |
then test it again to make sure there is no leak due to a typo. |
5 |
|
6 |
it would be easier if we knew what you were standing up the servers for. |
7 |
if it is for example your own domain name, you want something simple |
8 |
like a couple of A addresses and an MX record then you don't need to |
9 |
deviate much. |
10 |
|
11 |
if you are looking for dynamic dns updates you want to make sure you |
12 |
have auth by secured ip (encrypted traffic) and you want to guard your |
13 |
keys to allow DDNS. |
14 |
|
15 |
DNSSec is to prevent MITM attacks such as DNS cache poisoning, and you |
16 |
can see some starter material at ISC BIND website [1] |
17 |
|
18 |
In terms of "hack my dns server" there are many things that can hamper |
19 |
it - something at the bleeding edge like gentoo is ace for this kind of |
20 |
thing (*cough* centos is prehistoric *cough*) and if you were to load up |
21 |
metasploit with ISC specific filters you can try to see what is |
22 |
vulnerable. you can filter by CVE on your favourite website [2] |
23 |
|
24 |
If the server is public facing then you want to be wary of such goodies |
25 |
as recursive lookups as these can contribute to DoS attacks. you might |
26 |
also like to try flooding the server with DNS or spoofed ip and see what |
27 |
it responds to. these are not necessarily dns server specific but UDP |
28 |
server specific and you can start to get an idea of scalability. |
29 |
|
30 |
in terms of primary to secondary then you have to question the |
31 |
underlying layers -- is this being xferred across the internet ? |
32 |
internally over vpn ? are your secondary servers going to be full |
33 |
secondaries or just caching forwarders ? how will you control zone |
34 |
transfers ? consider filtering the type of queries, and the size of queries |
35 |
|
36 |
also consider the consequences of a hack. use selinux or similar, make |
37 |
sure dns running in its own username and/or namespace. primary target |
38 |
though has to be to change dns zones, so to make www.example.com map to |
39 |
www.clickads.com, so make sure that you have a remote server doing |
40 |
lookups regularly and report anomalies. |
41 |
|
42 |
hope this gives you a few directions to explore! |
43 |
|
44 |
[1] http://www.isc.org/downloads/bind/dnssec/ |
45 |
[2] |
46 |
https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html |