RE: [dhcwg] Trust model of Client FQDN option

And, we probably should add a 4th point ... If a DNS server allows dynamic
DNS updates, it is the final authority of what it allows to be added,
removed, or modified in a zone and should have properly configured policies
to prohibit operations that are not intended. Simply assuming that any
update from a trusted source (such as a DHCP server with a valid TSIG key)
should be performed is likely not acceptable.

- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@fugue.com] 
> Sent: Wednesday, August 04, 2004 1:43 PM
> To: Bernie Volz
> Cc: <dhcwg@ietf.org>
> Subject: Re: [dhcwg] Trust model of Client FQDN option
> 
> 
> On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote:
> > -> If the query returns NODATA, the updater can conclude that the
> > target
> > -> name is in use, but that no DHCID RR is present.  This indicates
> > that
> > -> some records have been configured by an administrator.  
> Whether the 
> > -> updater proceeds with an update is a matter of local 
> administrative 
> > -> policy.
> 
> Hm, this is interesting.   As a point of information, the two 
> implementations with which I am familiar do not give the 
> administrator 
> a knob to tweak here.  We just assume that if the name is in the DNS 
> and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on 
> it.
> 
> I think a stronger statement here might be better:
> 
> Whether the updater proceeds with an update is a matter of local 
> administrative policy.   DHCP servers MUST NOT proceed with 
> the update 
> unless explicitly configured to do so.
> 
> The draft should talk about these two issues in the security 
> considerations section, and the FQDN drafts should mention in the 
> security considerations section that these security 
> considerations are 
> addressed in the resolution draft.   I don't think we can make any 
> requirements to address this, but the answers we came up with in 
> response to Pekka's query could reasonably go into the security 
> considerations section of one or all of the drafts:
> 
> 1. If the DHCP server does updates, there is no way to prevent one 
> client from getting a name after another client had it, but that 
> client's lease expired.
> 
> 2. If the DHCP server does updates, it will be possible for DHCP 
> clients to request names that might have special meaning, like www or 
> wwww.   This can be handled in one of two ways:
>    a. Use a special zone for dynamic names, so that it doesn't
>       matter that the client gets www.dyndns.bigcompany.org, or
>    b. If the DHCP server provides this capability, set up a
>       filter on the DHCP server that prevents certain names from
>       being claimed by clients, even if they do not currently
>       appear in the DNS.
> 
> 3. If the DHCP server does updates, and is allowed to override names 
> that do not have DHCID records, this can mean that a client 
> will get a 
> name that is already registered for some purpose in the DNS.   This 
> behavior is required to be disabled by default, so it should not be a 
> problem in practice, but we mention it here to raise awareness of the 
> implications of configuring your DHCP server to allow it.
> 
> Hm, one other problem that occurs to me is that a client could send 
> something like "www.students" in the fqdn option, and this could turn 
> into "www.students.littlecollege.edu".   That is a vaguely 
> official-looking name.   So any filtering that needs doing based on 
> specific reserved names like "www" needs to be on the first label in 
> the name, not on the entire name.
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg