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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
