From Kumar.Ashutosh@microsoft.com Mon Mar 30 02:04:42 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: DNSEXT Group Working Thread-Topic: RFC 6604 Clarification Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56g== Date: Mon, 30 Mar 2015 09:04:33 +0000 Message-ID: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 09:28:40 -0000 --_000_af1796c3bda84e99844715264afc67a5HKXPR30MB021064dmgdmsft_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 indicat= e in some other way. 2. If the CNAME chain points to a Qname for which the auth server is non-au= thoritative (and recursion is disabled on the auth server.) The server in t= his 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 r= esolvers respect answers with SERV_FAIL in RCODE and cache the partial resp= onse? Can we put a clarification? Thanks Ashu Program Manager | Windows Networking| DNS --_000_af1796c3bda84e99844715264afc67a5HKXPR30MB021064dmgdmsft_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 ultima= te DNS response

  = ;    MUST BE set based on the final query cycle leading to t= hat

  = ;    response.  If the xNAME chain was terminated by an= error, it will

  = ;    be that error code.  If the xNAME chain terminated= without error,

&= nbsp;            &nb= sp;it will be zero.

 =

This is a l= ittle vague on two accounts:

1. What would be the error code if the se= rver 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 f= or 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 respec= t answers with SERV_FAIL in RCODE and cache the partial response?

 =

Can we put = a clarification?

 

Thanks

Ashu

Program Manager | Windows Networking= | DNS

 

