DHCPv6 and DDNS

[Philippe Clérié]

Hello,

First time on the list, mostly because I have not found my answer on
Debian users or anywhere else.

For the past couple of weeks I've been trying to set up isc-dhcp-server
( 4.3.1 ) on Debian Jessie for IPv6. I am at a point where the server is
providing addresses but I cannot get it to update the DNS server.

Both servers are on the same machine. The DNS server is bind9 ( 9.9.5 )
and is working correctly for both IPv4 and IPv6. DHCPv4 is updating DNS
with no problems and I can manage IPv6 addresses using nsupdate.

The last change I attempted in my dhcpd6.conf was to set
ddns-update-style to "standard" instead of "interim" as suggested by ISC
(https://deepthought.isc.org/article/AA-01091/0/ISC-DHCP-support-for-Standard-DDNS.html).
Setting update-optimization to false is also recommended.

Note that interim style does not work either. In fact, the only time I
saw some traffic from the DHCP transaction was just after changing to
standard style. There was a bunch of denied DNS queries from the
link-local address of the DHCP client. I allowed queries from fe80::/10
to the DNS servers and thoses messages disappeared.

I have also tried removing any existing lease on the client side before
attempting the connection. The only difference is that I get the
4-messages exchange with the DHCP server instead of the 2-message exchange.

Static leases on DHCPv4 are updated provided update-static-leases is on,
so I presume the behavior is the same with v6.

======== dhcpd6.conf =======
log-facility local7;

ddns-updates on;
ddns-update-style standard;

update-optimization false;
update-conflict-detection false;
allow leasequery;

update-static-leases on;

zone example.com {
         primary6 2001:xxxx:xxxx:xxxx::16;
}

zone x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa {
         primary6 2001:xxxx:xxxx:xxxx::16;
}

authoritative
option dhcp6.name-servers 2001:xxxx:xxxx:xxxx::16;
option dhcp6.domain-search "example.com";
default-lease-time 28800;
max-lease-time 86400;
min-lease-time 7200;
ddns-domainname "example.com.";
ddns-rev-domainname "ip6.arpa.";

host alcor {
     # IPv4 172.28.5.12
         fixed-address6 2001:xxxx:xxxx:xxxx::12;
         hardware ethernet 80:1f:02:bf:05:0e;
         default-lease-time 259200;
         max-lease-time 604800;
         min-lease-time 86400;
}

subnet6 2001:xxxx:xxxx:xxxx::/64 {
        range6 2001:xxxx:xxxx:xxxx::1:101
               2001:xxxx:xxxx:xxxx::1:130;
}

===============================

So in this fragment, server alcor gets both IP addresses correctly but
only the IPv4 address is entered in DNS.

Note that trio update-optimization, update-conflict-detection, allow
leasequery has been tried in all combinations of either false or
commented out.

So far I have not seen any trace of an attempt by the DHCPv6 server to
update the DNS. I would have preferred at least some error.

For completeness I'm adding below the contents of radvd.conf and the
relevant portions of named.conf.

Thanks in advance for any suggestion...

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>


======== radvd.conf ========
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   Generated by root on Wed Jun 17 10:32:44 2015
#
     IgnoreIfMissing on;
     AdvSendAdvert on;
     AdvOtherConfigFlag on;
     AdvDefaultLifetime 1800;
     AdvLinkMTU 0;
     AdvCurHopLimit 64;
     AdvReachableTime 0;
     MaxRtrAdvInterval 600;
     MinRtrAdvInterval 198;
     AdvDefaultPreference medium;
     AdvRetransTimer 0;
     AdvManagedFlag on;
     prefix 2001:xxxx:xxxx:xxxx::/64 {
         AdvPreferredLifetime 604800;
         AdvAutonomous on;
         AdvOnLink on;
         AdvValidLifetime 2592000;
     };
};

============================


======== named.conf.local (partial) ========

