[dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18]

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 07 May 2012 17:53 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C8321F8639; Mon, 7 May 2012 10:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1336413206; bh=q1Iw6UifAEsBb0F3Mado0p8r23gGzAggkmdxcxC9DwI=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=F5Ai/YrPczMGPTgNTis0OPIURB5yGQdIaqf5bAPMVaCBNjCWXJPNMcbvSu4SkE/Gk uun623xp9tyg5FIqiU5k0gLIq511vLVLIQFusXQP6YORsAeWnfiXZdYZTh7YatD0Lq CcYaVea97kZzTXjkR8DWofIEcBTNtn5V1AZ7R/5U=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E1021F8639 for <dnsext@ietfa.amsl.com>; Mon, 7 May 2012 10:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level:
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7spU5-Cr0fC for <dnsext@ietfa.amsl.com>; Mon, 7 May 2012 10:53:21 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C5E5621F8638 for <dnsext@ietf.org>; Mon, 7 May 2012 10:53:21 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 188EF1ECB41D for <dnsext@ietf.org>; Mon, 7 May 2012 17:53:21 +0000 (UTC)
Date: Mon, 07 May 2012 13:53:18 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsext@ietf.org
Message-ID: <20120507175312.GL8963@mail.yitter.info>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [dnsext] [reed@reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18]
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

Forwarded as suggested.  I think the draft name is misspelled.

A

----- Forwarded message from "Jeremy C. Reed" <reed@reedmedia.net> -----

Date: Mon, 7 May 2012 11:21:20 -0500 (CDT)
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: ajs@anvilwalrusden.com
Subject: comments on draft-weiler-dnsext-dnssec-bis-updates 18

The following are my comments on 
draft-weiler-dnsext-dnssec-bis-updates-18.  You may forward my comments 
or reply on list as desired.


4.3.  Check for CNAME

   Section 5 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs. 

* The wording above is confusing or misleading. RFC 4035 Section 5 says 
nothing about CNAME specifically.


5.3.  Private Algorithms

...

   In the remaining cases, the security status of the zone depends on
   whether or not the resolver supports any of the private algorithms in
   use (provided that these DS records use supported hash functions, as
   discussed in Section 5.2).

* This may be confusing since the draft's section 5.2 matches up with 
numbering of RFC 4035's Section 5.2 and the draft's 5.2 does not use the 
terminology "hash functions".


5.6.  Setting the DO Bit on Replies

* Mention is is Section 3.


5.7.  Setting the AD Bit on Queries

The use of the AD bit in the query was previously undefined.

* It was defined for queries. See RFC 4035 4.6: ``A security-aware 
resolver MUST clear the AD bit when composing query messages to protect 
against buggy name servers that blindly copy header bits that they do 
not understand from the query message to the response message.''


6.1.  Finding Zone Cuts

* What are the "special rules" and "special processing rules"?  The 
wording is unclear if these are the rules defined in RFC 4035 3.1.4.1 or 
if they are new special rules.  In other words, what is the minor 
correction or clarification here?


Appendix B.  Discussion of Setting the CD Bit

* Maybe mention "(server failure)" in first mention of RCODE=2.


* Also be consistent with referring to RFC numbers, maybe always use 
brackets around them every time.




----- End forwarded message -----

-- 
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext