> This does not address the scenario where a host has multiple AAAA > records and the DHCPv6 server is performing the updates -- and hence > ends up deleting all except one record, right? > > In that case, the DHCP(v6) server should possibly refuse to do any > forward DNS updates because it might end up deleting something it > should not. You can have DHCPv4 servers such as those likely in wide deployment today that assume one address per client and thus remove anything that's there already. This works well even when a host moves between networks (as the DHCP client will interact with the server whenever it connects to a network). Ideally, when DHCPv6 (IPv6) is added, the DHCPv4 servers would ideally not touch the AAAA records when updating A records -- they'd just remove all A RRs and add the current. For DHCPv6 servers, depending on policy (such as if it is the only server or if there is a one address/client policy) it may delete everything and add back those that are current or may just do add/removes. It really all depends on what the updater's policy is and whether it is the only updater or not. I suspect that the DHCPv6 is more likley to do adds/removes of individual RRs. Do we really need to get into this level of specificity around this? - Bernie > -----Original Message----- > From: Pekka Savola [mailto:pekkas@xxxxxxxxxx] > Sent: Monday, November 28, 2005 3:37 AM > To: Bernie Volz (volz) > Cc: iesg@xxxxxxxx; dhcwg@xxxxxxxx; ietf@xxxxxxxx > Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: > 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed > Standard] > > On Sun, 27 Nov 2005, Bernie Volz (volz) wrote: > > Regarding your one major issue, the updater is NOT the > entity that gets > > to decide whether to allow any DNS update to occur or not. > It is the DNS > > server that restricts who can do updates and what they can update. > > > > We're assuming that the most likely entity to be given fairly open > > access to a zone is the DHCP server and that is where the > administrative > > policy comes in. > > I'm sure the zone administrators would like to have policy > controls of > their own. But as you say above, the assumption is that the DHCP > server can be given "fairly open access" to the zone. In most cases > this might imply (taking BIND9 as an example) "allow-update" > from DHCP > servers and "update-policy self" from hosts themselves. > > Because DHCP server is assumed to be given fairly liberal access at > least in some scenarios, I believe it's justified to be more open > about the threats of having too open policy and discouraging against > a particular update scenario. > > ... > >> ==> how does the code know whether the updates only desires a > >> single IP address on the FQDN or not? AFAICS, there's no way to > >> signal this from the DHCP client! > > > > Agreed. That is why the language is the way it is. As a > DHCP server is > > likely to be doing the updates, it would be the entity to > implement the > > policy. In most DHCPv4 environments today, it is just a > single A record > > that is allowed. > > > > If the client is doing the updates, it is aware of what it has and > > therefore can do the correct thing. > > This does not address the scenario where a host has multiple AAAA > records and the DHCPv6 server is performing the updates -- and hence > ends up deleting all except one record, right? > > In that case, the DHCP(v6) server should possibly refuse to do any > forward DNS updates because it might end up deleting something it > should not. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf