RE: [dhcwg] Trust model of Client FQDN option

"Bernie Volz" <> Wed, 04 August 2004 18:42 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA27612; Wed, 4 Aug 2004 14:42:18 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1BsQQN-0005Rp-3H; Wed, 04 Aug 2004 14:23:39 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1BsQKo-0004Hr-7b for; Wed, 04 Aug 2004 14:17:54 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA25485 for <>; Wed, 4 Aug 2004 14:17:52 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.33) id 1BsQO7-0005GQ-Pf for; Wed, 04 Aug 2004 14:21:21 -0400
Received: from ( by with ESMTP; 04 Aug 2004 11:19:05 -0700
X-BrightmailFiltered: true
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id i74IHGSK013153; Wed, 4 Aug 2004 11:17:17 -0700 (PDT)
Received: from volzw2k ( []) by (MOS 3.4.6-GR) with ESMTP id AKP42380; Wed, 4 Aug 2004 14:17:16 -0400 (EDT)
From: "Bernie Volz" <>
To: "'Ted Lemon'" <>
Subject: RE: [dhcwg] Trust model of Client FQDN option
Date: Wed, 4 Aug 2004 14:18:41 -0400
Organization: Cisco
Message-ID: <000201c47a4f$78a634e0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

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 [] 
> Sent: Wednesday, August 04, 2004 1:43 PM
> To: Bernie Volz
> Cc: <>
> 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, 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 "".   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