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. Re: MAC randomisation and DHCP pools (Gregory Sloop)
2. Re: division of responsibility client/dhcp/bind (Boylan, Ross)
3. Re: Ipv6 hostname in dhclient.conf (Bill Shirley)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Jul 2020 11:40:40 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <1565312903.20200727114...@sloop.net>
Content-Type: text/plain; charset="us-ascii"
MP> As an aside,
MP> I fail to see the use case for long reservations in the first place. Lower
the
MP> lease time and move on with life.
I think the question is: What's a long reservation? 7 days hardly ever seems
appropriate. But the same is true for, say 2m.
If you set 10m reservations and have a problem with the DHCP server, it's going
to be a *REALLY* big problem in 10m. (Oops!)
[Don't ask me how I know this! :) ]
So, I tend to pick reservation times with an eye toward giving me some
breathing room should a DHCP server die or otherwise have problems.
But for pools of IP's with a lot of churn, that comes up against lease
exhaustion.
There's no really great universal answer. You're right, at least on the
surface, Matt - shorter reservations are helpful. But it's not a one-ended
calculation - where shorter is almost universally better. It's a trade-off.
And to expand the pool of options (pun intended) - How about a bigger address
pool as an option? I think in most of the cases where we're talking Wifi pools
with high churn, a bigger pool isn't that hard to come by . And then, churn
isn't as large a problem and super short leases aren't as critical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20200727/dcf113df/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 27 Jul 2020 19:28:32 +0000
From: "Boylan, Ross" <ross.boy...@ucsf.edu>
To: "dhcp-users@lists.isc.org" <dhcp-users@lists.isc.org>
Cc: Ross Boylan <rossboy...@stanfordalumni.org>
Subject: Re: division of responsibility client/dhcp/bind
Message-ID:
<byapr05mb5736d2e799d1eb0ca81203ef87...@byapr05mb5736.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Thank you for the very detailed response.
Since I want to get the hostname from the client, it seems to me I must rely on
it, and, since my DNS is not public facing, the risk seems OK.
Some questions about the configuration you suggested:
> option fqdn.fqdn = concat(config-option server.ddns-hostname, ".",
> config-option server.ddns-domainname);
I couldn't find server.ddns-hostname in the man pages. config-options says it
gets settings from the server or client; I figured that meant if used by dhcpd
it would get server variables, but it looks as if you can say server.* to get
server settings and client.* (?) to get client settings. Is that right?
ddns-hostname is not one of the options listed in the dhcp-options manpage.
However, dhcpd.conf does define it, and includes a discussion near the start of
the "THE DNS UPDATE SCHEME" section. It says, in part,
---------------------------------------------
If the server is configured not to allow client updates, or if the client
doesn?t want to do its own update, the server will simply choose a name for the
client. By default, the server will choose from the following three values:
?????1.?fqdn?option?(if?present)
?????2.?hostname?option?(if?present)
?????3.?Configured?hostname?option?(if?defined).
If these defaults for choosing the host name are not appropriate you can write
your own statement to set the ddns-hostname variable as you wish. If none of
the above are found the server will use the host declaration name (if one) and
use-host-decl-names is on.
---------------------------------------
But none of the 3 alternatives seem to be satisfied, and you say I could get by
without a host statement, which is where one would specify those options AFAIK.
So where would the hostname come from?
Finally,
> update-static-leases on;
The man page on this seems to say, apart from advising not to do it, that this
means DNS will be updated when the address is handed out, but not when the
client machine shuts down. Which doesn't seem that useful.
Ross
________________________________________
From: dhcp-users <dhcp-users-boun...@lists.isc.org> on behalf of Bill Shirley
<b...@c3po.polymerindustries.biz>
Sent: Saturday, July 25, 2020 3:07 AM
To: dhcp-users@lists.isc.org
Subject: Re: division of responsibility client/dhcp/bind
Allowing just any device to update the DNS is a recipe for disaster. "Hey Mr.
DNS, not only
am I desktop.yourdomain.com but also
www.yourdomain.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.yourdomain.com&d=DwMDaQ&c=iORugZls2LlYyCAZRB3XLg&r=nh70E5-mX2XsDe5lrDDMt_ZRqqGMcdTmTrRLvNmttYA&m=s-CGQm6iVqr1PxrBSzW_Le0jg1jA6LtIeFs1M6H_gsU&s=wj63PXYsF7sb9gvhMg9bZH0JrbUDsR3I7606h-J0r4o&e=>
as well as gateway.yourdomain.com."
Allowing client updates is a concept from a more innocent time of networking.
Configure dhcpd to do all the DNS updates:
deny client-updates;
deny duplicates;
deny declines;
option fqdn.no-client-update true;
option fqdn.server-update true;
.
.
subnet 192.168.99.0 netmask 255.255.255.0 {
ddns-updates on;
ddns-domainname "lan.yourdomain.com";
option domain-name "lan.yourdomain.com";
option domain-search "lan.yourdomain.com", "wifi.yourdomain.com";
option fqdn.fqdn = concat(config-option server.ddns-hostname, ".",
config-option server.ddns-domainname);
.
.
}
To get dhcpd to always update the DNS:
update-optimization off;
To get dhcpd to update the DNS for hosts with fixed addresses:
update-static-leases on;
To assign a DNS host name (with or without a fixed address):
host Bobs-phone { hardware ethernet ac:ff:10:d1:0d:2a; ddns-hostname
"Bobs-phone"; }
Static addresses should be outside of any pool.
I don't think host a statements are required to achieve what you want.
Bill
On 7/25/2020 3:15 AM, Boylan, Ross wrote:
I have a small private network with machines that go on and off. Some of those
machines may come up with the same hardware/mac address, and yet be running
different OS's. The different OS's have different host names, and I would like
that reflected in DNS. An additional complication is that some of the system
netboot into an NFS root. I'm having trouble getting things to work, and think
I'm missing something basic about how this is all supposed to work together.
Using ISD dhcpd 4.1, bind 9.11.5 with Debian buster. Initial testing used an
NFS root client that PXE booted (using dhcpd's support for that).
I don't understand why the DDNS update responsibility is potentially split
between the server and the client. It seems the default is that the client
updates the A record while the dhcp server requests the update of the PTR
record for reverse DNS. This seems like a recipe for trouble. First, they
could get out of sync. Second, if a key is required for updates, as was true
in my initial configuration, the clients won't ordinarily have it, and so the
update will fail. Because of the second concern, I set dhcpd.conf to "ignore
client-updates;". But my reading of the manual is that this means the client's
notion of its hostname will be ignored, defeating the ultimate goal of allowing
different hostnames for same MAC.
Another problem was that because of the NFS boot the usual code to bring up the
interface was skipped. So the client system didn't run dhclient. As a
result, I got DDNS entries when the client started. But when the lease expired
without further expression of interest from the client, dhcpd (successfully)
requested deletion of the DNS records for the client.
Also, since dhcpd only handed out parameters during the PXE boot, many of the
parameters like the domain and search list, didn't make it to the main system
once it was booted.
I tried forcing the interface up on the client (specifying auto in
/etc/network/interfaces). This solved some problems while introducing others:
the NIC ended up with 2 IP addresses. Initially only the first was in DNS.
When its lease expired, there were no entries in DNS, but since dhclient was
running for the 2nd IP, its lease was renewed and entered into DNS at that
time. In principle it seemed the first IP address could be handed out to
another machine, and then 2 machines that would think they had the same IP. It
may be that the discovery process would suffice to prevent this, but at any
rate it didn't seem to be a good state of affairs that the client thought it
had an IP address that both DHCP and BIND thought was free. Finally, the
client was unable to shutdown without a manual power off because it was waiting
for a response on one of the IP's "after" it shutdown.
In all the above I was assigning the client IPs from a pool, although the
client had a host declaration (with the MAC but without an IP). Some
discussion on this list says host declarations should use fixed IPs outside of
the pool range. So I gave the host declaration in dhcpd.conf a fixed IP
outside the pool range, as well as a very long lease. I also changed to the
default "allow client-updates" while changing bind to accept update without a
key.
The client came up, but no dynamic DNS entries were requested or created as a
result. So does that only happen for IP's allocated out of the pool? And
lease time is irrelevant for an IP not in the pool?
For now, I manually entered the forward and reverse DNS entries into my local
zone in bind.
These last choices (dhcpd.conf gets host with fixed ip; bind gets corresponding
forward and reverse entries; client does not try to bring interface up after
nfs boot) mostly work. The fact that the entries exist even when the system is
down doesn't seem like much of a practical problem, but this obviously can not
satisfy my original desire to allow different hostnames/OS's for the same
machine and MAC.
Suggestions?
Thanks.
Ross Boylan
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at
https://www.isc.org/contact/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.isc.org_contact_&d=DwMDaQ&c=iORugZls2LlYyCAZRB3XLg&r=nh70E5-mX2XsDe5lrDDMt_ZRqqGMcdTmTrRLvNmttYA&m=s-CGQm6iVqr1PxrBSzW_Le0jg1jA6LtIeFs1M6H_gsU&s=bTsyl7kohgC6D7i2Gs4_n6VG55uMU52ykJnMr6xDAx8&e=>
for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org<mailto:dhcp-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_dhcp-2Dusers&d=DwMDaQ&c=iORugZls2LlYyCAZRB3XLg&r=nh70E5-mX2XsDe5lrDDMt_ZRqqGMcdTmTrRLvNmttYA&m=s-CGQm6iVqr1PxrBSzW_Le0jg1jA6LtIeFs1M6H_gsU&s=Q3kqQXjPuccSUN2ieTjKl8sMHrg0FovFxng3N4U9xek&e=>
------------------------------
Message: 3
Date: Mon, 27 Jul 2020 16:19:31 -0400
From: Bill Shirley <b...@c3po.polymerindustries.biz>
To: dhcp-users@lists.isc.org
Subject: Re: Ipv6 hostname in dhclient.conf
Message-ID:
<a1d8c533-1687-e0fc-95d5-470d8f47b...@c3po.polymerindustries.biz>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
You can save your own variables in the leases file for non-static leases:
on commit {
??? if static {
#??? ??? set is-static = " --> STATIC";
??? } else {
??? ??? set is-static = "";
??? ??? set my_duid = option dhcp6.client-id;
??? ??? set my_duid_hex = pick-first-value(binary-to-ascii(16, 8, ":", option
dhcp6.client-id), "");
??? ??? set my_given_hostname = option fqdn.hostname;
??? }
}
Lease:
ia-na "mbl\022\000\001\000\001\025Yy\267lbm\207\267\370" {
? cltt 0 2020/07/12 12:45:07;
? iaaddr 2001:xxxx:yyyy:40:50f7::ee {
??? binding state active;
??? preferred-life 9000;
??? max-life 14400;
??? ends 0 2020/07/12 16:45:07;
??? set ddns-rev-name = "<redacted>";
??? set ddns-dhcid =
"\000\002\001\320F0\342\231\334\262\211\351u\023\260\207\200\240%\230\004ZD\035\370\221f\367E\225\245e\234\2154";
??? set ddns-fwd-name = "Karen-PC.example.com";
??? set my_MAC = "6c:62:6d:87:b7:f8";
??? set my_given_hostname = "Karen-PC";
??? set my_duid_hex = "0:1:0:1:15:59:79:b7:6c:62:6d:87:b7:f8";
??? set my_duid = "\000\001\000\001\025Yy\267lbm\207\267\370";
??? set member_of = "Microsoft";
??? set pool_type = "Microsoft";
? }
}
Hope this helps,
Bill
On 7/27/2020 8:04 AM, Anjali Krishna wrote:
>
> Hi
>
> ?I am using an embedded board with hostname "test_dut"[same under
> /etc/hostname]. I am testing ipv6 ans ipv4 using dhcpd on
> server side with? - 6, - 4 options and client side I am using dhclient with -
> 6 and - 4 option for ipv6 and ipv4 respectively.
> ?Both the cases Ip assignment is happening without any trouble. But in order
> to extend our application feature we are
> providing the information of the connected devices to the user such as mac
> id, ip, hostname/client name etc. In ipv4 these
> information are provided under dhcpd.leases file. In case of ipv6 I am not
> able to find the hostname (test_dut) under the
> dhcpd6.leases files
>
> I tried with adding various options under dhclient.conf such as send
> host-name "test_dut" and edited the dhclient-script under
> /sbin and called set_hostname call under bound-renew-reboot section of ipv6.
> Still the server lease file is not updating the
> hostname for ipv6 . But hostname is updating for ipv4 connection.
>
> How can I resolve this issue?
>
> Regards,
> Anjali
>
> _______________________________________________
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> 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/20200727/ea3a83bf/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 141, Issue 18
*******************************************
