[dnsext] Insecure referrals : should SOA be sent

"George Barwood" <george.barwood@blueyonder.co.uk> Mon, 11 April 2011 19:27 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 784433A6B35 for <dnsext@core3.amsl.com>; Mon, 11 Apr 2011 12:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.112
X-Spam-Level: *
X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_50=0.001, 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 ioLjTCQ3QNLU for <dnsext@core3.amsl.com>; Mon, 11 Apr 2011 12:27:52 -0700 (PDT)
Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by core3.amsl.com (Postfix) with ESMTP id 12D3B3A6B2F for <dnsext@ietf.org>; Mon, 11 Apr 2011 12:27:38 -0700 (PDT)
Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.4]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110411192733.QENU6199.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for <dnsext@ietf.org>; Mon, 11 Apr 2011 20:27:33 +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 1Q9Mlp-0003VW-17 for dnsext@ietf.org; Mon, 11 Apr 2011 20:27:33 +0100
Message-ID: <FB02D4E4170545D39D6AAADD306828D7@local>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: dnsext@ietf.org
Date: Mon, 11 Apr 2011 20:30:40 +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=OH-eE5XoA1IA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=5l99PD-s77Lk2urnsKQA:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Subject: [dnsext] Insecure referrals : should SOA be sent
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: Mon, 11 Apr 2011 19:27:53 -0000

http://tools.ietf.org/html/rfc4035#section-3.1.4

says

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR that proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

( Olafur : Note the constraint on the ordering, re your recent bis clarifications question )

My question is this : shouldn't the SOA also be sent. If not, the non-existence information
cannot be fully cached for downstream resolvers, and an extra query will be needed to get
the full DS non-existence response (with SOA) if a client asks for the DS RRset.

Either that, or clients could use just the TTL of the NSEC records for the negative caching TTL.
The TTL of this non-existence is in any case not clear (to me) from the current text.

George