Classified as: {OPEN}

I think so, but not 100% sure. I am not familiar with bind server side.
Do you think this is dhcp-ddns KEA side, or bind server side issue ?

With Best Regards,
Chris LIU



{OPEN}
From: Marek Greško <marek.gre...@protonmail.com>
Sent: Friday, September 29, 2023 7:27 AM
To: LIU Chris <chris-zq....@urbanandmainlines.com>
Subject: Re: [Kea-users] DDNS update fail

You don't often get email from 
marek.gre...@protonmail.com<mailto:marek.gre...@protonmail.com>. Learn why this 
is important<https://aka.ms/LearnAboutSenderIdentification>
Hello,

are you sure you are sending DDNS updates to the authoritative DNS server for 
the zone?

Marek

------- Original Message -------
On Friday, September 29th, 2023 at 3:01, LIU Chris via Kea-users 
<kea-users@lists.isc.org<mailto:kea-users@lists.isc.org>> wrote:


Classified as: {OPEN}

My DDNS server is running bind9
After dhcp4 assgined a IP to client/device, and send DDNS update to bind 
server, it fails, bind server did not update their record
The log as bleow:

Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: 2023-09-28 20:39:01.560 
ERROR [kea-dhcp-ddns.d2-to-dns/817343.140459200614528] 
DHCP_DDNS_FORWARD_REMOVE_RRS_IO_ERROR DHCP_DDNS Request ID 
000101E8D1B5468126C7E368CC92253A7009434B4B2E2259F3B707A152A7275C679710: 
encountered an IO error sending a forward RR removal for FQDN 
client-device.linuxlab.local. to DNS server xxx.yyy.zz.zz port:53
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: 2023-09-28 20:39:01.560 
ERROR [kea-dhcp-ddns.d2-to-dns/817343.140459200614528] DHCP_DDNS_REMOVE_FAILED 
DHCP_DDNS Request ID 
000101E8D1B5468126C7E368CC92253A7009434B4B2E2259F3B707A152A7275C679710: 
Transaction outcome: Status: Failed, Event: NO_MORE_SERVERS_EVT,  Forward 
change: failed,  Reverse change: failed,  request: Type: 1 (CHG_REMOVE)
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Forward Change: yes
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Reverse Change: yes
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: FQDN: 
[client=device.linuxlab.local.]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: IP Address: [xxx.xx.xx.xx]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: DHCID: 
[000101E8D1B5468126C7E368CC92253A7009434B4B2E2259F3B707A152A7275C679710]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Lease Expires On: 
20230928204802
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Lease Length: 600
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Conflict Resolution: no
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: 2023-09-28 20:39:01.562 
ERROR [kea-dhcp-ddns.d2-to-dns/817343.140459200614528] 
DHCP_DDNS_FORWARD_ADD_IO_ERROR DHCP_DDNS Request ID 
000101392F1AEA1CB2B761E4D99A75177520C58768D4F678B9E413CDBA07ACEE038110: 
encountered an IO error sending a forward mapping add for FQDN 
client-device.linuxlab.local. to DNS server xx.xxx.xx.x port:53
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: 2023-09-28 20:39:01.562 
ERROR [kea-dhcp-ddns.d2-to-dns/817343.140459200614528] DHCP_DDNS_ADD_FAILED 
DHCP_DDNS Request ID 
000101392F1AEA1CB2B761E4D99A75177520C58768D4F678B9E413CDBA07ACEE038110: 
Transaction outcome Status: Failed, Event: NO_MORE_SERVERS_EVT,  Forward 
change: failed,  Reverse change: failed,  request: Type: 0 (CHG_ADD)
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Forward Change: yes
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Reverse Change: yes
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: FQDN: 
[mcg-779.linuxsiplab.local.]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: IP Address: [xx.xx.xx.xxx]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: DHCID: 
[000101392F1AEA1CB2B761E4D99A75177520C58768D4F678B9E413CDBA07ACEE038110]
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Lease Expires On: 
20230928204901
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Lease Length: 600
Sep 28 20:39:01 Client-Device kea-dhcp-ddns[817343]: Conflict Resolution: no

I captured on DDNS server  via wireshark,  It says  not authoritative
DNS       139         Dynamic update response 0xa2ba Not authoritative SOA 
linuxlab.local TSIG

In client side, I changed the kea configuration:  authoritative: true or false, 
there is no difference.

What would be issue ?

With Best Regards,

Chris LIU


{OPEN}

Thales is in the process of carving out its Transportation activity (GTS) from 
other Thales' activities. In order to prepare this internal restructuring, a 
new e-mail address has been adopted and your GTS contacts now use 
urbanandmainlines.com. Please note that their Thales e-mail address remains 
also valid.


Thales is in the process of carving out its Transportation activity (GTS) from 
other Thales' activities. In order to prepare this internal restructuring, a 
new e-mail address has been adopted and your GTS contacts now use 
urbanandmainlines.com. Please note that their Thales e-mail address remains 
also valid.
-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Reply via email to