zone "logisys.ht" in{
         type master;
         file "/var/lib/bind/zone.example.com";
         allow-update { 172.28.5.0/24; 2001:xxxx:xxxx:xxxx::/10;
fe80::/64; localhost;  };
};

zone "x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" in{
         type master;
         file "/var/lib/bind/zone.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa";
         allow-update { 2001:xxxx:xxxx:xxxx::/64; fe80::/64; localhost; };
};

============================================
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Doug Barton]

On 6/18/15 9:35 AM, Philippe Clérié wrote:
> ddns-domainname "example.com.";
> ddns-rev-domainname "ip6.arpa.";

Shot in the dark, but try removing the dots at the end of those names.

Also, are you seeing any attempts on the master name server side?

Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Nicolas C.]

Le 18/06/2015 18:35, Philippe Clérié a écrit :

> Hello,
>
> First time on the list, mostly because I have not found my answer on
> Debian users or anywhere else.
>
> For the past couple of weeks I've been trying to set up isc-dhcp-server
> ( 4.3.1 ) on Debian Jessie for IPv6. I am at a point where the server is
> providing addresses but I cannot get it to update the DNS server.
>
> Both servers are on the same machine. The DNS server is bind9 ( 9.9.5 )
> and is working correctly for both IPv4 and IPv6. DHCPv4 is updating DNS
> with no problems and I can manage IPv6 addresses using nsupdate.
>
> The last change I attempted in my dhcpd6.conf was to set
> ddns-update-style to "standard" instead of "interim" as suggested by ISC
> (https://deepthought.isc.org/article/AA-01091/0/ISC-DHCP-support-for-Standard-DDNS.html).
> Setting update-optimization to false is also recommended.
>
> Note that interim style does not work either. In fact, the only time I
> saw some traffic from the DHCP transaction was just after changing to
> standard style. There was a bunch of denied DNS queries from the
> link-local address of the DHCP client. I allowed queries from fe80::/10
> to the DNS servers and thoses messages disappeared.

Hello Philippe,

Maybe the problem isn't on the servers sides. Keep in mind that, in
order to work, the CLIENT has to use the same identifier for DHCPv4 and
DHCPv6 transactions (RFC 4361).

That means that the client must run a recent version of ISC-DHCP and the
DHCPv6 and DHCPv4 should be configured to both use the DUID has identifier.

This is not a problem for the DHCPv6 client but using the DUID instead
of the client-identifier on DHCPv4 may require some tweaking on the
client OS.

If you understand French, I wrote an article and did a presentation on
this topic :

https://conf-ng.jres.org/2013/planning.html#article_27

Nicolas C.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/18/2015 01:04 PM, Doug Barton wrote:

> On 6/18/15 9:35 AM, Philippe Clérié wrote:
>> ddns-domainname "example.com.";
>> ddns-rev-domainname "ip6.arpa.";
>
> Shot in the dark, but try removing the dots at the end of those names.
>
> Also, are you seeing any attempts on the master name server side?
>
> Doug
>

:-)

Nice catch! I have no idea where the dots came from! I suppose I was
trying some suggestions from Google, but I really don't remember where
and when!

Makes no difference, though!

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/18/2015 01:38 PM, Nicolas C. wrote:
>
> Hello Philippe,
>
> Maybe the problem isn't on the servers sides. Keep in mind that, in
> order to work, the CLIENT has to use the same identifier for DHCPv4 and
> DHCPv6 transactions (RFC 4361).

Ok! But I do not want the clients to update DNS. I want DHCP to take
care of that.
>
> That means that the client must run a recent version of ISC-DHCP and the
> DHCPv6 and DHCPv4 should be configured to both use the DUID has identifier.
>
Debian uses by default ISC's DHCP client. In this case version 4.3.1.
That should be recent enough I think. Since I did nothing on the client
side, and since my test clients are getting their addresses, static and
dynamic, correctly assigned, I presume the clients are not the problem.

> This is not a problem for the DHCPv6 client but using the DUID instead
> of the client-identifier on DHCPv4 may require some tweaking on the
> client OS.
>
> If you understand French, I wrote an article and did a presentation on
> this topic :
>
> https://conf-ng.jres.org/2013/planning.html#article_27
>

I took a quick look (I'm rushed! Got to take a plane tomorrow!). Anyway,
it seems to me that you had to make up a solution and you did not use
whatever built-in facility there is in the DHCP server.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Nicolas C.]

Le 19/06/2015 02:48, Philippe Clérié a écrit :

> On 06/18/2015 01:38 PM, Nicolas C. wrote:
>>
>> Hello Philippe,
>>
>> Maybe the problem isn't on the servers sides. Keep in mind that, in
>> order to work, the CLIENT has to use the same identifier for DHCPv4 and
>> DHCPv6 transactions (RFC 4361).
>
> Ok! But I do not want the clients to update DNS. I want DHCP to take
> care of that.

When the DHCP server is doing the DDNS update, it has to authenticate
one way or the other the client. If not, what would happened if two
clients were using the same hostname ?

This is called "conflict-detection" : the client provides a hostname and
an identifier (historically client-identifier with DHCPv4, DUID with
DHCPv6), the DHCP server provides an IP address to the client and it
does the DDNS work only after validating that there are no conflicts
(duplicates) with the hostname.

>> That means that the client must run a recent version of ISC-DHCP and the
>> DHCPv6 and DHCPv4 should be configured to both use the DUID has
>> identifier.
>>
> Debian uses by default ISC's DHCP client. In this case version 4.3.1.
> That should be recent enough I think. Since I did nothing on the client
> side, and since my test clients are getting their addresses, static and
> dynamic, correctly assigned, I presume the clients are not the problem.

Yes but the correct use of the same identifier by both DHCPv4/6 client
is the answer to your problem.

Apparently, you need to use the "-i" option of "dhclient" :

"Use a DUID with DHCPv4 clients. If no DUID is available in the lease
file one will be constructed and saved. The DUID will be used to
construct a RFC4361 style client id that will be included in the
client’s messages. This client id can be overridden by setting a client
id in the configuration file. Overridding the client id in this fashion
is discouraged."

