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. [WORKAROUND] Re: The Problem With IPv4 & IPv6 DDNS in The
Same Zone (Mirsad Goran Todorovac)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Jun 2022 12:00:56 +0200
From: Mirsad Goran Todorovac <mirsad.todoro...@alu.unizg.hr>
To: Mirsad Goran Todorovac <mtodo...@alu.hr>, dhcp-users@lists.isc.org
Subject: [WORKAROUND] Re: The Problem With IPv4 & IPv6 DDNS in The
Same Zone
Message-ID: <fadf357e-c0dd-10d6-6e14-ac62272b4...@alu.unizg.hr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello,
I saw in a solution here: https://unixforum.org/viewtopic.php?t=124745
*update-conflict-detection false;*
However, I am not sure this is recommended, even when I have *deny
client-updates;*
I see both IPv4 and IPv6 Dual-Stack DHCP servers operate with
*ddns-update-style standard;*
I would not really like to turn DHCID records update & check off, but
make them work in dual stack,
as in RFC 4701? It appears if I turn the update-conflict-detection off,
the system would be running
as something on power grid without a fuse, right?
I see I still need more homework to do.
Thank you for any idea.
Kind regards,
On 24.6.2022. 16:51, Mirsad Goran Todorovac wrote:
>
> Hi,
>
> There seems to be something odd with the DHCPv6 server. I've read RFC
> 4701 on DHCID (https://datatracker.ietf.org/doc/html/rfc4701) but it
> doesn't explain it to me.
> (I am using BIND 9.16.27 and ISC DHCP 4.4.3 compiled with DDNS debugging.)
>
> DHCP log says:
>
> Jun 24 16:22:09 domac dhcpd: Forward map from
> DESKTOP-7BN2U5K.zam.alu.hr to 2001:b68:2:2e00::1095 FAILED: Has an
> address record but no DHCID, not mine.
>
> but the `dig @efk zam.alu.hr axfr` reveals that there *is* a DHCID
> record for that FQDN:
>
> DESKTOP-7BN2U5K.zam.alu.hr. 3600 IN???? DHCID
> AAEB5QtwrJi88z6yqBs7LCCtU8P/bMGOjg35vknusRnVHLU=
> DESKTOP-7BN2U5K.zam.alu.hr. 3600 IN???? A?????? 161.53.235.143
>
> The log of the session is like follows:
>
> Jun 24 16:22:09 domac dhcpd: Relay-forward message from
> 2001:b68:ff:ff:a2b:0:b6:2 port 547, link address 2001:b68:2:2e00::1,
> peer address fe80::8d06:5ca2:84c8:d93f
> Jun 24 16:22:09 domac dhcpd: Reply NA: address 2001:b68:2:2e00::1095
> to client with duid 00:01:00:01:23:33:10:b5:f4:93:9f:f0:a5:c3 iaid =
> 116691871 valid for 2592000 seconds
> Jun 24 16:22:09 domac dhcpd: ddns.c(150): Allocating
> ddns_cb=0x561a63b6c060
> Jun 24 16:22:09 domac dhcpd: DDNS: ddns_fwd_srv_connector: ddns_cb:
> 0x561a63b6c060 flags: 50b state: DDNS_STATE_CLEANUP cur_func: <null>
> eresult: 0
> Jun 24 16:22:09 domac dhcpd: DDNS: ddns_modify_fwd
> Jun 24 16:22:09 domac dhcpd: DDNS: build_fwd_add1:
> pname:[DESKTOP-7BN2U5K.zam.alu.hr] uname:[DESKTOP-7BN2U5K.zam.alu.hr]
> Jun 24 16:22:09 domac dhcpd: DDNS request: id ptr 0x7f476c297338
> DDNS_STATE_ADD_FW_NXDOMAIN 2001:b68:2:2e00::1095 for
> DESKTOP-7BN2U5K.zam.alu.hr zone: zam.alu.hr.dhcid:
> [00:02:01:3c:9a:f7:16:3b
> :ef:c1:8d:26:a9:03:22:8f:a6:2d:d7:db:f5:9a:be:f7:b8:69:62:52:8b:c6:96:d8:26:23:fb
> Jun 24 16:22:09 domac dhcpd: ddns.c(1722): Updating lease_ptr for
> ddns_cp=0x561a63b6c060 (addr=2001:b68:2:2e00::1095)
> Jun 24 16:22:09 domac dhcpd: Sending Relay-reply to
> 2001:b68:ff:ff:a2b:0:b6:2 port 547
> Jun 24 16:22:09 domac dhcpd: DDNS reply: id ptr 0x7f476c297338,
> result: YXDOMAIN
> Jun 24 16:22:09 domac dhcpd: DDNS: ddns_fwd_srv_add1: ddns_cb:
> 0x561a63b6c060 flags: 50b state: DDNS_STATE_ADD_FW_NXDOMAIN cur_func:
> ddns_fwd_srv_add1 eresult: 196614
> Jun 24 16:22:09 domac dhcpd: DDNS: ddns_modify_fwd
> Jun 24 16:22:09 domac dhcpd: DDNS: build_fwd_add2:
> pname:[DESKTOP-7BN2U5K.zam.alu.hr] uname:[DESKTOP-7BN2U5K.zam.alu.hr]
> Jun 24 16:22:09 domac dhcpd: DDNS request: id ptr 0x7f476c297338
> DDNS_STATE_ADD_FW_YXDHCID 2001:b68:2:2e00::1095 for
> DESKTOP-7BN2U5K.zam.alu.hr zone: zam.alu.hr.dhcid:
> [00:02:01:3c:9a:f7:16:3b:
> ef:c1:8d:26:a9:03:22:8f:a6:2d:d7:db:f5:9a:be:f7:b8:69:62:52:8b:c6:96:d8:26:23:fb
> Jun 24 16:22:09 domac dhcpd: DDNS reply: id ptr 0x7f476c297338,
> result: NXRRSET
> Jun 24 16:22:09 domac dhcpd: DDNS:ddns_fwd_srv_add2: ddns_cb:
> 0x561a63b6c060 flags: 50b state: DDNS_STATE_ADD_FW_YXDHCID cur_func:
> ddns_fwd_srv_add2 eresult: 196616
> Jun 24 16:22:09 domac dhcpd: Forward map from
> DESKTOP-7BN2U5K.zam.alu.hr to 2001:b68:2:2e00::1095 FAILED: Has an
> address record but no DHCID, not mine.
> Jun 24 16:22:09 domac dhcpd: ddns.c(1505): Updating lease_ptr for
> ddns_cp=0x561a63b6c060 (addr=2001:b68:2:2e00::1095)
> Jun 24 16:22:09 domac dhcpd: ddns.c(1506): freeing ddns_cb=0x561a63b6c060
>
> The effect is that the IPv6 AAAA RRs are not added to the zone, making
> DHCPv6 work in vain. :-/
>
> It would be very well that this works automatically for usability, for
> I don't think our Professors would be willing to type /64 hex IPv6
> addresses when connecting to their work computers via VPN, and
> maintaining this database by hand on all of our locations would simply
> require manpower we do not have.
>
> I have even tried to look up in the source code what it does, but I
> found no clues.
>
> IPv6 DDNS configuration is:
>
> ### DDNS Configuration
> ddns-updates on;
> ddns-update-style standard;
> # ddns-dual-stack-mixed-mode true;
> update-conflict-detection true;
> update-optimization false;
> deny client-updates;
> authoritative;
> allow unknown-clients;
> 88,1????????? 23%
> authoritative;
> allow unknown-clients;
> update-static-leases on;
> log-facility local7;
> ddns-domainname "local.alu.hr.";
> ddns-rev-domainname "ip6.arpa.";
>
> IPv4 DDNS configuration is:
>
> option domain-name "alu.hr";
> option domain-name-servers domac.alu.hr,bjesomar.srce.hr;
>
> ddns-updates on;
> ddns-update-style standard;
> update-conflict-detection true;
> update-optimization off;
> authoritative;
> ignore client-updates;
> allow unknown-clients;
> update-static-leases on;
>
> Thanks,
> Mirsad
>
> On 6/23/2022 4:34 PM, Mirsad Goran Todorovac wrote:
>>
>> Hi all,
>>
>> I have tried "update-conflict-detection true;" on both DHCPv4 and
>> DHCPv6 servers, however still getting
>>
>> Jun 23 16:15:57 domac dhcpd: Forward map from
>> PC-ANDJELKA.slava.alu.hr to 193.198.186.213 FAILED: Has an address
>> record but no DHCID, not mine.
>>
>> I wondered if the Kea server could make it better, for I have
>> understood that the same server updates both IPv4 and IPv6 address?
>>
>> Mirsad
>>
>> On 21.6.2022. 23:09, Mirsad Goran Todorovac wrote:
>>>
>>> Hi all,
>>>
>>> After two weeks I've made ISC DHCPv6 running with DDNS updates this
>>> morning, and I feel very good about
>>> how it works.
>>>
>>> (Unlike the Windows Server 2016 variant which gave me semaphore
>>> timeouts with far less diagnostics as clearly
>>> being a closed system.)
>>>
>>> It is great that now VPN users for example can access their work PCs
>>> from home even without knowing their
>>> PC's IPv6 address (and it would be error prone to tell them one over
>>> the phone each time DHCPv6 changes it,
>>> even when it tries to assign the same address if possible and the
>>> address pool is substantial).
>>>
>>> My idea was to have A and AAAA records in the same zone local.alu.hr
>>> or slava.alu.hr, and to allow
>>> the clients to access the hosts from a VPN connection over either
>>> IPv4 or IPv6 address transparently,
>>> whichever (IPv4 or IPv6) is configured on their client PC. (Or to
>>> select it at runtime as in ping -4 hostname and
>>> ping -6 hostname).
>>>
>>> This way the Professor or Assistant wouldn't have to even know if he
>>> is connecting via IPv4 or IPv6
>>> address, we could upgrade client PCs and laptops one by one, and the
>>> transition would become seamless
>>> and without an interruption of service.
>>>
>>> From configuration here:
>>> https://subatomicsolutions.org/8-freebsd/17-ipv4-ipv6-isc-dhcp-server-on-a-dual-stack-network
>>>
>>> I've got the DDNS configuration:
>>>
>>> ### DDNS Configuration
>>> ddns-updates on;
>>> ddns-update-style standard;
>>> # ddns-dual-stack-mixed-mode true;
>>> update-conflict-detection true;
>>> update-optimization false;
>>> deny client-updates;
>>> authoritative;
>>> allow unknown-clients;
>>> update-static-leases on;
>>> log-facility local7;
>>> ddns-domainname "local.alu.hr.";
>>> ddns-rev-domainname "ip6.arpa.";
>>>
>>> However I get the errors like this one:
>>>
>>> Jun 21 15:08:44 domac dhcpd: Forward map from PC-PAVAO.slava.alu.hr
>>> to 193.198.186.212 FAILED: Has an address record but no DHCID, not
>>> mine.
>>>
>>> Here:
>>> https://www.isc.org/blogs/using-dual-stack-mixed-mode-dsmm-with-ddns-in-isc-dhcp-4-4/
>>>
>>> it says:
>>>
>>> "The DHCPv4 and DHCPv6 protocols are very different; the client
>>> requests for v4 and v6 addresses will be asynchronous and thus need
>>> some sort of signalling mechanism to ensure that:
>>>
>>> * Two clients don?t get the same name (one with the A RR and the
>>> other with the AAAA)."
>>>
>>> But I want exactly for the A RR and AAAA RR to have the same
>>> hostname (PC-PAVAO.slava.alu.hr) because it is the same client with
>>> IPv4 and IPv6 address!
>>>
>>> I would like the PC to have something like:
>>>
>>> $ORIGIN slava.alu.hr.
>>>
>>> PC-PAVAO ?? IN??? A??? ??? ??? 193.198.186.212
>>> PC-PAVAO??? IN??? AAAA ??? 2001:b68:2:2a00::10c4
>>>
>>> This way our colleague could use PC-PAVAO.slava.alu.hr as his
>>> address without having to know whether he uses IPv4 or IPv6 (and it
>>> would take quite a conversation to explain the difference to an art
>>> historian for example).
>>>
>>> My goal is for IPv6 to be used seamlessly via FQDN names, as it is
>>> already been done with the server names.
>>>
>>> I figured out that I could use two zones like ipv4.slava.alu.hr and
>>> ipv6.slava.alu.hr, but I think that is awkward and the users like
>>> artists would never adopt that inconvenience. And the system that is
>>> inconvenient would probably not be used, even if it offers flow
>>> control, multimedia streaming to multicast addresses and lots of
>>> sensors, cameras and IoT devices ...
>>>
>>> Here is the complete transaction log for the host:
>>>
>>> Jun 21 15:08:44 domac dhcpd: Relay-forward message from
>>> 2001:b68:ff:ff:a2b:0:a8:2 port 547, link address 2001:b68:2:2a00::1,
>>> peer address fe80::51e5:1df6:c605:a036
>>> Jun 21 15:08:44 domac dhcpd: Reply NA: address 2001:b68:2:2a00::10c4
>>> to client with duid 00:01:00:01:25:c4:85:9c:1c:a0:b8:7d:11:aa iaid =
>>> 102539448 valid for 2592000 seconds
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(150): Allocating
>>> ddns_cb=0x556354446280
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_fwd_srv_connector: ddns_cb:
>>> 0x556354446280 flags: 50b state: DDNS_STATE_CLEANUP cur_func: <null>
>>> eresult: 0
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_modify_fwd
>>> Jun 21 15:08:44 domac dhcpd: DDNS: build_fwd_add1:
>>> pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
>>> Jun 21 15:08:44 domac dhcpd: DDNS request: id ptr 0x7f4e1040a338
>>> DDNS_STATE_ADD_FW_NXDOMAIN 2001:b68:2:2a00::10c4 for
>>> PC-PAVAO.slava.alu.hr zone: slava.alu.hr.dhcid:
>>> [00:02:01:de:c5:41:4f:69:a0:e4:6
>>> 5:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6
>>>
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1722): Updating lease_ptr for
>>> ddns_cp=0x556354446280 (addr=2001:b68:2:2a00::10c4)
>>> Jun 21 15:08:44 domac dhcpd: Sending Relay-reply to
>>> 2001:b68:ff:ff:a2b:0:a8:2 port 547
>>> Jun 21 15:08:44 domac dhcpd: DDNS reply: id ptr 0x7f4e1040a338,
>>> result: YXDOMAIN
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_fwd_srv_add1: ddns_cb:
>>> 0x556354446280 flags: 50b state: DDNS_STATE_ADD_FW_NXDOMAIN
>>> cur_func: ddns_fwd_srv_add1 eresult: 196614
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_modify_fwd
>>> Jun 21 15:08:44 domac dhcpd: DDNS: build_fwd_add2:
>>> pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
>>> Jun 21 15:08:44 domac dhcpd: DDNS request: id ptr 0x7f4e1040a338
>>> DDNS_STATE_ADD_FW_YXDHCID 2001:b68:2:2a00::10c4 for
>>> PC-PAVAO.slava.alu.hr zone: slava.alu.hr.dhcid:
>>> [00:02:01:de:c5:41:4f:69:a0:e4:65
>>> :2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6
>>>
>>> Jun 21 15:08:44 domac dhcpd: DDNS reply: id ptr 0x7f4e1040a338,
>>> result: success
>>> Jun 21 15:08:44 domac dhcpd: DDNS:ddns_fwd_srv_add2: ddns_cb:
>>> 0x556354446280 flags: 50b state: DDNS_STATE_ADD_FW_YXDHCID cur_func:
>>> ddns_fwd_srv_add2 eresult: 0
>>> Jun 21 15:08:44 domac dhcpd: Added new forward map from
>>> PC-PAVAO.slava.alu.hr to 2001:b68:2:2a00::10c4
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_modify_ptr
>>> Jun 21 15:08:44 domac dhcpd: DDNS request: id ptr 0x7f4e1040a338
>>> DDNS_STATE_ADD_PTR PC-PAVAO.slava.alu.hr for
>>> 4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.
>>> zone: 0.0.a.2.
>>> 2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.dhcid:
>>> [00:02:01:de:c5:41:4f:69:a0:e4:65:2a:e6:39:c5:77:2b:c6:a3:7e:2f:28:82:74:51:66:b2:f9:46:38:9e:af:bf:cc:c6
>>>
>>>
>>> Jun 21 15:08:44 domac dhcpd: DDNS reply: id ptr 0x7f4e1040a338,
>>> result: success
>>> Jun 21 15:08:44 domac dhcpd: Added reverse map from
>>> 4.c.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.2.2.0.0.0.8.6.b.0.1.0.0.2.ip6.arpa.
>>> to PC-PAVAO.slava.alu.hr
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1325): Updating lease_ptr for
>>> ddns_cp=0x556354446280 (addr=2001:b68:2:2a00::10c4)
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1326): freeing
>>> ddns_cb=0x556354446280
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(150): Allocating
>>> ddns_cb=0x5604136c60a0
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_fwd_srv_connector: ddns_cb:
>>> 0x5604136c60a0 flags: 50b state: DDNS_STATE_CLEANUP cur_func: <null>
>>> eresult: 0
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_modify_fwd
>>> Jun 21 15:08:44 domac dhcpd: DDNS: build_fwd_add1:
>>> pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
>>> Jun 21 15:08:44 domac dhcpd: DDNS request: id ptr 0x7fdc349e8010
>>> DDNS_STATE_ADD_FW_NXDOMAIN 193.198.186.212 for PC-PAVAO.slava.alu.hr
>>> zone: slava.alu.hr.dhcid: [00:01:01:7c:09:a5:ff:06:c6:fb:6d:76:2
>>> 1:b8:70:29:bc:ea:c3:e4:79:35:ce:76:3d:79:32:99:5b:b9:06:20:4c:bf:38
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1722): Updating lease_ptr for
>>> ddns_cp=0x5604136c60a0 (addr=193.198.186.212)
>>> Jun 21 15:08:44 domac dhcpd: DHCPREQUEST for 193.198.186.212 from
>>> 1c:a0:b8:7d:11:aa (PC-PAVAO) via eth0
>>> Jun 21 15:08:44 domac dhcpd: DHCPACK on 193.198.186.212 to
>>> 1c:a0:b8:7d:11:aa (PC-PAVAO) via eth0
>>> Jun 21 15:08:44 domac dhcpd: DDNS reply: id ptr 0x7fdc349e8010,
>>> result: YXDOMAIN
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_fwd_srv_add1: ddns_cb:
>>> 0x5604136c60a0 flags: 50b state: DDNS_STATE_ADD_FW_NXDOMAIN
>>> cur_func: ddns_fwd_srv_add1 eresult: 196614
>>> Jun 21 15:08:44 domac dhcpd: DDNS: ddns_modify_fwd
>>> Jun 21 15:08:44 domac dhcpd: DDNS: build_fwd_add2:
>>> pname:[PC-PAVAO.slava.alu.hr] uname:[PC-PAVAO.slava.alu.hr]
>>> Jun 21 15:08:44 domac dhcpd: DDNS request: id ptr 0x7fdc349e8010
>>> DDNS_STATE_ADD_FW_YXDHCID 193.198.186.212 for PC-PAVAO.slava.alu.hr
>>> zone: slava.alu.hr.dhcid: [00:01:01:7c:09:a5:ff:06:c6:fb:6d:76:21
>>> :b8:70:29:bc:ea:c3:e4:79:35:ce:76:3d:79:32:99:5b:b9:06:20:4c:bf:38
>>> Jun 21 15:08:44 domac dhcpd: DDNS reply: id ptr 0x7fdc349e8010,
>>> result: NXRRSET
>>> Jun 21 15:08:44 domac dhcpd: DDNS:ddns_fwd_srv_add2: ddns_cb:
>>> 0x5604136c60a0 flags: 50b state: DDNS_STATE_ADD_FW_YXDHCID cur_func:
>>> ddns_fwd_srv_add2 eresult: 196616
>>> Jun 21 15:08:44 domac dhcpd: Forward map from PC-PAVAO.slava.alu.hr
>>> to 193.198.186.212 FAILED: Has an address record but no DHCID, not
>>> mine.
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1505): Updating lease_ptr for
>>> ddns_cp=0x5604136c60a0 (addr=193.198.186.212)
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1505):
>>> find_lease_by_ip_addr(193.198.186.212) successful:lease=0x560413628910
>>> Jun 21 15:08:44 domac dhcpd: ddns.c(1506): freeing
>>> ddns_cb=0x5604136c60a0
>>>
>>> Sorry for my long email. English is not my first language, and I am
>>> still learning how to be concise.
>>>
>>> Thank you very much.
>>>
>>> Kind regards,
>>> Mirsad
>>>
>>> --
>>> Mirsad Goran Todorovac
>>> CARNet sistem in?enjer
>>> Grafi?ki fakultet | Akademija likovnih umjetnosti
>>> Sveu?ili?te u Zagrebu
>>> --
>>> CARNet system engineer
>>> Faculty of Graphic Arts | Academy of Fine Arts
>>> University of Zagreb, Republic of Croatia
>>> The European Union
>>> tel. +385 (0)1 3711 451
>>> mob. +385 91 57 88 355
>>>
>> --
>> Mirsad Todorovac
>> CARNet system engineer
>> Faculty of Graphic Arts | Academy of Fine Arts
>> University of Zagreb
>> Republic of Croatia, the European Union
>> --
>> CARNet sistem in?enjer
>> Grafi?ki fakultet | Akademija likovnih umjetnosti
>> Sveu?ili?te u Zagrebu
>>
> --
> Mirsad Goran Todorovac
> CARNet sistem in?enjer
> Grafi?ki fakultet | Akademija likovnih umjetnosti
> Sveu?ili?te u Zagrebu
> --
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb, Republic of Croatia
> tel. +385 (0)1 3711 451
> mob. +385 91 57 88 355
--
Mirsad Todorovac
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb
Republic of Croatia, the European Union
--
CARNet sistem in?enjer
Grafi?ki fakultet | Akademija likovnih umjetnosti
Sveu?ili?te u Zagrebu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220627/623ad8a5/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 164, Issue 32
*******************************************
