On Mon, 2007-12-03 at 18:37 +0100, Adam Tkac wrote: > On Mon, Dec 03, 2007 at 12:20:58PM -0500, Paul Wouters wrote: > > On Mon, 3 Dec 2007, Adam Tkac wrote: > > > > > For clarify what exactly discussed feature did (nothing more). When you get > > > nameservers from DHCP dhcdbd tells to named through DBUS that named > > > should use them as forwarders and NetworkManager sets 127.0.0.1 as > > > default nameserver in resolv.conf. So you could use named as > > > caching-nameserver on laptops and you don't have to edit named.conf > > > always when you move to different network. I think it makes sence add > > > this feature to some light DNS server but not into named. It's simply > > > too heavy-weight solution. > > > > But if you are running DNSSEC on your local laptop, and the network only > > allows dns to their forwarding nameservers, it is quite useful.... > > Yes, DNSSEC. I thought that someone come here with this argument. Current > situation is bad. When dhcdbd package doesn't exist someone has to write > support on NetworkManager side (not sure how much work it needs but from > discussion with NM people it needs some development) and I (or someone > else) have to write support into named nearly from scratch. I'm ready > to do it on named side and try put it to upstream (or keep it downstream). > Not sure what Dan Williams (or someone else from NM) thinks about this. NM is going to have to export the DHCP information in any case; the best option is a pull model where clients can query NM for the DHCP information they want based on what the current connection is. In the future, connections may span devices due to bonding/bridging/connection-sharing or whatever, and the connection is the thing that gets brought up, not the interface. And since DNS information is global to the machine (not specific to the interface but can be tweaked based on _routes_) this requires that programs that want to know about the DHCP information will need to ask first for the list of active connections, and second for the DHCP information (if any!) associated with that connection. When NM gets multiple active device support, there may be more than one active connection, and each connection may have DHCP information. Not sure how named would want to handle those cases. Dan > > > > > Also upstream will never accept such feature > > > because this is not primary BIND mission. Domain name modification > > > should be done with nsupdate utility through DDNS update message which > > > is part of DNS protocol. > > > > But I don't think nsupdate can modify the forwarders configured right? > > > > Yes you're right. I point that idea about configuring DNS RRs through > D-Bus is completely wrong. > > Adam > > -- > Adam Tkac, Red Hat, Inc. > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list