Re: dhcp6 and fqdn support (for dns)

[Dan Williams <dcbw redhat com>]

On Wed, 2012-09-19 at 08:29 -0400, Gene Czarcinski wrote:
> 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?

That depends on the provider that does this registration.  The "Register
this system" checkbox idea was dependent on the idea of DHCP being that
registration vehicle.  For IPv6, if DHCP is not being used then
obviously we need some other mechanism.

For the dnsmasq stuff you're describing, is that happening when dnsmasq
is the local caching nameserver, or when it's the *upstream* DNS server
and we're talking about a client using DHCP?  If it's the local caching
nameserver case we're talking about, it's hard to see how dnsmasq could
do anything that would register the system with DDNS, because it's
obviously running locally and can't touch anything that would relate to
DNS.

If we're talking about dnsmasq as the upstream DNS server that *is*
handling the DDNS updates, then is it handling the "fqdn" option sent
from "dhclient -6" or something?

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

Yeah, bugzilla is probably best here.

Dan