Re: [DNSOP] RFC2317 Question: Resolving cname delegation

Hector Santos <> Sat, 26 August 2017 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8356132BD4 for <>; Sat, 26 Aug 2017 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key) header.b=Cc+IJKC3; dkim=pass (1024-bit key) header.b=fy6cNdM7
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xcjW_nDQ-hU7 for <>; Sat, 26 Aug 2017 11:23:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC1B2132BD7 for <>; Sat, 26 Aug 2017 11:23:16 -0700 (PDT)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2286; t=1503771787;; 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 (Wildcat! SMTP Router v7.0.454.6) for; Sat, 26 Aug 2017 14:23:07 -0400
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all;
Received: from ([]) by (Wildcat! SMTP v7.0.454.6) with ESMTP id 3835633000.75665.5044; Sat, 26 Aug 2017 14:23:06 -0400
DKIM-Signature: v=1;; 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 (Wildcat! SMTP Router v7.0.454.6) for; Sat, 26 Aug 2017 14:22:11 -0400
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.6) with ESMTP id 719611328.9.22800; Sat, 26 Aug 2017 14:22:10 -0400
Message-ID: <>
Date: Sat, 26 Aug 2017 14:23:11 -0400
From: Hector Santos <>
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
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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   PTR     host1   PTR     host2
..   PTR     hostN

The non-authoritive response is:

qname                  qtype   data   CNAME PTR     host1 PTR     host2
.. 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 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.