Re: Late to the party - multiple search domains on the network.

Jason Vas Dias wrote:

I forsee a problem with the "all options" calls: I think that setting the "requested options" in a DHCP request to "everything" could easily result in a reply which overflows a DHCP packet (they are only 500 bytes or so) It might be better just to have the "get single option" methods, and generate DHCPINFORM queries to get the values of options from the DHCP server as and when needed.

It is not intended to modify the DHCP-Server <-> DHCP-Client protocol at all.

The existing ISC dhclient will be used. dhclient encodes all options
into the environment of the program it executes with the '-s' option
to perform configuration actions on each state change.

The DHCP protocol includes a set of "requested options" which the client sends to the server in each packet: the server then returns any values it knows for those options in each reply. You can't list every possible one of those options in the DHCPREQUEST/DHCPACK interaction, the answers would overflow the packet size. Dhclient must decide (or be told) which subset of options to ask for. It's possible to get round this by sending DHCPINFORM requests after configuration is complete. These don't do any address configuration, they just allow the client to ask for another set of options (they also allow a client which got an address not from DHCP to ask for options).

My point is that if you limit the methods for getting options to "get the value of _this_ option" and don't include "get the values of all known options" then the "get the value for this option" method can map onto a DHCPINFORM request from the DHCP client to the DHCP server.

Please could I see that as soon as you feel happy to release it? I'm currently struggling with the DBUS API (or rather the docs, incomplete, out of date, yadda yadda) so ready done code that implements a defined DBUS interface would really help me.

Yes, I found it so, too. I'll be submitting the code to FC4 by the end
of this week - I'll copy you on the email when I do so.

Many thanks.

Again, given that code I should be able to produce a revision of dnsmasq to do the same job in fairly short order.

Yes, but I think ISC BIND has had far more extensive testing, and
includes far more features, such as DNSSEC and IPv6 support, than
dnsmasq. We don't want to ship multiple code sets that do the same job, and we want to ship code to do a given job that has had the most testing and is the most performant and feature-rich.

I'll point out that dnsmasq has IPv6 support and enough DNSSEC support to avoid "getting in the way" whilst forwarding secure requests and replies, and then climb down from my hobby horse. :-)

Running a NetworkManager based system should not restrict what you can
do with the system, ie. you should be able to provide a full featured
DNS server as well as support dynamic configuration of name resolution
with DHCP (current resolver / resolv.conf + named capabilities).

Also I think moving towards hot-configuration of BIND with a D-BUS configuration interface is the right way to go for BIND, which is burdened by an over-complex text-based configuration file.

Can't argue with that.

Do you think ISC will take your patches back upstream?



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