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(_at_)netcore(_dot_)fi]
Sent: Monday, November 28, 2005 3:37 AM
To: Bernie Volz (volz)
Cc: iesg(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf