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-----
- Re: [dnsext] DNAME YXDOMAIN validation W.C.A. Wijngaards
- [dnsext] DNAME YXDOMAIN validation George Barwood
- Re: [dnsext] DNAME YXDOMAIN validation George Barwood