Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-04.txt

[Matthijs Mekking <[e-mail]>]

Hi Petr,

On 7/22/19 10:21 PM, Petr Špaček wrote:
> Hello,
> 
> this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes -

Thanks.


> I've managed to forget the old versions ;-)

Very wise :)

Comments below:


> On 08. 07. 19 22:05, [e-mail] wrote:
>> 	Filename        : draft-ietf-dnsop-aname-04.txt
> 
>> 4.  ANAME processing by primary masters
>>   o  Otherwise, wait until the target address RRset TTL has expired or
>>       is close to expiring, then repeat.
> 
> TTL handling in section 4 seems to be different than TTL handling in
> section 3 (Substituting ANAME sibling address records), which says "Set
> the TTL to the minimum of the ANAME TTL, the TTL of each intermediate
> record, and the TTL of the target address records."
> 
> Is it intentional?

Section 3 talks about what TTL to use when replacing sibling address
records with the target data.

Section 4 talks about when a primary master should query for target
data, and this interval is based on the TTL of the target data.

These are two different operations and so to answer your question: yes
this is intentional.

Then in Section 4.3 there is a bit more text on TTLs. Rereading those
paragraphs, I think the following lines might be confusing:

   Normally this TTL is expected to be the same as the
   target address records' TTL; ...

   This means that when adding address records into the zone as a result
   of ANAME processing, the TTL to use is at most that of the TTL of the
   target address records.

What is meant with the first line is that in normal cases the TTL of the
substituted sibling address records equals the TTL of the target address
records, but things like ANAME/CNAME chains, policies may affect this.

The second line says that the substituted sibling address records will
have a TTL that is at least not larger than that of the target address
records.


>> 4.  ANAME processing by primary masters
>>    Sibling address records are committed to the zone and stored in
>>    nonvolatile storage.
> 
> I propose to use this wording:
> "Sibling address records are committed to the zone as if replacement was
> done using dynamic update protocol, including normal zone maintenance
> (e.g. SOA serial update, DNSSEC resigning when applicable etc.)."
> 
> Reasoning:
> - It is better to be explicit and stress out that this is just normal
> zone update including all the maintenance.
> - I would hate to prescribe how servers should store their data in RR
> type spec ("non-volatile storage" etc.).

Yes, it is a normal zone update, but I would not like to require the
Dynamic Update protocol.  This could also be done by a small tool that
edits the zonefile for example.


>> 5.  ANAME processing by resolvers
>> the resolver might
>>       not be able to validate them because of a broken chain of trust,
>>       but its client could have an extra trust anchor that does allow it
>>       to validate them
> 
> I propose to use term "incomplete chain of trust" instead of "broken
> chain of trust". Broken would (at least in my head) imply bogus and
> that's different state than insecure.

Good point. Will change it.


>> 5.  ANAME processing by resolvers
> Editorial nit:
> It seems that current section 5 could be split into two sections:
> "recursive resolvers" and "stub resolvers". Such split would simplify
> the long explanatory paragraphs currently present in parentheses and be
> easier to follow.

I'll make a GitHub issue for this. Please provide text :)


> Semantic problem:
> I think the current section 5 needs to explicitly specify something
> along lines "resolver MUST NOT perform ANAME sibling address record
> substitution if resolver's client queries with DO=1 and the target name
> is signed".

Do you mean "and the sibling address RRset" is signed? Because that
matches the name that is queried for (the target name is referenced by
the right side of the ANAME).


>> 6.1.1.  Address queries
>>    When a server receives an address query for a name that has an ANAME
>>    record, the response's Answer section MUST contain the ANAME record,
>>    in addition to the sibling address queries.
> 
> Are there some statistics showing impact of ANAME in Answer section
> (together with address records)? I've read previous discussion about
> DNAME, but AFAIK DNAME is almost unused on the public Internet which
> implies that DNAME does not give real deployment experience.

What would be good to know if there are statistics showing impact of
other RRtype in answer section together with requested type records.

We have had this discussion see:

 https://github.com/each/draft-aname/issues/62
 https://mailarchive.ietf.org/arch/msg/dnsop/7ZKB4N4kFIXC3SSMVHzA3e-rOJk


> Maybe APNIC could use their test machinery and send ANAME along with
> A/AAAA responses?

Yes please :)


