• DHCP
• isc-dhcp-server

isc-dhcp-server

About

Internet Systems Consortium, Inc. (ISC) DHCP-Server

• Project Homepage https://www.isc.org/dhcp/

• Wiki EN Comparison of DHCP server software

Alternatives:

• Kea

• https://dnsmasq.org/

Standards

END OF LIFE

Please migrate to a supported software like ISC Kea.

• https://www.isc.org/dhcp_migration/

• https://www.isc.org/kea/

Docs

The man-pages provided on the system are great and sufficient.

   1 man 5 dhcp-options
   2 man 5 dhcpd.conf
   3 
   4 man 5 dhcpd.leases
   5 man 8 dhcpd

DHCP options

Please also see

• IANA - Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters

• IETF RFC2132 - DHCP Options and BOOTP Vendor Extensions

• IETF RFC5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX

121 classless-routes

Push static routes via DHCP

IETF RFC3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

Example

• Default via 10,0,0,1
• 172.17.0.0/24 via 10.0.0.11
• 192.168.2.128/25 via 10.0.0.21

   1 option classless-routes 0,10,0,0,1,24,172,16,0,25192,168,2,128,10,0,0,21

isc-dhcp-server and openvswitch

If you are using ip interfaces on ovs fake bridges to provide a gateway to guest networks, you need some adjustments in the boot order. The dhcp-server is configured to listen on the interfaces of the fake brigdes. The problem is that dhcpd won't start up on boot, if not all interfaces are available and configured. So we need to configure the order to startup the services.

1. openvswitch-switch
2. networking
3. isc-dhcp-server

openvswitch-switch

Is WantedBy = multi-user.target and we need to add network.target to make it start earlier. /lib/systemd/system/openvswitch-switch.service

   1 [Unit]
   2 Description=Open vSwitch
   3 After=openvswitch-nonetwork.service
   4 Requires=openvswitch-nonetwork.service
   5 Before=networking.service
   6 
   7 [Service]
   8 Type=oneshot
   9 ExecStart=/etc/init.d/openvswitch-switch start
  10 ExecStop=/etc/init.d/openvswitch-switch stop
  11 RemainAfterExit=yes
  12 
  13 [Install]
  14 WantedBy=multi-user.target network.target

The dependency between openvswitch-switch and networking is already defined by Before=networking.service.

isc-dhcp-server

Is legacy software that starts with an init-script on the SYSV-compatibility layer. Therefore we need to adjust the Init lsb headers and update SYSV boot dependencies in /etc/rc.*.d. In my case i attached  networking to the line # Required-Start:

We need to add the instance openvswitch-switch to Required-Start: /etc/init.d/isc-dhcp-server

   1 ### BEGIN INIT INFO
   2 # Provides:          isc-dhcp-server
   3 # Required-Start:    $remote_fs $network $syslog networking
   4 # Required-Stop:     $remote_fs $network $syslog
   5 # Should-Start:      $local_fs slapd $named
   6 # Should-Stop:       $local_fs slapd
   7 # Default-Start:     2 3 4 5
   8 # Default-Stop:      0 1 6
   9 # Short-Description: DHCP server
  10 # Description:       Dynamic Host Configuration Protocol Server
  11 ### END INIT INFO
  12 

Now the links in /etc/rc.*.d have to be updated

   1 update-rc.d openvswitch-switch defaults
   2 update-rc.d isc-dhcp-server defaults
   3 ### CHECK IT WITH
   4 find /etc/rc* \( -name '*isc*' -o -name '*openvswitch*' \)

Dynamic DNS Updates

• http://www.bind9.net/arm910.pdf

• http://www.bind9.net/manuals

• http://tools.ietf.org/html/rfc2845

• http://tools.ietf.org/html/rfc2930

Generate shared secret

Please see bind9#dnssec-keygen - TSIG

A complex choice

Multi-homed servers with multiple interfaces, dynamic dns updates and lots of options.

Definitions

First some definitions from the manual page, that are important later on.

The ddns-hostname statement

ddns-hostname name;

The name parameter should be the hostname that will be used in setting up the client's A and PTR records. If no ddns-hostname is specified in scope, then the server will derive the hostname automatically, using an algorithm that varies for each of the different update methods.

The ddns-domainname statement

ddns-domainname name;

The name parameter should be the domain name that will be appended to the client's hostname to form a fully-qualified domain-name (FQDN).

The ddns-update-style parameter

ddns-update-style style;

The style parameter must be one of standard, interim or none. The ddns-update-style statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is assigned an IP address, so there is no way to use different DNS update styles for different clients. The default is none. For more info about the update styles themselfes please see

ISC DHCP support for Standard DDNS

The use-host-decl-names statement

use-host-decl-names flag;

If the use-host-decl-names parameter is true in a given scope, then for every host declaration within that scope, the name provided for the host declaration will be supplied to the client as its hostname.

So, for example,

   1    group {
   2      use-host-decl-names on;
   3 
   4      host joe {
   5        hardware ethernet 08:00:2b:4c:29:32;
   6        fixed-address joe.example.com;
   7      }      
   8    }      

is equivalent to

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

Additionally, enabling use-host-decl-names instructs the server to use the host declaration name in the the forward DNS name, if no other values are available. This value selection process is discussed in more detail under DNS updates.

An option host-name statement within a host declaration will override the use of the name in the host declaration.

It should be noted here that most DHCP clients completely ignore the host-name option sent by the DHCP server, and there is no way to configure them not to do this. So you generally have a choice of either not having any hostname to client IP address mapping that the client will recognize, or doing DNS updates. It is beyond the scope of this document to describe how to make this determination.

The option host-name

option host-name string;

This option specifies the name of the client. The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name). See RFC 1035 for character set restrictions. This option is only honored by dhclient-script(8) if the hostname for the client machine is not set.

The problem

My idea of a hostname

When trying to implement this idea, while reducing statements using use-host-decl-names and groups to inherit ddns-domainname the identifiers of the statically defined hosts collide.

The solution

The only functional combination of settings is to use

• use-host-decl-names false;
• nested groups and their inheritance of ddns-domainname
• a free identifier in the host statement, that does never collide and is probably important for OMAPI
• the "option host-name" within the host declaration

   1 use-host-decl-names false;
   2 group sd1 {
   3         ddns-domainname "sd1.domain.tld."
   4         host hostname1.sd1 {
   5                 hardware ethernet     52:54:00:16:00:11;
   6                 option host-name      "hostname1";
   7                 fixed-address         172.16.0.11;
   8         }
   9 }
  10 group sd2 {
  11         ddns-domainname "sd2.domain.tld."
  12         host hostname1.sd2 {
  13                 hardware ethernet     52:54:00:17:00:11;
  14                 option host-name      "hostname1";
  15                 fixed-address         172.17.0.11;
  16         }
  17 }

dhcpd -t also validates this kind of config. the "option host-name" does not collide as the identifiers do.

Configure isc-dhcp-server

algorithm (should be a FQDN with a terminating ".", but the configuration file parser will add both if you left them out.)

   1 key DHCP_UPDATER {
   2         algorithm       HMAC-SHA512.SIG-ALG.REG.INT.;
   3         secret          "KeyExtractedFromPrivateFile==";
   4 };

