Hi Klaus, I provided responses inline.
On 5/28/19 5:49 PM, Klaus Malorny wrote: > > > 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? 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. 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. > - 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 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. > - 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? There is some guidance in appendix C on this: - In principle you should use a fixed TTL (no decremented TTLs) to avoid query bunching (C.1). - If the ANAME target lookup is done inside the name server, and implements a cache, may use a decremented TTL in the response to the client rather than using the original target address records' TTL, but not a near zero TTL (C.4). Hope this helps. > 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. No worries, and really: thank you for asking! If the specification is not clear, we should improve it. Please do not hesitate to send in text suggestions on this list or on the github (https://github.com/each/draft-aname). Matthijs > > Regards, > > Klaus > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
