Re: [DNSOP] RFC2317 Question: Resolving cname delegation

Grant Taylor <gtaylor@tnetconsulting.net> Thu, 24 August 2017 17:31 UTC

Return-Path: <gtaylor@tnetconsulting.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 E227E132418 for <dnsop@ietfa.amsl.com>; Thu, 24 Aug 2017 10:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net
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 XCePwViaripd for <dnsop@ietfa.amsl.com>; Thu, 24 Aug 2017 10:31:08 -0700 (PDT)
Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 5D30413202D for <dnsop@ietf.org>; Thu, 24 Aug 2017 10:31:08 -0700 (PDT)
Received: from hal9000.thn.corp.google.com ([IPv6:2620:0:102a:11:887e:3068:91e8:1e9d]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v7OHVCe4003292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <dnsop@ietf.org>; Thu, 24 Aug 2017 12:31:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1503595874; bh=+P4KWC31EHFnrghykaYwn6lXOyPqXbpa1RoUxxzc5ro=; h=Subject:To:References:From:Date:In-Reply-To:From; b=osB8ZqYpm0YCN/O9rVa75xgpJkHTM+ngg4AFo3IU1Vi2XUHie7evAsfgmzgd5Ymnh BnTaJMTB10sCMVNtNUW2QI7EHqn33jqsTaqAfKPneXu03qYUt6FNHX7y9pKiVR17cO sMJWKLJthySdxlL4etPwXa8IEhhKbje+4NE5rM1g=
To: dnsop@ietf.org
References: <599EF4F2.6070509@isdg.net>
From: Grant Taylor <gtaylor@tnetconsulting.net>
Message-ID: <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net>
Date: Thu, 24 Aug 2017 11:31:06 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <599EF4F2.6070509@isdg.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020302080308020207050309"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nyEE6Lnm40oUG-EUhK0v42rkypE>
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: Thu, 24 Aug 2017 17:31:11 -0000

On 08/24/2017 09:46 AM, 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?

This is one of the gotchas for classless in-addr.arpa delegation.

> 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.

I got bit by SORBS not understanding classless in-addr.arpa delegation 
(since been fixed) more than a decade ago and have never had any similar 
problems.



-- 
Grant. . . .
unix || die