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 9DD581321F1 for <dnsop@ietfa.amsl.com>; Sat, 26 Aug 2017 11:23:10 -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=hDRaPj6B; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=cOJy9Jyh
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 ZulDeN5WCO4R for <dnsop@ietfa.amsl.com>; Sat, 26 Aug 2017 11:23:08 -0700 (PDT)
Received: from listserv.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E73FB1329B8 for <dnsop@ietf.org>; Sat, 26 Aug 2017 11:23:06 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1443; t=1503771782; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VCLaJywTm2ROx2mWZJG2H7Q4AzA=; b=hDRaPj6BHCBriEWLZdO0Ke4IV/dvZpa2iAYK95mUWf4N5qOYEZHZiGfpAbAY0Q WbEBJC3icL/ZivGZ3dWRX2AMNITLmFQ4Sfrb2SH+yxCqMosxKSSHJe7nqcVfro8o QH6MVG9hnq079/rE3krKGwRxvDg4PBPmHSslLVjmGCSP0=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:23:02 -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 3835628071.75665.1700; Sat, 26 Aug 2017 14:23:01 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1443; t=1503771726; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KBc/CPK HyazLvzsKTof+c6M8qpNr+rSC0Igjs41UjZU=; b=cOJy9Jyh0HPVV+IIENwZE7M QCZCKhCXeuwY/M2lvSf8jGcEGJtw7ao1TYqGkjHCmUXWtGYVrBFVziAYwQ/r7ZYu nuGzwaquCzYVuYnvO5ny3Oi508DkjU89xfzYA78s2HlVctwaThCWTiVRw3zhGnqa xs89lxxun+aX2UcxZ6Kg=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:22:06 -0400
Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 719606296.9.22788; Sat, 26 Aug 2017 14:22:05 -0400
Message-ID: <59A1BC8A.3050204@isdg.net>
Date: Sat, 26 Aug 2017 14:23:06 -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> <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net>
In-Reply-To: <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Hff8eDvlqCAe-PIdkDQ1HVdGIsg>
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:11 -0000

On 8/24/2017 1:31 PM, Grant Taylor wrote:

>> Before I release my updates, I wonder if this was the right thing to
>> do.
>
> I prefer to use a different method to do classless in-addr.arpa
> delegation.
>
> Specifically, I ask ISPs to put an NS record for the IP(s) in question
> pointing to my own DNS server.  Then I configure zone(s) that match
> the full in-addr.arpa name with the PTR in the zone apex.
>
> You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP
> (a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.)
> with individual PTR records, much like the ISP normally does.
>
> If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd
> recommend that you have NS records for the other 224 IPs that point to
> your ISP's name server that is authoritative for the zone.
>
> In effect, you are actually delegating the IPs an additional level.

This was done, at least the first part of providing the ISP the two NS 
servers required.  They used RFC2317 to setup the cname delegation. 
On my servers, I had done what you suggestion with the second method 
using a parent c.b.a.in-addr.arpa zone.   It all seems to work, except 
for the unexpected cname+ptr records with non-authoritive results.

Still studying the impact.  I was trying to prevent some consistency 
in the results in the resolver.  In the same way, that its done for 
A->CNAME->A results.

Thanks

-- 
HLS