Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals

Edward Lewis <Ed.Lewis@neustar.biz> Thu, 31 March 2011 16:08 UTC

Return-Path: <Ed.Lewis@neustar.biz>
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 65E7628C118 for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 09:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.87
X-Spam-Level:
X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 hMxFLXsiF1wY for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 09:08:04 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 2FF6D3A6B3C for <dnsext@ietf.org>; Thu, 31 Mar 2011 09:08:04 -0700 (PDT)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2VG9gjM088749; Thu, 31 Mar 2011 12:09:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.112] by Work-Laptop-2.local (PGP Universal service); Thu, 31 Mar 2011 12:09:43 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 31 Mar 2011 12:09:43 -0400
Mime-Version: 1.0
Message-Id: <a06240800c9ba512398a2@[10.31.200.112]>
In-Reply-To: <alpine.LSU.2.00.1103311525350.5244@hermes-1.csi.cam.ac.uk>
References: <AANLkTimCZVyag8+Pv8zJsah2B-C=h3bPJ=DNVVo3agLc@mail.gmail.com> <34319.1301351478@nsa.vix.com> <BANLkTikkx4ndK3TpByptuRdtPGuFztm2yA@mail.gmail.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <a06240806c9b7b2040e80@10.31.200.119> <95465.1301414968@nsa.vix.com> <a06240807c9b7b5a6e892@10.31.200.119> <82vcz0n7a4.fsf@mid.bfk.de> <a06240800c9b93e602208@10.31.200.115> <1330.1301525305@nsa.vix.com> <AANLkTinurOKv61WOdwu4XtFHkzp2FzX5b2kFwazqRPHE@mail.gmail.com> <alpine.LSU.2.00.1103311525350.5244@hermes-1.csi.cam.ac.uk>
Date: Thu, 31 Mar 2011 12:07:45 -0400
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: ed.lewis@neustar.biz
Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals
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: Thu, 31 Mar 2011 16:08:05 -0000

At 15:27 +0100 3/31/11, Tony Finch wrote:
>Colm MacCárthaigh <colm@allcosts.net> wrote:
>>
>>  My vote would be for;
>>
>>    Recommending that authoritative servers implementing DNSSEC SHOULD
>>  NOT return NXDOMAIN for non-terminal labels.
>
>I believe that requirement already exists as a MUST NOT.

Although I agree that sending a NXDOMAIN for an 
empty non-terminal is a protocol error[0], I'll 
note that in the resimprove document it says:

# This is due to an ambiguity in RFC 1034 that failed to distinguish
# empty nonterminal domain names from nonexistent names.

To convert "I believe" to something more 
fact-based, it would be helpful if the ambiguity 
were identified.

[0] from this in RFC 1034, section 4.3.2:

# 3. Start matching down, label by label, in the zone.  The
#      matching process can terminate several ways:
#
#         a. If the whole of QNAME is matched, we have found the
#           node.

That is, the name/node exists, whether it has a type match remains to be seen.

#           ...skipping CNAME stuff...
#
#           Otherwise, copy all RRs which match QTYPE into the
#           answer section and go to step 6.

If there are no RRs to match (and empty 
non-terminal), none match, hence no data is put 
into the answer section.

On the other hand, of the name isn't there, here 
is the instruction for Name Error (aka NXDOMAIN):

#         c. If at some label, a match is impossible (i.e., the
#            corresponding label does not exist), look to see if a
#            the "*" label exists.
#
#            If the "*" label does not exist, check whether the name
#            we are looking for is the original QNAME in the query
#            or a name we have followed due to a CNAME.  If the name
#            is original, set an authoritative name error in the
#            response and exit.  Otherwise just exit.

RFC 2308, section 2.1 shows NXDOMAINs where the 
name is not original.  Reducing the logic that 
would mean the above reads as:

              If the "*" label does not exist, set an authoritative name
              error in the response and exit.  Otherwise just exit.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"