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

[Matthijs Mekking <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop