I'm having an issue which I don't believe is necessarily a dnsmasq issue,
but could perhaps be either a failing in Windows or a misunderstanding on
my part.
I am looking for guidance from the knowledgeable folks on this list as to
solutions and perhaps also requesting an enhancement to dnsmasq (if
it's even technically possible).
The issue is when utilizing dnsmasq as a DHCPv6 server and having clients
forward their DDNS to a separate DNS server (i.e. Windows AD DNS) using the
"dhcp-client-update" option.
During the DHCPv6 request packet, the Windows CLIENT sends the following:
---------------------------------------------------
Client Fully Qualified Domain Name
Option: Client Fully Qualified Domain Name (39)
Length: 28
Flags: 0x00 [CLIENT wants to update its AAAA RRs and SERVER to update
its PTR RRs]
.... .0.. = N bit: Server SHOULD perform PTR RR updates
.... ...0 = S bit: Server SHOULD NOT perform AAAA RR updates
Client Domain Name: MOBILEONE.domain.local.
---------------------------------------------------
dnsmasq, WITHOUT the dhcp-client-update option responds with:
---------------------------------------------------
Client Fully Qualified Domain Name
Option: Client Fully Qualified Domain Name (39)
Length: 28
Flags: 0x03 [SERVER SHALL update both AAAA and PTR RRs]
[Server has overridden the client's S bit]
.... .0.. = N bit: Server SHOULD perform PTR RR updates
.... ..1. = O bit: Server HAS overridden client's S bit preference
.... ...1 = S bit: Server SHOULD perform AAAA RR updates
Client Domain Name: MOBILEONE.domain.local.
---------------------------------------------------
When the dhcp-client-update option is set, the server's response is:
---------------------------------------------------
Client Fully Qualified Domain Name
Option: Client Fully Qualified Domain Name (39)
Length: 28
Flags: 0x00 [CLIENT SHALL update AAAA RRs; SERVER SHALL update PTR RRs]
.... .0.. = N bit: Server SHOULD perform PTR RR updates
.... ..0. = O bit: Server HAS NOT overridden client's S bit
preference
.... ...0 = S bit: Server SHOULD NOT perform AAAA RR updates
Client Domain Name: MOBILEONE.domain.local.
---------------------------------------------------
This seems like proper behavior from dnsmasq. With the dhcp-client-update
option set the server is not overriding any of the client requested
behavior.
MY ISSUE IS - that I cannot get the client to set the "N" bit to "1" in its
request which should allow the client to update its own PTR RR with the DNS
server.
According to the RFC:
"
The "O" bit indicates whether the server has overridden the client's
preference for the "S" bit. A client MUST set this bit to 0. A
server MUST set this bit to 1 if the "S" bit in its reply to the
client does not match the "S" bit received from the client.
The "N" bit indicates whether the server SHOULD NOT perform any DNS
updates. A client sets this bit to 0 to request that the server
SHOULD perform updates (the PTR RR and possibly the AAAA RR based on
the "S" bit) or to 1 to request that the server SHOULD NOT perform
any DNS updates. A server sets the "N" bit to indicate whether the
server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N"
bit is 1, the "S" bit MUST be 0.
"
It isn't totally clear to me here, but I'm not sure if there is even a
mechanism for the server to override the "N" bit set by the client
(the RFC seems to only mention the "S" bit).
If it were possible, I would ask about the possibility of dnsmasq
implementing such a function to allow for its use as a DHCPv6 server
for Windows clients who need to register with another DNS server?
I'm curious if anyone has tested this with other clients and is able
to actually see the "N" bit as set to "1" for a client to update their
own PTR records? For some additional information regarding Windows
clients:
Excluding Windows' DHCP servers ability to update records on behalf of
the clients, Windows clients can also update their own PTR records.
To configure this for IPv4 you need to go to the Advanced
configuration properties of the IPv4 protocol on an adapter and under
the DNS tab check the option for "Use this connection's DNS suffix in
DNS registration." It is this option that controls whether the client
will register a PTR record in addition to its A record(s).
IPv6 properties have a similar option which would seem to control what
the "N" bit carries, but it does not appear to have any effect at all
when this option is selected. I have tested this on Windows 10 and 11
clients.
Can anyone offer any insight into this?
thanks
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
