Dynamic Host Configuration Protocol (DHCP)

Table of Contents

1. DNS Alterations
2. DHCP Server Configuration
3. Client Configuration
4. Assessment

Note

In this lab, we do not consider IPv6 at all, DHCP is related only to IPv4. We could have a look at DHCPv6, but that is a more advanced issue that is not currently well supported at present in default configurations.

The DHCP server that ships with most Linux distributions is the standard ISC (Internet Software Consortium) DHCPd software. You can get more information from www.isc.org.

In order to set up DHCP on our server today, you will need to apt-get install dhcp3-server. When you install it, it will fail to start: this is expected, as there is no useful default configuration that can be supplied, so the server fails to start because there is missing information; it has been installed correctly, so don’t worry.

Note

In this lab, and most others, we have been loading all our services onto your Server1. However, in general there is no operational requirement for the DHCP service to be hosted on the same server as the DNS service, and on larger network it would be preferable to have them housed on different servers.

1. DNS Alterations

During this lab, we shall be offering a pool of addresses. These addresses should be listed in DNS. There may be other things you need to check too. You need to make the following maintenance to your DNS server:

  1. There is no well-known-alias for DHCP services, so you don’t need to worry about adding anything like dhcp.domain to our DNS.

  2. Ensure you have forward and reverse DNS mappings for Client1, with the address 192.168.1.11. You do not need to concern yourself with IPv6 for this lab. Client1 will be given a static DHCP address from the address.

  3. Add in mappings for 32 hosts, starting from 192.168.1.32 (this range is exactly the same as the CIDR prefix 192.168.1.32/27). We will use these for our pool of dynamic addresses. I suggest that you employ some suitable editor wizardry, as outlined below. You may like to refer to the video about this task on the website.

    When you have a lot of workstations, you generally have some sort of numerical scheme, and so can easily write a small script to generate lots of PTR records. Here’s an example which you would write into the DNS server configuration file. I normally store it in the file commented out, then copy, uncomment and execute to generate the output.

    for (( i=32; i<32+32; i++ ))
    do
      This version is suitable for a forward zone.
      printf "ip%03d\tA\t192.168.1.%d\n" $i $i
      This version is suitable for a reverse zone.
      # printf "%d\tPTR\tip%03d.localdomain.\n" $i $i
    done

    In vim, you can select this text (using the V command), then use !bash followed by RETURN to execute and replace the text using the bash interpreter. You will end up with the set of entries below.

    ip032   A       192.168.1.32
    ip033   A       192.168.1.33
    ip034   A       192.168.1.34
    …

    Hit u to undo the changes, make a copy of the script text, and comment out one copy, so you can reuse it later. Execute the uncommented version so you get the output you want. You will also need to follow a similar procedure for the reverse zone also. Don’t ignore the reverse zone, its correctness is relied on for many servers and services.

    Note

    If you want to do a similar thing in Emacs, use C-u M-| on a selection (region). Without the C-u, the output will be shown in a seperate buffer, rather than replacing the region in the current buffer.

    BIND $GENERATE statement

    Actually, generated data is a common requirement, so the BIND implementation has a shorthand for this in the master zone file. That would allow us to use one line in each zone file to replace each script that we used.

    $GENERATE 32-63 ip${,3,d}  A  192.168.1.$       Forward entries
    $GENERATE 32-63 $  PTR  ip${,3,d}.localdomain.  Reverse entries

    We’re not going to use it here, but if you want to know more, consult the BIND 9 Administrator Reference Manual for more information.

  4. Make the changes take effect by using rndc reload, and then check the logs to make sure that it loaded without complaint.

  5. Test that you can resolve forwards and backwards the mappings you just modified or added. For the dynamic addresses, you need only test the border cases.