ietf@ietf.org
[Top] [All Lists]

RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN

Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
From: Pekka Savola
Date: Mon, 28 Nov 2005 10:36:34 +0200 EET
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>