--_000_af1796c3bda84e99844715264afc67a5HKXPR30MB021064dmgdmsft_-- From nobody Tue Mar 31 00:22:31 2015 Return-Path: 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 55D9B1AD0CB for ; Tue, 31 Mar 2015 00:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ljoC95xXhLDh for ; Tue, 31 Mar 2015 00:22:27 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D7E1A0338 for ; Tue, 31 Mar 2015 00:22:26 -0700 (PDT) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 091E62734; Tue, 31 Mar 2015 09:22:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1427786544; bh=BQnSxaL9f7FZDA68WmDFr86IM3Vy/z5KKHWsQQUC9JY=; h=Date:From:To:Subject:References:In-Reply-To; b=vv4N8LUyN4QMvBV/fqNX/nNX/dLqFQwll2NAWrh/tzcb0xURtVjO8eNedIK4pvjS4 mPqKkEUFaOl/7uasO4MhVVSM/oGp0/w9UZUGEcQ12YdOC3KjM7WzKBOU6WTm62fNEv EiXHNFC4E9KqGHMflW9DYt9ZAuKlbyjRIlpJChB4= Received: from axiom.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:222:4dff:fe55:4d46]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id AB59F272E for ; Tue, 31 Mar 2015 09:22:21 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1427786541; bh=BQnSxaL9f7FZDA68WmDFr86IM3Vy/z5KKHWsQQUC9JY=; h=Date:From:To:Subject:References:In-Reply-To; b=mY3jsJ3wyKMghxGFXKSOQ/CXHVFVETle4PEr3kYshbUJ04T0n5WenZ5Dx+qHdXvm6 DrHkQ6J4xCileyboDX9x3YYYGt0d3MvuhUT2fUK6ZBnPDtkJWkO6ojbhEi77tNc/pp bLW09LU+YV+/Sv56h9fAfgQBBuhn+cpwY7qPMRiE= Message-ID: <551A4B2B.9070406@nlnetlabs.nl> Date: Tue, 31 Mar 2015 09:22:19 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 07:22:29 -0000 -----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). > > 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? You must send the partial response with RCODE NOERROR(0). Then, the resolver can retry after the CNAME. Best regards, Wouter > > > > Can we put a clarification? > > > > Thanks > > *Ashu* > > Program Manager | Windows Networking| DNS > > > > > > _______________________________________________ dnsext mailing > list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGksrAAoJEJ9vHC1+BF+Nv0QP/RY/NRKvkVhUKqFQ+CuWU/06 RQWEktMu4XMLBX6RlUteOwsc7Ufux5Fz+/KN50M8wrRZ+7I0CMFQBI88ugOSZ5mB iX2DYv6soBtZirX0gUsXtZ1PQRMOipx/7qi7YPIZS5Sm7WEWWdcuVMlIMiswVqLi 2gg3Ac4bOGYTMhR9cwlNGX4VYlDfQIjP7+HOcTZS5uBR6sc7hzmpH8xrSCHj49Je MVv2h/IpjR+DdNQSDPBJHhOyPnfjhgfcGDPgn7lbuGspaSEQ6onEAu1R/G7RJkhz QhbMXQmLlk22bxlZXhi33uHFjKLzWBttLe88+vFf1UgdpjQjrXnIRF4Y2UIDQGi5 CChfolUG2UIjyVzsd9yOX48T1rhe9L9MSD7SuqAc35/jN8eZG325kzF9h4iuNBhy NM/5XS68dejl9fUmgERZB14GGPw4ZdvtFyuFlXGKaQj8CHeMCHXg5A8TbnUdLelf XSKrSfQBslEzotJiNjdQWLomfcQPolkYwN/X9RaGvcPJbrGYWDtgqyVYbNTgWdOd 59GKt9xSvymYSlp91MTBmNNHPNdvf8l5RqGKiKrdB3kXenLNUx7mulYFonB4QvEy irsbPO36vtZub4OppUADysd76WsMPC/7m6YjGX92C40Jv1VRrlqKvOZgKlO2q6Ms alLuBIJh7/0fluO4vB4w =ZlFv -----END PGP SIGNATURE----- From nobody Tue Mar 31 07:26:29 2015 Return-Path: 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 65EA91ACD81 for ; Tue, 31 Mar 2015 07:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.238 X-Spam-Level: *** X-Spam-Status: No, score=3.238 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_CHARSET_FARAWAY=2.45, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Whj_G3SzSy6w for ; Tue, 31 Mar 2015 07:26:26 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8A1ACD7E for ; Tue, 31 Mar 2015 07:26:25 -0700 (PDT) Received: from [192.168.1.110] (unknown [125.33.4.118]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMISPrhpVrcYkAA--.5716S2; Tue, 31 Mar 2015 22:26:24 +0800 (CST) References: <551A4B2B.9070406@nlnetlabs.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <551A4B2B.9070406@nlnetlabs.nl> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Jiankang Yao Date: Tue, 31 Mar 2015 22:37:32 +0800 To: "W.C.A. Wijngaards" X-CM-TRANSID: AQAAf0ApMISPrhpVrcYkAA--.5716S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Gw48tFWxKr1ftr4xAw4rGrg_yoW8Jr4kpF ZxG3ZFyFWDJr1Iyw1vqrW2gF40yr93Cr9xCF95t3yIvw1v9rn5Zr40qa1S9rW7urW8Jay0 yrW5X397uFy5JFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW5XwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU4VWlDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 14:26:28 -0000 > =D4=DA 2015=C4=EA3=D4=C231=C8=D5=A3=AC15:22=A3=AC"W.C.A. Wijngaards" =D0=B4=B5=C0=A3=BA >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi Kumar, >=20 > I cannot answer on the RFC part, but I want to answer on what will > make the resolver continue the lookup. >=20 >> On 30/03/15 11:04, Kumar Ashutosh wrote: >> Hi >>=20 >> As per RFC 6604, section 3 >>=20 >> When an xNAME chain is followed, all but the last query cycle >>=20 >> necessarily had no error. The RCODE in the ultimate DNS response >>=20 >> MUST BE set based on the final query cycle leading to that >>=20 >> response. If the xNAME chain was terminated by an error, it will >>=20 >> be that error code. If the xNAME chain terminated without error, >>=20 >> it will be zero. >>=20 >>=20 >>=20 >> This is a little vague on two accounts: >>=20 >> 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. >=20 > The curtailed CNAME chain is best sent with RCODE NOERROR(0). >=20 >>=20 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 e= rror". So I agree that it is zero (no error). Jiankang Yao= From nobody Tue Mar 31 07:32:33 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: Jiankang Yao , "W.C.A. Wijngaards" 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: <551A4B2B.9070406@nlnetlabs.nl> In-Reply-To: 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: 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: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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-au= thoritative (and recursion is disabled on the auth server.) The server in t= his 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 r= esolvers respect answers with SERV_FAIL in RCODE and cache the partial resp= onse? 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 > =1B$B:_=1B(B 2015=1B$BG/=1B(B3=1B$B7n=1B(B31=1B$BF|!$=1B(B15:22=1B$B!$=1B= (B"W.C.A. Wijngaards" =1B$B=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Hi Kumar, >=20 > I cannot answer on the RFC part, but I want to answer on what will=20 > make the resolver continue the lookup. >=20 >> On 30/03/15 11:04, Kumar Ashutosh wrote: >> Hi >>=20 >> As per RFC 6604, section 3 >>=20 >> When an xNAME chain is followed, all but the last query cycle >>=20 >> necessarily had no error. The RCODE in the ultimate DNS response >>=20 >> MUST BE set based on the final query cycle leading to that >>=20 >> response. If the xNAME chain was terminated by an error, it will >>=20 >> be that error code. If the xNAME chain terminated without error, >>=20 >> it will be zero. >>=20 >>=20 >>=20 >> This is a little vague on two accounts: >>=20 >> 1.What would be the error code if the server decides to curtail the=20 >> CNAME chain after a certain length (say 20). Is it still success or=20 >> do we indicate in some other way. >=20 > The curtailed CNAME chain is best sent with RCODE NOERROR(0). >=20 >>=20 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 From nobody Tue Mar 31 12:20:22 2015 Return-Path: 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 7F7FA1ABD35 for ; Tue, 31 Mar 2015 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XaK1kVCmuroD for ; Tue, 31 Mar 2015 12:20:19 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A671ABB19 for ; Tue, 31 Mar 2015 12:20:18 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 796C73F439; Tue, 31 Mar 2015 15:20:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21786.62321.220106.816987@gro.dd.org> Date: Tue, 31 Mar 2015 15:20:17 -0400 From: Dave Lawrence To: Kumar Ashutosh In-Reply-To: <275d23dc0a4e4cdc88238b1c47ea0c36@HKXPR30MB021.064d.mgd.msft.net> References: <551A4B2B.9070406@nlnetlabs.nl> <275d23dc0a4e4cdc88238b1c47ea0c36@HKXPR30MB021.064d.mgd.msft.net> Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:20:20 -0000 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. From nobody Tue Mar 31 12:24:06 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: Dave Lawrence , "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: References: <551A4B2B.9070406@nlnetlabs.nl> <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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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]=20 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.)=20 > The server in this case cannot get the response. A direct query for=20 > this Qname will result in SERV_FAIL. Should the auth server return=20 > SERV_FAIL in this case? Will resolvers respect answers with SERV_FAIL=20 > 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 m= ajor resolvers that will not even bother looking for anything else beyond t= he 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 authorit= y. 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 superfici= ally seem to have a certain robustness to it, but I would not be surprised = to discover that some implementers made a different choice. From nobody Tue Mar 31 14:20:38 2015 Return-Path: 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 DED231A908E for ; Tue, 31 Mar 2015 03:54:03 -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 QngI-dGG36HX for ; Tue, 31 Mar 2015 03:54:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708061A8AD7 for ; Tue, 31 Mar 2015 03:54:01 -0700 (PDT) Received: from BY2PR03CA072.namprd03.prod.outlook.com (10.141.249.45) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 31 Mar 2015 10:53:56 +0000 Received: from BN1AFFO11FD035.protection.gbl (2a01:111:f400:7c10::100) by BY2PR03CA072.outlook.office365.com (2a01:111:e400:2c5d::45) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Tue, 31 Mar 2015 10:53:56 +0000 Received: from 064-smtp-out.microsoft.com (206.191.230.212) by BN1AFFO11FD035.mail.protection.outlook.com (10.58.52.159) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Tue, 31 Mar 2015 10:53:54 +0000 Received: from HKXPR30MB021.064d.mgd.msft.net (141.251.57.209) by HKXPR30MB021.064d.mgd.msft.net (141.251.57.209) with Microsoft SMTP Server (TLS) id 15.1.125.19; Tue, 31 Mar 2015 10:53:51 +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 10:53:51 +0000 From: Kumar Ashutosh To: "W.C.A. Wijngaards" , "dnsext@ietf.org" Thread-Topic: [dnsext] RFC 6604 Clarification Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56gAu+kSAAAc/FXA= Date: Tue, 31 Mar 2015 10:53:51 +0000 Message-ID: References: <551A4B2B.9070406@nlnetlabs.nl> In-Reply-To: <551A4B2B.9070406@nlnetlabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.57.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; nlnetlabs.nl; 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)(13464003)(479174004)(199003)(51704005)(24454002)(54524002)(66066001)(47776003)(92566002)(24736003)(86362001)(23726002)(6806004)(575784001)(86612001)(107886001)(108616004)(106466001)(19580405001)(102836002)(15975445007)(2950100001)(77156002)(2900100001)(87936001)(2656002)(50466002)(97756001)(33646002)(2501003)(76176999)(54356999)(46102003)(16796002)(19580395003)(86146001)(46406003)(50986999)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB077; 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:SN2PR03MB077; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:SN2PR03MB077; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB077; X-Forefront-PRVS: 0532BF6DC2 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2015 10:53:54.2459 (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: SN2PR03MB077 Archived-At: X-Mailman-Approved-At: Tue, 31 Mar 2015 14:20:37 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:54:04 -0000 Thank You Wouter. The first one seems to be a fair call. The second case is a little confusing. Also, I am a little skeptical about sending any partial response with SERV_= FAIL as many resolvers may simply reject the data in Serv_fail responses an= d will cause resolution failures.=20 Thanks Ashu Program Manager | Windows Networking| DNS & SDN -----Original Message----- From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of W.C.A. Wijngaard= s Sent: Tuesday, March 31, 2015 12:52 To: dnsext@ietf.org Subject: Re: [dnsext] RFC 6604 Clarification -----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 >=20 > As per RFC 6604, section 3 >=20 > When an xNAME chain is followed, all but the last query cycle >=20 > necessarily had no error. The RCODE in the ultimate DNS response >=20 > MUST BE set based on the final query cycle leading to that >=20 > response. If the xNAME chain was terminated by an error, it will >=20 > be that error code. If the xNAME chain terminated without error, >=20 > it will be zero. >=20 >=20 >=20 > This is a little vague on two accounts: >=20 > 1.What would be the error code if the server decides to curtail the=20 > CNAME chain after a certain length (say 20). Is it still success or do=20 > we indicate in some other way. The curtailed CNAME chain is best sent with RCODE NOERROR(0). >=20 > 2.If the CNAME chain points to a Qname for which the auth server is=20 > non-authoritative (and recursion is disabled on the auth > server.) The server in this case cannot get the response. A direct=20 > query for this Qname will result in SERV_FAIL. Should the auth server=20 > return SERV_FAIL in this case? Will resolvers respect answers with=20 > SERV_FAIL in RCODE and cache the partial response? You must send the partial response with RCODE NOERROR(0). Then, the resolv= er can retry after the CNAME. Best regards, Wouter >=20 >=20 >=20 > Can we put a clarification? >=20 >=20 >=20 > Thanks >=20 > *Ashu* >=20 > Program Manager | Windows Networking| DNS >=20 >=20 >=20 >=20 >=20 > _______________________________________________ dnsext mailing list=20 > dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVGksrAAoJEJ9vHC1+BF+Nv0QP/RY/NRKvkVhUKqFQ+CuWU/06 RQWEktMu4XMLBX6RlUteOwsc7Ufux5Fz+/KN50M8wrRZ+7I0CMFQBI88ugOSZ5mB iX2DYv6soBtZirX0gUsXtZ1PQRMOipx/7qi7YPIZS5Sm7WEWWdcuVMlIMiswVqLi 2gg3Ac4bOGYTMhR9cwlNGX4VYlDfQIjP7+HOcTZS5uBR6sc7hzmpH8xrSCHj49Je MVv2h/IpjR+DdNQSDPBJHhOyPnfjhgfcGDPgn7lbuGspaSEQ6onEAu1R/G7RJkhz QhbMXQmLlk22bxlZXhi33uHFjKLzWBttLe88+vFf1UgdpjQjrXnIRF4Y2UIDQGi5 CChfolUG2UIjyVzsd9yOX48T1rhe9L9MSD7SuqAc35/jN8eZG325kzF9h4iuNBhy NM/5XS68dejl9fUmgERZB14GGPw4ZdvtFyuFlXGKaQj8CHeMCHXg5A8TbnUdLelf XSKrSfQBslEzotJiNjdQWLomfcQPolkYwN/X9RaGvcPJbrGYWDtgqyVYbNTgWdOd 59GKt9xSvymYSlp91MTBmNNHPNdvf8l5RqGKiKrdB3kXenLNUx7mulYFonB4QvEy irsbPO36vtZub4OppUADysd76WsMPC/7m6YjGX92C40Jv1VRrlqKvOZgKlO2q6Ms alLuBIJh7/0fluO4vB4w =3DZlFv -----END PGP SIGNATURE----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From nobody Tue Mar 31 15:38:53 2015 Return-Path: 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 ; 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 ; 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 ; Tue, 31 Mar 2015 15:38:50 -0700 (PDT) Received: by ignm3 with SMTP id m3so20982621ign.0 for ; 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: References: Date: Tue, 31 Mar 2015 15:38:49 -0700 Message-ID: From: Brian Dickson To: Kumar Ashutosh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DNSEXT Group Working 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 22:38:52 -0000 On Mon, Mar 30, 2015 at 2:04 AM, 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. > 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 From nobody Tue Mar 31 17:17:56 2015 Return-Path: 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 D8E0F1A9036 for ; Tue, 31 Mar 2015 17:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SPV6tdOzq1xT for ; Tue, 31 Mar 2015 17:17:53 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656481A1AC9 for ; Tue, 31 Mar 2015 17:17:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-129-222-51.range86-129.btcentralplus.com ([86.129.222.51]:58886 helo=[192.168.1.107]) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:DHE-RSA-AES256-SHA:256) id 1Yd6Lu-00047j-he (Exim 4.82_3-c0e5623) (return-path ); Wed, 01 Apr 2015 01:17:50 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-96DB877E-70BD-4A5C-AB43-EA1713D1B7D9 Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Wed, 1 Apr 2015 01:17:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <452FFC6C-023B-4D93-8E24-6DE454DD9143@dotat.at> References: To: Brian Dickson Sender: Tony Finch Archived-At: Cc: DNSEXT Group Working 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 00:17:56 -0000 --Apple-Mail-96DB877E-70BD-4A5C-AB43-EA1713D1B7D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 Mar 2015, at 23:38, Brian Dickson wr= ote: >=20 > 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 send a query to an authoritative-only server for a name for which it i= sn't authoritative, you should get a referral if the qname is a subdomain of= one of the server's zones, or a referral to the root (traditional), or REFU= SED. A referral is a bit more than just NOERROR NODATA AA=3D0 :-) Tony. --=20 f.anthony.n.finch http://dotat.at --Apple-Mail-96DB877E-70BD-4A5C-AB43-EA1713D1B7D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 Mar 20= 15, at 23:38, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

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

If you send a query to an authorit= ative-only server for a name for which it isn't authoritative, you should ge= t a referral if the qname is a subdomain of one of the server's zones, or a r= eferral to the root (traditional), or REFUSED. A referral is a bit more than= just NOERROR NODATA AA=3D0 :-)

Tony.
-- 
f.anth= ony.n.finch  <dot@dotat.at> &= nbsp;http://dotat.at

= --Apple-Mail-96DB877E-70BD-4A5C-AB43-EA1713D1B7D9-- From nobody Tue Mar 31 18:11:51 2015 Return-Path: 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 0260E1B2BC6 for ; Tue, 31 Mar 2015 18:11:51 -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 VMSHkS1jLaIj for ; Tue, 31 Mar 2015 18:11:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534A51B2BC1 for ; Tue, 31 Mar 2015 18:11:49 -0700 (PDT) Received: from BY2PR03CA038.namprd03.prod.outlook.com (10.141.249.11) by BN1PR0301MB0612.namprd03.prod.outlook.com (25.160.170.27) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 1 Apr 2015 01:11:28 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::121) by BY2PR03CA038.outlook.office365.com (2a01:111:e400:2c5d::11) with Microsoft SMTP Server (TLS) id 15.1.130.23 via Frontend Transport; Wed, 1 Apr 2015 01:11:28 +0000 Received: from 064-smtp-out.microsoft.com (206.191.230.212) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.1.125.13 via Frontend Transport; Wed, 1 Apr 2015 01:11:26 +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; Wed, 1 Apr 2015 01:11:24 +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; Wed, 1 Apr 2015 01:11:24 +0000 From: Kumar Ashutosh To: Brian Dickson Thread-Topic: [dnsext] RFC 6604 Clarification Thread-Index: AdBqx4LlMcsNNOFbQA+DDcOOf8n56gBO/GqAAAUhPPA= Date: Wed, 1 Apr 2015 01:11:24 +0000 Message-ID: <0bea6bc18cb34b1681a1bd0484ec91a9@HKXPR30MB021.064d.mgd.msft.net> References: In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 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; gmail.com; 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)(13464003)(199003)(51704005)(189002)(377454003)(24454002)(86362001)(54356999)(50986999)(76176999)(2656002)(87936001)(77156002)(106466001)(62966003)(110136001)(47776003)(19580405001)(86146001)(6806004)(108616004)(16796002)(24736003)(23676002)(102836002)(33646002)(2900100001)(46102003)(92566002)(2950100001)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0612; 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:BN1PR0301MB0612; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR0301MB0612; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0612; X-Forefront-PRVS: 053315510E X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2015 01:11:26.8275 (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: BN1PR0301MB0612 Archived-At: Cc: DNSEXT Group Working 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:11:51 -0000 SGkgDQoNCiIgU2VuZGluZyB0aGUgcXVlcnkgdG8gdGhlIHByZXZpb3VzIGF1dGggc2VydmVyIHdv dWxkIGJlIHRoZSB3cm9uZyB0aGluZyB0byBkby4gRXZlbiBpZiBzdWNoIGEgcXVlcnkgd2VyZSBy ZWNlaXZlZCwgdGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMgTk9FUlJST1IsIE5PREFUQSwgd2l0aCBB QSB1bnNldCAoc2V0IHRvIHplcm8pLg0KDQpJZiB5b3UgYXJlIG5vdCBzdXJlIHlvdSB1bmRlcnN0 YW5kIHRoaXMsIHBsZWFzZSBhc2sgYW55IGNsYXJpZnlpbmcgcXVlc3Rpb25zIHlvdSBtYXkgaGF2 ZS4NCg0KUGxlYXNlIHRlbGwgdXMgdGhhdCBNUyBETlMgZG9lcyBOT1QgZG8gU0VSVl9GQUlMLCBv ciBpZiBpdCBkb2VzLCB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gZml4IGl0LiA6LSkiDQoNCkZvciBD TkFNRSBwYXJ0aWFsIGNoYWlucywgTVMgRE5TIHNlcnZlcnMgcmVzcG9uZCB3aXRoIE5PRVJST1Ig aW4gYWxsIHRoZSBjYXNlcyB0aWxsIG5vdy4gV2Ugd2VyZSBldmFsdWF0aW5nIHRvIHNlZSB3aGF0 IFJGQyA2NjA0IGNvbXBsaWFuY2Ugd291bGQgbWVhbiBpbiB0ZXJtcyBvZiBjaGFuZ2VzLg0KDQpG b3IgeW91ciBxdWVzdGlvbiBhYm92ZS4gSWYgYSBxdWVyeSBmb3IgQSBvZiB4LmV4YW1wbGUuY29t IGlzIHJlY2VpdmVkIG9uIGFuIGF1dGhvcml0YXRpdmUgc2VydmVyLCB3aGljaCBkb2VzIG5vdCBo YXZlIGFueSBpZGVhIG9mIGV4YW1wbGUuY29tIG9yIC5jb20sIHRoZW4gaXQgd2lsbCBzaW1wbHkg cmVzcG9uZCB3aXRoIHNlcnZfZmFpbC4gTk9EQVRBIHdpbGwgYmUgcmV0dXJuZWQgb25seSB3aGVu IHRoZXJlIGlzIGEgeC5leGFtcGxlLmNvbSBvZiBzb21lIG90aGVyIHR5cGUuIA0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIERpY2tzb24gW21haWx0bzpicmlh bi5wZXRlci5kaWNrc29uQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEsIDIw MTUgMDQ6MDkNClRvOiBLdW1hciBBc2h1dG9zaA0KQ2M6IEROU0VYVCBHcm91cCBXb3JraW5nDQpT dWJqZWN0OiBSZTogW2Ruc2V4dF0gUkZDIDY2MDQgQ2xhcmlmaWNhdGlvbg0KDQpPbiBNb24sIE1h ciAzMCwgMjAxNSBhdCAyOjA0IEFNLCBLdW1hciBBc2h1dG9zaCA8S3VtYXIuQXNodXRvc2hAbWlj cm9zb2Z0LmNvbT4gd3JvdGU6DQo+IEhpDQo+DQo+IEFzIHBlciBSRkMgNjYwNCwgc2VjdGlvbiAz DQo+DQo+ICAgICAgIFdoZW4gYW4geE5BTUUgY2hhaW4gaXMgZm9sbG93ZWQsIGFsbCBidXQgdGhl IGxhc3QgcXVlcnkgY3ljbGUNCj4NCj4gICAgICAgbmVjZXNzYXJpbHkgaGFkIG5vIGVycm9yLiAg VGhlIFJDT0RFIGluIHRoZSB1bHRpbWF0ZSBETlMgDQo+IHJlc3BvbnNlDQo+DQo+ICAgICAgIE1V U1QgQkUgc2V0IGJhc2VkIG9uIHRoZSBmaW5hbCBxdWVyeSBjeWNsZSBsZWFkaW5nIHRvIHRoYXQN Cj4NCj4gICAgICAgcmVzcG9uc2UuICBJZiB0aGUgeE5BTUUgY2hhaW4gd2FzIHRlcm1pbmF0ZWQg YnkgYW4gZXJyb3IsIGl0IA0KPiB3aWxsDQo+DQo+ICAgICAgIGJlIHRoYXQgZXJyb3IgY29kZS4g IElmIHRoZSB4TkFNRSBjaGFpbiB0ZXJtaW5hdGVkIHdpdGhvdXQgDQo+IGVycm9yLA0KPg0KPiAg ICAgICAgICAgICAgIGl0IHdpbGwgYmUgemVyby4NCg0KPiAyLiBJZiB0aGUgQ05BTUUgY2hhaW4g cG9pbnRzIHRvIGEgUW5hbWUgZm9yIHdoaWNoIHRoZSBhdXRoIHNlcnZlciBpcyANCj4gbm9uLWF1 dGhvcml0YXRpdmUgKGFuZCByZWN1cnNpb24gaXMgZGlzYWJsZWQgb24gdGhlIGF1dGggc2VydmVy LikgVGhlIA0KPiBzZXJ2ZXIgaW4gdGhpcyBjYXNlIGNhbm5vdCBnZXQgdGhlIHJlc3BvbnNlLiBB IGRpcmVjdCBxdWVyeSBmb3IgdGhpcyANCj4gUW5hbWUgd2lsbCByZXN1bHQgaW4gU0VSVl9GQUlM LiBTaG91bGQgdGhlIGF1dGggc2VydmVyIHJldHVybiBTRVJWX0ZBSUwgaW4gdGhpcyBjYXNlPw0K PiBXaWxsIHJlc29sdmVycyByZXNwZWN0IGFuc3dlcnMgd2l0aCBTRVJWX0ZBSUwgaW4gUkNPREUg YW5kIGNhY2hlIHRoZSANCj4gcGFydGlhbCByZXNwb25zZT8NCg0KSnVzdCB0byBjbGFyaWZ5IHlv dXIgcXVlc3Rpb24gZnVydGhlcjoNCg0KQSBDTkFNRSBjaGFpbiBpcyBub3JtYWxseSBwcm9jZXNz ZWQgRU5USVJFTFkgYnkgdGhlIGl0ZXJhdGl2ZQ0KKHJlY3Vyc2l2ZSkgcmVzb2x2ZXIuDQpJbiB0 aGUgY2FzZSBvZiBhIGdpdmVuIGF1dGhvcml0eSBzZXJ2ZXIgYmVpbmcgYXV0aG9yaXRhdGl2ZSBm b3IgdGhlIGRvbWFpbiBuYW1lIGZvdW5kIG9uIHRoZSByaWdodC1oYW5kLXNpZGUgb2YgYSBDTkFN RSwgYXMgYW4gb3B0aW1pemF0aW9uLCBpdCBNQVkgcHJvdmlkZSB0aGUgcmVzdWx0cyBvZiBhIHJl LXN0YXJ0ZWQgcXVlcnkgdXNpbmcgdGhhdCBSSFMgdmFsdWUuDQoNCkl0IGNhbiBPTkxZIGRvIHRo YXQgc28gbG9uZyBhcyBpdCBpcyBhdXRob3JpdGF0aXZlLiBJZiBpdCBpcyBub3QsIGl0IHNpbXBs eSByZXR1cm5zIHRoZSBkYXRhIGl0IGlzIGF1dGhvcml0YXRpdmUgZm9yLCB3aXRoIGEgTk9FUlJP UiBSQ09ERS4NCg0KUG9pbnRpbmcgdG8gYSBkb21haW4gbmFtZSB0aGF0IGl0IGlzIG5vdCBhdXRo b3JpdGF0aXZlIGZvciwgaXMgbm90IGFuIGVycm9yIGNvbmRpdGlvbi4NCg0KVGhlIGl0ZXJhdGl2 ZSByZXNvbHZlciB3b3VsZCBuZWVkIHRvIGNvbnRpbnVlIHByb2Nlc3NpbmcgdGhlIHJld3JpdHRl biBRTkFNRSwgYnkgc2VuZGluZyB0aGUgcmV3cml0dGVuIHF1ZXJ5IHRvIHdoYXRldmVyIGF1dGhv cml0eSBzZXJ2ZXIgaXMgYXV0aG9yaXRhdGl2ZSBmb3IgdGhhdCBuZXcgUU5BTUUuDQoNClNlbmRp bmcgdGhlIHF1ZXJ5IHRvIHRoZSBwcmV2aW91cyBhdXRoIHNlcnZlciB3b3VsZCBiZSB0aGUgd3Jv bmcgdGhpbmcgdG8gZG8uIEV2ZW4gaWYgc3VjaCBhIHF1ZXJ5IHdlcmUgcmVjZWl2ZWQsIHRoZSBj b3JyZWN0IGJlaGF2aW9yIGlzIE5PRVJSUk9SLCBOT0RBVEEsIHdpdGggQUEgdW5zZXQgKHNldCB0 byB6ZXJvKS4NCg0KSWYgeW91IGFyZSBub3Qgc3VyZSB5b3UgdW5kZXJzdGFuZCB0aGlzLCBwbGVh c2UgYXNrIGFueSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyB5b3UgbWF5IGhhdmUuDQoNClBsZWFzZSB0 ZWxsIHVzIHRoYXQgTVMgRE5TIGRvZXMgTk9UIGRvIFNFUlZfRkFJTCwgb3IgaWYgaXQgZG9lcywg dGhhdCB5b3UgYXJlIGdvaW5nIHRvIGZpeCBpdC4gOi0pDQoNCkJyaWFuDQo=