In this project you will build and use your own
caching-only nameserver (DNS).
(This nameserver is authoritative for localhost
only.)
After configuring a nameserver you then configure the
resolver library to use the nameserver and no longer use
the /etc/hosts file.
Note!
While you will go through the motions, the BIND DNS server
needs no local configuration to work; just install and run it.
For practice, you will make a couple of minor edits to the
named.conf file, as indicted below.
You need not define any “zones” or edit any zone files for
this project.
Four configuration files are used for a resolver-only configuration, where you do not run a name server locally. These files are:
/etc/nsswitch.conf /etc/hosts www”) to
FQDNs
(say “www.hccfl.edu”).
You would need this file even if nsswitch.conf
wasn't configured to use files to lookup hostnames. /etc/resolv.conf /etc/networks hosts file maps names to host
addresses.
It is not needed and is rarely used.
Note the /etc/networks file is always optional.
So is the /etc/resolv.conf file if you are not using
DNS at all, such as in host only or NIS
configurations.
In fact a minimal setup requires only two files: either
/etc/resolv.conf (for a DNS setup) or
/etc/hosts (for a non-DNS setup),
and /etc/nsswitch.conf (to say how to resolve names,
using the hosts file or using DNS).
Running a caching-only name server can be as simple as
running the name service caching daemon nscd.
However this daemon caches more than just hostnames.
It also caches user and group names (but not passwords).
So every time you add/delete/modify a user or group you must
remember to restart this daemon (to clear the cache).
Furthermore, running this daemon will occasionally interfere
with su.
(These are rarely problems on a production server however.)
Instead of running nscd, you will learn a lot
more about DNS by running the
BIND 9 name
server (named) as a caching-only server.
You then must setup the resolver to use this local
DNS server.
The most recent version of BIND is 10, but that is a complete rewrite and works very differently. Most distributions have decided to stick with BIND 9, and development has stopped on BIND 10 since nobody wanted it. You will want the most recent version of BIND 9. (You might need to explore your yum repos using the commands you have learned, to see what is available.)
If you run a nameserver you must configure it.
In a caching-only configuration of named, you
use the file /etc/named.conf (the nameserver
configuration), the DNS zone data files
named.<name-of-zone> (address to name)
and named.<name-of-zone> (name to address),
and named.ca (the so-called hints file).
(These may be installed almost anywhere and given arbitrary names,
but typically under /var/named/).
On Fedora, the bind package includes all the needed files,
and is pre-configured as a caching-only server.
Just install and run it, and it should work!
DNS is a service vulnerable to attack, so it makes sense
to secure it tightly.
The newer versions of named (the BIND
nameserver) support directives to restrict who can get info and
who can update the info, and to use encrypted communications.
In addition, it makes a lot of sense to run the nameserver inside of
a chroot jail.
(Or a BSD jail or Solaris 10
zone if available.)
The DNS records can be digitally signed, and the
data verified using “DNSSEC”.
In a large organization it makes sense to permit remote control
of the nameservers.
This is done with the command rndc (ndc
in older versions of BIND).
Obviously this command could be abused even if use is restricted to
users logged in on the localhost.
For this reason BIND permits you to configure this command with the
file /etc/rndc.conf, to restrict its use.
Additionally, rndc can be configured to use an
encryption key, generated with the command
rndc‑confgen, and stored in the file
/etc/rndc.key.
For our project, we will not configure DNSSEC or use
rndc.
Sample copies of all required files can be found on our class
website in the DNS resources
section.
(Keep in mind however, that over time, the commands and their configuration
change.
So don't simply copy the existing config files I provided as samples, they
are likely out of date!)
For this project you may work either individually or with
a single partner.
Groups of more than two are not allowed without explicit
permission of the instructor!
Each student must submit their own copy of the assignment, which
must include both your name and your partner's name.
You will setup, configure, and test a caching-only
nameserver, configure the resolver library to use it,
and configure the nameserver logging.
If necessary you will update the configuration of other affected
services, such as email aliases, syslog,
logrotate, or
DHCP.
Follow these steps and answer the following questions:
/etc/hosts and /etc/nsswitch.conf.
(Carefully examine the “127.0.0.1” line from
/etc/hosts and the “hosts” and
“networks” lines from
/etc/nsswitch.conf.)
What does the current configuration use to resolve
names?
What changes (if any) did you make to these files? named) name server if necessary.
Note!
With Fedora, if you used the server configuration when installing Fedora,
you probably already have BIND installed.
However, it seems that the default configuration doesn't always work!
It is probably best to simply uninstall BIND, then reinstall.
Use “dnf remove bind” to delete the old version
(and any dependent packages, such as bind-chroot.
Make a backup copy of named.conf, and any other files
you edit for this project.
You can then report the changes you made by showing the output of the
diff command.
Configure the nameserver by editing (if necessary) the
/etc/named.conf
file for a caching-only nameserver.
In what directory will the various zone
data files be stored?
What are the name(s) used for any zone files listed?
Verify your /etc/named.conf file has correct syntax
by running the command named‑checkconf.
View the man page to ensure you use the correct options.
Report and fix any errors found.
(No changes should be necessary for this step, but that may depend on your distribution and version.)
named.conf(8) man page to see how to comment out
lines.
What lines did you comment out?
/etc/named.conf.
Examine each zone file (and compare to the samples found in the
resources section of this
website).
What zone files are included by default on
your system?
In which directory are those file to be found?
(Hint: named.ca is not a normal zone file, so don't try to
check it.)
Do you like the zone file naming convention Red Hat uses?
If not, feel free to rename the files (and of course update
/etc/named.conf to use the new names).
A useful conventions is “zonename.zone”
for the forward zone file, and
“zonename‑rev.zone”
for the reverse zone file.
(I also like “root‑servers.hints” for the
hints file, since it isn't really a normal zone file.)
Report any changes you have made.
localhost has a legal syntax
by using the command “named‑checkzone”.
(Examine the man page for that command, to determine the correct options to
use.)
Report and fix any errors found.
What was the exact command line used to check that zone
file?
What changes (if any) did you make to these files? whois database to locate
the hostmaster.
For your own zones (and “fake” zones such as for
localhost) you can look in the zone file to find
the email address.
Check your textbook to determine which part of the zone data file
contains the email address.
(Hint: check the syntax of the “SOA” record.)
What is the email address listed for the
hostmaster for the localhost.localdomain zone?
(Optional part)
For any real zones (you don't have any for this assignment) you
should always verify that the email addresses used actually
exist.
Usually some email alias is used, so you must examine and
edit if necessary the /etc/aliases file.
It is very common to use (or create) an email alias
“hostmaster@yourDNS‑domain”
for the DNS administrator (usually
root).
Feel free to update your localhost zone data file(s)
with any valid email address you wish to use.
(The fake email address used by default is fine for a fake domain
such as localhost.)
What changes (if any) did you make to the
zone files? To the /etc/aliases file?
If you update the /etc/aliases file remember that
you must run the command “newaliases”
to rebuild the email alias database afterward.
/etc/sysconfig/named file has all lines
commented out.
This is a Red Hat configuration file used to set the command line
arguments to named.
(By default it may try to start the nameserver in a
chroot jail.
If so you must edit this file and comment out that line for
now.)
What changes did you make (if any)
to this file?
Note that if you do see any uncommented lines, you probably have
installed the wrong BIND package. named”) from the
command line.
This can be done if your system uses “Sys V init” by the
command “/etc/init.d/named start”.
However, if you have a modern systemd init system, you won't see any such
file.
Start the service using the normal systemctl command.
Examine the system log files for any errors or other name server
related messages.
What name server messages resulted when
you tried to start the nameserver?
You should see something like the following in your log file
(by default /var/log/messages on Fedora):
Mar 23 18:33:50 localhost named[9667]: starting BIND 9.2.3 -u named
Mar 23 18:33:50 localhost named[9667]: using 1 CPU
Mar 23 18:33:50 localhost named: named startup succeeded
Mar 23 18:33:50 localhost named[9667]: loading configuration from '/etc/named.conf'
Mar 23 18:33:51 localhost named[9667]: listening on IPv4 interface lo, 127.0.0.1#53
Mar 23 18:33:51 localhost named[9667]: listening on IPv4 interface eth0, 10.40.84.221#53
Mar 23 18:33:51 localhost named[9667]: command channel listening on 127.0.0.1#953
Mar 23 18:33:51 localhost named[9667]: zone 0.0.127.in-addr.arpa/IN: loaded serial 200503251
Mar 23 18:33:51 localhost named[9667]: zone localhost/IN: loaded serial 200503251
Mar 23 18:33:51 localhost named[9667]: running
Mar 23 18:33:51 localhost named[9667]: zone 0.0.127.in-addr.arpa/IN:
sending notifies (serial 200503251)
Mar 23 18:33:51 localhost named[9667]: received notify for zone '0.0.127.in-addr.arpa'
rndc status”,
if you configured that command correctly. /etc/resolv.conf to
include the line
nameserver 127.0.0.1
before any other nameserver lines.
(Note only the first three nameserver lines in
this file are used with some versions of the resolver.
The first one that provides an answer is used.)
Add (or replace) the search directive in this file like this:
search hccfl.edu
This will set a default domain name to use when resolving
hostnames without any periods in them (e.g.,
“www”).
(You should use search rather than the older
domain directive.)
Show the modified resolv.conf
file.
Note that DHCP over-writes the /etc/resolv.conf
file whenever it runs, usually at boot time.
So if you don't complete this project in one session, make sure to have
a copy of resolv.conf so you can quickly restore that file.
You can also try “host www”, which
(unlike ping) won't attempt to use
/etc/hosts no matter how nsswitch.conf
is set.
Finally, you can try “getent hosts www”,
which uses the resolver library (and thus tests everything).
What would it mean if ping and
getent return one result, but host returns a
different result?
named to start automatically at boot time.
How do you set named
to start automatically at boot time? /etc/resolv.conf file.
If so, you should update the NIC configuration file
ifcfg-nameOfNic so that doesn't happen.
Did your resolv.conf file
change after a reboot?
If so, what is the name of the configuration file for your NIC?
Show your changes to that file using diff.
resolv.conf
have the correct entries.
You would learn a lot by doing that!
But instead I have provided the information for you here;
you may wimp out and use it if you wish.
interface "eth0" {
prepend domain-name-servers 127.0.0.1;
supersede domain-name "hccfl.edu";
}
(You can determine the name of your NIC by examining the output of the command
“ifconfig”.)
See the man page for dhclient.conf for more
details if you are curious.
Note that NetworkManager won't use that file.
It only uses interface-specific files.
So if your NIC is named “eth0”,
you should make a symlink to that file as follows:
# ln -s /etc/dhcp/dhclient.conf /etc/dhcp/dhclient-eth0.conf
(Use your correct NIC instead of eth0.)
BIND (named) can use syslog to handle
errors.
But BIND also has a built-in version of syslog and
logrotate you can configure.
Rather than configure BIND to handle all the logging issues itself,
you can use its logging features to separate different kinds of
DNS log messages to go to separate syslog
facilities.
The default for log messages in BIND version 9 is to send all messages
of any type to syslog.
BIND uses syslog's daemon facility with
priority of info, for all messages.
With these settings, all nameserver messages end up in the
messages log file.
We want to change this so that DNS security messages
use the authpriv facility instead (and with
the default syslog configuration, the security
messages will end up in the /var/log/secure file.)
In addition we would like the other messages to end up
in a /var/log/named.log log file instead of the
/var/log/messages default.
To accomplish this you must update the syslog
configuration so it sends the messages to the correct place,
configure named to change the default logging,
and finally update the logrotate configuration
so the new log file gets rotated.
To do this, follow the steps below and answer the questions:
syslog.
Fedora uses “rsyslog” rather than
the traditional syslog daemon.
rsyslog is compatible with traditional syslog, except the
configuration file is named /etc/rsyslog.conf
rather than /etc/syslog.conf.
However the directions below will use the file name syslog.conf.
syslog.conf to identify
an unused facility.
Which general facilities
(local0 – local7) are not in
use? local2 isn't in use.
Edit syslog.conf and add a line to save all log
messages from local2 to the file
/var/log/named.log.
Also change the configuration so that local2 messages
only go to this file, and not also to any other.
(Duplicate log messages can be confusing!)
What did you add/change in
syslog.conf?
(Show the diff output.) tail ‑f /var/log/messages”.
In another window, activate your new syslog
configuration.
What command did you use to do
this?
Examine the output produced in the first window.
Did syslog restart
correctly? named you can specify
the facility you selected previously to log all messages,
say local2, and to additionally send security related
messages to the syslog authpriv facility.
Read your text for directions on how to add a logging
directive to your named.conf file.
When you have done that, compare your configuration with
the following (and if different, show your changes):
logging {
channel "security" { syslog authpriv; severity info; };
channel "named" { syslog local2; };
category security { "security"; "named"; };
category default { "named"; };
};
/var/log/named.log.
As we showed in class, you need to create a new configuration
file for logrotate in
/etc/logrotate.d.
(You can copy and modify one of the existing files rather than
start from scratch.)
Do not overwrite any existing named config file.
Simply create a new file (with a new name) to rotate your new log file.
Over time you will learn if the file is growing too fast
or too slow for the settings you chose, and you will need
to monitor the log file for a while and make any needed
adjustments.
Meanwhile, read the man page for logrotate.conf and
add any directives to your configuration that make sense to
you.
What is your logrotate configuration
for the named file?
A sample file can be found below.
/var/log/named.log {
missingok
create 0644 named named
postrotate
# For Sys V init:
# /etc/init.d/named reload 2> /dev/null >&1 || true
# For systemd init:
systemctl reload named.service 2> /dev/null >&1 || true
endscript
}
Read the man pages for whois,
host, and dig (host and
dig are replacements for the older nslookup
command).
Especially useful are:
host [-al] host-or-domain-name dig host-or-domain-name [any] getent hosts host-or-domain-name
(The getent command uses the resolver to get
the information; the other two commands directly query
DNS.
Notice that a simple change to the name server configuration has had
a cascade effect: many other services needed to be re-configured
as well (syslog, logrotate,
DHCP, and the email aliases).
Not realizing this cascade effect is a common trap for
system administrators.
You always need to ask “what else is affected by this
change?”
named, syslog, and logrotate,
what other services might be affected by changing the
named logging to use a new file?
(HINT: think about monitoring tools.)
hcc.edu”?
(Use whois for this; first try the command line tool,
then try an on-line website such as whois.domaintools.com.)
wpollock.com” and for
“hccfl.edu”?
hccfl.edu”)?
whois for this.)
Now look at the IP addresses in your host's
/etc/resolv.conf file, then
take a look at the IP addresses, and think about what
that shows about HCC's DNS setup.
dig @ns5.hccfl.edu -t AXFR wpollock.com
and then try
dig @ns5.hccfl.edu -t ANY wpollock.com
Note: here I showed using ns5, but be sure to
use an actual HCC name server found from the previous
question.
If you perform this project on-campus, you may need to use a different
nameserver from what whois shows.
This is because internal namservers use private IP
addresses, and whois data shows only the public,
external IP addresses.
Try one of the ones shown in your resolv.conf file.
(For security reasons, few servers allow unrestricted zone transfers using
AXFR!
So don't expect this to work.)
If the zone transfers were successful, explain why there are differences in the output.
dig -t AXFR hccfl.edu dig @ns5.hccfl.edu -t AXFR hccfl.edu dig @ns5.hccfl.edu -t ANY hccfl.edu
Explain the output:
Why did some commands work while others didn't?
Do you think you got all of the records in the hccfl.edu zone,
with the command that worked?
wpollock.com”, defined in that zone?
(This can be difficult to determine!
Try using a zone transfer and grep.
Remember, this will only work from YborStudent.)
When testing your setup you can temporarily rename the
/etc/hosts file, or remove “files”
from the “hosts:” line in
/etc/nsswitch.conf,
to be certain you are using the DNS system.
You should also frequently restart the DNS server
to clear the cache after each change.
(Speaking of caching, make sure you are not running nscd too!)
Sample configuration files can be found in the resources section of our class web page. You should be able to use them as models for your setup.
If you want some other host to use your nameserver, you must remember to adjust the firewall rules to allow other hosts access to your DNS server.
A copy of your relevant journal pages
and the answers to the questions asked above.
Use diff to show any file changes you made.
Project file" file
-->
Use Canvas and submit to the project's drop-box. Don't turn in your whole journal, you will need to add to it every day in class! It is common in fact to keep the journal as a text file on the system (with a paper backup of course).
Please see your syllabus for more information about submitting projects.