[thirdparty/dhcp.git] / server / dhcpd.conf.cat5

dhcpd.conf(5)                                       dhcpd.conf(5)


N\bNA\bAM\bME\bE
       dhcpd.conf - dhcpd configuration file

D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
       The dhcpd.conf file contains configuration information for
       _\bd_\bh_\bc_\bp_\bd_\b, the Internet Software Consortium DHCP Server.

       The dhcpd.conf file is a free-form ASCII text  file.    It
       is  parsed  by  the  recursive-descent  parser  built into
       dhcpd.   The file may contain extra tabs and newlines  for
       formatting purposes.  Keywords in the file are case-insen­
       sitive.   Comments may be placed anywhere within the  file
       (except  within quotes).   Comments begin with the # char­
       acter and end at the end of the line.

       The file essentially consists of  a  list  of  statements.
       Statements fall into two broad categories - parameters and
       declarations.

       Parameter statements either say how to do something (e.g.,
       how long a lease to offer), whether to do something (e.g.,
       should dhcpd provide addresses  to  unknown  clients),  or
       what  parameters to provide to the client (e.g., use gate­
       way 220.177.244.7).

       Declarations are used to describe the topology of the net­
       work,  to  describe  clients  on  the  network, to provide
       addresses that can be assigned to clients, or to  apply  a
       group  of  parameters to a group of declarations.   In any
       group of parameters and declarations, all parameters  must
       be specified before any declarations which depend on those
       parameters may be specified.

       Declarations about network topology include the
        _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations.   If  clients
       on  a  subnet  are to be assigned addresses dynamically, a
       _\br_\ba_\bn_\bg_\be declaration must appear within the  _\bs_\bu_\bb_\bn_\be_\bt  declara­
       tion.   For clients with statically assigned addresses, or
       for installations where only known clients will be served,
       each such client must have a _\bh_\bo_\bs_\bt declaration.   If param­
       eters are to be applied to a group of  declarations  which
       are  not related strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp
       declaration can be used.

       For every subnet which will be served, and for every  sub­
       net  to  which the dhcp server is connected, there must be
       one _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize
       that  an  address is on that subnet.  A _\bs_\bu_\bb_\bn_\be_\bt declaration
       is required for each subnet even if no addresses  will  be
       dynamically allocated on that subnet.

       Some  installations  have  physical networks on which more
       than one IP subnet operates.   For example, if there is  a
       site-wide requirement that 8-bit subnet masks be used, but



                                                                1





dhcpd.conf(5)                                       dhcpd.conf(5)


       a department  with  a  single  physical  ethernet  network
       expands  to the point where it has more than 254 nodes, it
       may be necessary to run two 8-bit subnets on the same eth­
       ernet  until  such  time  as a new physical network can be
       added.   In this case, the _\bs_\bu_\bb_\bn_\be_\bt declarations  for  these
       two  networks may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk declara­
       tion.

       Some sites may have departments which have clients on more
       than  one  subnet,  but it may be desirable to offer those
       clients a uniform set of parameters  which  are  different
       than  what  would be offered to clients from other depart­
       ments on the same subnet.    For  clients  which  will  be
       declared explicitly with _\bh_\bo_\bs_\bt declarations, these declara­
       tions can be enclosed in a _\bg_\br_\bo_\bu_\bp  declaration  along  with
       the  parameters which are common to that department.   For
       clients whose  addresses  will  be  dynamically  assigned,
       there  is  currently no way to group parameter assignments
       other than by network topology.

       When a client is to be booted,  its  boot  parameters  are
       determined by first consulting that client's _\bh_\bo_\bs_\bt declara­
       tion (if any), then consulting the _\bg_\br_\bo_\bu_\bp  declaration  (if
       any) which enclosed that _\bh_\bo_\bs_\bt declaration, then consulting
       the _\bs_\bu_\bb_\bn_\be_\bt declaration for the subnet on which the  client
       is booting, then consulting the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk declaration
       (if any) containing that subnet,  and  finally  consulting
       the top-level parameters which may be specified outside of
       any declaration.

       When dhcpd tries to find a _\bh_\bo_\bs_\bt declaration for a  client,
       it  first  looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd_\b-
       _\ba_\bd_\bd_\br_\be_\bs_\bs parameter which matches the subnet or shared  net­
       work  on which the client is booting.   If it doesn't find
       any such entry, it then tries to find an entry  which  has
       no  _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs  parameter.   If no such entry is found,
       then dhcpd acts as if there is no entry in the  dhcpd.conf
       file  for  that client, even if there is an entry for that
       client on a different subnet or shared network.

E\bEX\bXA\bAM\bMP\bPL\bLE\bES\bS
       A typical dhcpd.conf file will look something like this:

       _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.

       shared-network ISC-BIGGIE {
         _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         subnet 204.254.239.0 netmask 255.255.255.224 {
           _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
           range 204.254.239.10 204.254.239.30;
         }
         subnet 204.254.239.32 netmask 255.255.255.224 {
           _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
           range 204.254.239.42 204.254.239.62;



                                                                2





dhcpd.conf(5)                                       dhcpd.conf(5)


         }
       }

       subnet 204.254.239.64 netmask 255.255.255.224 {
         _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         range 204.254.239.74 204.254.239.94;
       }

       group {
         _\bg_\br_\bo_\bu_\bp_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         host zappo.test.isc.org {
           _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         }
         host beppo.test.isc.org {
           _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         }
         host harpo.test.isc.org {
           _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
         }
       }

                                Figure 1


       Notice that at the beginning of the file, there's a  place
       for  global  parameters.    These might be things like the
       organization's domain name,  the  addresses  of  the  name
       servers  (if  they are common to the entire organization),
       and so on.   So, for example:

            option domain-name "isc.org";
            option domain-name-servers ns1.isc.org, ns2.isc.org;

                                Figure 2

       As you can see in Figure 2, it's  legal  to  specify  host
       addresses  in  parameters  as  domain names rather than as
       numeric IP addresses.  If a  given  hostname  resolves  to
       more  than  one  IP address (for example, if that host has
       two ethernet interfaces), both addresses are  supplied  to
       the client.

       In  Figure  1,  you  can  see that both the shared-network
       statement and the subnet statements can  have  parameters.
       Let  us say that the shared network _\bI_\bS_\bC_\b-_\bB_\bI_\bG_\bG_\bI_\bE supports an
       entire department -  perhaps  the  accounting  department.
       If  accounting  has its own domain, then a shared-network-
       specific parameter might be:

            option domain-name "accounting.isc.org";

       All subnet declarations appearing  in  the  shared-network
       declaration  would then have the domain-name option set to
       "accounting.isc.org" instead of just "isc.org".



                                                                3





dhcpd.conf(5)                                       dhcpd.conf(5)


       The most obvious reason for having subnet-specific parame­
       ters  as  shown in Figure 1 is that each subnet, of neces­
       sity, has its own router.   So for the first  subnet,  for
       example, there should be something like:

            option routers 204.254.239.1;

       Note  that  the  address  here  is  specified numerically.
       This is not required - if you have a different domain name
       for  each interface on your router, it's perfectly legiti­
       mate to use the domain name for that interface instead  of
       the numeric address.   However, in many cases there may be
       only one domain name for all of a router's  IP  addresses,
       and it would not be appropriate to use that name here.

       In  Figure  1  there is also a _\bg_\br_\bo_\bu_\bp statement, which pro­
       vides common parameters for a set of three hosts -  zappo,
       beppo  and  harpo.  As you can see, these hosts are all in
       the test.isc.org domain, so it  might  make  sense  for  a
       group-specific  parameter to override the domain name sup­
       plied to these hosts:

            option domain-name "test.isc.org";

       Also, given the domain they're in, these are probably test
       machines.   If  we  wanted to test the DHCP leasing mecha­
       nism, we might set the lease timeout somewhat shorter than
       the default:

            max-lease-time 120;
            default-lease-time 120;

       You may have noticed that while some parameters start with
       the _\bo_\bp_\bt_\bi_\bo_\bn keyword, some  do  not.    Parameters  starting
       with the _\bo_\bp_\bt_\bi_\bo_\bn keyword correspond to actual DHCP options,
       while parameters that do not start with the option keyword
       either control the behaviour of the DHCP server (e.g., how
       long a lease dhcpd  will  give  out),  or  specify  client
       parameters that are not optional in the DHCP protocol (for
       example, server-name and filename).

       In Figure  1,  each  host  had  _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc  _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs.
       These  could  include  such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
       the name of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\b)  _\ba_\bn_\bd
       _\bt_\bh_\be  _\ba_\bd_\bd_\br_\be_\bs_\bs  _\bo_\bf  _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be
       _\b(_\bt_\bh_\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter).   In general,  any  parameter
       can  appear anywhere that parameters are allowed, and will
       be applied according to the scope in which  the  parameter
       appears.

       Imagine  that  you  have a site with a lot of NCD X-Termi­
       nals.   These terminals come in a variety of  models,  and
       you  want to specify the boot files for each models.   One
       way to do this would be to have host declarations for each



                                                                4





