IETF Logo Mail Archive

Re: [dnsext] RFC 6604 Clarification

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 31 March 2015 22:38 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85081A017F for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 15:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIaq4w-332KI for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 15:38:50 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474041A066B for <dnsext@ietf.org>; Tue, 31 Mar 2015 15:38:50 -0700 (PDT)
Received: by ignm3 with SMTP id m3so20982621ign.0 for <dnsext@ietf.org>; Tue, 31 Mar 2015 15:38:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qzh6B3wwo5SQDeClUHySBGpjN16s48chgXF7ih0erPw=; b=Q7ciyueBRyHvAb6kx2M6YDSucuKWSFFb0El8rnqlvRKOO973+/5PuywUUtE8+O/hSa ie5TEu0JER2W4D9OPhlcbLb5D/pFOQeAAQm3KQR47UICz9EaXMkIqzXmPnj5At8jjZJP oqO4nxsbo+zVvAR6D71QAWyJ8eJcdnzcioHl7GZzOiPZN1M3t4lisbBQCI38KLh0WhsP Y6lsc86RiCPSaIR6wrcTVYutpU+qrwt2oU3SWPVdlu0sVh1VSVzljhJeQaen5xRf1w44 nvdAEcLtfcLpFy4BM8+lxD9j1oSoVR4wytZCqgiCgh1ZK7a3dFf7RKHHE8MTXNypY+ik Yb6A==
MIME-Version: 1.0
X-Received: by 10.107.13.136 with SMTP id 130mr21841522ion.70.1427841529801; Tue, 31 Mar 2015 15:38:49 -0700 (PDT)
Received: by 10.64.57.201 with HTTP; Tue, 31 Mar 2015 15:38:49 -0700 (PDT)
In-Reply-To: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net>
References: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net>
Date: Tue, 31 Mar 2015 15:38:49 -0700
Message-ID: <CAH1iCip9Xgh0n5PFt-kyZaMA3Z9D28E0Dr2Rbg5iV5bzHKPHng@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Kumar Ashutosh <Kumar.Ashutosh@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/qxcFClyZdvNQ4I1HcqWrPToIXFs>
Cc: DNSEXT Group Working <dnsext@ietf.org>
Subject: Re: [dnsext] RFC 6604 Clarification
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 31 Mar 2015 22:38:52 -0000

On Mon, Mar 30, 2015 at 2:04 AM, Kumar Ashutosh
<Kumar.Ashutosh@microsoft.com> wrote:
> Hi
>
> As per RFC 6604, section 3
>
>       When an xNAME chain is followed, all but the last query cycle
>
>       necessarily had no error.  The RCODE in the ultimate DNS response
>
>       MUST BE set based on the final query cycle leading to that
>
>       response.  If the xNAME chain was terminated by an error, it will
>
>       be that error code.  If the xNAME chain terminated without error,
>
>               it will be zero.

> 2. If the CNAME chain points to a Qname for which the auth server is
> non-authoritative (and recursion is disabled on the auth server.) The server
> in this case cannot get the response. A direct query for this Qname will
> result in SERV_FAIL. Should the auth server return SERV_FAIL in this case?
> Will resolvers respect answers with SERV_FAIL in RCODE and cache the partial
> response?

Just to clarify your question further:

A CNAME chain is normally processed ENTIRELY by the iterative
(recursive) resolver.
In the case of a given authority server being authoritative for the
domain name found on the right-hand-side of a CNAME, as an
optimization, it MAY provide the results of a re-started query using
that RHS value.

It can ONLY do that so long as it is authoritative. If it is not, it
simply returns the data it is authoritative for, with a NOERROR RCODE.

Pointing to a domain name that it is not authoritative for, is not an
error condition.

The iterative resolver would need to continue processing the rewritten
QNAME, by sending the rewritten query to whatever authority server is
authoritative for that new QNAME.

Sending the query to the previous auth server would be the wrong thing
to do. Even if such a query were received, the correct behavior is
NOERRROR, NODATA, with AA unset (set to zero).

If you are not sure you understand this, please ask any clarifying
questions you may have.

Please tell us that MS DNS does NOT do SERV_FAIL, or if it does, that
you are going to fix it. :-)

Brian

v2.23.0 | Report a Bug | By Email