[dnsext] DNAME YXDOMAIN validation

"George Barwood" <george.barwood@blueyonder.co.uk> Mon, 16 May 2011 06:15 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
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 37ECCE069B for <dnsext@ietfa.amsl.com>; Sun, 15 May 2011 23:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.454
X-Spam-Level:
X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7qXn9vTyw26 for <dnsext@ietfa.amsl.com>; Sun, 15 May 2011 23:15:40 -0700 (PDT)
Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by ietfa.amsl.com (Postfix) with ESMTP id BC746E0694 for <dnsext@ietf.org>; Sun, 15 May 2011 23:15:07 -0700 (PDT)
Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110516061506.PFQD16165.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for <dnsext@ietf.org>; Mon, 16 May 2011 07:15:06 +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 1QLr57-0003ic-U0 for dnsext@ietf.org; Mon, 16 May 2011 07:15:05 +0100
Message-ID: <22823BCF8255413FBF76D4DF5D519471@local>
From: "George Barwood" <george.barwood@blueyonder.co.uk>
To: <dnsext@ietf.org>
Date: Mon, 16 May 2011 07:14:59 +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.6090
X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=hlFdjzOTVvTjXkPpUgYA:9 a=7c4ZYOelPRfFOg5oreQA:7 a=wPNLvfGTeEIA:10 a=ZQ5fZReqlZkWP-jv:21 a=VkSF00tIekFM1gg2:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Subject: [dnsext] DNAME YXDOMAIN validation
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>
X-List-Received-Date: Mon, 16 May 2011 06:15:41 -0000

What are the requirements on resolvers for validating DNAME YXDOMAIN responses?

http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-22#section-5.3.1

says

  The domain name can get too long during substitution.  For example,
   suppose the target name of the DNAME RR is 250 octets in length
   (multiple labels), if an incoming QNAME that has a first label over 5
   octets in length, the result would be a name over 255 octets.  If
   this occurs the server returns an RCODE of YXDOMAIN [RFC2136].  The
   DNAME record and its signature (if the zone is signed) are included
   in the answer as proof for the YXDOMAIN (value 6) RCODE.

which implies that YXDOMAIN responses can be validated.

However, I'm wondering if this is actually useful, and simply clearing the AD
bit would be acceptable. i.e. "validators MAY validate YXDOMAIN responses" but no stronger.
Or maybe I'm wrong, and YXDOMAIN responses MUST be validated if possible, in which case I think
this would be best stated explicitly.

As an aside,  I may be mistaken, but it seems that both BIND and UNBOUND don't
currently handle YXDOMAIN responses, returning SERVERFAIL instead of YXDOMAIN. 
I think this is quite likely to be the behavior for legacy resolvers as well, maybe that could be noted.

George