dhcpd.conf(5)                                       dhcpd.conf(5)


       server and group them by model:

       group {
         filename "Xncd19r";
         next-server ncd-booter;

         host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
         host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
         host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
       }

       group {
         filename "Xncd19c";
         next-server ncd-booter;

         host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
         host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
       }

       group {
         filename "XncdHMX";
         next-server ncd-booter;

         host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
         host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
         host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
       }

R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
       T\bTh\bhe\be _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        s\bsh\bha\bar\bre\bed\bd-\b-n\bne\bet\btw\bwo\bor\brk\bk _\bn_\ba_\bm_\be {\b{
          [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
          [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
        }\b}

       The  _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk  statement  is used to inform the DHCP
       server that some IP subnets actually share the same physi­
       cal  network.   Any  subnets in a shared network should be
       declared within a  _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk  statement.   Parameters
       specified  in  the  _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk  statement will be used
       when booting clients on those  subnets  unless  parameters
       provided  at  the  subnet or host level override them.  If
       any subnet in a shared network has addresses available for
       dynamic  allocation,  those addresses are collected into a
       common pool  for  that  shared  network  and  assigned  to
       clients  as  needed.   There  is  no way to distinguish on
       which subnet of a shared network a client should boot.

       _\bN_\ba_\bm_\be should be the name of the shared network.   This name
       is  used when printing debugging messages, so it should be
       descriptive for the shared network.   The  name  may  have
       the  syntax of a valid domain name (although it will never
       be used as  such),  or  it  may  be  any  arbitrary  name,



                                                                5





dhcpd.conf(5)                                       dhcpd.conf(5)


       enclosed in quotes.

       T\bTh\bhe\be _\bs_\bu_\bb_\bn_\be_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        s\bsu\bub\bbn\bne\bet\bt _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br n\bne\bet\btm\bma\bas\bsk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{
          [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
          [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
        }\b}

       The  _\bs_\bu_\bb_\bn_\be_\bt statement is used to provide dhcpd with enough
       information to tell whether or not an  IP  address  is  on
       that  subnet.   It may also be used to provide subnet-spe­
       cific parameters and to  specify  what  addresses  may  be
       dynamically  allocated  to clients booting on that subnet.
       Such addresses are specified using the _\br_\ba_\bn_\bg_\be  declaration.

       The  _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br  should be an IP address or domain name
       which resolves to the subnet number of  the  subnet  being
       described.   The _\bn_\be_\bt_\bm_\ba_\bs_\bk should be an IP address or domain
       name which resolves to the subnet mask of the subnet being
       described.   The subnet number, together with the netmask,
       are sufficient to determine whether any given  IP  address
       is on the specified subnet.

       Although  a netmask must be given with every subnet decla­
       ration, it is recommended that if there is any variance in
       subnet  masks at a site, a subnet-mask option statement be
       used in each subnet declaration to set the desired  subnet
       mask, since any subnet-mask option statement will override
       the subnet mask declared in the subnet statement.

       T\bTh\bhe\be _\br_\ba_\bn_\bg_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        r\bra\ban\bng\bge\be [ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp ] _\bl_\bo_\bw_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [ _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs];\b;

       For any subnet on which addresses will be assigned dynami­
       cally,  there  must be at least one _\br_\ba_\bn_\bg_\be statement.   The
       range statement gives the lowest and highest IP  addresses
       in  a  range.   All IP addresses in the range should be in
       the subnet in which the _\br_\ba_\bn_\bg_\be statement is declared.   The
       _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp  flag  may  be specified if addresses in the
       specified range  may  be  dynamically  assigned  to  BOOTP
       clients  as well as DHCP clients.   When specifying a sin­
       gle address, _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs can be omitted.

       T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        h\bho\bos\bst\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
          [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
          [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
        }\b}

       There must be at least one h\bho\bos\bst\bt statement for every  BOOTP
       client  that is to be served.  h\bho\bos\bst\bt statements may also be



                                                                6





dhcpd.conf(5)                                       dhcpd.conf(5)


       specified for DHCP clients, although this is not  required
       unless booting is only enabled for known hosts.

       If  it  is  desirable  to  be able to boot a DHCP or BOOTP
       client on more than one subnet with fixed addresses,  more
       than  one  address  may  be specified in the _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
       parameter, or more than one h\bho\bos\bst\bt statement may  be  speci­
       fied.

       If  client-specific  boot  parameters must change based on
       the network to which the client is attached, then multiple
       h\bho\bos\bst\bt statements should be used.

       If  a client is to be booted using a fixed address if it's
       possible, but should be allocated a dynamic address other­
       wise,  then  a  h\bho\bos\bst\bt statement must be specified without a
       f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs clause.  _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identify­
       ing  the  host.  If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for
       the host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be is used.

       _\bH_\bo_\bs_\bt declarations are matched  to  actual  DHCP  or  BOOTP
       clients  by  matching  the  dhcp-client-identifier  option
       specified in the _\bh_\bo_\bs_\bt declaration to the one  supplied  by
       the client, or, if the _\bh_\bo_\bs_\bt declaration or the client does
       not provide a dhcp-client-identifier option,  by  matching
       the _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the net­
       work hardware address  supplied  by  the  client.    BOOTP
       clients  do not normally provide a _\bd_\bh_\bc_\bp_\b-_\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br,
       so the hardware address must be used for all clients  that
       may boot using the BOOTP protocol.

       T\bTh\bhe\be _\bg_\br_\bo_\bu_\bp s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        g\bgr\bro\bou\bup\bp {
          [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
          [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
        }\b}

       The  group  statement  is used simply to apply one or more
       parameters to a group of declarations.   It can be used to
       group  hosts,  shared  networks,  subnets,  or  even other
       groups.

R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: A\bAL\bLL\bLO\bOW\bW a\ban\bnd\bd D\bDE\bEN\bNY\bY
       The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by statements can be used to  control  the
       behaviour of dhcpd to various sorts of requests.


       T\bTh\bhe\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn_\b-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bke\bey\byw\bwo\bor\brd\bd

        a\bal\bll\blo\bow\bw u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
        d\bde\ben\bny\by u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;

       The  u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs flag is used to tell dhcpd whether or



                                                                7





dhcpd.conf(5)                                       dhcpd.conf(5)


       not to dynamically assign addresses  to  unknown  clients.
       Dynamic  address  assignment to unknown clients is a\bal\bll\blo\bow\bwed
       by default.

       T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bp k\bke\bey\byw\bwo\bor\brd\bd

        a\bal\bll\blo\bow\bw b\bbo\boo\bot\btp\bp;\b;
        d\bde\ben\bny\by b\bbo\boo\bot\btp\bp;\b;

       The b\bbo\boo\bot\btp\bp flag is used to tell dhcpd  whether  or  not  to
       respond  to  bootp  queries.  Bootp queries are a\bal\bll\blo\bow\bwed by
       default.

       T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bke\bey\byw\bwo\bor\brd\bd

        a\bal\bll\blo\bow\bw b\bbo\boo\bot\bti\bin\bng\bg;\b;
        d\bde\ben\bny\by b\bbo\boo\bot\bti\bin\bng\bg;\b;

       The b\bbo\boo\bot\bti\bin\bng\bg flag is used to tell dhcpd whether or  not  to
       respond to queries from a particular client.  This keyword
       only has meaning when it appears in  a  host  declaration.
       By  default, booting is a\bal\bll\blo\bow\bwed, but if it is disabled for
       a particular client, then that client will not be able  to
       get and address from the DHCP server.

R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: P\bPA\bAR\bRA\bAM\bME\bET\bTE\bER\bRS\bS
       T\bTh\bhe\be _\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        d\bde\bef\bfa\bau\bul\blt\bt-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;

       _\bT_\bi_\bm_\be should be the length in seconds that will be assigned
       to a lease if the client requesting the lease does not ask
       for a specific expiration time.

       T\bTh\bhe\be _\bm_\ba_\bx_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        m\bma\bax\bx-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;

       _\bT_\bi_\bm_\be  should be the maximum length in seconds that will be
       assigned to a lease.   The only exception to this is  that
       Dynamic  BOOTP  lease  lengths, which are not specified by
       the client, are not limited by this maximum.

       T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        m\bmi\bin\bn-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;

       _\bT_\bi_\bm_\be should be the minimum length in seconds that will  be
       assigned to a lease.

       T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bs_\be_\bc_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        m\bmi\bin\bn-\b-s\bse\bec\bcs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;




                                                                8





dhcpd.conf(5)                                       dhcpd.conf(5)


       _\bS_\be_\bc_\bo_\bn_\bd_\bs  should  be  the minimum number of seconds since a
       client began trying to acquire a new lease before the DHCP
       server will respond to its request.  The number of seconds
       is based on what the client reports, and the maximum value
       that  the  client  can report is 255 seconds.   Generally,
       setting this to one will result in  the  DHCP  server  not
       responding  to  the  client's  first  request,  but always
       responding to its second request.

       This can be used to set up a secondary DHCP  server  which
       never  offers  an  address  to  a client until the primary
       server has been given a chance to do so.   If the  primary
       server  is  down,  the  client  will bind to the secondary
       server, but otherwise clients should always  bind  to  the
       primary.    Note  that  this does not, by itself, permit a
       primary server and a secondary server to share a  pool  of
       dynamically-allocatable addresses.

       T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;

       In  order for a BOOTP client to be recognized, its network
       hardware address must be declared using a _\bh_\ba_\br_\bd_\bw_\ba_\br_\be  clause
       in  the _\bh_\bo_\bs_\bt statement.  _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be must be the name of
       a physical hardware interface type.   Currently, only  the
       e\bet\bth\bhe\ber\brn\bne\bet\bt  and  t\bto\bok\bke\ben\bn-\b-r\bri\bin\bng\bg  types  are recognized, although
       support for a f\bfd\bdd\bdi\bi hardware type (and others)  would  also
       be  desirable.   The  _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs  should be a set of
       hexadecimal octets (numbers from 0 through  ff)  seperated
       by colons.   The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\bf_\bR _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt _\bm_\ba_\by _\ba_\bl_\bs_\bo _\bb_\be _\bu_\bs_\be_\bd _\bf_\bo_\br
       _\bD_\bH_\bC_\bP _\bc_\bl_\bi_\be_\bn_\bt_\bs_\b.

       T\bTh\bhe\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b";\b;

       The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement can be used to specify the name  of
       the  initial  boot file which is to be loaded by a client.
       The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
       file  transfer  protocol the client can be expected to use
       to load the file.

       T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bn_\ba_\bm_\be"\b";\b;

       The _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be statement can be used to inform the client
       of the name of the server from which it is booting.   _\bN_\ba_\bm_\be
       should be the name that will be provided to the client.

       T\bTh\bhe\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        n\bne\bex\bxt\bt-\b-s\bse\ber\brv\bve\ber\br _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be;\b;



                                                                9





dhcpd.conf(5)                                       dhcpd.conf(5)


       The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br statement is  used  to  specify  the  host
       address  of  the  server  from which the initial boot file
       (specified in the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement)  is  to  be  loaded.
       _\bS_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be  should  be  a  numeric IP address or a domain
       name.   If no _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter  applies  to  a  given
       client, the DHCP server's IP address is used.

       T\bTh\bhe\be _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;

       The  _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
       fixed IP addresses to a client.  It should only appear  in
       a _\bh_\bo_\bs_\bt declaration.  If more than one address is supplied,
       then when the  client  boots,  it  will  be  assigned  the
       address  which  corresponds  to the network on which it is
       booting.  If none of the addresses  in  the  _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
       statement  are on the network on which the client is boot­
       ing, that client will not match the _\bh_\bo_\bs_\bt declaration  con­
       taining that _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement.  Each _\ba_\bd_\bd_\br_\be_\bs_\bs should
       be either an IP address or a domain name which resolves to
       one or more IP addresses.

       T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-c\bcu\but\bto\bof\bff\bf _\bd_\ba_\bt_\be;\b;

       The  _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf  statement sets the ending
       time for all leases assigned dynamically to BOOTP clients.
       Because  BOOTP  clients  do  not  have any way of renewing
       leases, and don't know that their leases could expire,  by
       default  dhcpd  assignes  infinite  leases  to  all  BOOTP
       clients.  However, it may make sense in some situations to
       set  a cutoff date for all BOOTP leases - for example, the
       end of a school term, or the time at night when a facility
       is closed and all machines are required to be powered off.

       _\bD_\ba_\bt_\be should be the date on which all assigned BOOTP leases
       will end.  The date is specified in the form:

                         W YYYY/MM/DD HH:MM:SS

       W  is  the day of the week expressed as a number from zero
       (Sunday) to six (Saturday).  YYYY is the  year,  including
       the century.  MM is the month expressed as a number from 1
       to 12.  DD is the day of the month, counting from  1.   HH
       is  the hour, from zero to 23.  MM is the minute and SS is
       the second.  The time is always  in  Greenwich  Mean  Time
       (GMT), not local time.

       T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-l\ble\ben\bng\bgt\bth\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;




                                                               10





dhcpd.conf(5)                                       dhcpd.conf(5)


       The  _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh  statement  is used to set
       the  length  of  leases  dynamically  assigned  to   BOOTP
       clients.    At  some  sites,  it may be possible to assume
       that a lease is no longer in use if  its  holder  has  not
       used  BOOTP  or  DHCP  to get its address within a certain
       time period.   The period is specified in _\bl_\be_\bn_\bg_\bt_\bh as a num­
       ber  of  seconds.   If a client reboots using BOOTP during
       the timeout period, the lease duration is reset to _\bl_\be_\bn_\bg_\bt_\bh,
       so  a BOOTP client that boots frequently enough will never
       lose its lease.  Needless to say, this parameter should be
       adjusted with extreme caution.

       T\bTh\bhe\be _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        g\bge\bet\bt-\b-l\ble\bea\bas\bse\be-\b-h\bho\bos\bst\btn\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;

       The  _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs  statement  is used to tell dhcpd
       whether or not to look up the domain name corresponding to
       the  IP  address of each address in the lease pool and use
       that address for the DHCP _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be  option.   If  _\bf_\bl_\ba_\bg  is
       true,  then  this  lookup is done for all addresses in the
       current scope.   By default,  or  if  _\bf_\bl_\ba_\bg  is  false,  no
       lookups are done.

       T\bTh\bhe\be _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        u\bus\bse\be-\b-h\bho\bos\bst\bt-\b-d\bde\bec\bcl\bl-\b-n\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;

       If  the  _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs  parameter is true in a given
       scope, then for every host declaration within that  scope,
       the  name  provided  for the host declaration will be sup­
       plied to the client as its hostname.   So, for example,

           group {
             use-host-decl-names on;

             host joe {
            hardware ethernet 08:00:2b:4c:29:32;
            fixed-address joe.fugue.com;
             }
           }

       is equivalent to

             host joe {
            hardware ethernet 08:00:2b:4c:29:32;
            fixed-address joe.fugue.com;
               option host-name "joe";
             }

       An _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt_\b-_\bn_\ba_\bm_\be statement within  a  host  declaration
       will override the use of the name in the host declaration.

       T\bTh\bhe\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt



                                                               11





dhcpd.conf(5)                                       dhcpd.conf(5)


        a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;

        n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;

       The DHCP server will normally assume that  the  configura­
       tion information about a given network segment is known to
       be correct and is authoritative.   So if a client requests
       an  IP  address on a given network segment that the server
       knows is not valid  for  that  segment,  the  server  will
       respond with a DHCPNAK message, causing the client to for­
       get its IP address and try to get a new one.

       If a DHCP server is being configured by  somebody  who  is
       not  the  network administrator and who therefore does not
       wish to assert this level of authority, then the statement
       "not  authoritative"  should be written in the appropriate
       scope in the configuration file.

       Usually, writing n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b; at the  top  level  of
       the file should be sufficient.   However, if a DHCP server
       is to be set up so that it is aware of some  networks  for
       which  it  is authoritative and some networks for which it
       is not, it may be more appropriate to declare authority on
       a per-network-segment basis.

       Note that the most specific scope for which the concept of
       authority makes any sense is the physical network  segment
       -  either a shared-network statement or a subnet statement
       that is not contained within a  shared-network  statement.
       It is not meaningful to specify that the server is author­
       itative for some subnets within a shared network, but  not
       authoritative  for others, nor is it meaningful to specify
       that the server is authoritative for  some  host  declara­
       tions and not others.

       T\bTh\bhe\be _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        u\bus\bse\be-\b-l\ble\bea\bas\bse\be-\b-a\bad\bdd\bdr\br-\b-f\bfo\bor\br-\b-d\bde\bef\bfa\bau\bul\blt\bt-\b-r\bro\bou\but\bte\be _\bf_\bl_\ba_\bg;\b;

       If  the _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be parameter is true
       in a given scope, then instead of sending the value speci­
       fied  in  the routers option (or sending no value at all),
       the IP address of the lease being assigned is sent to  the
       client.   This supposedly causes Win95 machines to ARP for
       all IP addresses, which can be helpful if your  router  is
       configured for proxy ARP.

       T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt

        s\bse\ber\brv\bve\ber\br-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;

       The  server-identifier statement can be used to define the
       value that is sent in the DHCP  Server  Identifier  option
       for  a  given  scope.    The value specified m\bmu\bus\bst\bt be an IP



                                                               12





dhcpd.conf(5)                                       dhcpd.conf(5)


       address for the DHCP server, and must be reachable by  all
       clients served by a particular scope.

       The  use  of the server-identifier statement is not recom­
       mended - the only reason to use it is  to  force  a  value
       other than the default value to be sent on occasions where
       the default value would be incorrect.   The default  value
       is  the first IP address associated with the physical net­
       work interface on which the request arrived.

       The usual case where the _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br statement needs
       to  be sent is when a physical interface has more than one
       IP address, and the one being sent by default isn't appro­
       priate  for  some or all clients served by that interface.
       Another common case is when an alias is  defined  for  the
       purpose  of  having  a  consistent IP address for the DHCP
       server, and it is desired that the  clients  use  this  IP
       address when contacting the server.

       Supplying a value for the dhcp-server-identifier option is
       equivalent to using the server-identifier statement.

R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: O\bOP\bPT\bTI\bIO\bON\bN S\bST\bTA\bAT\bTE\bEM\bME\bEN\bNT\bTS\bS
       DHCP  option  statements  are  documented  in  the   d\bdh\bhc\bcp\bp-\b-
       o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b) manual page.

S\bSE\bEE\bE A\bAL\bLS\bSO\bO
       dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.

A\bAU\bUT\bTH\bHO\bOR\bR
       d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> under a
       contract with Vixie Labs.   Funding for this  project  was
       provided  by  the Internet Software Corporation.  Informa­
       tion about the Internet Software Consortium can  be  found
       at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.






















                                                               13