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

From: Klaus Malorny <[email-masked]>
Date: Tue, 28 May 2019 17:49:52 +0200

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?

- 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

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

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.

Regards,

Klaus

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 28 May 2019 21:14:47 +0200

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

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

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 29 May 2019 07:42:24 +0200

Moin!

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

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

So long
-Ralf
—--
Ralf Weber

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 29 May 2019 08:25:27 +0200

Hi Ralf,

> and not do any special processing at all, hoping the resolver does

Yes, it could do that. But it is not likely that this scenario is
particularly useful in the early stage of ANAME deployment.

> the signed ANAME is important and not the unsigned addresses or am I

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

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 29 May 2019 09:34:00 +0200

> Hi Klaus,

Hi Matthijs,

> I provided responses inline.

I too.

>> [...]
>> [...]

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.

> not a near zero TTL (C.4).

Ah, ok. This is helpful.

Thanks for answering.

Klaus

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 29 May 2019 10:52:09 +0200

Hi Klaus,

On 5/29/19 9:34 AM, Klaus Malorny wrote:
> 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