[DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

Klaus Malorny <Klaus.Malorny@knipp.de> Tue, 28 May 2019 15:50 UTC

Return-Path: <Klaus.Malorny@knipp.de>
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 28EBA12010F for <dnsop@ietfa.amsl.com>; Tue, 28 May 2019 08:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 pWJpU6GqJA1A for <dnsop@ietfa.amsl.com>; Tue, 28 May 2019 08:50:49 -0700 (PDT)
Received: from kmx5b.knipp.de (kmx5b.knipp.de [IPv6:2a01:5b0:0:29::6a]) (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 12FFA120179 for <dnsop@ietf.org>; Tue, 28 May 2019 08:50:48 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5b.knipp.de (Postfix) with ESMTP id 887D9300739; Tue, 28 May 2019 15:50:45 +0000 (UTC)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (Postfix) with ESMTP id 80A3FA380C; Tue, 28 May 2019 17:50:15 +0200 (MESZ)
To: dnsop@ietf.org
From: Klaus Malorny <Klaus.Malorny@knipp.de>
Message-ID: <54f0a685-0a57-2821-26cc-c136c39e7750@knipp.de>
Date: Tue, 28 May 2019 17:49:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Thunderbird/69.0a1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
Authentication-Results: kmx5b.knipp.de; none
X-Rspamd-Server: s671
X-Rspamd-Queue-Id: 887D9300739
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; IP_WHITELIST(0.00)[195.253.2.54]
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jcbRhLx-YGJHrITyZBVptt3F3Lc>
Subject: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 May 2019 15:50:51 -0000


Hi all,

I am working on an experimental implementation of ANAMEs in our authoritative 
name server software, which shall perform its own ANAME lookup. I am a bit 
puzzled what is really expected to be returned for regular address (A/AAAA) 
queries.


- Is it right that the determined target address records shall appear twice, 
first in the answer section, with the query name as the owner and the TTL 
adjusted (based on the involved records), second in the original form in the 
additional section?


- It is not yet quite clear to me what the purpose of recording the visited 
ANAMEs and CNAMEs beyond the very first ANAME in the additional section, as 
described in the section 3. Is it of any use for an aware resolver? Shall it 
validate the path to the target addresses in order to recognize them as such? 
And what about DNAMEs? I constructed a nice example, despite not knowing whether 
such a situation would ever occur in real life:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3
;; flags: qr aa ; qd: 1 an: 1 au: 0 ad: 5
;; QUESTIONS:
;;	multi.example., type = AAAA, class = IN

;; ANSWERS:
multi.example.		20000	IN	AAAA	fe:dc:ba:98:76:54:32:10

;; AUTHORITY RECORDS:

;; ADDITIONAL RECORDS:
multi.example.		86400	IN	ANAME	redir1.target.
redir1.target.		20000	IN	CNAME	redir2.sub.target.
sub.target.		86400	IN	DNAME	base.target.
redir2.base.target.	86400	IN	ANAME	redir3.target.
redir3.target.		30000	IN	AAAA	fe:dc:ba:98:76:54:32:10

;; Message size: 223 bytes


- if the name server chooses to cache the target address records (and the 
intermediate xNAME records), shall the answer reflect the age of the cache 
entries in the TTLs (i.e. be subtracted) of the records in the answer and/or 
additional section?

Sorry in case that the questions do not make sense. I have to admit that I have 
not yet fully understood the document in all aspects. But that's why I am asking.

Regards,

Klaus