Re: [dnsext] RFC 6604 Clarification

Kumar Ashutosh <Kumar.Ashutosh@microsoft.com> Fri, 03 April 2015 08:48 UTC

Return-Path: <Kumar.Ashutosh@microsoft.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 B797C1A1AA9 for <dnsext@ietfa.amsl.com>; Fri, 3 Apr 2015 01:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Gh9O0bjsN-cT for <dnsext@ietfa.amsl.com>; Fri, 3 Apr 2015 01:48:09 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D171A1A7C for <dnsext@ietf.org>; Fri, 3 Apr 2015 01:48:09 -0700 (PDT)
Received: from BY2PR03CA055.namprd03.prod.outlook.com (10.141.249.28) by CY1PR0301MB0649.namprd03.prod.outlook.com (25.160.158.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 3 Apr 2015 08:48:07 +0000
Received: from BN1BFFO11FD008.protection.gbl (2a01:111:f400:7c10::1:174) by BY2PR03CA055.outlook.office365.com (2a01:111:e400:2c5d::28) with Microsoft SMTP Server (TLS) id 15.1.130.23 via Frontend Transport; Fri, 3 Apr 2015 08:48:07 +0000
Authentication-Results: spf=pass (sender IP is 206.191.230.212) smtp.mailfrom=microsoft.com; gmail.com; dkim=none (message not signed) header.d=none;
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.230.212 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.230.212; helo=064-smtp-out.microsoft.com;
Received: from 064-smtp-out.microsoft.com (206.191.230.212) by BN1BFFO11FD008.mail.protection.outlook.com (10.58.144.71) with Microsoft SMTP Server (TLS) id 15.1.136.16 via Frontend Transport; Fri, 3 Apr 2015 08:48:06 +0000
Received: from HKXPR30MB021.064d.mgd.msft.net (141.251.57.209) by HKXPR30MB022.064d.mgd.msft.net (141.251.57.210) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 3 Apr 2015 08:48:03 +0000
Received: from HKXPR30MB021.064d.mgd.msft.net ([141.251.57.209]) by HKXPR30MB021.064d.mgd.msft.net ([141.251.57.209]) with mapi id 15.01.0125.002; Fri, 3 Apr 2015 08:48:03 +0000
From: Kumar Ashutosh <Kumar.Ashutosh@microsoft.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Thread-Topic: [dnsext] RFC 6604 Clarification
Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56gBO/GqAAHnIXWA=
Date: Fri, 03 Apr 2015 08:48:03 +0000
Message-ID: <e57fc4a63f4543149b396ff18eff6855@HKXPR30MB021.064d.mgd.msft.net>
References: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net> <CAH1iCip9Xgh0n5PFt-kyZaMA3Z9D28E0Dr2Rbg5iV5bzHKPHng@mail.gmail.com>
In-Reply-To: <CAH1iCip9Xgh0n5PFt-kyZaMA3Z9D28E0Dr2Rbg5iV5bzHKPHng@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.251.58.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:206.191.230.212; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(377454003)(24454002)(51704005)(199003)(189002)(24736003)(86362001)(62966003)(19580405001)(2656002)(19580395003)(6806004)(86146001)(106466001)(77156002)(102836002)(110136001)(23676002)(92566002)(47776003)(66066001)(50986999)(33646002)(86612001)(2900100001)(76176999)(46102003)(50466002)(16796002)(108616004)(2950100001)(87936001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0649; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0649;
X-Microsoft-Antispam-PRVS: <CY1PR0301MB0649573ADEC7FAFD8EB2356780F10@CY1PR0301MB0649.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CY1PR0301MB0649; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0649;
X-Forefront-PRVS: 05352A48BE
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2015 08:48:06.6006 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.230.212]; Helo=[064-smtp-out.microsoft.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0649
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/RKfY7_0fAZBm8PwwsX-5k8ykj0A>
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: Fri, 03 Apr 2015 08:48:10 -0000

@Brian

>>>>Please tell us that MS DNS does NOT do SERV_FAIL, or if it does, that you are going to fix it. :-)
At present MS DNS servers respond back with RCODE=0 in case of partial CANME chain response (even when last query in the chain results in NXDOMAIN. That is the reason why we are evaluating the RFC 6604 where the clarification has been added in section 3)

Thanks
Ashu
Program Manager | Windows Networking| DNS & SDN

-----Original Message-----
From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] 
Sent: Wednesday, April 1, 2015 04:09
To: Kumar Ashutosh
Cc: DNSEXT Group Working
Subject: Re: [dnsext] RFC 6604 Clarification

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