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

[Matthijs Mekking <[e-mail]>]

Hi Klaus,

On 5/29/19 9:34 AM, Klaus Malorny wrote:
> On 28.05.19 21:14, Matthijs Mekking wrote:
>> Hi Klaus,
>>
> 
> Hi Matthijs,
> 
>> I provided responses inline.
> 
> I too.
> 
>>
>> On 5/28/19 5:49 PM, Klaus Malorny wrote:
>>>
>>>
>>> Hi all,
>>>
>>> [...]
>>
>> I am not sure what text in Section 3 you are referring to, can you quote
>> the specific text?
>>
>> AFAICS there is nothing that says the visited ANAMEs and CNAMEs needs to
>> be set in the Additional section.  Visited ANAME and CNAME records are
>> used to adjust the owner name and the TTL.
> 
> Well, just the two sentences just below the headline of section 3:
> 
>    The requirements in this section apply to both recursive and
>    authoritative servers.
>    ^^^^^^^^^^^^^
> 
>    An ANAME target MAY resolve to address records via a chain of CNAME
>    and/or ANAME records; any CNAME/ANAME chain MUST be included when
>                                          ^^^^^^^^^^^^^^^^^^^^^^^
>    adding target address records to a response's Additional section.
> 
> Along with the following requirement of 3.1:
> 
>    o  MAY contain the target address records that match the query type
>       (or the corresponding proof of nonexistence), if they are
>       available and the target address RDATA fields differ from the
>       sibling address RRset.
> 
> So, I can choose to add the target addresses to the additional section,
> but then I have to add the full path of ANAME/CNAME/DNAME(?) also. This
> is my interpretation.

Stupid me, I looked at the work in progress draft in the github, where
the additional section processing sections have been split in
authoritative servers and resolvers.

But yeah, in -03 that seems right.  I was thinking of leaving out this
MAY keyword for authoritative servers because the target address records
are normally not available there, but if there is a caching resolver
inside the authoritative it may have them.  And so perhaps the MAY
keyword should stay for both cases.


Best regards,

Matthijs