division of responsibility client/dhcp/bind

[Boylan, Ross]

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/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

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 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/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Boylan, Ross]

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 <[hidden email]> on behalf of Bill Shirley <[hidden email]>
Sent: Saturday, July 25, 2020 3:07 AM
To: [hidden email]
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
[hidden email]<mailto:[hidden email]>
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=>

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley-2]

ddns-hostname is what the dhcp server has chosen to update the DNS with.  It
uses the recipe you quoted below.  Some clients on dhcpv4 and many clients on
dhcpv6 don't send a host name.  I use this to create one:
class "NoName" {
    match if not (
        exists server.ddns-hostname
        or exists fqdn.hostname
        or exists host-name    # <-- leave this one out for dhcpv6
    );

    ddns-hostname = concat("NoName-", binary-to-ascii(16, 8, "", substring(hardware, 4, 3)));    # dhcpv4
#   ddns-hostname = concat("NoName-", binary-to-ascii(16, 8, "", suffix(option dhcp6.client-id, 3)));    # dhcpv6
    option dhcp.host-name = config-option server.ddns-hostname;
#    option fqdn.hostname = config-option server.ddns-hostname;
}

update-static-leases on;
It's a static lease; no other device will get it.  Unless a client releases a lease, it will also
remain in the DNS.  It should be removed when the lease expires but that's not
always the case.  I've used 'update-static-leases on' for years with no problems.

Bill

On 7/27/2020 3:28 PM, Boylan, Ross wrote:

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 [hidden email] on behalf of Bill Shirley [hidden email]
Sent: Saturday, July 25, 2020 3:07 AM
To: [hidden email]
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
[hidden email][hidden email]
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=>

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users