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

Matthijs Mekking <matthijs@pletterpet.nl> Wed, 29 May 2019 06:25 UTC

Return-Path: <matthijs@pletterpet.nl>
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 3EE3F12008B for <dnsop@ietfa.amsl.com>; Tue, 28 May 2019 23:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 q5FpU2-PeXmU for <dnsop@ietfa.amsl.com>; Tue, 28 May 2019 23:25:34 -0700 (PDT)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 34A7E120019 for <dnsop@ietf.org>; Tue, 28 May 2019 23:25:33 -0700 (PDT)
Received: from [IPv6:2001:980:4eb1:1:e522:da23:9773:2af5] ([IPv6:2001:980:4eb1:1:e522:da23:9773:2af5]) by smtp-cloud9.xs4all.net with ESMTPSA id Vs1fhnJmcsDWyVs1ghfZlm; Wed, 29 May 2019 08:25:28 +0200
To: Ralf Weber <dns@fl1ger.de>
Cc: dnsop@ietf.org
References: <54f0a685-0a57-2821-26cc-c136c39e7750@knipp.de> <59692e76-d5f3-eab0-7fe7-150a0430b32e@pletterpet.nl> <291E9200-6C8C-44DA-A238-12935BC6BA33@fl1ger.de>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <f94f6db2-9017-5ef7-9798-0200834cbca7@pletterpet.nl>
Date: Wed, 29 May 2019 08:25:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <291E9200-6C8C-44DA-A238-12935BC6BA33@fl1ger.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfNlh3htbXefOHD7bnwJr5lr8tCppOTDxMJD7myHM0xqbf/U3dYvRXYvghZRc7vAAA8uX9XP0bd4St6ctgd2vtezDETY4x9Xgyn2Sc0M00K6hY9DUbOFY DGrWnm3ZByuTguPeSrnuP/D5UaOnw4FSksMc+M02+yRHQAelW5yki9hBuiYq6wsogpL9HXtaouZ+WTEGOk/7ahrJYhPMYUIAa9G2VFoHEwSOwXKl0I9OnH86 5J6TFYgCYT5rGkyYoI1v/V+aAdmBao4m4+2qiA6e9kyubsK94xufl1h+AyxAwQnk
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DugtbpQOFa8bs0ZD729QHOikTPQ>
Subject: Re: [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: Wed, 29 May 2019 06:25:36 -0000

Hi Ralf,

On 5/29/19 7:42 AM, Ralf Weber wrote:
> Moin!
> 
> On 28 May 2019, at 21:14, Matthijs Mekking wrote:
>> For authoritative servers that receive A or AAAA requests, the address
>> records shall appear only once: in the answer section.  It is correct
>> that those address records have the owner name and TTL adjusted (to the
>> owner name of the ANAME record and the minimum of the encountered TTLs).
>>
>> There is nothing in the additional section, except for the ANAME record,
>> as described in Section 6.1.1:
>>
>>    When a server receives an address query for a name that has an ANAME
>>    record, the response's Additional section MUST contain the ANAME
>>    record.  The ANAME record indicates to a client that it might wish to
>>    resolve the target address records itself.
> So that means an authoritative server could just use the “static” A
> records in the zone and just put in the ANAME in the additional section
> and not do any special processing at all, hoping the resolver does
> follow the ANAME?

Yes, it could do that. But it is not likely that this scenario is
particularly useful in the early stage of ANAME deployment.


>> Note that there is separate additional processing for authoritative
>> servers and resolvers.  For resolvers there is a requirement of having
>> target address records in the additional section.
> Why? They are the same that are in the answer section and for DNSSEC
> the signed ANAME is important and not the unsigned addresses or am I
> missing something?

Why is there a requirement or why is there a difference?

First, the word "requirement" is causing confusion here, I am sorry.
What I meant is that for resolvers the draft has a RFC 2119 keyword
related to adding target address records in the additional section (it's
a MAY). So not required, but optional.

Why is there different additional processing for authoritative servers
and resolvers?  Basically because in a traditional authoritative name
server the target address records are not available (so adding them is
not in scope), but a resolver may have them in the cache (and note these
may be signed address records).


Best regards,

Matthijs



> 
> So long
> -Ralf
> —--
> Ralf Weber
>