Re: [dnsext] Reminder: two WGLC closing in one week
Michael StJohns <mstjohns@comcast.net> Tue, 23 September 2008 04:47 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6AF3A6AC8; Mon, 22 Sep 2008 21:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awTThl1HNypG; Mon, 22 Sep 2008 21:47:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC6D83A68AB; Mon, 22 Sep 2008 21:47:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Khzea-000Bob-2Y for namedroppers-data@psg.com; Tue, 23 Sep 2008 04:37:36 +0000
Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1KhzeO-000BnV-G0 for namedroppers@ops.ietf.org; Tue, 23 Sep 2008 04:37:33 +0000
Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA04.westchester.pa.mail.comcast.net with comcast id J1cD1a03o0QuhwU544dPPa; Tue, 23 Sep 2008 04:37:23 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA02.westchester.pa.mail.comcast.net with comcast id J4cs1a0092P9w053N4csAF; Tue, 23 Sep 2008 04:36:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=gwu2n-TYGH0A:10 a=YzQq6kKhkNwA:10 a=-00ntuNjTI1CNvlMxtcA:9 a=Cg-jgozk8NH_k2Xc4WsA:7 a=MYp2CI7HHL03vZpmsQi2QIra4AIA:4 a=lv1_I0N3rasA:10 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 23 Sep 2008 00:37:21 -0400
To: Mark Andrews <Mark_Andrews@isc.org>
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: [dnsext] Reminder: two WGLC closing in one week
Cc: Andrew Sullivan <ajs@commandprompt.com>, namedroppers@ops.ietf.org
In-Reply-To: <200809230309.m8N39Uwt073117@drugs.dv.isc.org>
References: <Your message of "Mon, 22 Sep 2008 22:52:10 -0400." <20080923025212.A378411402C@mx.isc.org> <200809230309.m8N39Uwt073117@drugs.dv.isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
Message-Id: <E1Khzea-000Bob-2Y@psg.com>
At 11:09 PM 9/22/2008, Mark Andrews wrote: >In message <20080923025212.A378411402C@mx.isc.org>, Michael StJohns writes: >> OK - so if the last chain validates, but the intermediate chain was unsecure, t >> hen you return the answer, but don't set the AD bit. If the last chain doesn't >> validate, you return what? The data without the AD bit, or RCODE 2/SERVFAIL? > > SERVFAIL. If they ask with cd=1 then they get the full answer. > >> (I.e.is it really possible to have data that's both bogus and unsecure?) > > A particulare RRset is falls into exactly one of secure, insecure or > bogus post validation. Right, but the answer is a mixture of three RRSets - one secure, one unknown and one bogus... which I guess makes the whole thing bogus and results in the return of RCODE 2. >> Is t >> here any reason to do validation for the third chain in my example once you've >> wandered over into unsecure land? > > Yes as you may be asked the later question. Fair enough. >> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for >> that matter) is your last conclusion stated as a specific protocol element? I >> just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to sa >> y this. The definition for "secure" in 4.3 only says to trace from the answer >> to a trust anchor. The definition for insecure *could* be read to say what you >> said, but then it would be in conflict with the definition for "secure". > > A security-aware name server MUST NOT set the AD bit in a response > unless the name server considers all RRsets in the Answer and > Authority sections of the response to be authentic. OK. I can go along with this reading - but I think I'm still not quite done. So the last question is what goes on when you have the same three queries - except the last one now validates, and the DO bit wasn't set from the stub resolver? (e.g, I won't understand the lack of AD bit) The simple answer would be to return the three RRSets - but is that the right approach or only one of several correct approaches? I could argue the paranoids point, that once the answer becomes secure, unless it becomes securely unsecure (by proving there's no DS at a delegation point), then the final answer must either be secure or bogus. In other words, if I get a referral via a CNAME or DNAME into unsecure space, then the final answer should be "bogus". The above is different than the secure delegation to an unsecure zone: The signed delegation to an unsigned zone is controllable by the delegator. The signed CNAME or DNAME referral to an zone carries no information about whether the referrer/signer believes the target zone/name should be signed. I'm trying to reconcile this with the general policies on how data is returned from a validating recursive resolver to a non-DNSSEC aware stub resolver. The VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bogus), and returns the data which has no superior trust anchor (unknown), returns the data it was able to validate (secure), and returns the data which was below an unsecure delegation point (unsecure). I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone from a secure zone is equivalent to an unsecure delegation from that secure zone to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC status at any time after the CNAME/DNAME is published. Unfortunately, I can't see any way of encoding the DNAME/CNAME signers expectation of security for the target zone in the current definitions. So if I follow the principal of "if it started out secure and I can't prove it was meant to be unsecure then it should be bogus if I can't validate it" which we follow for on-tree delegations, shouldn't I follow it for off-tree delegations? Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- [dnsext] Reminder: two WGLC closing in one week Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Scott Rose
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Edward Lewis
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Remind… Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Re… Edward Lewis
- [dnsext] recommeded contents for Re: DNAME (and C… Edward Lewis
- [dnsext] flip-flopping secure and unsecure DNAME/… Edward Lewis
- Re: [dnsext] recommeded contents for Re: DNAME (a… Scott Rose
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… John Dickinson
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Olafur Gudmundsson
- Re: [dnsext] flip-flopping secure and unsecure DN… Edward Lewis
- the DO bit Re: [dnsext] Reminder: two WGLC closin… Edward Lewis
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… bmanning
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… David Conrad
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Wouter Wijngaards
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- CNAME/DNAME - Re: [dnsext] flip-flopping secure a… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Shane Kerr
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Interpreting DNSSEC was Re: [dnsext] flip-floppin… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Wouter Wijngaards
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Stephane Bortzmeyer
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis