IETF Logo Mail Archive

Re: [dnsext] RFC 6604 Clarification

Kumar Ashutosh <Kumar.Ashutosh@microsoft.com> Tue, 31 March 2015 14:32 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 43C361ACD97 for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 07:32:32 -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 Xb5J1tsw_Keq for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 07:32:28 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53181ACD8E for <dnsext@ietf.org>; Tue, 31 Mar 2015 07:32:27 -0700 (PDT)
Received: from CH1PR03CA003.namprd03.prod.outlook.com (10.255.156.148) by BY2PR03MB395.namprd03.prod.outlook.com (10.141.141.14) with Microsoft SMTP Server (TLS) id 15.1.125.14; Tue, 31 Mar 2015 14:32:25 +0000
Received: from BN1BFFO11FD001.protection.gbl (10.255.156.132) by CH1PR03CA003.outlook.office365.com (10.255.156.148) with Microsoft SMTP Server (TLS) id 15.1.118.21 via Frontend Transport; Tue, 31 Mar 2015 14:32:24 +0000
Authentication-Results: spf=pass (sender IP is 206.191.230.212) smtp.mailfrom=microsoft.com; cnnic.cn; 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 BN1BFFO11FD001.mail.protection.outlook.com (10.58.144.64) with Microsoft SMTP Server (TLS) id 15.1.136.16 via Frontend Transport; Tue, 31 Mar 2015 14:32:22 +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; Tue, 31 Mar 2015 14:32:19 +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; Tue, 31 Mar 2015 14:32:19 +0000
From: Kumar Ashutosh <Kumar.Ashutosh@microsoft.com>
To: Jiankang Yao <yaojk@cnnic.cn>, "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
Thread-Topic: [dnsext] RFC 6604 Clarification
Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56gAu+kSAAA8zJAAAADLT4A==
Date: Tue, 31 Mar 2015 14:32:19 +0000
Message-ID: <275d23dc0a4e4cdc88238b1c47ea0c36@HKXPR30MB021.064d.mgd.msft.net>
References: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net> <551A4B2B.9070406@nlnetlabs.nl> <FD8E7EA6-7B27-4442-8FCD-F54533DEB530@cnnic.cn>
In-Reply-To: <FD8E7EA6-7B27-4442-8FCD-F54533DEB530@cnnic.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.251.58.196]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
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)(51704005)(479174004)(199003)(13464003)(54524002)(24454002)(189002)(6806004)(86612001)(66066001)(50466002)(33646002)(108616004)(19580405001)(76176999)(54356999)(62966003)(77156002)(50986999)(46102003)(102836002)(86146001)(86362001)(15975445007)(19580395003)(16796002)(23736002)(87936001)(120846001)(24736003)(2950100001)(2900100001)(92566002)(47776003)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB395; 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:BY2PR03MB395;
X-Microsoft-Antispam-PRVS: <BY2PR03MB39504CD37D8AC19A9E0D0BB80F40@BY2PR03MB395.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:BY2PR03MB395; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB395;
X-Forefront-PRVS: 0532BF6DC2
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2015 14:32:22.6753 (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: BY2PR03MB395
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/bDTn3sd-9og4_wQqqY90aN8QW8k>
Cc: "dnsext@ietf.org" <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 14:32:32 -0000

I agree with the 1st
What about ?
1.	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?



Thanks
Ashu
Program Manager | Windows Networking| DNS & SDN

-----Original Message-----
From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Jiankang Yao
Sent: Tuesday, March 31, 2015 20:08
To: W.C.A. Wijngaards
Cc: dnsext@ietf.org
Subject: Re: [dnsext] RFC 6604 Clarification





> 在 2015年3月31日，15:22，"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> 写道：
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi Kumar,
> 
> I cannot answer on the RFC part, but I want to answer on what will 
> make the resolver continue the lookup.
> 
>> On 30/03/15 11:04, Kumar Ashutosh 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.
>> 
>> 
>> 
>> This is a little vague on two accounts:
>> 
>> 1.What would be the error code if the server decides to curtail the 
>> CNAME chain after a certain length (say 20). Is it still success or 
>> do we indicate in some other way.
> 
> The curtailed CNAME chain is best sent with RCODE NOERROR(0).
> 
>> 




Based on the current text below"
>>   If the xNAME chain terminated without error, it will be zero.
>> "

"Curtail the cname chain" can be regarded as a kind of "terminated without error".
So I agree that it is zero (no error).

Jiankang Yao
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

v2.23.0 | Report a Bug | By Email