[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
- [DNSOP] question regarding draft-ietf-dnsop-aname… Klaus Malorny
- Re: [DNSOP] question regarding draft-ietf-dnsop-a… Matthijs Mekking
- Re: [DNSOP] question regarding draft-ietf-dnsop-a… Ralf Weber
- Re: [DNSOP] question regarding draft-ietf-dnsop-a… Matthijs Mekking
- Re: [DNSOP] question regarding draft-ietf-dnsop-a… Klaus Malorny
- Re: [DNSOP] question regarding draft-ietf-dnsop-a… Matthijs Mekking