IETF Logo Mail Archive

Re: [dnsext] additional section processing for DNAME

JINMEI Tatuya / 神明達哉 <jinmei@isc.org> Tue, 11 January 2011 07:14 UTC

Return-Path: <jinmei@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB0D3A69B8 for <dnsext@core3.amsl.com>; Mon, 10 Jan 2011 23:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2]
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 kG5SgDL2Vk9y for <dnsext@core3.amsl.com>; Mon, 10 Jan 2011 23:14:55 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 0B2EB3A6884 for <dnsext@ietf.org>; Mon, 10 Jan 2011 23:14:55 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 434C1C941E; Tue, 11 Jan 2011 07:17:01 +0000 (UTC) (envelope-from jinmei@isc.org)
Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EE1F1216C3B; Tue, 11 Jan 2011 07:17:00 +0000 (UTC) (envelope-from jinmei@isc.org)
Date: Mon, 10 Jan 2011 23:16:32 -0800
Message-ID: <m2fwsz29m7.wl%jinmei@isc.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isc.org>
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06240800c9510b2218ce@[10.31.200.129]>
References: <m2zkrc1f2u.wl%jinmei@isc.org> <a06240800c9510b2218ce@[10.31.200.129]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Cc: scottr.nist@gmail.com, dnsext@ietf.org
Subject: Re: [dnsext] additional section processing for DNAME
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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>
X-List-Received-Date: Tue, 11 Jan 2011 07:14:56 -0000

At Mon, 10 Jan 2011 14:20:10 -0500,
Edward Lewis <Ed.Lewis@neustar.biz> wrote:

> >(p.s. I spent some time of googling to find the answer myself, and I
> >noticed this change was introduced in rev 15 of this document around
> >when there was a WG last call.  So I suspect this is a response to a
> >last call comment, but I couldn't find the relevant discussion.
> >Hence this question, at the risk of asking something twice at the same
> >place)
> 
> I'm still puzzled by the question, especially the reference to a 
> change "in rev 15".  RFC 2672 has "The DNAME RR causes type NS 
> additional section processing."  Only the location of that comment 
> has changed in the 22 versions of 2672bis.
> 
> Is the original question "what's the significance/usefulness of the 
> glue records in a DNAME-involved response?"  Does the question apply 
> against the original RFC too, or to something that has been changed 
> in the draft?

Ah, sorry for the confusing question.  It applies to the original
RFC2672, too.  Actually I first had the question when I (re)read
Section 3 of RFC2672:

   The DNAME RR causes type NS additional section processing.

So I next checked the latest revision of the bis draft
(rfc2672bis-dname-21) and found:

   The DNAME RR causes type NS additional section processing.  This
   refers to action at step 6 of the server algorithm outlined in
   section 3.2.

Since it was changed from the original RFC, I thought it was a result
of an attempt of clarifying the original text, but it was still
unclear to me (as I said in my original question message).  So I next
searched draft archives to identify when exactly the change was
introduced.  It was revision 15:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-dnsext-rfc2672bis-dname-14&difftype=--html&submit=Go!&url2=draft-ietf-dnsext-rfc2672bis-dname-15

But I still failed to understand the sense of the change, and what
"type NS additional section processing" means wasn't still clear to
me.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

v2.23.0 | Report a Bug | By Email