Re: DHCPv6 DDNS registration with FQDN
On Thu, 2015-02-26 at 11:12 +0100, Alexander Groß wrote: The patch was applied successfully and I was able to build on Fedora 21 with these commands (if you have opinions about these, I'm happy to learn more about your build system - I'm still a Linux noob): $ ./autogen.sh \ --prefix=/usr\ --sysconfdir=/etc\ --localstatedir=/var \ --with-nmtui $ make $ make install The DHCP packets look good now and I got the occasional DDNS update to happen successfully. I write occassional, because there's a new outstanding issue. Excellent. I'll merge the patch then. Windows DHCP has the option to protect DNS entries with a DHCID RR https://tools.ietf.org/html/draft-ietf-dnsext-dhcid-rr-13 next to the A/ RR to prevents name squatting (examples https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255MSPPError=-2147217396). It's not really Windows-specific, but from my 30 minute research there seems to be a problem with two dhclient instances (-4 and -6) requesting IPv4 and IPv6 addresses in short succession. For illustration, let's say IPv4 is the first DHCP server transaction to finish. The DHCP server will request a DDNS update with a DHCID computed based on the DHCPv4 request. The DHCID RR is placed next to the A RR in DNS. The last string is the DHCID: Yes, the interaction between DHCPv6 DUID and the IPv4 client ID is a bit more complicated than just treating the two separately as used to be the case. I don't think we can ignore existing client IDs since that would break stable IP addresses for many people, but we can start using the DUID to create the v4 ClientID for new leases, I think. That'll take a bit more work though. 30,02/26/15,00:15:39,DNS Update Request,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, 32,02/26/15,00:15:40,DNS Update Successful,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, When the DHCPv6 transaction finishes a couple of milliseconds later, the DHCPv6 server will request a DDNS update with a DHCID computed based on the DHCPv6 request, which is different: 11022,02/26/15,00:15:41,DNS IPV6 Update Request,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, 11024,02/26/15,00:15:41,DNS IPV6 Update Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, The DNS server will check the second DHCID against the one it already knows and reject the DDNS update (the log above says it was successful, but Windows logs generally suck ;-) It's easy to confirm that the DHCID RR is actually the culprit. Just delete it from the DNS, re-request DHCPv6 and the RR shows up. My dhclient man page has the following snippet: -df duid-lease-file Path to a secondary lease file. If the primary lease file doesn't contain a DUID this file will be searched. The DUID read from the secondary will be written to the primary. This option can be used to allow an IPv4 instance of the client to share a DUID with an IPv6 instance. After starting one of the instances the second can be started with this option pointing to the lease file of the first instance. There is no default. If no file is specified no search is made for a DUID should one not be found in the main lease file. The DUID https://tools.ietf.org/html/rfc3315#section-9 is a main contributor to the DHCID. As both IPv4 and IPv6 addresses are requested by/for the same interface it seems NM should make sure to use the same DUID for its requests. Yes, it should, according to http://www.ietf.org/rfc/rfc4361.txt . I've filed https://bugzilla.gnome.org/show_bug.cgi?id=745243 to track the issue. Thanks for your help! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
The patch was applied successfully and I was able to build on Fedora 21 with these commands (if you have opinions about these, I'm happy to learn more about your build system - I'm still a Linux noob): $ ./autogen.sh \ --prefix=/usr\ --sysconfdir=/etc\ --localstatedir=/var \ --with-nmtui $ make $ make install The DHCP packets look good now and I got the occasional DDNS update to happen successfully. I write occassional, because there's a new outstanding issue. Windows DHCP has the option to protect DNS entries with a DHCID RR https://tools.ietf.org/html/draft-ietf-dnsext-dhcid-rr-13 next to the A/ RR to prevents name squatting (examples https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255MSPPError=-2147217396). It's not really Windows-specific, but from my 30 minute research there seems to be a problem with two dhclient instances (-4 and -6) requesting IPv4 and IPv6 addresses in short succession. For illustration, let's say IPv4 is the first DHCP server transaction to finish. The DHCP server will request a DDNS update with a DHCID computed based on the DHCPv4 request. The DHCID RR is placed next to the A RR in DNS. The last string is the DHCID: 30,02/26/15,00:15:39,DNS Update Request,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, 32,02/26/15,00:15:40,DNS Update Successful,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=, When the DHCPv6 transaction finishes a couple of milliseconds later, the DHCPv6 server will request a DDNS update with a DHCID computed based on the DHCPv6 request, which is different: 11022,02/26/15,00:15:41,DNS IPV6 Update Request,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, 11024,02/26/15,00:15:41,DNS IPV6 Update Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=, The DNS server will check the second DHCID against the one it already knows and reject the DDNS update (the log above says it was successful, but Windows logs generally suck ;-) It's easy to confirm that the DHCID RR is actually the culprit. Just delete it from the DNS, re-request DHCPv6 and the RR shows up. My dhclient man page has the following snippet: -df duid-lease-file Path to a secondary lease file. If the primary lease file doesn't contain a DUID this file will be searched. The DUID read from the secondary will be written to the primary. This option can be used to allow an IPv4 instance of the client to share a DUID with an IPv6 instance. After starting one of the instances the second can be started with this option pointing to the lease file of the first instance. There is no default. If no file is specified no search is made for a DUID should one not be found in the main lease file. The DUID https://tools.ietf.org/html/rfc3315#section-9 is a main contributor to the DHCID. As both IPv4 and IPv6 addresses are requested by/for the same interface it seems NM should make sure to use the same DUID for its requests. I'll try forging my DUIDs to be the same and also try send dhcp6.client-id something and report my findings. Beste Grüße, Alex -- Alexander Groß http://therightstuff.de/ On Wed, Feb 25, 2015 at 5:43 PM, Dan Williams d...@redhat.com wrote: On Wed, 2015-02-25 at 17:40 +0100, Alexander Groß wrote: On Wed, Feb 25, 2015 at 5:33 PM, Dan Williams d...@redhat.com wrote: Hmm, it seems to apply with 'git am /path/to/mail.mbox' for me. What version of NetworkManager are you using? I'll generate a non-git patch for that version. I made a fresh clone and tried to apply if on the master branch. The version of NM is use on CentOS or Fedora shouldn't be relevant to that, but I have * NetworkManager-0.9.10.1-3.20150219git.fc21.x86_64 and * NetworkManager-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64. I have to admit I don't have any mailbox setup on my boxes. I copied the patch from the nm-list web interface and made sure line endings are correct. Try the attached patch which I've done against 0.9.10; I believe it'll apply with just: cd NetworkManager/ patch -p1 /path/to/patch Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Fri, 2015-02-06 at 10:39 +0100, Alexander Groß wrote: On Thu, Feb 5, 2015 at 1:02 AM, Dan Williams d...@redhat.com wrote: The question is why it was done that way originally, which I haven't looked into yet but will do. The commit that added the code is 90b995. It hasn't been change since. Can you rebuild with the attached patch and see if that makes things work for you? If so I'll go ahead and commit it, and backport to 0.9.10 and 1.0. Thanks! Dan dhclient only supports fqdn.fqdn for server DDNS updates with DHCPv6. And even though the underlying DHCP options that fqdn.fqdn controls allow non-qualified hostnames on the wire, dhclient does not. So we must require a fully-qualified name for DHCPv6. Second, while no-client-updates seems like it should be off, doing that apparently makes dhclient set the O flag to 1 which appears to be a bug, and results in the server not doing the DDNS update. So we must stop setting that option too. Found by: Alexander Groß --- src/dhcp-manager/nm-dhcp-dhclient-utils.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/src/dhcp-manager/nm-dhcp-dhclient-utils.c b/src/dhcp-manager/nm-dhcp-dhclient-utils.c index 46e8e0b..54381a0 100644 --- a/src/dhcp-manager/nm-dhcp-dhclient-utils.c +++ b/src/dhcp-manager/nm-dhcp-dhclient-utils.c @@ -39,8 +39,8 @@ #define HOSTNAME4_TAGsend host-name #define HOSTNAME4_FORMAT HOSTNAME4_TAG \%s\; # added by NetworkManager -#define HOSTNAME6_TAGsend fqdn.fqdn -#define HOSTNAME6_FORMAT HOSTNAME6_TAG \%s\; # added by NetworkManager +#define FQDN_TAGsend fqdn.fqdn +#define FQDN_FORMAT FQDN_TAG \%s\; # added by NetworkManager #define ALSOREQ_TAG also request @@ -57,7 +57,7 @@ add_also_request (GPtrArray *array, const char *item) } static void -add_hostname (GString *str, const char *format, const char *hostname) +add_hostname4 (GString *str, const char *format, const char *hostname) { char *plain_hostname, *dot; @@ -109,7 +109,7 @@ add_ip4_config (GString *str, GBytes *client_id, const char *hostname) g_string_append (str, ; # added by NetworkManager\n); } - add_hostname (str, HOSTNAME4_FORMAT \n, hostname); + add_hostname4 (str, HOSTNAME4_FORMAT \n, hostname); g_string_append_c (str, '\n'); @@ -125,13 +125,17 @@ add_ip4_config (GString *str, GBytes *client_id, const char *hostname) } static void -add_ip6_config (GString *str, const char *hostname) +add_hostname6 (GString *str, const char *hostname) { - add_hostname (str, HOSTNAME6_FORMAT \n, hostname); - g_string_append (str, -send fqdn.encoded on;\n -send fqdn.no-client-update on;\n -send fqdn.server-update on;\n); + /* dhclient only supports the fqdn.fqdn for DHCPv6 and requires a fully- +* qualified name for this option, so we must require one here too. +*/ + if (hostname strchr (hostname, '.')) { + g_string_append_printf (str, FQDN_FORMAT \n, hostname); + g_string_append (str, +send fqdn.encoded on;\n +send fqdn.server-update on;\n); + } } static GBytes * @@ -232,7 +236,7 @@ nm_dhcp_dhclient_create_config (const char *interface, if (hostname) { if (strncmp (p, HOSTNAME4_TAG, strlen (HOSTNAME4_TAG)) == 0) continue; - if (strncmp (p, HOSTNAME6_TAG, strlen (HOSTNAME6_TAG)) == 0) + if (strncmp (p, FQDN_TAG, strlen (FQDN_TAG)) == 0) continue; } @@ -290,7 +294,7 @@ nm_dhcp_dhclient_create_config (const char *interface, g_string_append_c (new_contents, '\n'); if (is_ip6) { - add_ip6_config (new_contents, hostname); + add_hostname6 (new_contents, hostname); add_also_request (alsoreq, dhcp6.name-servers); add_also_request (alsoreq, dhcp6.domain-search); add_also_request (alsoreq, dhcp6.client-id); -- 2.1.0 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Thu, Feb 5, 2015 at 1:02 AM, Dan Williams d...@redhat.com wrote: The question is why it was done that way originally, which I haven't looked into yet but will do. The commit that added the code is 90b995. It hasn't been change since. Alex -- Alexander Groß http://therightstuff.de/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
On Tue, 2015-02-03 at 12:05 +0100, Alexander Groß wrote: I have some more findings after several debugging sessions. According to RFC 4704, section 4.2 https://tools.ietf.org/html/rfc4704#section-4.2: The Domain Name part of the option carries all or part of the FQDN of a DHCPv6 client. ... A client MAY be configured with a fully qualified domain name or with a partial name that is not fully qualified. ... To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS-encoded domain name without the terminating zero-length label. According to this, Windows clients send a partial host name, e.g. FOO, without a terminating NULL character. dhclient, on the other hand, always sends a FQDN including the terminating NULL making the value fully qualified. I found a possibly unrelated discussion about this issue here: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1088682 As such, send fqdn.fqdn foo.example.local. must always be a fully qualified domain name (as NULL is automatically appended), otherwise the DDNS update won't happen in the correct DNS zone. Any idea how to achieve that given that NM always overwrites fqdn.fqdn values found in custom (merged) dhclient6.confs? http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp-manager/nm-dhcp-dhclient-utils.c#n232 So the short answer here is, you're right, NM is doing some wrong stuff with the DHCPv6 hostname. It is chopping off the FQDN when using dhclient, and that's likely a mis-interpretation of how the dhclient config was supposed to work. The question is why it was done that way originally, which I haven't looked into yet but will do. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCPv6 DDNS registration with FQDN
I have some more findings after several debugging sessions. According to RFC 4704, section 4.2 https://tools.ietf.org/html/rfc4704#section-4.2: The Domain Name part of the option carries all or part of the FQDN of a DHCPv6 client. ... A client MAY be configured with a fully qualified domain name or with a partial name that is not fully qualified. ... To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS-encoded domain name without the terminating zero-length label. According to this, Windows clients send a partial host name, e.g. FOO, without a terminating NULL character. dhclient, on the other hand, always sends a FQDN including the terminating NULL making the value fully qualified. I found a possibly unrelated discussion about this issue here: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1088682 As such, send fqdn.fqdn foo.example.local. must always be a fully qualified domain name (as NULL is automatically appended), otherwise the DDNS update won't happen in the correct DNS zone. Any idea how to achieve that given that NM always overwrites fqdn.fqdn values found in custom (merged) dhclient6.confs? http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp-manager/nm-dhcp-dhclient-utils.c#n232 Thanks, Alex -- Alexander Groß http://therightstuff.de/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
DHCPv6 DDNS registration with FQDN
Hi all, I've started this discussion with @dcbw on the IRC channel today. As he needed to leave, I want to summarize all information here and get more input. I'm running radvd on a CentOS box and Windows-based stateful DHCPv6 and DNS servers. radvd announces that IPv6 addresses are managed. Clients will then talk to DHCP and the DHCP server is configured to securely update DNS with IPv6 addresses handed out by DHCP. It works perfectly for my Windows boxes, i.e. their IPv6 addresses are resolved by my DNS without any further ado. I also have a couple of Fedora 21 and CentOS 7 boxes that should take advantage of DDNS as well with needing to resort to `nsupdate` and its security implications. Fedora: nmcli tool, version 0.9.10.1-1.4.20150115git.fc21 CentOS: nmcli tool, version 0.9.9.1-29.git20140326.4dba720.el7_0 [root@fedora ~]# nmcli con show ens192 | grep ipv6 ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.routes: ipv6.ignore-auto-routes:no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: no ipv6.ip6-privacy: -1 (unknown) ipv6.dhcp-hostname: fedora.test.local [root@fedora ~]# hostname fedora.test.local [root@fedora ~]# hostnamectl Static hostname: fedora.test.local Icon name: computer-vm Chassis: vm Machine ID: ff1345d296f247bebff818e004ac746a Boot ID: 45df522f11e449bd8821922a13b150f7 Virtualization: vmware Operating System: Fedora 21 (Twenty One) CPE OS Name: cpe:/o:fedoraproject:fedora:21 Kernel: Linux 3.18.3-201.fc21.x86_64 Architecture: x86-64 [root@fedora ~]# cat /etc/sysconfig/network-scripts/ifcfg-* | grep DHCP no output What I found is that ipv6.dhcp-hostname is not very stable. If I set and then `systemctl restart network` the ipv6.dhcp-hostname value gets removed (e.g. == --). Anyway, I want the boxes to auto-register with DNS. Here is what NM generates for dhclient: [root@fedora ~]# cat /var/lib/NetworkManager/dhclient6-ens192.conf # Created by NetworkManager send fqdn.fqdn fedora; # added by NetworkManager send fqdn.encoded on; send fqdn.no-client-update on; send fqdn.server-update on; also request dhcp6.name-servers; also request dhcp6.domain-search; also request dhcp6.client-id; Here is what I use for tests with `dhclient -6 -d -lf /dev/null -cf /etc/dhcp/dhclient6-ens192.conf`. It registers the box successfully in Windows DNS. [root@fedora ~]# cat /tmp/dhclient6-ens192.conf send fqdn.fqdn fedora.test.local; send fqdn.encoded on; send fqdn.no-client-update off; send fqdn.server-update on; also request dhcp6.name-servers; also request dhcp6.domain-search; also request dhcp6.client-id; There are two key differences: - send fqdn.fqdn fedora; # added by NetworkManager + send fqdn.fqdn fedora.wghoch4.local; It is the FQDN so Windows knows which DNS zone to update. - send fqdn.no-client-update on; + send fqdn.no-client-update off; It's 'off' in my test config such that the DHCP option 39 O bit remains unset. The S bit is set, and according to https://tools.ietf.org/html/rfc4704#section-5.2, when S=1, O=0 and N=0 the DHCP server is responsible for updating the and PTR resource records. What are the necessary configuration values such that NM invokes dhclient in such a way that my boxes are registered in Windows DNS? Thanks , Alex -- Alexander Groß http://therightstuff.de/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list