Transcript Lecture 1: Introduction

New SA Training
Topic 7: DNS and DHCP
To implement the underlying basis for our
organizations networking, we rely on two
fundamental services
– the hierarchical system by which host
(computer, printer, etc.) names can be are
translated to IP addresses – and IP addresses to
names.
 DNS
– the protocol which allows hosts to
receive basic configuration information (most
commonly, the IP address) necessary for
communication on a given network.
 DHCP
DNS - Overview
 Three components:
 resolver (client)
 name server (named)
 zone files (or some form of database, like AD). A
zone corresponds roughly to a domain.
 Resolver is set in platform-specific ways. Though
other information can be configured as well, the
two key items are:


What domain am I in by default?
What servers should I get DNS information from?
DNS - Overview (cont.)
 Servers can be:
Masters that are the authoritative source
for a domain
 Slaves that download information from a
master via zone transfers
 Caching-only servers that only cache
queries and don't pre-fetch
 Zone files are databases -- we'll discuss this
in a bit more detail when we see actual
named.conf and zone files

DNS - Platform-specific Issues
 Windows client configuration is handled via
DHCP or through the GUI
 Linux client is managed in /etc/resolv.conf
 Windows server DNS is usually managed
through the Microsoft Management Console
(MMC) and can be configured as part of
Active Directory (AD)
 Linux server is named and base configuration
is in /etc/named.conf, but the actual zone files
themselves are typically in /var/named
DNS - sample named.conf
options {
directory "/var/named";
};
// a master server configuration
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "mylab.net" {
type master;
file "mylab.net.hosts";
};
zone "168.192.in-addr.arpa" {
type master;
file "192.168.reverse";
DNS - sample zone file
$TTL 86400
@ IN SOA mylab.net. (
2001061401
; Serial
21600
; Slave Refresh
1800
; Slave Retry
604800
; Slave Expire
900 )
; Negative cache TTL
IN NS ns1.mylab.net.
; Defines a name server
IN NS ns2.mylab.net.
; Defines a name server
IN NS ns-server.myisp.com. ; Defines a name server
IN MX 10 mail.mylab.net.
; Defines a mail server
IN MX 20 backup-mail.mylab.net. ; Defines a mail server
localhost IN A 127.0.0.1
; Defines the local host
socrates IN A 192.168.1.1
; Defines a host in this zone
plato IN A 192.168.1.2
; Defines a host in this zone
ns1 IN A 192.168.1.3
; Defines a host in this zone
ns2 IN A 192.168.1.4
mail IN A 192.168.1.5
loghost IN CNAME plato.mylab.net. ; Defines a host in this zone
backup-mail IN CNAME ns2.mylab.net. ; Defines a host in this zone
aristotle IN A 192.168.1.6
; Defines a host in this zone
alexander IN A 192.168.1.7
DNS - A few things to note
 Each zone needs a separate zone file, which holds





the actual DNS contents
Types of records/entries
header/localhost/host order
header contents
Order of entries is arbitrary, but it helps to be humanfriendly
Without PTR records (in the .in-addr.arpa domain),
reverse lookups won't work. This is where DHCP
breaks static DNS and makes DDNS useful.
DNS – sample reverse zone file
$TTL 86400
; Addresses and other host information for the domain 168.192.inaddr.arpa
@ IN SOA mylab.net. (
2001061401 ; Serial
21600 ; Refresh
1800 ; Retry
604800 ; Expire
900 ) ; Negative cache TTL
1.1 IN PTR socrates.mylab.net.
2.1 IN PTR plato.mylab.net.
3.1 IN PTR ns1.mylab.net.
4.1 IN PTR ns2.mylab.net.
5.1 IN PTR mail.mylab.net.
6.1 IN PTR aristotle.mylab.net.
7.1 IN PTR alexander.mylab.net.
DNS Exercise
 Let’s think about adding a domain to DNS
 Let’s think about looking up a host’s IP
Organizational addressing
 For the initial setup of our new business
locations, you will use the 10.1.x.x range
– Abingdon, VA
 10.1.20.x – Caro, WV
 10.1.30.x – Chattanooga, TN
 10.1.40.x – Kiawah, SC
 10.1.50.x – Mortimer, NC
 10.1.60.x – York, PA
 10.1.70.x – Cleveland, OH
 10.1.10.x
DHCP - Background
 Basic idea is that systems will lease an IP address
rather than be assigned one statically. This simplifies
a traditional problem: keeping track of which IP
addresses in a set are free.
 Leasable parameters include:
 IP addresses and netmasks
 Gateways (default routes)
 DNS name servers
 Logging hosts
DHCP – How it works
 Client: who am I?
 Server: Would you like a lease for IP address
BLAH?
 Client: I would like to lease IP address BLAH
 Server: Ok
Note the four step process:
Discovery/Offer/Request/Acknowledge
DHCP - Platform-specific Issues
 Windows client is handled through the
ipconfig command or through the GUI
 Linux client is handled through pump as part
of /etc/sysconfig/network-scripts/ifcfg*
 Windows server is managed through the
Microsoft Management Console (MMC)
 Linux server is dhcpd and configuration is in
/etc/dhcpd.conf
DHCP - sample dhcpd.conf
# dhcpd.conf
#
# global options
option domain-name "mylab.test";
option domain-name-servers ns1.mylab.test;
option subnet-mask 255.255.255.0
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.51 192.168.1.60;
option broadcast-address 192.168.1.255;
option routers gateway.mylab.test;
}
DHCP Exercise
 Question: What would happen if there were
two DHCP servers on a single network, with a
client attempting to lease an IP address?
Describe a potential successful scenario and
a potential failure.