Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 05 July 2018 16:30 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 0F12412785F for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 09:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 X4CqRF5vYh6y for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 09:30:27 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B371129C6A for <dnsop@ietf.org>; Thu, 5 Jul 2018 09:30:26 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id 69-v6so11845931wmf.3 for <dnsop@ietf.org>; Thu, 05 Jul 2018 09:30:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Dhw/z/AyYNfoF+Vb4vSdKaAShoL1kVCPfUujb9aDLYk=; b=G4SEPD4R3TZptxRI8uafQarUP3gLh0y+fTHSQs2xgVCG7PID4/qY0GeFt/1pta9vH1 qk4Iac/S0/VtVsoPvSTYp7SvY2voFw48MXCQYcsoylfxT+qEX6fIEsdsrv2MvqbHhRGr euxwGX8vbcwcwNKMiVZa+T2OTTt1Y47p7tdc42o1jfX+Dw2X8BwGkKO3icniD0QPJRmm 7k6j+Y2fZ7yhSMoLhW3OCLsSHFDM1Xabd6PwwSGOpA0Sd/kTcqBkVHwNhPh+jF3J3kpP VH1Nahp+ag7YKzCF4C/HazZ7LDtuivCFaIlYs/0y20RC23NaMRy3xrMASrVq33MrVaxv ag+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Dhw/z/AyYNfoF+Vb4vSdKaAShoL1kVCPfUujb9aDLYk=; b=oISmRtSBRhHmiOgDJaZQJPNIF3A+A0NE7aV+vlIErsa5ZUXyxH7HkKJep52B5GvZYV qqz5Yw0E9Dzvcmtn+CKvNQVH8zp5DFcGG6Rc5yRxFCdOaICBjVTFMJXE+S+FP6I8ATPN 2rTHdcXjFfLiIeSqqw3QPcRUI+FzAVNKxbxPaL/lJM/1ZWw8JHMAzCWh2T5LjtsR1CJJ +boq/Wvguqdj/SPEYpEFRHvXzB72n3wNRiln+HLWREE74QQtEvPjDbLzIOSCRqQrugks 7AUq7F+b6V60bfwoDdLAyBX2jZNgK1LbJMsf4ha+UzJ88muLI4PEkYOdmoP7sPCgMbFf Fx9g==
X-Gm-Message-State: APt69E350dtFBRAhMtN/iTXRQiRR692cf/MZXGKv5rfFQ5aR86QRc9an mh9UM9dnNuVTEmncszzpWAJBsq1tYJ5rGLRFWMHyyg==
X-Google-Smtp-Source: AAOMgpcFQ4F9F/iAWwwlPfW42s8lyaTgv2IgeGwvIJTRFodmvQuw4AKNqhUBgRcJp2HZXGsDL0tTT3dEldg/0uBjiBM=
X-Received: by 2002:a1c:99c5:: with SMTP id b188-v6mr4226928wme.15.1530808224736; Thu, 05 Jul 2018 09:30:24 -0700 (PDT)
MIME-Version: 1.0
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 05 Jul 2018 09:30:13 -0700
Message-ID: <CAH1iCirhDz3E2nu+LUvNM4gWfKaWFZiNCkwLTYBVYXuBqM=c3A@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000746ce30570431014"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9OxPrROEHpRz8qc34O3AqWDGZgQ>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 16:30:30 -0000

Paul Vixie wrote:

> Tony Finch wrote:
>
> Paul Wouters<paul at nohats.ca>  wrote:
>
> I understand, I just disagree this is the right way. I don't see why
> this entire problem shouldn't be resolved at the well, resolver level.
>
> I don't see how that can be deployed in a way that is compatible with
> existing software.
>
> there are now a half dozen x.x.x.x (where x is the same in all four octets)
> public anycast resolvers. if they can all be upgraded to handle dnssec or
> ECS, they can all be upgraded to handle something like ANAME.
>
> the "resolver" here is the recursive, not the stub. stubs believe what they
> hear, for good or ill. if we need to change what they hear, it's not as
> impossible as changing what they understand.
>
> --
> P Vixie
>
>
>
Apologies for a late response to an early part of the thread/discussion.

To paraphrase (hopefully correctly), we should be looking at ways of
getting the resolver to possibly just return A records (with appropriate
TTL) to stubs, even if the recursive was handed something along the likes
of an apex CNAME that it understood, or something that achieves the same
effect if the apex CNAME isn't something the resolver understands.

I think there is something that can be borrowed from the DNSSEC DNAME
stuff, where a DNAME signed response is accompanied by an unsigned CNAME.
DNAME-aware resolvers use/cache it, while DNAME-unaware resolvers get the
synthesized CNAME which they can cache. DNSSEC required DNAME, which is
very helpful -- this ensures the unsigned CNAME isn't breaking validation.

The thing to note about DNAME/CNAME, is that there is a performance/scale
benefit to having a resolver that understands DNAME. The CNAME hack works,
but can require much more work by the resolver (in terms of query to the
authoritative). Having DNSSEC-unaware resolver clients is pretty easy, as
the resolver can do its own CNAME synthesis.

The analogous set-up would be a CNAME2 RR type accompanied by (or replaced
by) a corresponding CNAME RR with TTL=0. I think it would preferable to use
a bit flag in the EDNS bitfield, where the client can signal CNAME2
awareness, and the server can signal its own support on replies. And I
think chaining involving both types (regardless of order of type in an
ordered chain) produces correct results/behavior.

(In the following, foo2 means foo understands CNAME2, foo means it doesn't)

foo -> resolver -> auth2 : auth2 sends CNAME TTL=0, resolver sends (but
does not cache) CNAME TTL=0.
foo -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2,
sends CNAME with TTL=0.
foo2 -> resolver2 -> auth2 : auth2 sends CNAME2, resolver caches CNAME2,
sends CNAME2 response.

CNAME2 would need to have a bitfield of applicable RRTYPEs, similar to
NSEC/NSEC3.

resolver2 would then be able to synthesize CNAME TTL=0 responses for
subsequent queries from foo (or any other non-CNAME2-aware client).

Other than performance load due to TTL=0 for popular domains, which
admittedly is a big one, I don't think this wouldn't work.

This is probably something that would require substantial deployment in the
resolver community before it likely gets much use on the auth side.

Thoughts? Or discuss in Montreal...

Brian