/etc/dhcp/dhcpd.conf

   1 # dhcpd.conf
   2 #
   3 # Configuration file for ISC dhcpd for Debian
   4 #
   5 
   6 # The ddns-updates-style parameter controls whether or not the server will
   7 # attempt to do a DNS update when a lease is confirmed. We default to the
   8 # behavior of the version 2 packages ('none', since DHCP v2 didn't
   9 # have support for DDNS.)
  10 ddns-update-style       standard;       #Default none, standard, interim, ad-hoc no longer supported
  11 ddns-updates            on;             #Default on
  12 do-forward-updates      on;             #Default on 
  13 ### DO NOT PERFORM DNS UPDATES WITH EVERY RENEW (DISABLED DURING TESTING)
  14 #update-optimization     false;          #Default on
  15 update-static-leases    on;             #Default off
  16 allow                   client-updates; #Default on 
  17 ### USE NAMES DECLARED AS IDENTIFIER OF STATIC HOST DECLARATIONS AS HOSTNAME
  18 ### IF YOU DON'T WANT TO USE THE CLIENT PROVIDED HOST-NAME FOR YOUR DDNS-UPDATES
  19 ### YOU MUST CONFIGURE A "option host-name" IN THE STATIC HOST DEFINITION
  20 use-host-decl-names     false;          #Default probably false
  21 
  22 default-lease-time              3600;
  23 max-lease-time                  14400;
  24 
  25 # If this DHCP server is the official DHCP server for the local
  26 # network, the authoritative directive should be uncommented.
  27 authoritative;
  28 
  29 # Use this to send dhcp log messages to a different log file (you also
  30 # have to hack syslog.conf to complete the redirection).
  31 log-facility local7;
  32 
  33 
  34 ### DYNAMIC DNS SETUP
  35 #key DHCP_UPDATER {
  36 #       algorithm       HMAC-MD5.SIG-ALG.REG.INT.;
  37 #       secret          "ShortMD5Secret";
  38 #};
  39 
  40 key DHCP_UPDATER {
  41         algorithm       HMAC-SHA512.SIG-ALG.REG.INT.;
  42         secret          LongSHA512Secret==;
  43 };
  44 
  45 ### ZONES
  46 
  47 ### KVM2
  48 zone 1a.rockstable.it. {
  49         primary                 127.0.0.1;
  50         key                     DHCP_UPDATER;
  51 }
  52 
  53 zone 1n.rockstable.it. {
  54         primary                 127.0.0.1;
  55         key                     DHCP_UPDATER;
  56 }
  57 
  58 zone 2a.rockstable.it. {
  59         primary                 127.0.0.1;
  60         key                     DHCP_UPDATER;
  61 }
  62 
  63 zone 2n.rockstable.it. {
  64         primary                 127.0.0.1;
  65         key                     DHCP_UPDATER;
  66 }
  67 
  68 ### FOR ARPA ZONES RANGES OR CIDR MAY BE ALSO USED LIKE
  69 ###zone 0-255.18.172.in-addr.arpa. {
  70 ###zone 64/24.18.172.in-addr.arpa. {
  71 zone 0.18.172.in-addr.arpa. {
  72         primary                 127.0.0.1;
  73         key                     DHCP_UPDATER;
  74 }
  75 
  76 zone 64.18.172.in-addr.arpa. {
  77         primary                 127.0.0.1;
  78         key                     DHCP_UPDATER;
  79 }
  80 
  81 zone 128.18.172.in-addr.arpa. {
  82         primary                 127.0.0.1;
  83         key                     DHCP_UPDATER;
  84 }
  85 
  86 zone 192.18.172.in-addr.arpa. {
  87         primary                 127.0.0.1;
  88         key                     DHCP_UPDATER;
  89 }
  90 
  91 ###KVM2
  92 group kvm2 {
  93         option domain-name              "rockstable.it";
  94         option domain-name-servers      ns3.rockstable.org, ns2.rockstable.org;
  95         option domain-search            "2n.rockstable.it", "2a.rockstable.it",
  96                                         "1n.rockstable.it", "1a.rockstable.it",
  97                                         "rockstable.it";
  98 
  99         ### SUBNET DECLARATIONS
 100         ### INTERFACE OVS-1A (VLAN 1000)
 101         subnet 172.18.0.0 netmask 255.255.255.0 {
 102                 ddns-domainname                 "1a.rockstable.it";
 103                 range                           172.18.0.128    172.18.0.254;
 104                 option domain-name              "1a.rockstable.it";
 105                 option domain-name-servers      router.1a.rockstable.it,
 106                                                 ns3.rockstable.org,
 107                                                 ns2.rockstable.org;
 108                 option routers                  router.1a.rockstable.it;
 109         }
 110 
 111         ### INTERFACE OVS-1N (VLAN 1500)
 112         subnet 172.18.64.0 netmask 255.255.255.0 {
 113                 ddns-domainname                 "1n.rockstable.it";
 114                 range                           172.18.64.128   172.18.64.254;
 115                 option domain-name              "1n.rockstable.it";
 116                 option domain-name-servers      router.1n.rockstable.it,
 117                                                 ns3.rockstable.org,
 118                                                 ns2.rockstable.org;
 119                 option routers                  router.1n.rockstable.it;
 120         }
 121 
 122         ### INTERFACE OVS-2A (VLAN 2000)
 123         subnet 172.18.128.0 netmask 255.255.255.0 {
 124                 ddns-domainname                 "2a.rockstable.org";
 125                 range                           172.18.128.128  172.18.128.254;
 126                 option domain-name              "2a.rockstable.it";
 127                 option domain-name-servers      router.2a.rockstable.it,
 128                                                 ns3.rockstable.org,
 129                                                 ns2.rockstable.org;
 130                 option routers                  router.2a.rockstable.it;
 131         }
 132 
 133         ### INTERFACE OVS-2N (VLAN 2500)
 134         subnet 172.18.192.0 netmask 255.255.255.0 {
 135                 ddns-domainname                 "2n.rockstable.it";
 136                 range                           172.18.192.128  172.18.192.254;
 137                 option domain-name              "2n.rockstable.it";
 138                 option domain-name-servers      router.2n.rockstable.it,
 139                                                 ns3.rockstable.org,
 140                                                 ns2.rockstable.org;
 141                 option routers                  router.2n.rockstable.it;
 142         }
 143 
 144         group 1n {
 145                 ddns-domainname                 "1n.rockstable.it";
 146 
 147                 ### HOST DECLARATIONS
 148                 ### GIT
 149                 host git1.1n {
 150                         hardware ethernet               52:54:00:00:00:01;
 151                         fixed-address                   172.18.0.11;
 152                         option host-name                git1;
 153                 }
 154 
 155                 #host git-run1.1n {
 156                 #       hardware ethernet               52:54:00:00:00:02;
 157                 #       fixed-address                   172.18.72.21;
 158                 #       option host-name                git-run1;
 159                 #}
 160 
 161                 #host git-run2.1n {
 162                 #       hardware ethernet               52:54:00:00:00:03;
 163                 #       fixed-address                   172.18.72.22;
 164                 #       option host-name                git-run2;
 165                 #}
 166 
 167                 host mx1.1n {
 168                         hardware ethernet               52:54:00:00:00:04;
 169                         fixed-address                   172.18.0.41;
 170                         option host-name                mx1;
 171                 }
 172 
 173                 host wiki1.1n {
 174                         hardware ethernet               52:54:00:00:00:05;
 175                         fixed-address                   172.18.0.31;
 176                         option host-name                wiki1;
 177                 }
 178 
 179                 host www2.1n {
 180                         hardware ethernet               52:54:00:00:00:06;
 181                         fixed-address                   172.18.0.32;
 182                         option host-name                www2;
 183                 }
 184         }
 185 }

