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-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-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