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

From: Stefan Bühler <[email-masked]>
Date: Sat, 3 Feb 2018 12:20:34 +0100

Hi again,

On 01/26/2018 09:09 PM, Evan Hunt wrote:
>> I have concerns about the resolver replacing A/AAAA records in signed
>> zones as it breaks validation.
> 
> What do you mean by "the resolver" in this case?

The "recursive resolver".

>> If a resolver understanding ANAME is queried using the DO=1 flag it
>> shouldn't touch the A/AAAA records, because it already knows the
>> requestor would through them away.
> 
> It doesn't *know*. DO=1 doesn't mean the client is validating; it means the
> client understands RRSIG.

Well, better safe than sorry.

Tony Finch had a more detailed suggestion which sounds good to me.

> The draft already advises that ANAME will break validation unless the
> validator is ANAME-aware or the auth server has access to the zone's
> private key and can sign responses on the fly. (This suggests to me that
> the use of ANAME in signed zones will probably be limited at first.)

This advise suggests that if the auth server has access to the zone's
private key and can sign responses on the fly, ANAME works with signed
zones.

But it doesn't!  Because ANAME-aware recursive resolvers will replace
the signed records with unsigned ones.  If the next client (which
queried the ANAME-aware recursive resolver, but isn't ANAME-aware
itself) tries to validate the answer it will reject the address records,
and won't be able to resolve them again with ANAME.

Which means in the current proposal you can't use ANAME in a signed zone
unless you know that ALL validating clients are either ANAME-aware or
don't have a ANAME-aware recursive resolver in the chain to the auth.

>> This also means a caching resolver should store the original A/AAAA
>> records (and not the ones resolved through ANAME) in the cache.
> 
> Certainly.
> 
>> With this change I don't think it makes sense to say "a resolver MUST
>> re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and
>> the query didn't use DO=1".
> 
> I'm sorry, I'm not getting this. Please explain further, particularly
> with an expansion of the word "it"?

"it" as "the resolver".  I think the text suggested by Tony Finch covers
the DO=1 part.

I'd also suggest to relax the "MUST re-query" requirement if the
resolver used ECS - because it means the auth server had a good chance
to respect the network topology (this is unrelated to signed zones).

cheers,
Stefan

---

From: Evan Hunt <[email-masked]>
Date: Sat, 3 Feb 2018 22:10:46 +0000

On Sat, Feb 03, 2018 at 12:20:34PM +0100, Stefan Bühler wrote:
> the signed records with unsigned ones.

No, an ANAME-aware resolver would ignore those records, re-query for
the ANAME target, and validate the response from there - same as it does
now with a CNAME. As long as the ANAME is validly signed, it's just a
chain query.

> to respect the network topology (this is unrelated to signed zones).

It's the same requirement as for CNAME. Putting full trust in a chain
returned by an auth server risks cache poisoning. (Not even necessarily
malicious; the auth might simply be serving information that's outdated.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Feb 2018 12:38:47 +0000

> now with a CNAME. As long as the ANAME is validly signed, it's just a

That only works if the downstream resolvers (stubs etc.) are not
validating. (Or maybe if they are ANAME-aware but the upstream resolver
has no way of knowing that.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: Southwest, veering northwest 5 to 7, occasionally gale 8 at
first in Hebrides, then perhaps gale 8 later. Rough or very rough, becoming
high later in west. Rain then snow showers. Good, occasionally poor.