Some notes on dhcpd.conf

• Host-declarations should reside in the global scope (not in subnet).
• Groups can be nested and inherit from each other.
• For DDNS to work isc-dhcp-server needs information which zone a host is assigned to.

  This can be achieved by using ddns-domainname (e.g. in a wrapping group). If dhcpd does not initiate a DNS update, its probably not been able to find out which zone a host should be assigned to.

• The statically defined hostname and ddns-domainname concatenate to the FQDN. The hostname is sent to the client and is used as transient hostname, when /etc/hostname contains a invalid hostname like localhost.localdomain.

• The statically defined hostname should not contain dots, as they are also send to the client, which takes this as a hostname.

• For statically defined hosts the client-specified

  ddns-hostname = gethostname() is superseeded by the name that was declared in host-declaration, if use-host-decl-names is enabled.

• fixed-address may also be a DNS resolvable FQDN.

• There is no super debug-level, the information contained in syslog is sufficient.

• option domain-name is not needed any more

  • option domain-name text;

    This option specifies the domain name that client should use when resolving hostnames via the Domain Name System.

  • option domain-search domain-list;

    The domain-search option specifies a ´search list´ of Domain Names to be used by the client to locate not-fully-qualified domain names. The difference between this option and

    historic use of the domain-name option for the same ends is that this option is encoded in RFC1035 compressed labels on the wire.

    For example:

    option domain-search "example.com", "sales.example.com", "eng.example.com";

Check dhcpd.conf

Always check isc-dhcp-server config after a change!

   1 dhcpd -t

List dynamic dhcp-leases

Unfortunately statically addressed leased cannot be displayed, as they are not stored in /var/lib/dhcp/dhcpd.leases.

To see interface-card manufacturer

   1 aptitude install ieee-data
   2 pushd /usr/share/misc;
   3 ln -s ../ieee-data/oui.txt;
   4 popd

   1 dhcp-lease-list --all
   2 Reading leases from /var/lib/dhcp/dhcpd.leases
   3 MAC                IP              hostname       valid until         manufacturer        
   4 ===============================================================================================
   5 52:54:00:00:00:01  172.18.0.128    -NA-           2019-07-01 14:56:57 
   6 52:54:00:00:00:02  172.18.0.129    -NA-           2019-07-01 18:27:46 

Configure bind9

There is a small tool that can help to generate a ddns configuration for bind9

   1 host # ddns-confgen
   2 # To activate this key, place the following in named.conf, and
   3 # in a separate keyfile on the system or systems from which nsupdate
   4 # will be run:
   5 key "ddns-key" {
   6         algorithm hmac-sha256;
   7         secret "GEFaX01eF/DdUicA+WQviHFq+airvu5w59sg3AA2LJ0=";
   8 };
   9 
  10 # Then, in the "zone" statement for each zone you wish to dynamically
  11 # update, place an "update-policy" statement granting update permission
  12 # to this key.  For example, the following statement grants this key
  13 # permission to update any name within the zone:
  14 update-policy {
  15         grant ddns-key zonesub ANY;
  16 };
  17 
  18 # After the keyfile has been placed, the following command will
  19 # execute nsupdate using this key:
  20 nsupdate -k <keyfile>

How isc-bind9 checks its algorithms: lib/bind9/check.c:2172:bind9_check_key

   1           static const algorithmtable algorithms[] = {
   2                   { "hmac-md5", 128 },
   3                   { "hmac-md5.sig-alg.reg.int", 0 },
   4                   { "hmac-md5.sig-alg.reg.int.", 0 },
   5                   { "hmac-sha1", 160 },
   6                   { "hmac-sha224", 224 },
   7                   { "hmac-sha256", 256 },
   8                   { "hmac-sha384", 384 },
   9                   { "hmac-sha512", 512 },
  10                   {  NULL, 0 }
  11           };

Configure named.conf.local. An algorithm with fqdn (like in dhcpd.conf) will not work

   1 key DHCP_UPDATER {
   2         algorithm       HMAC-SHA512;
   3         secret          "KeyExtractedFromPrivateFile==";
   4 };
   5 
   6 zone "16.172.in-addr.arpa" {
   7         type                    master;
   8         file                    "/var/lib/bind/zones/db.16.172";
   9         update-policy {
  10                 grant DHCP_UPDATER      zonesub ANY;
  11         };
  12         allow-query             { dmz; localhost; };                    # { address_match_list };
  13         allow-query-on          { 172.17.0.1; localhost;};              # { address_match_list };
  14 };
  15 
  16 zone "17.172.in-addr.arpa" {
  17         type                    master;
  18         file                    "/var/lib/bind/zones/db.17.172";
  19         update-policy {
  20                 grant DHCP_UPDATER      zonesub ANY;
  21         };
  22         allow-query             { inside; localhost; };                 # { address_match_list };
  23         allow-query-on          { 172.17.0.1; localhost;};              # { address_match_list };
  24 };
  25 
  26 zone "dmz.rockstable.org" {
  27         type                    master;
  28         masterfile-format       text;                                   # (text|raw)
  29         file                    "/var/lib/bind/zones/db.org.rockstable.dmz";
  30         journal                 "/var/lib/bind/journal/db.org.rockstable.dmz.jnl";      # string ;
  31         allow-query             { dmz; inside; localhost; };            # { address_match_list };
  32         allow-query-on          { 172.16.0.1; 172.17.0.1; localhost;};  # { address_match_list };
  33         update-policy   {
  34                 grant DHCP_UPDATER      zonesub ANY;
  35         };
  36         check-names             warn;                                   # (warn|fail|ignore) ;
  37         check-mx                warn;                                   # (warn|fail|ignore) ;
  38         check-wildcard          yes;                                    # yes_or_no;
  39         check-integrity         yes;                                    # yes_or_no ;
  40         notify                  yes;                                    # yes_or_no | explicit | master-only ;
  41         zone-statistics         yes;                                    # yes_or_no ;
  42 };
  43 
  44 zone "inside.rockstable.org" {
  45         type                    master;
  46         masterfile-format       text;                                   # (text|raw)
  47         file                    "/var/lib/bind/zones/db.org.rockstable.inside";         # string ;
  48         journal                 "/var/lib/bind/journal/db.org.rockstable.inside.jnl";   # string ;
  49         update-policy   {
  50                 grant DNS_REPLICATOR    zonesub ANY;
  51                 grant DHCP_UPDATER      zonesub ANY;
  52         };
  53         allow-query             { inside; localhost; };                 # { address_match_list };
  54         allow-query-on          { 172.17.0.1; localhost;};              # { address_match_list };
  55         check-names             warn;                                   # (warn|fail|ignore) ;
  56         check-mx                warn;                                   # (warn|fail|ignore) ;
  57         check-wildcard          yes;                                    # yes_or_no;
  58         check-integrity         yes;                                    # yes_or_no ;
  59         notify                  yes;                                    # yes_or_no | explicit | master-only ;
  60         zone-statistics         yes;                                    # yes_or_no ;
  61 };

Check bind9 config

   1 named-checkconf

This is an excerpt of my logging configuration concerning ddns updates:
/etc/bind/named.conf.logging

   1 logging {
   2         channel update_debug {
   3                 file            "/var/log/bind/update-debug.log" versions 10 size 10m;
   4                 severity        debug   3;
   5                 print-category  yes;
   6                 print-severity  yes;
   7                 print-time      yes;
   8         };
   9 
  10         category update         { update_debug; };
  11 };

Update Forwarding

ISC DHCP KB - How do DNS dynamic updates find the "right" server?

You may allow to forward dynamic updates to the master server. But make sure you are using a stronger authentication than IP addresses like TSIG.

{allow-update-forwarding

When set in the zone statement for a secondary zone, this specifies which hosts are allowed to submit Dynamic DNS updates and have them be forwarded to the

primary. The default is  { none; } , which means that no update forwarding is performed.

To enable update forwarding, specify allow-update-forwarding  { any; };  in the zone statement. Specifying values other than  { none; }  or  { any; }  is usually counterproductive; the responsibility for update access control should rest with the primary server, not the secondary.

Note that enabling the update forwarding feature on a secondary server may expose primary servers to attacks if they rely on insecure IP-address-based access control; see Dynamic Update Security for more details.

In general this option should only be set at the zone level. While a default value can be set at the options or view level and inherited by zones, this can lead to some zones unintentionally forwarding updates.

Test

Attach to logs

   1 tail -f /var/log/dhcpd.log /var/log/bind/update-debug.log

Restart services

   1 systemctl restart bind9
   2 systemctl restart isc-dhcp-server.service

You can raise the loglevel during the tests

   1 # rndc debug 8
   2 

Test it by releasing ip from interface and requesting a new dhcp-lease

   1 ip addr del 172.17.181.143/16 dev ens3
   2 dhclient ens3

And it works even with the long SHA2 signatures.

   1 20-Jul-2017 23:30:25.712 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
   2 20-Jul-2017 23:30:25.712 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update failed: rejected by secure update (REFUSED)
   3 20-Jul-2017 23:30:25.712 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': rolling back
   4 20-Jul-2017 23:30:30.625 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
   5 20-Jul-2017 23:30:30.626 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update failed: rejected by secure update (REFUSED)
   6 20-Jul-2017 23:30:30.626 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': rolling back
   7 20-Jul-2017 23:30:30.791 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
   8 20-Jul-2017 23:30:30.791 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update failed: rejected by secure update (REFUSED)
   9 20-Jul-2017 23:30:30.791 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': rolling back
  10 20-Jul-2017 23:33:12.116 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
  11 20-Jul-2017 23:33:12.116 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update failed: rejected by secure update (REFUSED)
  12 20-Jul-2017 23:33:12.116 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': rolling back
  13 20-Jul-2017 23:36:24.076 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
  14 20-Jul-2017 23:36:24.076 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update section prescan OK
  15 20-Jul-2017 23:36:24.076 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': adding an RR at 'www1.inside.rockstable.org' A 172.17.181.143
  16 20-Jul-2017 23:36:24.076 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': adding an RR at 'www1.inside.rockstable.org' TXT "0041e742142b95b84c48c66835a0bf3e6b"
  17 20-Jul-2017 23:36:24.076 update: debug 3: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': checking for NSEC3PARAM changes
  18 20-Jul-2017 23:36:24.076 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': writing journal /var/lib/bind/journal/db.org.rockstable.inside.jnl
  19 20-Jul-2017 23:36:24.223 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': committing update transaction
  20 20-Jul-2017 23:36:24.265 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': prerequisites are OK
  21 20-Jul-2017 23:36:24.265 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': update section prescan OK
  22 20-Jul-2017 23:36:24.265 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': deleting rrset at '143.181.17.172.in-addr.arpa' PTR
  23 20-Jul-2017 23:36:24.265 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': adding an RR at '143.181.17.172.in-addr.arpa' PTR www1.inside.rockstable.org.
  24 20-Jul-2017 23:36:24.265 update: debug 3: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': checking for NSEC3PARAM changes
  25 20-Jul-2017 23:36:24.265 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': writing journal /var/lib/bind/zones/db.17.172.jnl
  26 20-Jul-2017 23:36:24.437 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': committing update transaction
  27 21-Jul-2017 00:02:07.954 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update unsuccessful: www1.inside.rockstable.org: 'name not in use' prerequisite not satisfied (YXDOMAIN)
  28 21-Jul-2017 00:02:07.954 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': rolling back
  29 21-Jul-2017 00:02:08.014 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': prerequisites are OK
  30 21-Jul-2017 00:02:08.014 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': update section prescan OK
  31 21-Jul-2017 00:02:08.014 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': deleting rrset at 'www1.inside.rockstable.org' A
  32 21-Jul-2017 00:02:08.014 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': adding an RR at 'www1.inside.rockstable.org' A 172.17.128.1
  33 21-Jul-2017 00:02:08.014 update: debug 3: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': checking for NSEC3PARAM changes
  34 21-Jul-2017 00:02:08.014 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': writing journal /var/lib/bind/journal/db.org.rockstable.inside.jnl
  35 21-Jul-2017 00:02:08.108 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone 'inside.rockstable.org/IN': committing update transaction
  36 21-Jul-2017 00:02:08.109 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': prerequisites are OK
  37 21-Jul-2017 00:02:08.109 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': update section prescan OK
  38 21-Jul-2017 00:02:08.109 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': deleting rrset at '1.128.17.172.in-addr.arpa' PTR
  39 21-Jul-2017 00:02:08.109 update: info: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': adding an RR at '1.128.17.172.in-addr.arpa' PTR www1.inside.rockstable.org.
  40 21-Jul-2017 00:02:08.109 update: debug 3: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': checking for NSEC3PARAM changes
  41 21-Jul-2017 00:02:08.109 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': writing journal /var/lib/bind/zones/db.17.172.jnl
  42 21-Jul-2017 00:02:08.195 update: debug 8: client 127.0.0.1#7440/key dhcp_updater: updating zone '17.172.in-addr.arpa/IN': committing update transaction

Object Management API (OMAPI)

• http://www.ipamworldwide.com/ipam/isc-dhcp-api.html

omshell - OMAPI Command Shell

The OMAPI Command Shell, omshell, provides an interactive way to connect to, query, and possibly change, the ISC DHCP Server's state via OMAPI, the Object Management API. By using OMAPI and omshell, you do not have to stop, make changes, and then restart the DHCP server, but can make the changes while the server is running. Omshell provides a way of accessing OMAPI.

OMAPI is simply a communications mechanism that allows you to manipulate objects. In order to actually use omshell, you must understand what ob‐ jects are available and how to use them. Documentation for OMAPI objects can be found in the documentation for the server that provides them - for example, in the dhcpd(1) manual page and the dhclient(1) manual page.

Comment

The dhcp-client-identifier and hardware addresses are terrible data to identify a client. They are both supplied by the client over unauthenticated, shared, plaintext, unsigned communication and therefore subject to manipulation on the network (mitm) or were even spoofed on the source device itself.

DHCP Failover

• https://kb.isc.org/docs/aa-00502

dhclient

• ISC DHCP 4.4 Manual Pages - dhclient

dhclient timings

Please see:

• PROTOCOL TIMING

• IETF RFC2131 - Dynamic Host Configuration Protocol #4.4 DHCP client behavior

PROTOCOL TIMING

The timing behaviour of the client need not be configured by the user. If no timing configuration is provided by the user, a fairly reasonable timing behaviour will be used by default - one which results in fairly timely updates without placing an inordinate load on the server.

If required the following statements can be used to adjust the timing behaviour of the DHCPv4 client. The DHCPv6 protocol provides values to use and they are not currently configurable.

• The timeout statement

  • timeout time;

  • default: 60s, 1min
  • The timeout statement determines the amount of time that must pass between the time that the client begins to try to determine its address and the time that it decides that it’s not going to be able to contact a server. By default, this timeout is sixty seconds. After the timeout has passed, if there are any static leases defined in the configuration file, or any leases remaining in the lease database that have not yet expired, the client will loop through these leases attempting to validate them, and if it finds one that appears to be valid, it will use that lease’s address. If there are no valid static leases or unexpired leases in the lease database, the client will restart the protocol after the defined retry interval.

• The retry statement

  • retry time;

  • default: 300s, 5min
  • The retry statement determines the time that must pass after the client has determined that there is no DHCP server present before it tries again to contact a DHCP server. By default, this is five minutes.

• The select-timeout statement

  • select-timeout time;

  • default: 10s
  • It is possible (some might say desirable) for there to be more than one DHCP server serving any given network. In this case, it is possible that a client may be sent more than one offer in response to its initial lease discovery message. It may be that one of these offers is preferable to the other (e.g., one offer may have the address the client previously used,

    and the other may not).
    The select-timeout is the time after the client sends its first lease discovery request at which it stops waiting for offers from servers, assuming that it has received at least one such offer. If no offers have been received by the time the select-timeout has expired, the client will accept the first offer that arrives.
    By default, the select-timeout is zero seconds - that is, the client will take the first offer it sees.

• The reboot statement

  • reboot time;

  • default: 15s
  • When the client is restarted, it first tries to reacquire the last address it had. This is called the INIT-REBOOT state. If it is still attached to the same network it was attached to when it last ran, this is the quickest way to get started. The reboot statement sets the time that must elapse after the client first tries to reacquire its old address before it gives up and tries to discover a new address. By default, the reboot timeout is ten seconds.

• The backoff-cutoff statement

  • backoff-cutoff time;

  • default: 15s
  • The client uses an exponential backoff algorithm with some randomness, so that if many clients try to configure themselves at the same time, they will not make their requests in lockstep. The backoff-cutoff statement determines the maximum amount of time that the client is allowed to back off, the actual value will be evaluated randomly between 1/2 to 1 1/2 times the time specified. It defaults to fifteen seconds.

• The initial-interval statement

  • initial-interval time;

  • default: 10s
  • The initial-interval statement sets the amount of time between the first attempt to reach a server and the second attempt to reach a server. Each time a message is sent, the interval between messages is incremented by twice the current interval multiplied by a random number between zero and one. If it is greater than the backoff-cutoff amount, it is set to that amount. It defaults to ten seconds.

• The initial-delay statement

  • initial-delay time;

  • default: 5s
  • initial-delay parameter sets the maximum time client can wait after start before commencing first transmission. According to RFC2131 Section 4.4.1, client should wait a random time between startup and the actual first transmission. Previous versions of ISC DHCP client used to wait random time up to 5 seconds, but that was unwanted due to impact on startup time. As such, new versions have the default initial delay set to 0. To restore old behavior, please set initial-delay to 5.

Spanning Tree and DHCP

• The dhclient timeout is 60s by default.

  • Please see
    PROTOCOL TIMING

• The STP forward-delay timer on Cisco is usually 15s by default

  • Please see
    Cisco - Understanding and Tuning Spanning Tree Protocol Timers

• In the states "listening" and "learning" the forward-delay is ticking down.
• The dhcp client timeout may occure before a IP has been acquired.
• To overcome this problem

  configure PortFast on Cisco devices
  Cisco.com - Configuring Spanning Tree PortFast, BPDU Guard, BPDU Filter, UplinkFast, BackboneFast, and Loop Guard

Lease renewal and expiration

• ISC DHCP 4.4 Manual Pages - dhclient