Re: [dnsext] Reminder: two WGLC closing in one week

Michael StJohns <mstjohns@comcast.net> Tue, 23 September 2008 07:33 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 88E373A6C81; Tue, 23 Sep 2008 00:33:12 -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=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, 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 LBrb4BDNGNBn; Tue, 23 Sep 2008 00:33:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65CD93A6C66; Tue, 23 Sep 2008 00:33:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Ki2Fa-0003A7-A7 for namedroppers-data@psg.com; Tue, 23 Sep 2008 07:23:58 +0000
Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1Ki2FW-00039e-Sv for namedroppers@ops.ietf.org; Tue, 23 Sep 2008 07:23:56 +0000
Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id J7AC1a00G0EPchoA17PexX; Tue, 23 Sep 2008 07:23:38 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id J7Pq1a0062P9w058M7PrVo; Tue, 23 Sep 2008 07:23:54 +0000
X-Authority-Analysis: v=1.0 c=1 a=gwu2n-TYGH0A:10 a=YzQq6kKhkNwA:10 a=aYJz2LTxOLZ76KqD1VMA:9 a=87ZMfoOgLTUdp_SnH40A:7 a=V1FQinBjPOaRK4VKxsmwVBwXkM0A:4 a=h9s5Ru71U4oA:10 a=HqOtT4Tb9C66RVC1AX8A:9 a=7CKdzF66qC24mcoW0asA:7 a=dxQDhWdeQIVDUT98B0B4DqOOUtYA:4 a=37WNUvjkh6kA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 23 Sep 2008 03:23:48 -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: <200809230618.m8N6IXIU074687@drugs.dv.isc.org>
References: <Your message of "Tue, 23 Sep 2008 00:37:21 -0400." <E1Khzea-000Bob-2Y@psg.com> <200809230618.m8N6IXIU074687@drugs.dv.isc.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_638747484==.ALT"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
Message-Id: <E1Ki2Fa-0003A7-A7@psg.com>

At 02:18 AM 9/23/2008, Mark Andrews wrote:
>        No, it is NOT unkown.  It is insecure.  You are attempting to introduce
>        a state which does not exist.
>
>        secure -> passes validation
>        insecure -> no TA or there is a insecure delegation from a secure zone.
>        bogus -> fails validation

 From 4035...

   Secure: An RRset for which the resolver is able to build a chain of
      signed DNSKEY and DS RRs from a trusted security anchor to the
      RRset.  In this case, the RRset should be signed and is subject to
      signature validation, as described above.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.





Arends, et al.              Standards Track                    [Page 20]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   Bogus: An RRset for which the resolver believes that it ought to be
      able to establish a chain of trust but for which it is unable to
      do so, either due to signatures that for some reason fail to
      validate or due to missing data that the relevant DNSSEC RRs
      indicate should be present.  This case may indicate an attack but
      may also indicate a configuration error or some form of data
      corruption.

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.