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

Stefan Bühler <ietf-dnsop@stbuehler.de> Sat, 03 February 2018 11:20 UTC

Return-Path: <ietf-dnsop@stbuehler.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632A212711E for <dnsop@ietfa.amsl.com>; Sat, 3 Feb 2018 03:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LJCv4TQNiK2 for <dnsop@ietfa.amsl.com>; Sat, 3 Feb 2018 03:20:39 -0800 (PST)
Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B48D126BF3 for <dnsop@ietf.org>; Sat, 3 Feb 2018 03:20:39 -0800 (PST)
Received: from [IPv6:2a02:8070:a29c:5000:8cab:9f98:b4af:2a05] (unknown [IPv6:2a02:8070:a29c:5000:8cab:9f98:b4af:2a05]) by mail.stbuehler.de (Postfix) with ESMTPSA id B2219B8034D; Sat, 3 Feb 2018 11:20:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1517656835; bh=Osju6FncMfFViFftJGMB3OzDPo+3S4TmTA1s8svtzpY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=glpY9Ufls43mqui9yIFy7VR98WSWlpeQxuw7a7+iE0zRsYONO2dvarbywp48pHWCm 4dzaGVs3h8hiSrfe0mi7pV+el4+d18Rrrrc2KU2SaVkYFBq4mI/vUGeLfVcOJCMHqf N2Eu4Xjn1cfKPl81gtEp6bmp8MIq5kAzEdZOVxAM=
To: Evan Hunt <each@isc.org>
Cc: dnsop@ietf.org
References: <151573473976.18703.16142464801623244164@ietfa.amsl.com> <102bc41e-d2cf-e184-4bec-b1fdf945ae3e@stbuehler.de> <20180126200942.GA7808@isc.org>
From: Stefan Bühler <ietf-dnsop@stbuehler.de>
Message-ID: <29db47a4-2355-2eae-de68-b4bb18b4ebaf@stbuehler.de>
Date: Sat, 03 Feb 2018 12:20:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180126200942.GA7808@isc.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VYKYhtpATNHEEgwjLOs0_PJWTtg>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Feb 2018 11:20:42 -0000

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