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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf