IETF Logo Mail Archive

Re: [dnsext] RFC 6604 Clarification

Kumar Ashutosh <Kumar.Ashutosh@microsoft.com> Tue, 31 March 2015 19:24 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 70A651A92DD for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 12:24:05 -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, 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 NWS8SKwWmp_m for <dnsext@ietfa.amsl.com>; Tue, 31 Mar 2015 12:24:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E921D1A923E for <dnsext@ietf.org>; Tue, 31 Mar 2015 12:24:02 -0700 (PDT)
Received: from BY2PR03CA068.namprd03.prod.outlook.com (10.141.249.41) by BY2PR0301MB0615.namprd03.prod.outlook.com (25.160.125.25) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 31 Mar 2015 19:23:57 +0000
Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::104) by BY2PR03CA068.outlook.office365.com (2a01:111:e400:2c5d::41) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Tue, 31 Mar 2015 19:23:57 +0000
Authentication-Results: spf=pass (sender IP is 206.191.230.212) smtp.mailfrom=microsoft.com; dd.org; 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 BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.1.136.16 via Frontend Transport; Tue, 31 Mar 2015 19:23:55 +0000
Received: from HKXPR30MB021.064d.mgd.msft.net (141.251.57.209) by HKXPR30MB023.064d.mgd.msft.net (141.251.57.213) with Microsoft SMTP Server (TLS) id 15.1.125.19; Tue, 31 Mar 2015 19:23:53 +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 19:23:53 +0000
From: Kumar Ashutosh <Kumar.Ashutosh@microsoft.com>
To: Dave Lawrence <tale@dd.org>, "dnsext@ietf.org" <dnsext@ietf.org>
Thread-Topic: [dnsext] RFC 6604 Clarification
Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56gAu+kSAAA8zJAAAADLT4AAJrSiAAAAOquA=
Date: Tue, 31 Mar 2015 19:23:53 +0000
Message-ID: <e566bdb9e93544599abfd469eb0ce7df@HKXPR30MB021.064d.mgd.msft.net>
References: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net> <551A4B2B.9070406@nlnetlabs.nl> <FD8E7EA6-7B27-4442-8FCD-F54533DEB530@cnnic.cn> <275d23dc0a4e4cdc88238b1c47ea0c36@HKXPR30MB021.064d.mgd.msft.net> <21786.62321.220106.816987@gro.dd.org>
In-Reply-To: <21786.62321.220106.816987@gro.dd.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [122.175.7.45]
Content-Type: text/plain; charset="us-ascii"
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)(189002)(199003)(13464003)(76176999)(46102003)(50466002)(62966003)(23726002)(2501003)(54356999)(46406003)(102836002)(50986999)(97756001)(86362001)(24736003)(93886004)(108616004)(47776003)(107886001)(16796002)(87936001)(2656002)(86146001)(19580405001)(2950100001)(19580395003)(106466001)(77156002)(6806004)(92566002)(33646002)(2900100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0615; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0615;
X-Microsoft-Antispam-PRVS: <BY2PR0301MB0615AFB57F21E9A3DF7786E280F40@BY2PR0301MB0615.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:BY2PR0301MB0615; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0615;
X-Forefront-PRVS: 0532BF6DC2
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2015 19:23:55.7608 (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: BY2PR0301MB0615
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/LALexa6Jq343OdWRMiY2WXKiDGU>
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 19:24:05 -0000

Actually this RFC has created some sort of confusion regarding sending SERV_FAIL as error code.
Will submit for a clarification.

-----Original Message-----
From: Dave Lawrence [mailto:tale@dd.org] 
Sent: Wednesday, April 1, 2015 00:50
To: Kumar Ashutosh
Cc: dnsext@ietf.org
Subject: Re: [dnsext] RFC 6604 Clarification

Kumar Ashutosh writes:
> 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?

It's best to just send NOERROR if you put in a CNAME, even if you tried to chase it and got your own failure.

While I can't speak for every implementation, I know at least a couple of major resolvers that will not even bother looking for anything else beyond the CNAME, even if the target is apparently in the same zone.
By a strict reading of RFC 1034 and RFC 1035, the resolver will restart the query with the target name by sending a new query to the relevant authority.

Without going to check the code, I'm honestly not sure what they'd do with status of SERVFAIL from an authority but an answer section that
started with a CNAME.   RFC 1034 section 5.3.3 puts checking for the
server failure status after checking for the CNAME, and that does superficially seem to have a certain robustness to it, but I would not be surprised to discover that some implementers made a different choice.

v2.23.0 | Report a Bug | By Email