Re: dhcp6 and fqdn support (for dns)
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 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
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 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
Re: dhcp6 and fqdn support (for dns)
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 now provides both IPv6 and IPv4 addresses. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
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 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. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
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 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. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
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 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 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. 3. Supposedly the ISC dhcp is the reference against which other implementations must be measured. [at least ISC says so] 4. I do not know if this was the reason for it but
Re: dhcp6 and fqdn support (for dns)
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 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,
Re: dhcp6 and fqdn support (for dns)
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. -- Jiri ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
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. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
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 Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/15/2012 10:13 AM, Gene Czarcinski wrote: I am trying to set up an IPv6 virtual network using dnsmasq to support the dhcp and dns. Recently (the last couple of releases) dnsmasq has supported dhcp with updating dns. I have gotten it so that the IPv6 addresses are assigned correctly but I have been driving myself nuts trying to figure out why it does not update the dns with the IPv6 address. I have come to the conclusion that it is because NetworkManager does not send the fqdn. I am not sure if fqdn is required or if the hostname would be OK. However, in looking at some of the dhcp documentation for options, it appears that fqdn should be specified and not just the hostname. Before I turn in some bug reports and look at the code, is my understanding correct? I have done some additional testing. I suspected that something was missing from the NetworkMananger support for IPv6 dhcp. Here is what I did the prove it. 1. Stop NetworkManager. 2. Make sure that the ifcfg-eth0 file has DHCP_HOSTNAME== and DHCPV6C=yes are specified. 3. Slightly modify the ifup-eth network script to change the -H to -F on the dhclient -6 line. 4. do ifup eth0 5 Use wireshark (or equivalent) to trace the packets on the interface. See that fqdn info is being passed whereas it was not when NetworkManager did everything. 6. With dnsmasq I now have IPv6 addresses added to the dns. In examining various documents but not doing any testing, I believe that dhcpd-v6 will need to info to support dynamic dns updating for IPv6 addresses. 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. OK, bug or feature? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dhcp6 and fqdn support (for dns)
I am trying to set up an IPv6 virtual network using dnsmasq to support the dhcp and dns. Recently (the last couple of releases) dnsmasq has supported dhcp with updating dns. I have gotten it so that the IPv6 addresses are assigned correctly but I have been driving myself nuts trying to figure out why it does not update the dns with the IPv6 address. I have come to the conclusion that it is because NetworkManager does not send the fqdn. I am not sure if fqdn is required or if the hostname would be OK. However, in looking at some of the dhcp documentation for options, it appears that fqdn should be specified and not just the hostname. Before I turn in some bug reports and look at the code, is my understanding correct? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
