%\documentclass[colorBG,slideColor,troispoints,pdf]{prosper} \documentclass[colorBG,total,slideColor,pdf]{prosper} %\documentclass[colorBG,slideColor,ps]{prosper} \usepackage{alltt,key,xr,cols,rcs,acro,amstext,nick,% graphicx,varioref,explanation,booktabs,color} \usepackage[nolineno,noindent]{lgrind} \definecolor{green}{rgb}{0,1,0} \RCS $Revision: 1.0 $ \renewcommand*{\bs}{\texttt{\char '134}} % Backslash `\' \newcommand*{\labTitle}{DHCP and DNS} \newcommand*{\subject}{Operating Systems and Systems Integration} \newcommand*{\emphcolour}[1]{\emph{\red#1}} \providecommand*{\RPM}{\acro{RPM}\xspace} \providecommand*{\CD}{\acro{CD}\xspace} \providecommand*{\IPC}{\acro{IPC}\xspace} \providecommand*{\UID}{\acro{UID}\xspace} \providecommand*{\GID}{\acro{GID}\xspace} \providecommand*{\SMP}{\acro{SMP}\xspace} \providecommand*{\API}{\acro{API}\xspace} \providecommand*{\NTP}{\acro{NTP}\xspace} \title{DHCP and DNS} \author{Nick Urbanik \texttt{}\\ \footnotesize{}Copyright Conditions: GNU FDL (see \url{http://www.gnu.org/licenses/fdl.html})} \institution{A computing department} \slideCaption{OSSI---DHCP and DNS} %%%\Logo{\includegraphics[height=15mm]{ict-logo-smaller}} \begin{document} \maketitle \begin{slide}{\DHCP and DNS} \begin{center} \LARGE{}Dynamic Host Configuration Protocol (\DHCP)\\and\\ Domain Name System (DNS) \end{center} \begin{center} Organising computers in a large network \end{center} \begin{center} Reference books: \end{center} \begin{center} \emphcolour{{The DHCP Handbook}}{, Ralph Droms \& Ted Lemon, 2}$^{\mathrm{{nd}}}${ edition,} \end{center} \begin{center} \emphcolour{DNS and Bind}, Paul Albitz and Cricket Liu, 4$^{\mathrm{th}}$ edition \end{center} \end{slide} \begin{slide}{\DHCP: Why?} \begin{itemize} \item Manually assigning \IP addresses (the alternative to \DHCP) causes: \begin{itemize} \item More work to set up \item Much more work to change \item \IP address conflicts \item Unsatisfied users who configure their own machines to cause more conflicts \end{itemize} \end{itemize} \end{slide} \begin{slide}{\DHCP: Why not?} \begin{itemize} \item Last year, on many Tuesday afternoons, our laboratories were disrupted by ``network failure'' \item This was caused by project students running \DHCP servers on our network, \item \ldots and also, by a small router running a \DHCP server accidentally plugged into our campus network \item Solution: when detect this, run \texttt{Ethereal} listening on ports 67 and 68 \item identify culprit, and turn off rogue server \end{itemize} \end{slide} \begin{slide}{What can \DHCP do?} \begin{itemize} \item Current standard \DHCP servers can: \item Allocate all \IP parameters \item Divide hosts into classes, based on many criteria, such as: \begin{itemize} \item Manufacturer \item Explicitly putting individual machines into different classes \item Whether the machine is registered \end{itemize} \item Offer different parameters to machines in different classes \item Dynamically update \DNS servers \item Support a \DHCP failover protocol \end{itemize} \end{slide} \begin{slide}{Internet Software Consortium: \ISC \DHCP} \begin{itemize} \item \ISC makes \emphcolour{reference implementations} of \DNS, \DHCP \item Available from {\red\url{http://www.isc.org/}} \item Implemented by people directly involved with the standardisation process \item Provide the most standards compliant, most feature-rich implementations \item \ISC \DHCP server very robust \begin{itemize} \item See experience with Tsing Yi Computer Centre \end{itemize} \end{itemize} \end{slide} \begin{slide}{Experience at Tsing Yi CC} \begin{itemize} \item At Tsing Yi Computer Centre: \begin{itemize} \item Computer Centre in TY used MS \DHCP on \NT 4 \item Crashed twice, with complete loss of database containing \MAC addresses of all computers on campus \item Out of action for \emphcolour{two days} at a time, long sessions of \emphcolour{manual retyping} of all the data again \end{itemize} \item Replaced with system based on \ISC \DHCP server on a 486 \item Has worked well ever since (no down time) \end{itemize} \end{slide} \begin{slide}{Characteristics of \DHCP} \begin{itemize} \item \emphcolour{\underline{All}} communication \emphcolour{initiated by the client} \item Uses UDP on port 68 for client, port 67 for server \item One \DHCP session has a common \texttt{xid} (``transaction ID'' in Ethereal), randomly selected by the client \item Uses \emphcolour{\underline{unicast}} when client has \IP address, [and client is \emphcolour{not} in \texttt{REBINDING} state --- see later; \emphcolour{\underline{broadcast}} otherwise \item Addresses offered from \begin{itemize} \item \emphcolour{\underline{address pools}}, or \item Fixed addresses allocated to particular computers \end{itemize} \end{itemize} \end{slide} \begin{slide}{Leases} \begin{itemize} \item Server offers \IP address and network parameters for a limited time (called a \emphcolour{\underline{lease}}) \item In practice, leases may very from 30 minutes to a week or so \item Short lease: \begin{itemize} \item clients get updated parameters quickly \item Essential if have more clients than addresses \item requires more processing power on server \end{itemize} \item Long lease: \begin{itemize} \item more reliable (clients may continue to operate for a week after \DHCP server fails) \item but takes longer for all clients to get new settings if they change \end{itemize} \end{itemize} \end{slide} \begin{slide}{(Some) Standards for \DHCP} \begin{itemize} \item RFC 2131 --- Basic \DHCP operation \begin{itemize} \item excerpts from this appear in exams! \end{itemize} \item RFC 2132 --- \DHCP options: a list of the kinds of things a client can ask a \DHCP server for \item IETF Drafts: \begin{itemize} \item draft-ietf-dhc-authentication-14.txt \item supports authentication between clients and servers \item draft-ietf-dhc-dhcp-dns-12.txt \item interaction between \DHCP and \DNS servers \item draft-ietf-dhc-failover-07.txt \item supports failover between 2 \DHCP servers \end{itemize} \end{itemize} \end{slide} \begin{slide}{\DHCP Messages --- 1} \begin{itemize} \item \texttt{\green{}DHCPDISCOVER} --- from {\green{}client} \begin{itemize} \item client has no address, asking for a new one \end{itemize} \item \texttt{\red{}DHCPOFFER} --- from {\red{}server} \begin{itemize} \item Offer of address and other parameters \end{itemize} \item \texttt{\green{}DHCPREQUEST} --- from {\green{}client} \begin{itemize} \item Client asks if can use the offered address and parameters \end{itemize} \item \texttt{\red{}DHCPACK} --- from {\red{}server} \begin{itemize} \item Server says ``yes, go ahead, this address and these parameters are yours; the lease starts now.'' \end{itemize} \end{itemize} \end{slide} \begin{slide}{\DHCP Messages --- 2} \begin{itemize} \item \texttt{\red{}DHCPNAK} --- from {\red{}server} \begin{itemize} \item ``no, you may not have that address; go to the \texttt{INIT} state'' \end{itemize} \item \texttt{\green{}DHCPDECLINE} --- from {\green{}client} \begin{itemize} \item Client has detected another machine is using the offered address, and tells the server about this problem \end{itemize} \item \texttt{\green{}DHCPRELEASE} --- from {\green{}client} \begin{itemize} \item Server expires the lease immediately \end{itemize} \item \texttt{\green{}DHCPINFORM} --- from {\green{}client} \begin{itemize} \item Client already has an \IP address, but wants other network settings from the server \end{itemize} \end{itemize} \end{slide} \begin{slide}{State Diagram for \DHCP protocol} \begin{itemize} \item See page 34 of RFC 2131 for a more complete state diagram. \end{itemize} \end{slide} \begin{slide}{\DHCP Client States --- 1} \centering% \includegraphics[width=\slideWidth]{dhcp-client-state-diagram} \end{slide} \begin{slide}{\DHCP Client States --- 2} \begin{itemize} \item \texttt{INIT} (client is booting) \begin{itemize} \item no \IP address yet. \item next message from client will be a broadcast \texttt{DHCPDISCOVER}. \end{itemize} \item \texttt{INIT-REBOOT} (has unexpired lease) \begin{itemize} \item has \IP address, but is not using it \item client will next broadcast \texttt{DHCPREQUEST} \item Will move to \texttt{BIND} state if no response \end{itemize} \item \texttt{SELECTING} (has received at least one \texttt{DHCPOFFER}) \begin{itemize} \item Waiting for any other \texttt{DHCPOFFER}s \end{itemize} \end{itemize} \end{slide} \begin{slide}{\DHCP Client States --- 3} \begin{itemize} \item \texttt{BOUND} (Client has an address) \begin{itemize} \item Initiated by client receiving \texttt{DHCPACK} to \texttt{DHCPREQUEST} \item Send no more messages until T1 (renewal time, configured in client by the server) \end{itemize} \item \texttt{RENEWING} (client has reached \emphcolour{\underline{renewal time}} $T1$ in \texttt{BOUND} state) \begin{itemize} \item client \emphcolour{\underline{unicasts}} \texttt{DHCPREQUEST} to server \item server \emphcolour{\underline{unicasts}} \texttt{DHCPACK} to client \item $T1 = \text{lease time} / 2$ \end{itemize} \end{itemize} \end{slide} \begin{slide}{\DHCP Client States --- 4} \begin{itemize} \item \texttt{REBINDING} (client has reached \emphcolour{\underline{rebinding time}} $T2$ without \texttt{DHCPACK} from server) \begin{itemize} \item client broadcasts \texttt{DHCPREQUEST} \item client is looking for another server \item $T2 = \text{lease time} \times 7/8$ \item If lease expires, client goes back to \texttt{INIT} state \item Any network connections lost---bad for users!! Don't let it happen to them! \end{itemize} \end{itemize} \end{slide} \begin{slide}{Obtaining an initial configuration} \begin{itemize} \item The client is booting, with no \IP lease \end{itemize} \centering% \includegraphics[width=0.7\slideWidth]{obtain-initial-config} \end{slide} \begin{slide}{Confirming an \IP Address when restarting} \begin{itemize} \item The client's lease has not expired \centering% \includegraphics[width=0.5\slideWidth]{confirm-renew-address} \end{itemize} \end{slide} \begin{slide}{Extending a lease} \begin{itemize} \item Lease is extended at $T1$ before expires \item Unicast, because address is valid \item only case of unicast in \DHCP protocol \item $T1 = \text{leasetime}/2$ \end{itemize} \centering% \includegraphics[width=0.45\slideWidth]{extend-active-lease} \end{slide} \begin{slide}{Moving a computer to new subnet} \begin{itemize} \item Refuse old address, issue a new one \end{itemize} \centering% \includegraphics[width=\slideWidth]{moved-to-new-network} \end{slide} \begin{slide}{Problems on the Network} \begin{itemize} \item Often a computer has a bad configuration \item Faulty hardware may also cause excessive resending of bad packets \item Less often, a person may be doing something naughty on purpose! \item Need some way to: \begin{itemize} \item track the location of a computer on the network \item determine if a computer is managed by the company or is a notebook brought in by a visitor \end{itemize} \item Want some way to register company machines \end{itemize} \end{slide} \begin{slide}{Ways of using \DHCP} \begin{itemize} \item There are two fundamentally different ways of using \DHCP \item Typified by implementation in Campus, and \ICT (till last week) \begin{itemize} \item (both implemented by Nick!) \item \mbox{}{\red{}Fixed addresses for registered clients} (Campus network) \item \mbox{}{\red{}Dynamic addresses} for all comers (\ICT till recently) \end{itemize} \item Better: can provide automatic registration for clients: see chapter 20 of \emph{The DHCP Handbook} \end{itemize} \end{slide} \begin{slide}{\texttt{/etc/dhcpd.conf}} \begin{itemize} \item This plain text configuration controls behaviour of \ISC \DHCP server \item \ISC \DHCP server supports conditional statements, switch statements, substring expressions \item Almost a complete programming language! \item This text file can be generated by software (Perl programs often used) \end{itemize} \end{slide} \begin{slide}{\texttt{dhcpd.leases}} \begin{itemize} \item This plain text file is generated by the \DHCP server \item Can be parsed by a Perl program \item Can be used to determine the \MAC address of an unregistered computer \end{itemize} \end{slide} \begin{slide}{Advantage of {\red{}Text}\blue{} Configuration} \begin{itemize} \item \emphcolour{Text} can be easily generated by a program \item Can be easily checked by a human \item Microsoft \DHCP server configuration and lease information is in an undocumented binary format \item reduces what can be done with it \item makes it hard to enter large amounts of information about many computers \begin{itemize} \item experience at Tsing Yi Computer Centre \end{itemize} \end{itemize} \end{slide} \begin{slide}{Host Records with Fixed Address} \begin{itemize} \item Can specify a fixed address for particular hosts: \end{itemize} {\footnotesize% \begin{verbatim} # Machine type = COMPAQ DESKPRO Laboratory = A204c host a204c-03 { hardware ethernet 00:01:03:44:1d:62; fixed-address 172.19.80.003; } # Machine type = COMPAQ DESKPRO Laboratory = A204c host a204c-04 { hardware ethernet 00:01:03:45:2d:8f; fixed-address 172.19.80.004; } \end{verbatim} }% \begin{itemize} \item Can generate these with a Perl program \end{itemize} \end{slide} \begin{slide}{Method used by Computer Centre} \label{sld:old-cc-ssytem} \begin{itemize} \item Uses Samba, \ISC \DHCP \item Documented on our web site; see the link to ``DHCP and DNS System'' {\footnotesize\url{http://nicku.org/snm/dhcp-dns-system/}} \end{itemize} \end{slide} \begin{slide}{Method Currently used by ICT} \begin{itemize} \item Fixed \DHCP and \DNS records generated from an Excel spreadsheet \item Same as older method used by Computer Centre \item \ldots but also use the Perl module \texttt{Spreadsheet::ParseExcel}, which can read an Excel Spreadsheet directly --- see \texttt{parse-excel.pl} at the \URL in slide~\pageref{sld:old-cc-ssytem} \item Generates \DNS records also, using \texttt{h2n} \end{itemize} \end{slide} \begin{slide}{\texttt{h2n}---not a bird flu} \begin{itemize} \item According to {\tiny\url{http://www.menandmice.com/6000/61_recent_survey.html}}, 68\% of \DNS servers in .com domain are misconfigured. \item System administrators can make many mistakes \item Best to generate \DNS resource records with a progam rather than by hand \item \texttt{h2n}, available from \url{http://www.deer-run.com/~hal/h2n/} and \url{http://examples.oreilly.com/dns4/} \item input: a file in host table format (of \texttt{/etc/hosts}) \item output is all the resource records, and \DNS server configuration file. \end{itemize} \end{slide} \begin{slide}{Method Currently used by ICT---2} \begin{itemize} \item \texttt{cron} job runs every 2 minutes, and does the following: \begin{alltt}\tiny if \meta{excel spreadsheet} is newer than \texttt{/etc/dhcpd.conf} parse \meta{excel spreadsheet} into a \meta{hostfile} append any other required host files to this \meta{hostfile} if generate \texttt{/tmp/dhcpd.conf} from \meta{hostfile} move \texttt{/tmp/dhcpd.conf} to \texttt{/etc/dhcpd.conf} restart \DHCP server ensure \meta{excel spreadsheet} is not newer than \texttt{/etc/dhcpd.conf} stop \DNS server wait for it to stop generate \DNS resource records from \meta{hostfile} remove \DNS journal files start \DNS server \end{alltt} \end{itemize} \end{slide} \begin{slide}{Older method used in ICT: free for all!} \footnotesize% \begin{itemize} \item Each client is offered: \begin{itemize} \item an address in range 172.19.123.1 to 172.19.127.200 \item netmask \texttt{/18} \item default gateway 172.19.127.254 \item domain name, \texttt{tyict.vtc.edu.hk} \item name servers 172.19.64.52, 202.40.209.220 \item \WINS servers 192.168.68.240, 202.20.100.226 \item \NTP server \texttt{ntp.tyict.vtc.edu.hk} \item a lease of 2 hours ($2 = 7200 \text{\ seconds} / 3600$) \end{itemize} \item The \DHCP server attempts to create a \DNS record for the client \item A separate log file will be created (see \texttt{man syslog}) \end{itemize} \end{slide} \begin{slide}{Older method used in ICT: free for all!} \tiny% \begin{verbatim} authoritative; log-facility local1; option domain-name "tyict.vtc.edu.hk"; ddns-update-style interim; option netbios-name-servers 192.168.68.240, 202.20.100.226; option domain-name-servers 172.19.64.52, 202.40.209.220; option ntp-servers ntp.tyict.vtc.edu.hk; subnet 172.19.64.0 netmask 255.255.192.0 { option routers 172.19.127.254; max-lease-time 7200; default-lease-time 7200; range 172.19.123.1 172.19.127.200; } \end{verbatim} \end{slide} \begin{slide}{Troubleshooting \DHCP 1} \begin{itemize} \item Our major problem: unauthorised \DHCP servers giving \texttt{DHCPNAK} to all requests \item Solution: use \texttt{ethereal} in promiscuous mode with filter\texttt{ port 67 or port 68} \item Examine packets from rogue server \item Use \texttt{xnmap} to gather more information about the rogue server \item Now go and talk with the person responsible \end{itemize} \end{slide} \begin{slide}{Troubleshooting \DHCP 2} \begin{itemize} \item Other problems: \item Examine the \DHCP server log using \texttt{tail -f} \begin{itemize} \item shows all \DHCP messages received and sent by the server \end{itemize} \item Examine log on the client \item Use \texttt{tcpdump} or \texttt{ethereal} to collect data \begin{itemize} \item analyse it in Ethereal \end{itemize} \item Compare with the \emphcolour{client state diagram} \item Compare with normal, expected behaviour \end{itemize} \end{slide} \begin{slide}{Automatic Client Registration} \huge% \begin{center} Making it easy for customers to register their computers \end{center} \begin{center} Avoiding manual misconfigured settings \end{center} \end{slide} \begin{slide}{Automatic Client Registration} \begin{itemize} \item It is good to be able to map \IP addresses to particular computers (and users) \item Often computers cause trouble without the user being aware \begin{itemize} \item e.g., project students with rogue \DHCP servers \end{itemize} \item Want convenience for user and sysadmin \item Can use the \ISC \DHCP server to implement such an automatic registration system. \item Depends on dividing \IP hosts into two \emphcolour{classes}: known and unknown. \end{itemize} \end{slide} \begin{slide}{\ISC \DHCP host declarations} \begin{itemize} \item The file /etc/dhcpd.conf controls the behaviour of the \ISC \DHCP server \item It may be edited by external programs and host statements may be added: \item Examples: \end{itemize} \begin{verbatim} host a204-16 { hardware ethernet 00:08:02:1d:87:72; } host a204-17 { hardware ethernet 00:08:02:1d:87:02; } host a204-18 { hardware ethernet 00:08:02:1c:1c:43; } \end{verbatim} \end{slide} \begin{slide}{Known and unknown hosts} \begin{itemize} \item A host is \emphcolour{known} if it has a host declaration \end{itemize} \tiny% \begin{verbatim} subnet 172.19.64.0 netmask 255.255.192.0 { option routers 172.19.127.254; # Unknown clients get this pool. pool { option domain-name-servers bogus.tyict.vtc.edu.hk; max-lease-time 120; range 172.19.120.0 172.19.122.255; allow unknown clients; } # Known clients get this pool. pool { option domain-name-servers ns.tyict.vtc.edu.hk; max-lease-time 28800; range range 172.19.123.1 172.19.127.200; deny unknown clients; } } \end{verbatim} \end{slide} \begin{slide}{Known and unknown hosts} \begin{itemize} \item So the hosts \texttt{a204-16}, \texttt{a204-17} and \texttt{a204-18} get full parameters \item Others (without a hosts declaration) get \begin{itemize} \item a short lease \item a bogus name server that redirects all web access to a registration server \end{itemize} \item Block the \IP addresses from unknown hosts at the firewall \item they get no Internet access \item users are motivated to register \end{itemize} \end{slide} \begin{slide}{The registration server} \begin{itemize} \item All unregistered hosts get a ``bogus'' name server that maps all hostnames to itself \item The web browser will go to the registration application, no matter \URL entered \item Registration application edits \texttt{/etc/dhcpd.conf} on \DHCP server \item Adds the host as a \emphcolour{known host} \item Gets the information from the {\red{}\DHCP lease} \item User just needs to enter their user name and \LDAP password \end{itemize} \end{slide} \begin{slide}{Registration Application} \begin{itemize} \item A web application \item User interface is very simple --- enter only: \begin{itemize} \item user name \item password \end{itemize} \item Application knows \IP address from web server \item Looks up MAC address from \DHCP leases file \item Edits \texttt{/etc/dhcpd.conf}, adds a host record \item Can assign a fixed or dynamic address \end{itemize} \end{slide} \begin{slide}{Registered computer} \begin{itemize} \item Now the client can either reboot, or wait 60 seconds to $T1$, and get a long term lease \item The machine becomes a ``known host'' \item Client can now access Internet conveniently \item Could extend this by adding \MAC address to access control list of the appropriate port on the main switch \item Unregistered computers blocked by switch \item Enforces limiting access to registered computers only \end{itemize} \end{slide} \begin{slide}{Fixed or Dynamic Addresses} \begin{itemize} \item Would it be better to have known host records for registered computers and \emphcolour{dynamic addresses}, registered \emphcolour{dynamically} with the \DNS server\ldots \item Or is it better to have \emphcolour{fixed addresses} and \emphcolour{fixed} \DNS records? \item I think that dynamic updates to \DNS provide no additional benefit, and simply make the system more complex. \item I recommend making the system as simple as possible \begin{itemize} \item both for the system administrator and the users \item \ldots but no simpler. \end{itemize} \end{itemize} \end{slide} \end{document}