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