Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. DDNS update not sent on initial DHCP offer/request/ack
(Forman, Jeffrey)
2. Re: DDNS update not sent on initial DHCP offer/request/ack
(/dev/rob0)
3. Re: DDNS update not sent on initial DHCP offer/request/ack
(Rick Dicaire)
4. Re: DDNS update not sent on initial DHCP offer/request/ack
(Simon Hobson)
5. Re: DDNS update not sent on initial DHCP offer/request/ack
(Forman, Jeffrey)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Dec 2016 10:33:02 -0500
From: "Forman, Jeffrey" <li...@jeffreyforman.net>
To: dhcp-users@lists.isc.org
Subject: DDNS update not sent on initial DHCP offer/request/ack
Message-ID:
<camqstxq-_wcdordqqgms0fwje9a3hthrdh9_jcnrs8xaok7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've got a fairly standard setup here, ISC dhcpd handing out IPv4 address,
updating a DNS zone handled by BIND with those hostnames. Though it seems
lately (perhaps it's always been this case?) that the first time a new host
comes up and requests an IP from the dhcp server, BIND is not notified of
the new hostname and IP address. I have to reboot the client and then, on
the subsequent request/ack cycle, is DNS updated. So my question is, why do
I have to reboot the clients to get dhcpd to update bind? Is something
misconfigured in my DHCPD to not do the intial update, or is it something
client-side that is needed?
Infrastructure:
- dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
- dhcpd version: isc dhcpd 4.3.4
- bind version: isc bind 9.10-4p2
- client OS: CoreOS (though I also run ubuntu and OSX locally as well)
($COREOSCLIENT in the below logs)
>From the DHCPD logs, the initial request:
Dec 7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to
52:54:00:18:f7:fb via vlan12
Dec 7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
from 52:54:00:18:f7:fb via vlan12
Dec 7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
via vlan12
I reboot the client, and then:
Dec 7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
from 52:54:00:18:f7:fb via vlan12
Dec 7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
(coreE3) via vlan12
07-Dec-2016 06:27:59.177 update-security: info: client 10.10.2.1#28804/key
$TSIG-KEY: signer "$TSIG-KEY" approved
07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
$TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT'
A 10.10.2.245
07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
$TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT'
TXT "31b0331ba3cfc488d24fbfc87f9e127924"
Dec 7 06:27:59 $OPENBSD dhcpd: Added new forward map from $COREOSCLIENT to
10.10.2.245
07-Dec-2016 06:27:59.182 update-security: info: client 10.10.2.1#28804/key
$TSIG-KEY: signer "$TSIG-KEY" approved
07-Dec-2016 06:27:59.182 update: info: client 10.10.2.1#28804/key
$TSIG-KEY: updating zone '2.10.10.in-addr.arpa/IN': deleting rrset at
'245.2.10.10.in-addr.arpa' PTR
07-Dec-2016 06:27:59.182 update: info: client 10.10.2.1#28804/key
$TSIG-KEY: updating zone '2.10.10.in-addr.arpa/IN': adding an RR at
'245.2.10.10.in-addr.arpa' PTR $COREOSCLIENT.
relevant dhcpd config:
ddns-updates on;
ddns-update-style interim;
update-optimization off;
subnet 10.10.2.0 netmask 255.255.255.0 {
range 10.10.2.200 10.10.2.250;
option routers 10.10.2.1;
option domain-name-servers 10.10.2.1;
zone dns.zone.net {
primary 10.10.2.1;
key "$TSIG-KEY";
}
zone 2.10.10.in-addr.arpa {
primary 10.10.2.1;
key "$TSIG-KEY";
}
}
What am I missing here? Why does it require a restart of the client to get
the dns entry added?
Thanks,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161207/dd02894f/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 7 Dec 2016 10:11:10 -0600
From: /dev/rob0 <r...@gmx.co.uk>
To: dhcp-users@lists.isc.org
Subject: Re: DDNS update not sent on initial DHCP offer/request/ack
Message-ID: <20161207161110.gr8...@harrier.slackbuilds.org>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 07, 2016 at 10:33:02AM -0500, Forman, Jeffrey wrote:
> I've got a fairly standard setup here, ISC dhcpd handing out IPv4
> address, updating a DNS zone handled by BIND with those hostnames.
> Though it seems lately (perhaps it's always been this case?) that
> the first time a new host comes up and requests an IP from the dhcp
> server, BIND is not notified of the new hostname and IP address. I
> have to reboot the client and then, on the subsequent request/ack
> cycle, is DNS updated. So my question is, why do I have to reboot
> the clients to get dhcpd to update bind? Is something misconfigured
> in my DHCPD to not do the intial update, or is it something
> client-side that is needed?
What you showed us suggests it's a client issue.
> Infrastructure:
>
> - dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
> - dhcpd version: isc dhcpd 4.3.4
> - bind version: isc bind 9.10-4p2
> - client OS: CoreOS (though I also run ubuntu and OSX locally as well)
> ($COREOSCLIENT in the below logs)
>
> From the DHCPD logs, the initial request:
>
> Dec 7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to
> 52:54:00:18:f7:fb via vlan12
>
> Dec 7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec 7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> via vlan12
I don't see in that where any hostname was provided.
> I reboot the client, and then:
>
> Dec 7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec 7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> (coreE3) via vlan12
Here "coreE3" is the hostname ... was this a munging failure meant to
be "$COREOSCLIENT"?
> 07-Dec-2016 06:27:59.177 update-security: info: client 10.10.2.1#28804/key
> $TSIG-KEY: signer "$TSIG-KEY" approved
>
> 07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
> $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT'
> A 10.10.2.245
"Zone.net" is not a good choice for a home zone name. If you're
simply hiding the real name behind "zone.net", use "example.net"
which has been set aside for such use.
[snip]
> What am I missing here? Why does it require a restart of the client
> to get the dns entry added?
Apparently it did not provide a hostname to add to DNS.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
------------------------------
Message: 3
Date: Wed, 7 Dec 2016 11:26:20 -0500
From: Rick Dicaire <kri...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DDNS update not sent on initial DHCP offer/request/ack
Message-ID:
<CA+Cc--f1cb7vLSMRceLFRFGmh4ZdJ9oBnYrwf7H=5cim-ak...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jeff, I have the following in global options:
ddns-hostname = pick (option fqdn.hostname, option host-name, concat
("ddns-", binary-to-ascii (10, 8, "-", leased-address)));
option host-name = config-option server.ddns-hostname;
If the client doesnt send a hostname, one is created in the form of
ddns-192-168-17-34, then the forward and reverse zones are updated
accordingly.
If the client sends a hostname, then the zones are updated accordingly.
hope that helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161207/8869179e/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 7 Dec 2016 16:31:50 +0000
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DDNS update not sent on initial DHCP offer/request/ack
Message-ID: <0f9d1be0-ce7b-45bc-b357-3c283693d...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Is this an issue with all clients, or just a subset ?
Is it consistent, or does it vary ?
------------------------------
Message: 5
Date: Wed, 7 Dec 2016 20:42:11 -0500
From: "Forman, Jeffrey" <li...@jeffreyforman.net>
To: dhcp-users@lists.isc.org
Subject: Re: DDNS update not sent on initial DHCP offer/request/ack
Message-ID:
<camqstxqqpcpdt91x2ozt7gyenerrlqzg473yv_4cstr1hqs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Dec 7, 2016 at 11:11 AM, /dev/rob0 <r...@gmx.co.uk> wrote:
> On Wed, Dec 07, 2016 at 10:33:02AM -0500, Forman, Jeffrey wrote:
> > I've got a fairly standard setup here, ISC dhcpd handing out IPv4
> > address, updating a DNS zone handled by BIND with those hostnames.
> > Though it seems lately (perhaps it's always been this case?) that
> > the first time a new host comes up and requests an IP from the dhcp
> > server, BIND is not notified of the new hostname and IP address. I
> > have to reboot the client and then, on the subsequent request/ack
> > cycle, is DNS updated. So my question is, why do I have to reboot
> > the clients to get dhcpd to update bind? Is something misconfigured
> > in my DHCPD to not do the intial update, or is it something
> > client-side that is needed?
>
> What you showed us suggests it's a client issue.
>
> > Infrastructure:
> >
> > - dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
> > - dhcpd version: isc dhcpd 4.3.4
> > - bind version: isc bind 9.10-4p2
> > - client OS: CoreOS (though I also run ubuntu and OSX locally as well)
> > ($COREOSCLIENT in the below logs)
> >
> > From the DHCPD logs, the initial request:
> >
> > Dec 7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to
> > 52:54:00:18:f7:fb via vlan12
> >
> > Dec 7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> > from 52:54:00:18:f7:fb via vlan12
> >
> > Dec 7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to
> 52:54:00:18:f7:fb
> > via vlan12
>
> I don't see in that where any hostname was provided.
>
> > I reboot the client, and then:
> >
> > Dec 7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> > from 52:54:00:18:f7:fb via vlan12
> >
> > Dec 7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to
> 52:54:00:18:f7:fb
> > (coreE3) via vlan12
>
> Here "coreE3" is the hostname ... was this a munging failure meant to
> be "$COREOSCLIENT"?
>
yes
>
> > 07-Dec-2016 06:27:59.177 update-security: info: client
> 10.10.2.1#28804/key
> > $TSIG-KEY: signer "$TSIG-KEY" approved
> >
> > 07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
> > $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at
> '$COREOSCLIENT'
> > A 10.10.2.245
>
> "Zone.net" is not a good choice for a home zone name. If you're
> simply hiding the real name behind "zone.net", use "example.net"
> which has been set aside for such use.
>
Nod. I can do so in later examples if necessary.
>
> [snip]
> > What am I missing here? Why does it require a restart of the client
> > to get the dns entry added?
>
> Apparently it did not provide a hostname to add to DNS.
>
Huh. Apparently even if the host knows its hostname upon install. :/
> --
> http://rob0.nodns4.us/
> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20161207/e68d7269/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 98, Issue 10
******************************************
