GNOME.org
 

Re: dhcp6 and fqdn support (for dns)

On 09/18/2012 04:17 PM, Dan Williams wrote:

On Tue, 2012-09-18 at 14:59 -0400, Gene Czarcinski wrote:

On 09/18/2012 02:22 PM, Dan Williams wrote:

On Tue, 2012-09-18 at 13:08 -0500, Dan Williams wrote:

On Tue, 2012-09-18 at 13:19 -0400, Gene Czarcinski wrote:

On 09/17/2012 02:36 PM, Gene Czarcinski wrote:

On 09/17/2012 02:24 PM, Gene Czarcinski wrote:

On 09/17/2012 12:05 PM, Jiri Popelka wrote:

On 09/16/2012 09:55 PM, Gene Czarcinski wrote:

BTW, from the info in the dhcp-options man-page, I believe that
NetworkManager should be doing "send fqdn.fqdn" instead of "send
host-name" for IPv4.  This should be with a plain name ... not a
qualified name.  See the man-page.


The story behind this is
https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager)
https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts)


OK, bug or feature?

Well, me and the original reporter of those bugs had suggested to
"send fqdn.fqdn" when $(hostname) was FQDN and "send host-name"
otherwise, but Bill Nottingham (initscripts) decided to always "send
host-name". So I thought it would be better for NM to stay
consistent with initscripts.
Read those BZs and if you think the behavior is wrong you could try
to re-open them.


I have not gone back to look into the history of what should or
should not be sent.  I only looked at what is said in the current
(Fedora 17,  dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page.
------------
option fqdn.fqdn text;

   Specifies  the  domain name that the client wishes to use. This can
be a fully-qualified domain name, or a single label. If there is no
trailing  ´.´  character  in the name, it is not fully-qualified, and
the server will generally update that name in some  locally-defined
domain.
-----------

It also says that "options fqdn.hostname" and "option
fqdn.domainname" should never be set.

When I got things to work, there was a lot of options in the lease
file in addition to fqdn.  I am not sure exactly what needs to be
specified except that for IPv6 if I specify "-F <homtname>" on the
dhclient command line, things work. For IPv7 "-H <homename>" seems to
work.

Regardless, as things now work I do not get dynamic dns update for
IPv6 (works fine for IPv4).  This has been with dnsmasq as the dns
and dhcp server.  I am not setting up testing on qemu/kvm/libvirt
with a guest running named and dhcpd instead of dnsmasq.  My
expectation is that it will not do dynamic dns either.

My reason for pushing this is that while using radvd to help with
IPv6 address assignment works for a client-only situation, it soon
falls apart when I have a bunch of systems referring to each other.
For IPv4 using addresses only is painful, for IPv6 it is impractical.

I believe that such situations will needs either a IPv6 dhcpd with
DDNS to named or a dnsmasq.  I do not know, there might be other
packages out there but these seem to be common.


https://bugzilla.gnome.org/show_bug.cgi?id=684242


I have duplicated the situation but instead of using dnsmasq for dns and
dhcp services.

I installed and configured named, dhcpd, and dhcpd6 on the server an
started them.

On the client, disable networking and stop the NettworkManager.service.
Again, the small change in the ifup-eth network script to use "-F"
instead of "-H" and on dhclient commandline for "-6" and "ifup eth0"
works its magic.   "host xxxx" now provides both IPv6 and IPv4 addresses.

ISTR the problem here is that since you can't use -H and -F together,
you have to pick one or the other.  And how do you make that choice?  Is
it another checkbox in the UI that nobody should ever really have to
click?  Does the DHCP server not have a configuration option to handle
DDNS using the 'send host-name' bits?  THe manpage for dhclient says
"the  server will append the ddns-domainname or domain-name options, if
any, to derive the fully qualified domain name of the client" but while
that talks about DDNS, it's unclear whether that does any DDNS stuff.

Ok, I see what's going on now.  The ISC DHCP client has two modes:
"adhoc" and "draft".  The "adhoc" mode is now deprecated and apparently
doesn't work with failover, while the "draft" mode is preferred.  The
"adhoc" mode used the hostname + a config option to construct the DDNS
name, while the "draft" mode uses the FQDN and is preferred.

So the question becomes: is anyone actually using the old "adhoc" mode,
and would we break anyone by moving to using the FQDN option instead?
That's the big question here.  Plus, we're not just talking about the
ISC DHCP client, we need to figure out what happens with (a) MS DHCP/DNS
and (b) WiFi routers with built-in DDNS functionality.



Couple of things to consider --

1.  You could make it a configuration option

Right, but ideally we don't have to.  More UI checkboxes isn't something
anyone wants.  Yes, it could be a config option underneath or something
like that, not exposed in the UI, but ideally we find a solution that
handles this and then we don't need another config option.  Uncontrolled
proliferation of config options is a loss for everyone.


2.  The problem is that right now dynamic updating of the dns (whether
it is bind or dnsmasq or anything else) does not work for IPv6.  It does
not matter what the server is, the client's hostname is not sent.

Ah, we don't create a config file for dhclient when using IPv6.  That
can be fixed.  We should really use the same codepaths as IPv4 here.


3.  Supposedly  the ISC dhcp is the "reference" against which other
implementations must be measured. [at least ISC says so]

I wouldn't hold my breath...


4.  I do not know if this was the reason for it but dnsmasq has this
(sorry Simon) hokey mode where it uses slaac for IPv6 addresses and then
does a dance with the IPv4 address and dns entry to figure out if this
named system has a IPv6 address.  Of course this does not work if it is
not a dual stack network.

5.  I still believe that NetworkManager could use "-H" if it is IPV4 and
"-F" if it is IPv6.  You already have the additional "-6" parameter if
an IPv6 instantiation of dhclient.

Well, AFAIK the old "adhoc" method wont' work well with IPv4 either.  We
should be sending the hostname for IPv6 too.  But of course that doesn't
solve the -H vs. -F problem.


6.  I really have some other work I would like to be doing but I just
might see if I could come up with a patch for NetworkManager to
implement 5. above.

One thought I had was to send "-H" as we do now, and add a checkbox to
the UI for "Register this system with Dynamic DNS" or something like
that, which NM would then use to enable the -F option.  ISTR that's
mostly what Windows does, which while that's not a reason to slavishly
duplicate how they do network setup, is at least a data point.
I have run more tests and have more comments. Your call as to what is preferred or more appropriate: continue this discussion here on this mailing list or move it to gnome's bugzilla.
That said, your last thought for a UI option to "Register this system with Dynamic DNS" has some implications. If the services are being provided by named/dhcpd/dhcpd6 or dnsmasq, this will work ... it works now for IPv4.
But, how about some other dhcp service provider and/or name service provider?
And then there is the little thing that dnsmasq can do when the network runs dual stacks where slaac is used for the IPv6 address and dnsmasq does a dance to figure out if the slaac address should be entered into the name service cache.
The statement about the UI checkbox implies that the dns will be dynamically updated regardless of how the IPv6 address was determined (including manually defined). I doubt that this was your intent and far beyond anything I believe is reasonable. 

Anyway ... where to ..here? bugzilla?

Gene
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]