Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 28 Nov 2005 12:09:23 -0500

> 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:[email-masked]] 
> Sent: Monday, November 28, 2005 3:37 AM
> To: Bernie Volz (volz)
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2005 13:13:43 -0500

>>>>> "Bernie" == Bernie Volz (volz) <[email-masked]> writes:

    Bernie> For DHCPv6 servers, depending on policy (such as if it is
    Bernie> the only server or if there is a one address/client
    Bernie> policy) it may delete everything and add back those that
    Bernie> are current or may just do add/removes. It really all
    Bernie> depends on what the updater's policy is and whether it is
    Bernie> the only updater or not. I suspect that the DHCPv6 is more
    Bernie> likley to do adds/removes of individual RRs.

    Bernie> Do we really need to get into this level of specificity
    Bernie> around this?

You need to get sufficiently specific that in practice, the
implementation of this option is not influencing addressing plans.
For example if servers tend to get this wrong in a way that makes it
difficult for me to have multiple addresses for client then you were
not specific enough.

--Sam

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 29 Nov 2005 00:11:17 +0000

> difficult for me to have multiple addresses for client then you were

In practice, at least one implementation today will fail (logging an
error) if more than one A record on a given FQDN is present.

Will more specific text change that?

It's actually the current wording of the drafts that first imparted to
me the contrary, and the means to acheive that, and you might see a
future version of ISC DHCP moving in that direction as a consequence.

So, in my unreliable opinion, it's fine the way it is.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins