Re: DHCPv6 DDNS registration with FQDN

2015-02-26 Thread Dan Williams
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

2015-02-26 Thread Alexander Groß
​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

2015-02-24 Thread Dan Williams
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

2015-02-06 Thread Alexander Groß
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

2015-02-04 Thread Dan Williams
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

2015-02-03 Thread Alexander Groß
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

2015-02-02 Thread Alexander Groß
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