New SA Training Topic 7: DNS and DHCP

1. New SA TrainingTopic 7: DNS and DHCP To implement the underlying basis for our organizations networking, we rely on two fundamental services • DNS – the hierarchical system by which host (computer, printer, etc.) names can be are translated to IP addresses – and IP addresses to names. • DHCP – the protocol which allows hosts to receive basic configuration information (most commonly, the IP address) necessary for communication on a given network.

2. 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?

3. 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

4. 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

5. 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"; };

6. 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

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 human-friendly • 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.

8. DNS – sample reverse zone file $TTL 86400 ; Addresses and other host information for the domain 168.192.in-addr.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.

9. DNS Exercise • Let’s think about adding a domain to DNS • Let’s think about looking up a host’s IP

10. Organizational addressing • For the initial setup of our new business locations, you will use the 10.1.x.x range • 10.1.10.x – 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

11. 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

12. 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

13. 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

14. 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; }

15. 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.