Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals

"George Barwood" <george.barwood@blueyonder.co.uk> Tue, 29 March 2011 14:02 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 CB78D3A682D for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 07:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.068
X-Spam-Level:
X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753]
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 xK-GrQrQ0Ccb for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 07:02:03 -0700 (PDT)
Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by core3.amsl.com (Postfix) with ESMTP id 9297B3A693E for <dnsext@ietf.org>; Tue, 29 Mar 2011 07:02:02 -0700 (PDT)
Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.4]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110329140334.WCLS13167.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Tue, 29 Mar 2011 15:03:34 +0100
Received: from [92.238.99.235] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from <george.barwood@blueyonder.co.uk>) id 1Q4ZWA-0004Py-5e; Tue, 29 Mar 2011 15:03:34 +0100
Message-ID: <FCB25297BFF0419692724D36AF3BC99E@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: dnsext@ietf.org, Edward Lewis <Ed.Lewis@neustar.biz>
References: <alpine.LSU.2.00.1103281507410.5244@hermes-1.csi.cam.ac.uk><8EA8D1A36B8F4968ABE973C39CA5E0E0@local> <a06240800c9b78d52751f@[10.31.200.116]>
Date: Tue, 29 Mar 2011 15:03:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
X-Cloudmark-Analysis: v=1.1 cv=JvdXmxIgLJv2/GthKqHpGJEEHukvLcvELVXUanXFreg= c=1 sm=0 a=WnkCSP1BjtsA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=CIE4dlYyxOFyP2u2CAIA:9 a=3VXdAdOfH_TkwBtwIJoF9vaM0-UA:4 a=wPNLvfGTeEIA:10 a=Fw9EzWXUJMYA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Cc: ed.lewis@neustar.biz
Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-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: Tue, 29 Mar 2011 14:02:03 -0000

----- Original Message ----- 
From: "Edward Lewis" <Ed.Lewis@neustar.biz>
To: <dnsext@ietf.org>
Cc: <ed.lewis@neustar.biz>
Sent: Tuesday, March 29, 2011 2:27 PM
Subject: Re: [dnsext] draft-vixie-dnsext-resimprove - NXDOMAIN for emptynon-terminals


> At 22:29 +0100 3/28/11, George Barwood wrote:
> 
>>I'd also like to see the standard updated to allow resolvers to infer
>>NoData conditions from NSEC/NSEC3 records ( the standard does not exactly
>>forbid this at present, but there is discouraging language ).
> 
> http://www.ietf.org/mail-archive/web/dnsext/current/msg10820.html
> 
> One motivation is to pursue "tricks" like RFC 4470 but applied to the 
> type bitmap.  A signer may decide not to include all types in the 
> NSEC it hands out.  Or the answering server will be synthesizing the 
> answer dependent on the query.

If a signer or server does this, all security is lost, because an attacker can use
the incomplete NSEC records to deny the existence of RRsets.

So allowing this (standard breaking) possibility does not seem at all useful.

What is the motive for this "trick"? Saving bandwidth??

George

> By enlarging the role of caches, the authoritative server choices are shrunk.