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.
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/host.conf.
In this file you can tell the system to try various means to
resolve a name such as look it up in a file,
use DNS, LDAP, NIS,
or other services.
(Additionally, this file describes how to resolve other things such
as service names to port numbers, automount information, password
and group information, etc.) /etc/hosts wwwwww.hccfl.edunsswitch.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 name
server (named) as a caching-only server.
You then must setup the resolver to use this local
DNS server.
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
db.127.0.0 (address to name)
and db.localhost (name to address),
and root.cache (hints file).
(These may be installed almost anywhere and given arbitrary names,
but typically under /var/named/).
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 digitially 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.
Sample copies of all required files can be found on our class website in the DNS resources section.
For this project you may work either individually or with
a single partner.
Groups of more than two are not allowed!
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/etc/hosts and the hostsnetworks/etc/nsswitch.conf.)
What changes (if any) did you make to these
files? /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.
Report and fix any errors found.
Be sure to comment out ALL lines containing any reference to
DNSSEC
(should be about five such lines).
DNSSEC requires more configuration than you need to
do for this project!
/etc/named.conf.
Examine each zone file (and compare to the samples found in the
resources section of this
website).
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.
A useful conventions is zonename.zonezonename‑rev.zoneroot‑servers.hintsserial numberfield! One good convention for serial numbers is to use the current date plus a number (in case you edit the file more than once in a given day), for example
2010080100. But you can use any number, as long as it increases for every change to the zone file. What serial number would you use for your zone files, if you needed to make changes today?
named‑checkzonewhois database to locate
the hostmaster.
For your own zones (and fakezones 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
for the DNS administrator (usually
hostmaster@yourDNS‑domainroot).
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
to rebuild the email alias database afterward. newaliases
/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? namedSys V initmethod of
/etc/init.d/named start.
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'
/etc/init.d/named status
or with rndc status. /etc/resolv.conf to
include the line
nameserver 0.0.0.0
before any other nameserver lines.
In this file the special IP of 0.0.0.0
means localhost.
(Note only the first three nameserver lines in
this file are used with some versions of the resolver.)
Add a search directive to 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.,
).
(You should use wwwsearch rather than the older
domain directive.)
Show the modified resolv.conf
file.
You can also try
, which
(unlike host wwwping) won't attempt to use
/etc/hosts no matter how nsswitch.conf
is set.
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 must update the DHCP configuration so
that doesn't happen.
Did your resolv.conf file
change after a reboot?
What is the name of the DHCP
client run on your system?
How did you find this out?
A nasty instructor would let you work out on your own how to configure your DHCP client. 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 0.0.0.0;
supersede domain-name "hccfl.edu";
}
See the man page for dhclient.conf for more
details.
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 (the most current at
this time) is to send all messages of any type to
syslog.
The default is to use 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 (since version 10) 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.
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? tail ‑f /var/log/messagessyslog
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 you can compare your configuration with
the following:
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.)
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
/etc/init.d/named reload 2> /dev/null >&1 || true
endscript
}
Read the man pages for whois,
host, and dig (host and
dig replace 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.
See
as
the command has no useful man page.)
getent ‑‑help
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.eduwhois for this.) wpollock.comhccfl.eduhccfl.edudig @ns1.hcc-online.com -t AXFR wpollock.com
and then try
dig -t AXFR hccfl.edu
Explain why there are differences in the output.
wpollock.comgrep.)
When testing your setup you can temporarily rename the
/etc/hosts file, or remove
from the files
line in
hosts:/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.
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. You can send as email to (preferred). If email is a problem for some reason, you may turn in a hard-copy. In this case the pages should be readable, dated, and stapled together. Your name should appear on the first page. Consider using this command when printing each file:
lpr -pJ "Your name - Caching DNS Server Project file" file
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.