>> 6.1.  Authoritative servers
>> 6.1.2.  ANAME queries
>>
>>    When a server receives an query for type ANAME, regardless of whether
>>    the ANAME record exists on the queried domain, any sibling address
>>    records SHOULD be added to the Additional section.  Note that the
>>    sibling address records may have been substituted already.
>>
>>    When adding address records to the Additional section, if not all
>>    address types are present and the zone is signed, the server SHOULD
>>    include a DNSSEC proof of nonexistence for the missing address types.
> 
> SHOULDs in this section make me (as resolver implementor) nervous. It
> would be much simpler for resolvers if these were MUST because resolvers
> would not need to worry about missing A/AAAAs in ANAME queries.

I understand your reasoning but remember:

1. SHOULD means you should do it unless you have a real good reason not
to do so.

2. Records in additional section may already be omitted because of
truncation, minimal responses, ...

Also note that this is a query for the ANAME type, not A or AAAA so this
is likely a query that does ANAME target lookup.


>> 6.1.2.  ANAME queries
>>    When adding address records to the Additional section, if not all
>>    address types are present and the zone is signed, the server SHOULD
>>    include a DNSSEC proof of nonexistence for the missing address types.
> 
> Why SHOULD and not MUST? It is super hard to do correct decisions on
> receiving side with SHOULDs all over the protocol...

See above (but I am happy to make this a MUST if people think that's
better).


> With resolver implementer hat on I would like to see either:
> a) Removal of additional processing because its current form is unreliable.
> 
> b) Some behavior which is guaranteed to give all address types + signal,
> that it is supported (so we can distinguish no addresses from missing
> ANAME support). That might be useful as shortcut for "all address records".
> 
> Anything between is IMHO waste of engineering time.

I made https://github.com/each/draft-aname/issues/73 for this.


>> 6.2.  Resolvers
>> 6.2.1.  Address queries
>>    When a server receives an address query for a name that has an ANAME
>>    record, the response's Answer section MUST contain the ANAME record,
>>    in addition to the sibling address queries.
> 
> Here I have even stronger concerns voiced already in auth section 6.1.1.
>  Address queries. We need more data ... or flag day 2021 for unexpected
> types in answers :-D
> 
> The idea itself is okay, assuming it actually works on the Internet.
> 
> 
>>    The Additional section MAY contain the target address records that
>>    match the query type (or the corresponding proof of nonexistence), if
>>    they are available in the cache and the target address RDATA fields
>>    differ from the sibling address RRset.
> 
> This is confusing, because section 3 instructs auth to replace sibling
> address records with target address records ... so I do not see the
> value of repeating the records in Answer and Additional.
>
> What am I missing?

Authoritative may have replaced it, but it also may have not. This
document does not enforce ANAME target lookups by authoritative or
resolver. If nobody does it the behavior is similar as if you would put
just address records in your zone.

The idea is that DNS providers for CDNs will implement this at their
authoritatives (along with the special sauce that is called ECS, lookup
on the fly, DNSSEC online signing). The same parties that now have their
own proprietary solutions that prevent their customers from supporting
the multiple provider model. And perhaps in the future, browsers will
query for ANAME (or HTTP*) record directly, doing the target lookup
themselves.

The idea is that anyone can do it, but if multiple parties will do ANAME
processing it may be redundant but it will still work.

So the resolver may perform ANAME processing too. It queries for the
targets and may replace the address records in the Answer section. The
encountered target records may be useful information to the requester.

But I think there is at least an error in that paragraph: "target
address records that match the query type". This will never be true
because the query type will match the sibling address records (those
next to the ANAME record).

> Besides that, MAY is not useful for developers of resolvers and clients ...

To be honest I also question how useful it is to give back that information.


>>    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.
> 
> What is the purpose here? The only thing I can imagine is
> DNSSEC-validating client which follows chain from ANAME down to the
> target address records, but I'm not sure it is worth optimizing for it.
> If we wanted to optimize validating clients we should go for RFC 7901
> CHAIN query and specify interaction with it.

Right, I think Tony added that for the DNSSEC case.


> Proposal: Remove this paragraph completely.

Disagree because one way or another we do need to support DNSSEC
validation at the client.


>> 6.2.2.  ANAME queries
> 
> Same proposal as for 6.2.1.:
> 
> Pick a sensible behavior and use it consistently, pretty please. It
> would greatly simplify implementation.

Covered by the same GitHub issue.


> To conclude, I think we need to give more time and thought to
> specification how queries affected by ANAME should be responded to.

Err, does not compute. What do you mean with that?


Thanks again for your review,

Cheers,

Matthijs