Re: [dnsext] DNAME YXDOMAIN validation

"W.C.A. Wijngaards" <wouter@NLnetLabs.nl> Mon, 16 May 2011 08:51 UTC

Return-Path: <wouter@nlnetlabs.nl>
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 A1BE0E0763 for <dnsext@ietfa.amsl.com>; Mon, 16 May 2011 01:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 XrRvuMHsY3a5 for <dnsext@ietfa.amsl.com>; Mon, 16 May 2011 01:51:09 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E8E073A for <dnsext@ietf.org>; Mon, 16 May 2011 01:51:08 -0700 (PDT)
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p4G8p4VK016686 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Mon, 16 May 2011 10:51:05 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl)
Message-ID: <4DD0E578.1020207@nlnetlabs.nl>
Date: Mon, 16 May 2011 10:51:04 +0200
From: "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: dnsext@ietf.org
References: <22823BCF8255413FBF76D4DF5D519471@local>
In-Reply-To: <22823BCF8255413FBF76D4DF5D519471@local>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 16 May 2011 10:51:05 +0200 (CEST)
Subject: Re: [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 08:51:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi George,

On 05/16/2011 08:14 AM, George Barwood wrote:
> What are the requirements on resolvers for validating DNAME YXDOMAIN responses?

There are no requirements.  Because there is no text in RFC2672 or -bis.

> 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.

Yes.

> 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.

I thought it would be good to include the DNAME (I believe the authority
servers already include the DNAME for YXDOMAIN responses, so the
signature (when appropriate, DO flag, signed zone) is not a lot of
work), just because you can.

> 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.

Yes, there does not seem to be a great deal of utility for validating
the YXDOMAIN.  It is nice that there is some sort of proof for the RCODE
(since for many other RCODEs no proof is possible, and considering the
length of effort we took to prove NXDOMAINs).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN0OV4AAoJEJ9vHC1+BF+NC7sP/1f62TjtCcT/6myJNazWFium
ONfeQwx25kD3fg7PHAOeiFl02KqiLNdehg3W+DuovK9m7la4SC2x5hGkYl1aJxZK
yXF2zPL7zTELhWd2nlrtQHc7KXn+8M9XE8GcHn2jge2wu628Ecch4Yd9tq9caArZ
tAcsSpRj4hte1XSw9V3HT9QwBvyUvZm1mbkz4aVdk4ACxsILlCKMV8wCsI6d65xz
en4NS1ISGHgCX1RW0D9jBYbFb7CbVCoih35skMkIvznmkYB3VPguCefAUg/CtkVo
fSRtJ/skwOxB1Z6P0ojBkrKUWPJJl90dqAgIN59QqBhgxS3SaoSFK7ssfR7eCKar
/pZMYi4XFKqI0lwa59g8ykhms3Q7lpANazNZE0IacN5Nf2nzaasVQMx7l3nbsaDd
oUuSG4DAIKRJuG6T7VRGq25DYHnFi0wJgdkozRMyVEhn0tEeg9Xj1Ned9bs8/zm0
XPieIDiY6m6mlR7G8xgeft/038QtY6ljBLBn0hNc3f+0WCa6f/1zVcYBgrO7n0Hq
MMKiDbUB2fYnt35SwjYz4y3Ot6tmPMR53+9HLfYT2EUj7TGSyAZEyS1tpDJIeDRG
aSw3PKKBwFCbFnKP8RjOpKrKO83y29wYhpj37T8cssnno6xneCRn7OHjJjmF/mK8
1M2WsrAM/DZMziCx7xOg
=tGwd
-----END PGP SIGNATURE-----