>> This is not a problem for the DHCPv6 client but using the DUID instead
>> of the client-identifier on DHCPv4 may require some tweaking on the
>> client OS.
>>
>> If you understand French, I wrote an article and did a presentation on
>> this topic :
>>
>> https://conf-ng.jres.org/2013/planning.html#article_27
>>
>
> I took a quick look (I'm rushed! Got to take a plane tomorrow!). Anyway,
> it seems to me that you had to make up a solution and you did not use
> whatever built-in facility there is in the DHCP server.

We had to workaround because our clients are mostly Windows workstations
and printers. If we had only Linux Debian clients we would have used
DHCPv4 + DHCPv6 has you are trying to do.

One test that you can do is :

  - Configure the client with DHCPv4 only
  - See what records are added to the forward DNS zone (normally you'll
end up with one "A" holding the IPv4 address and one "TXT" holding the
hash of the DHCPv4 identifier)
  - Stop the DHCPv4 client, clean the records
  - Configure the client with DHCPv6 only
  - See what records are added to the forward DNS zone (normally you'll
end up with one "AAAA" holding the IPv6 address and one "TXT" holding
the hash of the DHCPv6 identifier)

Compare the content of the TXT record, it must be the same in both cases.

Regards,

Nicolas C.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Nicolas C. <[hidden email]> wrote:

> When the DHCP server is doing the DDNS update, it has to authenticate one way or the other the client. If not, what would happened if two clients were using the same hostname ?

> This is called "conflict-detection" : the client provides a hostname and an identifier (historically client-identifier with DHCPv4, DUID with DHCPv6), the DHCP server provides an IP address to the client and it does the DDNS work only after validating that there are no conflicts (duplicates) with the hostname.

With IPv4, it'll update the records because it'll pass the "does it have the safety TXT record" test. It's why the check is there - to stop someone naming their client he same as your important server and hi-jacking the DNS records.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

I get your points and in fact I have thought about them. The one reason why I have not pursued them is that I would have expected some trace in syslog of any attempt at communication between DHCPv6 and BIND. There is nothing ... 😕

Another point is that ISC creates the DUID from the MAC address and a time value. The DUID for v4 and v6 might differ. But we should still see a trace in the logs if and when an attempt is made to update DNS.

Note: I am using the MAC as client ID for both v4 and v6. It is permitted I believe. Second, I am using standard style not interim. But that does not invalidate your argument.

Last, as soon as I'm back I'll try your test procedure. 😀 I should have thought of that. 😊

At this point though, I'm beginning to suspect that the v6 server is broken in some weird way.


Thanks

The trouble with common sense is that it is so uncommon.

On Jun 20, 2015 14:22, "Nicolas C." <[hidden email]> wrote:

>
> Le 19/06/2015 02:48, Philippe Clérié a écrit :
> > On 06/18/2015 01:38 PM, Nicolas C. wrote:
> >>
> >> Hello Philippe,
> >>
> >> Maybe the problem isn't on the servers sides. Keep in mind that, in
> >> order to work, the CLIENT has to use the same identifier for DHCPv4 and
> >> DHCPv6 transactions (RFC 4361).
> >
> > Ok! But I do not want the clients to update DNS. I want DHCP to take
> > care of that.
>
> When the DHCP server is doing the DDNS update, it has to authenticate
> one way or the other the client. If not, what would happened if two
> clients were using the same hostname ?
>
> This is called "conflict-detection" : the client provides a hostname and
> an identifier (historically client-identifier with DHCPv4, DUID with
> DHCPv6), the DHCP server provides an IP address to the client and it
> does the DDNS work only after validating that there are no conflicts
> (duplicates) with the hostname.
>
> >> That means that the client must run a recent version of ISC-DHCP and the
> >> DHCPv6 and DHCPv4 should be configured to both use the DUID has
> >> identifier.
> >>
> > Debian uses by default ISC's DHCP client. In this case version 4.3.1.
> > That should be recent enough I think. Since I did nothing on the client
> > side, and since my test clients are getting their addresses, static and
> > dynamic, correctly assigned, I presume the clients are not the problem.
>
> Yes but the correct use of the same identifier by both DHCPv4/6 client
> is the answer to your problem.
>
> Apparently, you need to use the "-i" option of "dhclient" :
>
> "Use a DUID with DHCPv4 clients. If no DUID is available in the lease
> file one will be constructed and saved. The DUID will be used to
> construct a RFC4361 style client id that will be included in the
> client’s messages. This client id can be overridden by setting a client
> id in the configuration file. Overridding the client id in this fashion
> is discouraged."
>
> >> This is not a problem for the DHCPv6 client but using the DUID instead
> >> of the client-identifier on DHCPv4 may require some tweaking on the
> >> client OS.
> >>
> >> If you understand French, I wrote an article and did a presentation on
> >> this topic :
> >>
> >> https://conf-ng.jres.org/2013/planning.html#article_27 
> >>
> >
> > I took a quick look (I'm rushed! Got to take a plane tomorrow!). Anyway,
> > it seems to me that you had to make up a solution and you did not use
> > whatever built-in facility there is in the DHCP server.
>
> We had to workaround because our clients are mostly Windows workstations
> and printers. If we had only Linux Debian clients we would have used
> DHCPv4 + DHCPv6 has you are trying to do.
>
> One test that you can do is :
>
>   - Configure the client with DHCPv4 only
>   - See what records are added to the forward DNS zone (normally you'll
> end up with one "A" holding the IPv4 address and one "TXT" holding the
> hash of the DHCPv4 identifier)
>   - Stop the DHCPv4 client, clean the records
>   - Configure the client with DHCPv6 only
>   - See what records are added to the forward DNS zone (normally you'll
> end up with one "AAAA" holding the IPv6 address and one "TXT" holding
> the hash of the DHCPv6 identifier)
>
> Compare the content of the TXT record, it must be the same in both cases.
>
> Regards,
>
> Nicolas C.
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/18/2015 12:35 PM, Philippe Clérié wrote:
> Hello,
>
> First time on the list, mostly because I have not found my answer on
> Debian users or anywhere else.
>
> For the past couple of weeks I've been trying to set up isc-dhcp-server
> ( 4.3.1 ) on Debian Jessie for IPv6. I am at a point where the server is
> providing addresses but I cannot get it to update the DNS server.
>



Just returning to this subject. It seems that the server works correctly
with windows clients. At least, the one windows machine in the house is
getting IPv4 and IPv6 addresses assigned; A and AAAA records are created
by the DHCP server along with the respective reverse entries.

I guess that proves the server configuration is perfectly adequate for
some clients. A Macbook did not work though: the address was issued and
used but no DNS updates were performed. Androids and Chromebooks all
seem to be stateless only. It feels very weird that Windows does this
correctly with BIND, but ISC's own client does not.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/26/2015 09:10 AM, Philippe Clérié wrote:

> On 06/18/2015 12:35 PM, Philippe Clérié wrote:
>> Hello,
>>
>> First time on the list, mostly because I have not found my answer on
>> Debian users or anywhere else.
>>
>> For the past couple of weeks I've been trying to set up isc-dhcp-server
>> ( 4.3.1 ) on Debian Jessie for IPv6. I am at a point where the server is
>> providing addresses but I cannot get it to update the DNS server.
>>
>
>
>
> Just returning to this subject. It seems that the server works correctly
> with windows clients. At least, the one windows machine in the house is
> getting IPv4 and IPv6 addresses assigned; A and AAAA records are created
> by the DHCP server along with the respective reverse entries.
>
> I guess that proves the server configuration is perfectly adequate for
> some clients. A Macbook did not work though: the address was issued and
> used but no DNS updates were performed. Androids and Chromebooks all
> seem to be stateless only. It feels very weird that Windows does this
> correctly with BIND, but ISC's own client does not.
>

It took a while but I believe I have found my problem. It appears that
the DHCP server does not update DNS records for static leases. DNS does
get updated for clients that get their addresses from the subnet range.

Can anyone confirm that please?


Thanks.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Chris Buxton]

On Jun 29, 2015, at 11:51 AM, Philippe Clérié <[hidden email]> wrote:

> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>
> Can anyone confirm that please?

Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".

Chris Buxton
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/29/2015 03:23 PM, Chris Buxton wrote:

> On Jun 29, 2015, at 11:51 AM, Philippe Clérié <[hidden email]> wrote:
>
>> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>>
>> Can anyone confirm that please?
>
> Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".
>
> Chris Buxton
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

At the top of my config file:

ddns-updates on;
ddns-update-style standard;

update-static-leases on;
~~~~~~~~~~~~~~~~~~~~~~~~

The same config options work perfectly on DHCPv4.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/29/2015 02:51 PM, Philippe Clérié wrote:

> On 06/26/2015 09:10 AM, Philippe Clérié wrote:
>> On 06/18/2015 12:35 PM, Philippe Clérié wrote:
>>> Hello,
>>>
>>> First time on the list, mostly because I have not found my answer on
>>> Debian users or anywhere else.
>>>
>>> For the past couple of weeks I've been trying to set up isc-dhcp-server
>>> ( 4.3.1 ) on Debian Jessie for IPv6. I am at a point where the server is
>>> providing addresses but I cannot get it to update the DNS server.
>>>
>>
>>
>>
>> Just returning to this subject. It seems that the server works correctly
>> with windows clients. At least, the one windows machine in the house is
>> getting IPv4 and IPv6 addresses assigned; A and AAAA records are created
>> by the DHCP server along with the respective reverse entries.
>>
>> I guess that proves the server configuration is perfectly adequate for
>> some clients. A Macbook did not work though: the address was issued and
>> used but no DNS updates were performed. Androids and Chromebooks all
>> seem to be stateless only. It feels very weird that Windows does this
>> correctly with BIND, but ISC's own client does not.
>>
>
> It took a while but I believe I have found my problem. It appears that
> the DHCP server does not update DNS records for static leases. DNS does
> get updated for clients that get their addresses from the subnet range.
>
> Can anyone confirm that please?
>
>
> Thanks.
>

I thought it might be useful to put up my client config.


============ /etc/dhcp/dhclient.conf ============
option rfc3442-classless-static-routes code 121 = array of unsigned
integer 8;

send host-name = gethostname();
send fqdn.fqdn = gethostname();
do-forward-updates on;

request subnet-mask, broadcast-address, time-offset, routers,
         domain-name, domain-name-servers, domain-search, host-name,
         dhcp6.name-servers, dhcp6.domain-search,
         netbios-name-servers, netbios-scope, interface-mtu,
         rfc3442-classless-static-routes, ntp-servers, dhcp6.fqdn,
        dhcp6.sntp-servers;
==================================================

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Chris Buxton <[hidden email]> wrote:

>> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>>
>> Can anyone confirm that please?
>
> Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".

Just for completeness, be aware that IIRC it will create the DNS entries but doesn't delete them. That's because a static lease (host declaration with fixed-address statement) doesn't create a lease record, so the server actually has no comprehension of the "lease" expiring.


Philippe Clérié <[hidden email]> wrote:

> I thought it might be useful to put up my client config.
> ...
> do-forward-updates on;

Whether that works or not depends on several factors.
Firstly, the DHCP server can over-ride it and do the forward updates.
Secondly, the DNS server may or may not have restrictions (either by IP/net or keys) configured for zone updates. If the DHCP server allows it, but the DNS server does not - it will just fail.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/29/2015 04:53 PM, Simon Hobson wrote:

> Chris Buxton <[hidden email]> wrote:
>
>>> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>>>
>>> Can anyone confirm that please?
>>
>> Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".
>
> Just for completeness, be aware that IIRC it will create the DNS entries but doesn't delete them. That's because a static lease (host declaration with fixed-address statement) doesn't create a lease record, so the server actually has no comprehension of the "lease" expiring.
>
>
> Philippe Clérié <[hidden email]> wrote:
>
>> I thought it might be useful to put up my client config.
>> ...
>> do-forward-updates on;
>
> Whether that works or not depends on several factors.
> Firstly, the DHCP server can over-ride it and do the forward updates.

Understood. But note, one, that it was always my intention for the
server to do the updates, and two, that the logs show that the source
for the updates is the server itself as configured in dhcpd6.conf.

The DHCPv4 server does not need those lines, so v6 shouldn't either.

> Secondly, the DNS server may or may not have restrictions (either by IP/net or keys) configured for zone updates. If the DHCP server allows it, but the DNS server does not - it will just fail.

The DNS server is configured to allow updates from both IPv4 and IPv6
networks. (I was being intentionally lazy expecting to restrict that
once I had things working.) Anyway, I can update the DNS from the server
using nsupdate. The DHCP server does the updates for IPv4 (no problems
at all) and for IPv6 when the address is allocated from the given subnet
range.

BTW the DHCP config file is in my first post at the top of this thread.

Here's the scenario:

- The DHCP server is configured using the config file mentioned above.
- The DHCP client is configured using the config file just posted.
- On boot, the client is assigned the fixed IPv6 address but does not
update DNS. There is not a trace of an attempt at updating DNS. Not in
syslog and not in tshark.
- Now, in DHCP server config, comment out the static address.
- On boot, the client is assigned an address from the dynamic range and
updates the DNS server.

For what it's worth, there are more problems.

- There's a race condition with DAD (There's a work around for that, but
it was supposed to have been fixed - in Debian.).

