Hello,
this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes -
I've managed to forget the old versions ;-)
On 08. 07. 19 22:05, internet-dra...@ietf.org 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?
> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
