5.3. Set up name resolution
While the DHCP server decides which MAC gets which IP, we want a way to
use more human readable names for our server. This requires us to setup
a mapping between the human readable names, such as c01.mgmt, and
their IP addresses.
For smaller systems it can be enough to only set up a /etc/hosts
file to resolve host names to IPs
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.1 c01.mgmt
192.168.1.2 c02.mgmt
After editing this file, you can easily check if resolution works by issuing a ping command:
[root@master ~]# ping c01.mgmt
PING c01.mgmt (192.168.1.1) 56(84) bytes of data.
...
This will however only configure name resolution on that particular host
that has this file. One way is to copy this hosts file to all
servers which need to be able resolve names to IP addresses.
However, with larger set ups this will quickly become cumbersome. Instead we want to configure our own DNS server, which any server in our network can then contact to ask for name resolution.
5.3.1. Forward Lookup
Remove any changes you made to
/etc/hostsInstall the Berkeley Internet Name Domain (BIND) service
A commonly used DNS server implementation is the Berkeley Internet Name Domain service or BIND. It is usually available via the package manage. Install it on the master node.
[root@master ~]# yum install bind bind-utils
Configure the
nameddaemonThe BIND package provides the
nameddaemon which is a DNS server that listens to port 53. Its configuration main configuration file can be found in/etc/named.conf.DNS servers are great target for outside attacks. We want to limit our DNS queries to be only accepted from the inside of our cluster networks. To do so we define which subnets we will listen to and use them in
listen-onandallow-queryoptions.acl servicenets { 192.168.0.0/20; 192.168.16.0/20; }; options { listen-on port 53 { localhost; servicenets; }; allow-query { localhost; servicenets; }; ...
Add zone definition for
.mgmtdomain.zone "mgmt." { type master; file "mgmt"; };
Create a file
/var/named/mgmtwith the following contents:$TTL 300 @ IN SOA master.mgmt. master.mgmt. ( 2018102904 ; Serial 600 ; Refresh 1800 ; Retry 604800 ; Expire 300 ; TTL ) IN NS master.mgmt. master IN A 192.168.0.1 c01 IN A 192.168.1.1 c02 IN A 192.168.1.2
Enable and start the
nameddaemon[root@master ~]# systemctl enable named [root@master ~]# systemctl start named
Try resolving one of the compute node host names
[root@master ~]# host c01.mgmt Host c01.mgmt not found: 3(NXDOMAIN)
Something is missing. We still have to tell our network stack which name server to use.
Look at the file
/etc/resolv.conf. This file is automatically generated by thedhclient-scriptuses our network configuration scripts.[root@master ~]# cat /etc/resolv.conf ; generated by /usr/sbin/dhclient-script nameserver 172.16.1.1
Depending on your network configuration it will register a domain name server in this file. However this one doesn’t know anything about our internal domain.
Manually edit this file to use our own DNS server
nameserver 192.168.0.1
and try again:
[root@master ~]# host c01.mgmt c01.mgmt has address 192.168.1.1
By prepending
search mgmtto/etc/resolv.confyou can even omit the domain name (.mgmt) completely.search mgmt nameserver 192.168.0.1
[root@master ~]# host c01 c01.mgmt has address 192.168.1.1
Our internal DNS server is now functioning. We want outside DNS requests to be forwarded to our external DNS server. Add the
forwardersline to yournamedconfiguration.acl servicenets { 192.168.0.0/20; 192.168.16.0/20; }; options { listen-on port 53 { localhost; servicenets; }; allow-query { localhost; servicenets; }; forwarders { 172.16.1.1; }; # at MHPC clusters use 172.16.0.1 as forwarder ...
[root@master ~]# host google.com google.com has address 172.217.12.174 google.com has IPv6 address 2607:f8b0:4002:c08::65 google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. google.com mail is handled by 30 alt2.aspmx.l.google.com.
All of these changes to
/etc/resolv.confare temporary and will not survive a reboot. To make them persistent, we need to modify our network configuration scripts accordingly to achieve the same effect.Correct your network configuration to use the local name server
Add the following lines to your
eno3interface configuration file (the one connected to the management network):DOMAIN="mgmt" DNS1=192.168.0.1
For all other interfaces set the following option:
PEERDNS=no
This way that interface will not “learn” new DNS servers when it gets them via DHCP and modify the
/etc/resolv.conf.Finally restart the network interface
[root@master ~]# ifdown eno3 [root@master ~]# ifup eno3
and verify
/etc/resolv.confmatches the following:search mgmt nameserver 192.168.0.1
5.3.2. Reverse lookup
So far we’ve configured DNS to resolve human readable names into corresponding IP addresses. You can also do the reverse with DNS.
Right now this doesn’t work:
[root@master ~]# host 192.168.1.1
Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
Reverse zone file for the IPMI subnet
Create a new zone file with the name
/var/named/192.168.1with the following contents:$TTL 300 @ IN SOA master.mgmt. master.mgmt. ( 2018102904 ; Serial 600 ; Refresh 1800 ; Retry 604800 ; Expire 300 ; TTL ) IN NS master.mgmt. master IN A 192.168.0.1 1 IN PTR c01.mgmt.; 2 IN PTR c02.mgmt.;
Add a new zone section in
/etc/named.confzone "1.168.192.in-addr.arpa." { type master; file "192.168.1"; };
Restart the
nameddaemon[root@master ~]# systemctl restart named
Verify reverse lookup works
[root@master ~]# host 192.168.1.1 1.1.168.192.in-addr.arpa domain name pointer c01.mgmt.