RE: [dhcwg] Trust model of Client FQDN option
"Bernie Volz" <volz@cisco.com> Wed, 04 August 2004 17:34 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21604; Wed, 4 Aug 2004 13:34:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPUo-0002pY-S0; Wed, 04 Aug 2004 13:24:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsPNe-0001ag-MI for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 13:16:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20100 for <dhcwg@ietf.org>; Wed, 4 Aug 2004 13:16:43 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsPQy-0003xB-Qi for dhcwg@ietf.org; Wed, 04 Aug 2004 13:20:13 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 10:17:58 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i74HGCDZ019489; Wed, 4 Aug 2004 10:16:12 -0700 (PDT)
Received: from volzw2k (sjc-vpn3-189.cisco.com [10.21.64.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP36098; Wed, 4 Aug 2004 13:16:10 -0400 (EDT)
From: Bernie Volz <volz@cisco.com>
To: 'Pekka Savola' <pekkas@netcore.fi>
Subject: RE: [dhcwg] Trust model of Client FQDN option
Date: Wed, 04 Aug 2004 13:17:37 -0400
Organization: Cisco
Message-ID: <002101c47a46$f10e92a0$3f428182@amer.cisco.com>
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: <Pine.LNX.4.44.0408040551410.4392-100000@netcore.fi>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, 'Ted Lemon' <mellon@fugue.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Hi: Ok, perhaps that title of the draft isn't the greatest, but see section 6.3.1: 6.3.1 Initial DHCID RR Query When a DHCP client or server intends to update an A RR, it performs a DNS query with QNAME of the target name and with QTYPE of DHCID. If the query returns NXDOMAIN, the updater can conclude that the name is not in use and proceeds to Section 6.3.2. -> 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. Now, admittedly doesn't address the situation where there is no existing "www" name and a client comes along and requests to use that. If you have a better name suggestion for the draft, please let me know. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Tuesday, August 03, 2004 10:57 PM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Ted Lemon' > Subject: RE: [dhcwg] Trust model of Client FQDN option > > > On Tue, 3 Aug 2004, Bernie Volz wrote: > > Correct, this appears in > draft-ietf-dhc-ddns-resolution-07.txt. This > > draft is referenced in the "7. DNS Update Conflicts" > section of the > > FQDN draft. > > > > The resolution draft still needs additional work for DHCPv6 - it > > currently only applies to IPv4. > > This has some, but relatively little, to do with "Resolution > of DNS Name Conflicts among DHCP Clients", because the main > threat is that it doesn't conflict with another *DHCP client* > (though that's imaginable as well) but a manual entry (or > that it might not conflict at all, but just be something like > wwww.example.com (with one extra 'w'). > > In any case, I think this requires quite a bit more extensive > discussion (and appropriate pointers) in > draft-ietf-dhc-fqdn-option (which seems like the main draft > of this bundle) especially from the > *security* perspective. > > -- > 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 > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Trust model of Client FQDN option Pekka Savola
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- Re: [dhcwg] Trust model of Client FQDN option Pekka Savola
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Mark Stapp
- RE: [dhcwg] Trust model of Client FQDN option Pekka Savola
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon