For the lab I need a DNS server, I used to always setup a Windows server but with no key the fun ends after a while and you have to remember to re-activate the server and so on. This gets boring after a while. So to get around it I setup a bind server, also since there is a limit to what linux requires for resources to work and Windows requires for the same.
So after setting up a small Debian server and going over the general setup steps, I covered those in a sub article here.
To setup bind you need to install some tools. I do suggest you use a small text based server and install it with openssh but to install the bind tools run the following command: “sudo apt-get install -y bind9 bind9utils bind9-doc dnsutils” (For other Linux flavors you can use “yum install -y bind9 bind9utils bind9-doc dnsutils“. The rest below should be quite similar).
That will install what we need. Next we need to edit a file and create some files.
Run this to edit the first file: “sudo vim /etc/bind/named.conf.local“
Add the following so that we create a foward and reverse zone. vCenter for example needs this.
cat /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "test.local" IN { //Domain name
type master; //Primary DNS
file "/etc/bind/forward.test.local.db"; // Forward lookup file
allow-update { none;}; // Since this is the primary DNS server, this should be none.
};
zone "226.168.192.in-addr.arpa" IN {
type master;
file "/etc/bind/reverse.test.local.db";
allow-update {none;};
};
Do be careful with names of the files as typos can really make you want to pull out any remaining hairs on your head.
Next we need to copy a file to forward zone:
“sudo cp /etc/bind/db.local /etc/bind/forward.test.local.db“
and at the same time you can create the reverse file zone:
“sudo cp /etc/bind/db.127 /etc/bind/reverse.test.local.db“
The foward zone file should look similar to this (Bold is modified text):
; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA testhost01.test.local. root.testhost01.test.local. ( 3; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800 ); Negative Cache TTL ; @ IN NS localhost. @ IN A 127.0.0.1 @ IN AAAA ::1 ;Name Server Information @ IN NS testhost01.test.local. ;IP address of name server testhost01 IN A 192.168.226.11 ;A - Record Hostname to IP address esx01 IN A 192.168.226.21 esx02 IN A 192.168.226.22 esx03 IN A 192.168.226.23 esx04 IN A 192.168.226.24 witness IN A 192.168.226.20 vcenter IN A 192.168.226.31
The reverse lookup zone file should look like this (Again Bold text is modified):
; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA testhost01. root.testhost01. ( 1; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800 ); Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR localhost. ;NS Server Information @ IN NS testhost01.test.local. testhost01 IN A 192.168.226.11 ;Reverse lookup for Name server 11 IN PTR testhost01.test.local ;PTR record IP address to hostname 20 IN PTR witness.test.local 21 IN PTR esx01.test.local 22 IN PTR esx02.test.local 23 IN PTR esx03.test.local 24 IN PTR esx04.test.local 31 IN PTR vcenter.test.local
Next you should verify you haven’t made any mistakes. “;” is a common mistake here but also type errors can cause issues in either of the three files so make sure that all is good.
We use named-checkzone to check the files like this: “sudo named-checkzone test.local /etc/bind/forward.test.local.db” and “sudo named-checkzone test.local /etc/bind/reverse.test.local.db“
dnsadmin@testhost01:~$ sudo named-checkzone test.local /etc/bind/forward.test.local.db zone test.local/IN: loaded serial 3 OK dnsadmin@testhost01:~$ sudo named-checkzone test.local /etc/bind/reverse.test.local.db zone test.local/IN: loaded serial 1 OK dnsadmin@testhost01:~$
If it looks like this, all is good. If you get errors then you need to go and fix these.
Next step is to restart bind9 and enable it (if it isn’t already)
We do this by running sudo “systemctl restart bind9” and “sudo systemctl enable bind9“
Once done you can check the status of the bind service: “sudo systemctl status bind9“
You should not have gotten any errors from the above and the bind service should look like this:
named.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2023-02-18 20:56:09 CET; 7min ago Docs: man:named(8) Main PID: 2064 (named) Tasks: 8 (limit: 4617) Memory: 17.0M CPU: 68ms CGroup: /system.slice/named.service └─2064 /usr/sbin/named -f -u bind Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving '_.arpa/A/IN': 2001:500:1::53#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving '_.arpa/A/IN': 2001:500:200::b#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2001:500:87::87#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2001:67c:e0::1#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2620:37:e000::53#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2001:43f8:110::10#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2001:dd8:6::101#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'esx01.in-addr.arpa/PTR/IN': 2001:13c7:7010::53#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'in-addr.arpa/DNSKEY/IN': 2001:dd8:6::101#53 Feb 18 20:56:15 testhost01 named[2064]: network unreachable resolving 'in-addr.arpa/DNSKEY/IN': 2001:500:87::87#53
Now we can test that all is ok by running the dig command:
“dig esx01.test.local” for normal lookup and it should give you something like this. The important part is the ;;ANSWER SECTION: if there is no answer, something is wrong. I highlighted it in the output here:
; <<>> DiG 9.16.37-Debian <<>> esx01.test.local ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58339 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5ff2bf95ca928c420100000063f12f565e243136b294a50f (good) ;; QUESTION SECTION: ;esx01.test.local. IN A ;; ANSWER SECTION: esx01.test.local. 604800 IN A 192.168.226.21 ;; Query time: 0 msec ;; SERVER: 192.168.226.11#53(192.168.226.11) ;; WHEN: Sat Feb 18 21:04:38 CET 2023 ;; MSG SIZE rcvd: 89
For reverse lookup we use a similar command. “dig -x 192.168.226.22“
That gives this output, again same thing, answer section is all you want out of this.
; <<>> DiG 9.16.37-Debian <<>> -x 192.168.226.22 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63732 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: e9b34d82a2658de80100000063f12f6045e630a5eb563338 (good) ;; QUESTION SECTION: ;22.226.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 22.226.168.192.in-addr.arpa. 604800 IN PTR esx02.test.local.226.168.192.in-addr.arpa. ;; Query time: 8 msec ;; SERVER: 192.168.226.11#53(192.168.226.11) ;; WHEN: Sat Feb 18 21:04:48 CET 2023 ;; MSG SIZE rcvd: 139
That is it for a primary dns server. If you want to try yourself out with a slave dns server then you can read about it here.