Provided by: isc-dhcp-server_4.1.ESV-R4-0ubuntu5_amd64 bug


       dhcpd.leases - DHCP client lease database


       The  Internet Systems Consortium DHCP Server keeps a persistent database of leases that it
       has assigned.  This database is a free-form  ASCII  file  containing  a  series  of  lease
       declarations.   Every  time  a  lease  is  acquired, renewed or released, its new value is
       recorded at the end of the lease file.  So if more than  one  declaration  appears  for  a
       given lease, the last one in the file is the current one.

       When  dhcpd is first installed, there is no lease database.   However, dhcpd requires that
       a lease database be present before it will start.  To make  the  initial  lease  database,
       just create an empty file called DBDIR/dhcpd.leases.   You can do this with:

            touch DBDIR/dhcpd.leases

       In  order  to prevent the lease database from growing without bound, the file is rewritten
       from time to time.   First, a temporary lease database is created and all known leases are
       dumped  to  it.    Then, the old lease database is renamed DBDIR/dhcpd.leases~.   Finally,
       the newly written lease database is moved into place.


       Lease descriptions are stored in a format that is parsed by  the  same  recursive  descent
       parser used to read the dhcpd.conf(5) and dhclient.conf(5) files.  Lease files can contain
       lease declarations, and also  group  and  subgroup  declarations,  host  declarations  and
       failover  state  declarations.   Group,  subgroup and host declarations are used to record
       objects created using the OMAPI protocol.

       The lease file is a log-structured file - whenever a lease changes, the contents  of  that
       lease  are  written  to the end of the file.   This means that it is entirely possible and
       quite reasonable for there to be two or more declarations of the same lease in  the  lease
       file  at the same time.   In that case, the instance of that particular lease that appears
       last in the file is the one that is in effect.

       Group, subgroup and host declarations in the lease file are handled in  the  same  manner,
       except  that  if  any of these objects are deleted, a rubout is written to the lease file.
       This is just the same declaration, with { deleted; } in  the  scope  of  the  declaration.
       When  the lease file is rewritten, any such rubouts that can be eliminated are eliminated.
       It is possible to delete a declaration in the dhcpd.conf file; in this  case,  the  rubout
       can never be eliminated from the dhcpd.leases file.


       lease ip-address { statements... }

       Each  lease declaration includes the single IP address that has been leased to the client.
       The statements within the braces define the duration of  the  lease  and  to  whom  it  is

       starts date;
       ends date;
       tstp date;
       tsfp date;
       atsfp date;
       cltt date;

       The start and end time of a lease are recorded using the starts and ends statements.   The
       tstp statement is specified if the failover protocol is being  used,  and  indicates  what
       time  the  peer has been told the lease expires.   The tsfp statement is also specified if
       the failover protocol is being used, and indicates the lease expiry time that the peer has
       acknowledged.  The atsfp statement is the actual time sent from the failover partner.  The
       cltt statement is the client's last transaction time.

       The date is specified in two ways, depending on the configuration value for  the  db-time-
       format parameter.  If it was set to default, then the date fields appear as follows:

       weekday year/month/day hour:minute:second

       The  weekday  is  present  to make it easy for a human to tell when a lease expires - it's
       specified as a number from zero to six, with zero  being  Sunday.   The  day  of  week  is
       ignored  on input.  The year is specified with the century, so it should generally be four
       digits except for really long leases.  The month is specified as a number starting with  1
       for  January.   The day of the month is likewise specified starting with 1.  The hour is a
       number between 0 and 23, the minute a number between 0 and  59,  and  the  second  also  a
       number between 0 and 59.

       Lease times are specified in Universal Coordinated Time (UTC), not in the local time zone.
       There is probably nowhere in the world where the times recorded on a lease are always  the
       same  as wall clock times.  On most unix machines, you can display the current time in UTC
       by typing date -u.

       If the db-time-format was configured to local, then the date fields appear as follows:

        epoch     <seconds-since-epoch>;     #     <day-name>      <month-name>      <day-number>
       <hours>:<minutes>:<seconds> <year>

       The  seconds-since-epoch is as according to the system's local clock (often referred to as
       "unix time").  The # symbol supplies a comment that describes what actual time this is  as
       according  to  the system's configured timezone, at the time the value was written.  It is
       provided only for human inspection.

       If a lease will never expire, date is never instead of an actual date.

       hardware hardware-type mac-address;

       The hardware statement records the MAC address of the network interface on which the lease
       will be used.   It is specified as a series of hexadecimal octets, separated by colons.

       uid client-identifier;

       The  uid  statement records the client identifier used by the client to acquire the lease.
       Clients are not required to send client identifiers, and this statement  only  appears  if
       the  client  did  in  fact  send one.   Client identifiers are normally an ARP type (1 for
       ethernet) followed by the MAC address, just like in the hardware statement,  but  this  is
       not required.

       The  client  identifier  is  recorded as a colon-separated hexadecimal list or as a quoted
       string.   If it is recorded as a quoted string and it contains one or  more  non-printable
       characters,  those  characters  are  represented  as octal escapes - a backslash character
       followed by three octal digits.

       client-hostname hostname ;

       Most DHCP clients will send their hostname in the host-name option.  If a client sends its
       hostname  in  this  way,  the  hostname  is  recorded  on the lease with a client-hostname
       statement.   This is not required by the  protocol,  however,  so  many  specialized  DHCP
       clients do not send a host-name option.


       The  abandoned statement indicates that the DHCP server has abandoned the lease.   In that
       case, the abandoned statement will be used to  indicate  that  the  lease  should  not  be
       reassigned.   Please  see  the  dhcpd.conf(5)  manual page for information about abandoned

       binding state state; next binding state state;

       The binding state statement declares the lease's binding state.  When the DHCP  server  is
       not configured to use the failover protocol, a lease's binding state will be either active
       or free.   The failover protocol adds some additional transitional states, as well as  the
       backup  state,  which indicates that the lease is available for allocation by the failover

       The next binding state statement indicates what state the lease  will  move  to  when  the
       current  state expires.   The time when the current state expires is specified in the ends

       option agent.circuit-id string; option agent.remote-id string;

       The option agent.circuit-id and option agent.remote-id statements are used to  record  the
       circuit  ID  and  remote  ID  options send by the relay agent, if the relay agent uses the
       relay agent information option.   This allows these options to  be  used  consistently  in
       conditional evaluations even when the client is contacting the server directly rather than
       through its relay agent.

       set variable = value;

       The set statement sets the value of a variable on the lease.  For general  information  on
       variables, see the dhcp-eval(5) manual page.

       The ddns-text variable

       The  ddns-text  variable  is  used  to record the value of the client's TXT identification
       record when the interim ddns update style has been used to update the DNS for a particular

       The ddns-fwd-name variable

       The  ddns-fwd-name  variable records the value of the name used in updating the client's A
       record if a DDNS update has been successfully done by the server.   The  server  may  also
       have used this name to update the client's PTR record.

       The ddns-client-fqdn variable

       If  the  server is configured to use the interim ddns update style, and is also configured
       to allow clients to update their own fqdns, and the client did  in  fact  update  its  own
       fqdn, then the ddns-client-fqdn variable records the name that the client has indicated it
       is using.   This is the name that the server will have used to  update  the  client's  PTR
       record in this case.

       The ddns-rev-name variable

       If  the server successfully updates the client's PTR record, this variable will record the
       name that the DHCP server used for the PTR record.   The name  to  which  the  PTR  record
       points will be either the ddns-fwd-name or the ddns-client-fqdn.

       The vendor-class-identifier variable

       The  server  retains  the client-supplied Vendor Class Identifier option for informational
       purposes, and to render them in DHCPLEASEQUERY responses.

       on events { statements... } The on statement records a list of statements to execute if  a
       certain event occurs.   The possible events that can occur for an active lease are release
       and expiry.   More than one event can be specified - if so, the events  are  separated  by
       '|' characters.

       bootp;  reserved;  These  two statements are effectively flags.  If present, they indicate
       that the BOOTP and RESERVED failover  flags,  respectively,  should  be  set.   BOOTP  and
       RESERVED  dynamic  leases  are treated differently than normal dynamic leases, as they may
       only be used by the client to which they are currently allocated.


       The state of any failover peering arrangements is also recorded in the lease  file,  using
       the failover peer statement:

       failover peer name state {
       my state state at date;
       peer state state at date;

       The  states  of  the  peer  named  name is being recorded.   Both the state of the running
       server (my state) and  the  other  failover  partner  (peer  state)  are  recorded.    The
       following  states  are  possible:  unknown-state,  partner-down,  normal,  communications-
       interrupted, resolution-interrupted, potential-conflict, recover, recover-done,  shutdown,
       paused, and startup.


       DBDIR/dhcpd.leases DBDIR/dhcpd.leases~


       dhcpd(8), dhcp-options(5), dhcp-eval(5), dhcpd.conf(5), RFC2132, RFC2131.


       dhcpd(8)  was  written  by  Ted Lemon under a contract with Vixie Labs.   Funding for this
       project was provided by Internet Systems Consortium.  Information about  Internet  Systems
       Consortium can be found at: