[Kea-users] DDNS update for win10 clients

Francis Dupont fdupont at isc.org
Sun Oct 22 12:24:23 UTC 2017

I believe I found the source of your problem:

Here is the request sent by Windows 10:

> 10:21:35.722392 IP (tos 0x0, ttl 128, id 8385, offset 0, flags [none],
> proto UDP (17), length 335)
> > [udp sum ok] BOOTP/DHCP, Request from
> bc:83:85:25:f6:6a, length 307, xid 0xef706b5a, Flags [Broadcast] (0x8000)
>           Client-Ethernet-Address bc:83:85:25:f6:6a
>           Vendor-rfc1048 Extensions
>             Magic Cookie 0x63825363
>             DHCP-Message Option 53, length 1: Request
>             Client-ID Option 61, length 7: ether bc:83:85:25:f6:6a
>             Requested-IP Option 50, length 4:
>             Server-ID Option 54, length 4:
>             Hostname Option 12, length 5: "APFEL"
>             FQDN Option 81, length 8: "APFEL"
=>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>             Vendor-Class Option 60, length 8: "MSFT 5.0"
>             Parameter-Request Option 55, length 13:
>               Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
>               Router-Discovery, Static-Route, Vendor-Option,
> Netbios-Name-Server
>               Netbios-Node, Netbios-Scope, Classless-Static-Route,
> Classless-Static-Route-Microsoft
>               Option 252
>             END Option 255, length 0

FQDN option is defined in RFC 4702 and was introduced to replace
Hostname option with a more flexible semantic:

The DHCP Client FQDN option is primarily intended to operate
   in the following two cases:

   1.  DHCP client updates the A RR, DHCP server updates the PTR RR.

   2.  DHCP server updates both the A and the PTR RRs.

The idea is simple: the DHCP server has always the authority on
the reverse domain so it is enough to have or not have the option
in requests to know what to do. The authority over the direct domain
depends on cases so the FQDN option carries a flag field (there are
a few bytes before the FQDN itself) with (quoting again the RFC):

   The format of the 1-octet Flags field is:

        0 1 2 3 4 5 6 7
        |  MBZ  |N|E|O|S|

The interesting flag is the last one 'S':

   The "S" bit indicates whether the server SHOULD or SHOULD NOT perform
   the A RR (FQDN-to-address) DNS updates.  A client sets the bit to 0
   to indicate the server SHOULD NOT perform the updates and 1 to
   indicate the server SHOULD perform the updates.  The state of the bit
   in the reply from the server indicates the action to be taken by the
   server; if 1, the server has taken responsibility for A RR updates
   for the FQDN.
So if you can dump the request if the details of the FQDN option
(i.e. increase verbosity or click on the filed on the GUI)
you should understand exactly what goes wrong.

BTW the RFC has a MUST NOT for sending both Hostname and FQDN options
and a SHOULD (implemented by Kea) to prefer the FQDN option when
both are received (so Windows 10 is no compliant).

I googled to see if there is something explaining how to toggle
this bit in Windows 10 but got only something for Windows 2000


so I'll resume my Windows VM (I just upgraded it to the Fall Creators
update so it needs to run to become stable anyway :-) to look at
the corresponding setting (if it exists).

In conclusion I think the problem is on the Windows 10 which
requires a config or if all windows >= 2000 want unconditionally
to update the A RR themselves you have the "ipconfig /registerdns"
command or you can force the server to do both updates with the
"override-client-update": true
in "dhcp-ddns" config, cf user/admin " When Does the kea-dhcp4
Server Generate DDNS Requests?" (or this other word it is a common problem
so Kea provides a solution :-).


Francis Dupont <fdupont at isc.org>

More information about the Kea-users mailing list