- DHCPv4 and v6 don't seem to agree on what DUID each is using (not sure
what the story is on that. It's not a priority presently.)

- I'm now trying out updates from the client (just adding "allow
client-updates" to the server configuration), and my client just hangs
on boot, never replying to the Advertise message from the server.
Investigation is ongoing.

Regards,

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Shawn Routhier]

> On Jun 29, 2015, at 5:05 PM, Philippe Clérié <[hidden email]> wrote:
>
> On 06/29/2015 04:53 PM, Simon Hobson wrote:
>> Chris Buxton <[hidden email]> wrote:
>>
>>>> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>>>>
>>>> Can anyone confirm that please?
>>>
>>> Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".
>>
>> Just for completeness, be aware that IIRC it will create the DNS entries but doesn't delete them. That's because a static lease (host declaration with fixed-address statement) doesn't create a lease record, so the server actually has no comprehension of the "lease" expiring.
>>
>>

The server currently doesn’t do DDNS updates for v6 static leases with or without the update-static-leases option enabled.

<snip>

>
> For what it's worth, there are more problems.
>
> - There's a race condition with DAD (There's a work around for that, but it was supposed to have been fixed - in Debian.).
>
> - DHCPv4 and v6 don't seem to agree on what DUID each is using (not sure what the story is on that. It's not a priority presently.)

