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

From: [email-masked]
Date: Mon, 08 Jul 2019 13:05:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Address-specific DNS aliases (ANAME)
        Authors         : Tony Finch
                          Evan Hunt
                          Peter van Dijk
                          Anthony Eden
                          Matthijs Mekking
	Filename        : draft-ietf-dnsop-aname-04.txt
	Pages           : 17
	Date            : 2019-07-08

Abstract:
   This document defines the "ANAME" DNS RR type, to provide similar
   functionality to CNAME, but only for address queries.  Unlike CNAME,
   an ANAME can coexist with other record types.  The ANAME RR allows
   zone owners to make an apex domain name into an alias in a standards
   compliant manner.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-aname-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Petr Špaček <[email-masked]>
Date: Mon, 22 Jul 2019 16:21:10 -0400

Hello,

this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes -
I've managed to forget the old versions ;-)

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

> 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.).

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

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

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".

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

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

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

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

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.

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

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

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

Proposal: Remove this paragraph completely.

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

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

-- 
Petr Špaček  @  CZ.NIC

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 23 Jul 2019 10:34:34 +0200

Hi Petr,

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

> record, and the TTL of the target address records."

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.

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

> that's different state than insecure.

Good point. Will change it.

> the long explanatory paragraphs currently present in parentheses and be

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

> substitution if resolver's client queries with DO=1 and the target name

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).

> 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

Yes please :)

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

> 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).

> Anything between is IMHO waste of engineering time.

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

> value of repeating the records in Answer and Additional.

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.

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

> would greatly simplify implementation.

Covered by the same GitHub issue.

> 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