Re: [DNSOP] RFC2317 Question: Resolving cname delegation
Hector Santos <hsantos@isdg.net> Sat, 26 August 2017 18:23 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8356132BD4 for <dnsop@ietfa.amsl.com>; Sat, 26 Aug 2017 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Cc+IJKC3; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=fy6cNdM7
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 xcjW_nDQ-hU7 for <dnsop@ietfa.amsl.com>; Sat, 26 Aug 2017 11:23:18 -0700 (PDT)
Received: from listserv.winserver.com (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B2132BD7 for <dnsop@ietf.org>; Sat, 26 Aug 2017 11:23:16 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2286; t=1503771787; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vTXhOGdRwNpZST6L8Q+jzEWE2Pk=; b=Cc+IJKC3xTpqTkjdaRgM7SgBfTgDwUsHMPjZaYc7F4YEUAqzo/U4DNnCkd3TJF 47wYW4nTN9S154S2UX0U60i8OtjitMndKBmN1ATIW/sSlzOL2tg2NoBtN2ztTHf2 fkAp4UsH1B1Fmz+Rob9gJNTwfHuoc03ZiC+VuBpuvLoXE=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:23:07 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3835633000.75665.5044; Sat, 26 Aug 2017 14:23:06 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2286; t=1503771731; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2qtN/LL jJR//YLd6luMJRCqdKoCuWpOl6AEd56zKhLY=; b=fy6cNdM7M4FTaQp0Tt4tQAD rQvqFW9ALhKHQUM3G55YtfWBogQvnSEGMFc/OREW+x5F0H2JdJN9xyfqoDr4hrTt 9IdzQGcDj7yt7AKMssAs3puKFQBTMb+7V45LAEJ13mHXPWVGnC7lSA+EFG6ehSJZ ULTL8/N0gUR5fhjAa7Vc=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:22:11 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 719611328.9.22800; Sat, 26 Aug 2017 14:22:10 -0400
Message-ID: <59A1BC8F.4040006@isdg.net>
Date: Sat, 26 Aug 2017 14:23:11 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: dnsop@ietf.org
References: <599EF4F2.6070509@isdg.net> <3d0a3708-f5ed-151e-816f-c88662400d8b@nic.cz>
In-Reply-To: <3d0a3708-f5ed-151e-816f-c88662400d8b@nic.cz>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LJyCYfSC2w5cM1SRnhcNAfgIv_c>
Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Aug 2017 18:23:20 -0000
On 8/24/2017 12:06 PM, Vladimír Čunát wrote: > Hello. > > On 08/24/2017 05:46 PM, Hector Santos wrote: >> [...] Not expecting this in my DNS resolver code, I modified the >> resolver to take the CNAMEs into account and return the host names >> instead. Was this the correct thing to do, thus providing the same >> results regardless of the query location? [...] > > I can't see any hint in RFC2317 that resolvers should/could change the > data they obtain from upstream, even if just "expand CNAMEs" (and it's > only BCP RFC anyway). In particular, if the particular zone is covered > by DNSSEC, you may trigger validation errors by that. You're right. But I believe it does allude to potential problems and confusion. As I study this more, the issue is this old RFC promoted unexpected cname for the qname in PTR results. My ISP is using it for delegating our new /27 segment of ips. The direct DNS server authoritive response is: qname qtype data d.c.b.a.in-addr.arpa PTR host1 d.c.b.a.in-addr.arpa PTR host2 .. d.c.b.a.in-addr.arpa PTR hostN The non-authoritive response is: qname qtype data d.c.b.a.in-addr.arpa CNAME d.X.c.b.a.in-addr.arpa d.X.c.b.a.in-addr.arpa PTR host1 d.X.c.b.a.in-addr.arpa PTR host2 .. d.X.c.b.a.in-addr.arpa PTR hostN Where X is the the first IP in the delegated IP range. Although my resolver will only return the requested PTR records, the record.name field will contain the cname. I am still studying the impact. The exploratory change in the resolver was to basically compare the name field with the qname, and set it to the qname if different. That way the clients will get the same expected results. I don't think its any different when A->CNAME->A operations is done and cached. It does not seem its going to be a impact on my SMTP clients/senders that could be setup to dynamically obtain the EHLO/HELO hostname by extracting the first record in a PTR lookup. But it could be an impact on incoming SMTP filter scripts that could be setting a PTR requirement. Not sure. It does seem safe, for our system compatibility, to make it consistent. In my opinion, the delegation CNAME is meta-data and it should be passive in the query results. Thanks for the heads up. -- HLS
- [DNSOP] RFC2317 Question: Resolving cname delegat… Hector Santos
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Vladimír Čunát
- Re: [DNSOP] RFC2317 Question: Resolving cname del… P Vix
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Grant Taylor
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Hector Santos
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Hector Santos
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Grant Taylor
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Tony Finch
- Re: [DNSOP] RFC2317 Question: Resolving cname del… Hector Santos