This is addressed in 4.3.x. You would need to set the ddns-update-stype to “standard” and to have your clients form their DUID
and client-id correctly and consistently.

>
> - I'm now trying out updates from the client (just adding "allow client-updates" to the server configuration), and my client just hangs on boot, never replying to the Advertise message from the server. Investigation is ongoing.
>
> Regards,
>
> --
> Philippe
>
> ------
> The trouble with common sense it that it is so uncommon.
> <Anonymous>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Philippe Clérié]

On 06/29/2015 10:22 PM, Shawn Routhier wrote:

>
>> On Jun 29, 2015, at 5:05 PM, Philippe Clérié <[hidden email]> wrote:
>>
>> On 06/29/2015 04:53 PM, Simon Hobson wrote:
>>> Chris Buxton <[hidden email]> wrote:
>>>
>>>>> It took a while but I believe I have found my problem. It appears that the DHCP server does not update DNS records for static leases. DNS does get updated for clients that get their addresses from the subnet range.
>>>>>
>>>>> Can anyone confirm that please?
>>>>
>>>> Correct, that is the default behavior. It can be changed with a configuration option. Iirc, the option is called "update-static-leases".
>>>
>>> Just for completeness, be aware that IIRC it will create the DNS entries but doesn't delete them. That's because a static lease (host declaration with fixed-address statement) doesn't create a lease record, so the server actually has no comprehension of the "lease" expiring.
>>>
>>>
>
> The server currently doesn’t do DDNS updates for v6 static leases with or without the update-static-leases option enabled.
>
> <snip>
>
>>
>> For what it's worth, there are more problems.
>>
>> - There's a race condition with DAD (There's a work around for that, but it was supposed to have been fixed - in Debian.).
>>
>> - DHCPv4 and v6 don't seem to agree on what DUID each is using (not sure what the story is on that. It's not a priority presently.)
>
> This is addressed in 4.3.x. You would need to set the ddns-update-stype to “standard” and to have your clients form their DUID
> and client-id correctly and consistently.
>
>>
>> - I'm now trying out updates from the client (just adding "allow client-updates" to the server configuration), and my client just hangs on boot, never replying to the Advertise message from the server. Investigation is ongoing.
>>
>> Regards,
>>
>> --
>> Philippe
>>
>> ------
>> The trouble with common sense it that it is so uncommon.
>> <Anonymous>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

I was also working under the assumption that DDNS updates for static
leases worked in v6 with update-static-leases enabled.

That turns out to be incorrect according to the man page for dhcpd.conf
(Debian 4.3.1). It is specifically stated that this only works for the
interim update style. Since I am using standard style, it may well be
that the behavior I am seeing is as intended. So I think that pursuing
this is a waste of time. And I've already spent far too much time on
just this one issue for the past few weeks.

So I'll just go fill in my DNS zones with static entries and be done
with it.

Thanks for the replies and the help.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users