<div dir="ltr">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.<div>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).</div><div><br></div><div>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.</div><div><br></div><div>During the DHCPv6 request packet, the Windows CLIENT sends the following:</div><div>---------------------------------------------------</div><div>Client Fully Qualified Domain Name<br> Option: Client Fully Qualified Domain Name (39)<br> Length: 28<br> Flags: 0x00 [CLIENT wants to update its AAAA RRs and SERVER to update its PTR RRs]<br> .... .0.. = N bit: Server SHOULD perform PTR RR updates<br> .... ...0 = S bit: Server SHOULD NOT perform AAAA RR updates<br> Client Domain Name: MOBILEONE.domain.local.<br></div><div>---------------------------------------------------<br></div><div><br></div><div>dnsmasq, WITHOUT the dhcp-client-update option responds with:</div><div>---------------------------------------------------<br></div><div>Client Fully Qualified Domain Name<br> Option: Client Fully Qualified Domain Name (39)<br> Length: 28<br> Flags: 0x03 [SERVER SHALL update both AAAA and PTR RRs]<br>[Server has overridden the client's S bit]<br> .... .0.. = N bit: Server SHOULD perform PTR RR updates<br> .... ..1. = O bit: Server HAS overridden client's S bit preference<br> .... ...1 = S bit: Server SHOULD perform AAAA RR updates<br> Client Domain Name: MOBILEONE.domain.local.<br></div><div>---------------------------------------------------<br></div><div><br></div><div>When the dhcp-client-update option is set, the server's response is:</div><div>---------------------------------------------------<br></div><div>Client Fully Qualified Domain Name<br> Option: Client Fully Qualified Domain Name (39)<br> Length: 28<br> Flags: 0x00 [CLIENT SHALL update AAAA RRs; SERVER SHALL update PTR RRs]<br> .... .0.. = N bit: Server SHOULD perform PTR RR updates<br> .... ..0. = O bit: Server HAS NOT overridden client's S bit preference<br> .... ...0 = S bit: Server SHOULD NOT perform AAAA RR updates<br> Client Domain Name: MOBILEONE.domain.local.<br></div><div>---------------------------------------------------<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>According to the RFC:</div><div>"</div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"> 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.</pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page">"</pre></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small;white-space:normal">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).</span></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small;white-space:normal">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?</span></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small;white-space:normal"><br></span></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">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:</span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal"><br></span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">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).</span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal"><br></span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">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.</span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal"><br></span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">Can anyone offer any insight into this?</span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal"><br></span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">thanks</span></font></pre><pre class="gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page"></pre></div></div>