Re: [dhcwg] Trust model of Client FQDN option

Ted Lemon <> Tue, 03 August 2004 22:30 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA18254; Tue, 3 Aug 2004 18:30:05 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1Bs7ie-0003RI-LF; Tue, 03 Aug 2004 18:25:16 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1Bs7cn-0002n7-Jd for; Tue, 03 Aug 2004 18:19:13 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA17700 for <>; Tue, 3 Aug 2004 18:19:10 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1Bs7ft-0002bv-WB for; Tue, 03 Aug 2004 18:22:29 -0400
Received: from [] ( []) by (Postfix) with ESMTP id ACA0B1B29EB; Tue, 3 Aug 2004 17:18:20 -0500 (CDT)
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <>
Subject: Re: [dhcwg] Trust model of Client FQDN option
Date: Tue, 3 Aug 2004 15:19:05 -0700
To: Pekka Savola <>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote:
> I'm not sure the v4 or v6 DHC FQDN client options address the problem
> of the trust model for the update content sufficiently well.  I'd even
> go as far to say that it might create a false sense of security.

Pekka, in the meeting this morning, you said you hadn't read the drafts 
having to do with DNS updates on DHCPv4.   Have you now read them?   
The reason I ask is that for the entire duration of the time I've been 
coming to IETF, people have occasionally raised the very same issue you 
are now raising.

The solution we have adopted, which is widely deployed, allows two 
answers to your question.   The first is a more paranoid solution that 
requires widespread distribution of individual DNS update keys.   The 
second is a more laissez-faire solution that does not require the 
distribution of individual DNS update keys.   This second solution is 
no more or less secure than the first, but its behavior is different.   
Names added by the DHCP server are marked as such, and if a name is 
present and was not added by the DHCP server, that name can't be 
replaced at the request of the DHCP client.   When a client's lease 
expires, another client can acquire the previous client's name, so 
there's no protection for client names.   You get to pick which 
solution to deploy, based on your willingness to distribute keys and 
based on whether or not you care whether a DHCP client can count on 
retaining its name, once its name is registered.

So this is a well-understood problem, with well-understood and widely 
deployed solutions.   You can see an example implementation in the ISC 
DHCP client and server if you're curious, and as far as I know every 
commercial DHCP server also implements this, and I know of quite a few 
sites that use it in practice.  Indeed, it's been deployed at IETF 
meetings in the past (not sure if it's running this time).

dhcwg mailing list