Re: [dhcwg] Trust model of Client FQDN option

Ted Lemon <> Wed, 04 August 2004 19:49 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA03671; Wed, 4 Aug 2004 15:49:07 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BsRh4-0007nU-8J; Wed, 04 Aug 2004 15:44:58 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BsRZb-0006U2-JE for; Wed, 04 Aug 2004 15:37:15 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA02777 for <>; Wed, 4 Aug 2004 15:37:13 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1BsRcv-0006yh-Qp for; Wed, 04 Aug 2004 15:40:43 -0400
Received: from [] ( []) by (Postfix) with ESMTP id AF56E1B22C7; Wed, 4 Aug 2004 14:36:14 -0500 (CDT)
In-Reply-To: <000201c47a4f$78a634e0$>
References: <000201c47a4f$78a634e0$>
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: Wed, 4 Aug 2004 12:37:10 -0700
To: "Bernie Volz" <>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
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 4, 2004, at 11:18 AM, Bernie Volz wrote:
> 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.

I would expect this to be a rather controversial statement, and I think 
we should leave it out.   It could be equally legitimately argued that 
if you give some entity a key to update a zone, you are trusting that 
entity not to do anything inappropriate with the key, and that if you 
do  not trust that entity, you should not have given it such a key.

I'm not saying either position is correct - they are both valid.   So 
asserting one over the other seems like a recipe for delay.

dhcwg mailing list