isc-dhcp-server
Contents
About
Internet Systems Consortium, Inc. (ISC) DHCP-Server
Project Homepage https://www.isc.org/dhcp/
Alternative:
Docs
The man-pages provided on the system are great and sufficient.
DHCP options
Please also see
IANA - Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters
IETF RFC5071 - Dynamic Host Configuration Protocol Options Used by PXELINUX
121 classless-routes
Push static routes via DHCP
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
dhclient
Default timeout is 60s.
The STP forward-delay timer on Cisco is usually 15s by default
Cisco - Understanding and Tuning Spanning Tree Protocol Timers- In the listening and learning states the forward-delay is ticking down.
- The dhcp client tiemout may occure before a IP has been aquired.
- To overcome this problem
configure PortFast on Cisco devices
Cisco.com - Configuring Spanning Tree PortFast, BPDU Guard, BPDU Filter, UplinkFast, BackboneFast, and Loop Guard
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.
- openvswitch-switch
- networking
- 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
Dynamic DNS Updates
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
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,
- is equivalent to
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
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.)
/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";
- 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
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 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
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
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
You can raise the loglevel during the tests
Test it by releasing ip from interface and requesting a new dhcp-lease
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)
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.