IETF Logo Mail Archive

[dnsext] RFC 6604 Clarification

Kumar Ashutosh <Kumar.Ashutosh@microsoft.com> Mon, 30 March 2015 09:04 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 52E0E1ACD2E for <dnsext@ietfa.amsl.com>; Mon, 30 Mar 2015 02:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CNmCOb03c2iG for <dnsext@ietfa.amsl.com>; Mon, 30 Mar 2015 02:04:40 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9781ACD2D for <dnsext@ietf.org>; Mon, 30 Mar 2015 02:04:40 -0700 (PDT)
Received: from BY2PR03CA040.namprd03.prod.outlook.com (10.141.249.13) by BN1PR0301MB0610.namprd03.prod.outlook.com (25.160.170.25) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 09:04:38 +0000
Received: from BN1AFFO11FD050.protection.gbl (2a01:111:f400:7c10::165) by BY2PR03CA040.outlook.office365.com (2a01:111:e400:2c5d::13) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Mon, 30 Mar 2015 09:04:37 +0000
Received: from 064-smtp-out.microsoft.com (206.191.230.212) by BN1AFFO11FD050.mail.protection.outlook.com (10.58.53.65) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Mon, 30 Mar 2015 09:04:36 +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; Mon, 30 Mar 2015 09:04:33 +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; Mon, 30 Mar 2015 09:04:33 +0000
From: Kumar Ashutosh <Kumar.Ashutosh@microsoft.com>
To: DNSEXT Group Working <dnsext@ietf.org>
Thread-Topic: RFC 6604 Clarification
Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56g==
Date: Mon, 30 Mar 2015 09:04:33 +0000
Message-ID: <af1796c3bda84e99844715264afc67a5@HKXPR30MB021.064d.mgd.msft.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.251.57.133]
Content-Type: multipart/alternative; boundary="_000_af1796c3bda84e99844715264afc67a5HKXPR30MB021064dmgdmsft_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
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;
Authentication-Results: spf=pass (sender IP is 206.191.230.212) smtp.mailfrom=Kumar.Ashutosh@microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;
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)(2656002)(16796002)(66066001)(106466001)(19625215002)(87936001)(15975445007)(84326002)(19580395003)(54356999)(24736003)(108616004)(110136001)(86146001)(86362001)(450100001)(2900100001)(102836002)(6806004)(50986999)(512954002)(46102003)(107886001)(62966003)(19300405004)(33646002)(86612001)(92566002)(229853001)(77156002)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0610; 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:BN1PR0301MB0610;
X-Microsoft-Antispam-PRVS: <BN1PR0301MB061062E55D3C67428D24119580F50@BN1PR0301MB0610.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:BN1PR0301MB0610; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0610;
X-Forefront-PRVS: 05315CBE52
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2015 09:04:36.3603 (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: BN1PR0301MB0610
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/Bm1sg7-AVZq9eFxzTo5bWDzVxYk>
X-Mailman-Approved-At: Mon, 30 Mar 2015 18:22:58 -0700
Subject: [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: Mon, 30 Mar 2015 09:28:40 -0000

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.

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?

Can we put a clarification?

Thanks
Ashu
Program Manager | Windows Networking| DNS

v2.23.0 | Report a Bug | By Email