IETF Logo Mail Archive

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

"John R Levine" <johnl@taugh.com> Sat, 23 June 2018 01:18 UTC

Return-Path: <johnl@taugh.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 0FF41130DC5 for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 18:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=CLkQ12ZL; dkim=pass (1536-bit key) header.d=taugh.com header.b=iMRMgh8y
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 gtd5Ptc1nCQy for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 18:18:28 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9D57D12F1A5 for <dnsop@ietf.org>; Fri, 22 Jun 2018 18:18:28 -0700 (PDT)
Received: (qmail 72912 invoked from network); 23 Jun 2018 01:18:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11ccc.5b2d9fe2.k1806; bh=AXIis3y8mVgm5crH/CL4h/A07K/a9dKvdL7oilvQGzA=; b=CLkQ12ZL1WJlO8ZNvUYjHN4uafk4F2b+ST+L4jf3x2kf4pVPXrrz/Yk+FY/Fe2vhD64Pnb3hLbket0HTgdEelGaoula1lujBHRy6MHe2f2DkxrkaIRdmfDEOX5VVsdcQ0iOI5UsWv6lKUFkihwZVGntz8DL+Gbg8aMjTnHyoRTnX9I0G3gGUXO9fohq1VB4dhO7t/paQ0i/+JtDBkIPEm3wU9AEVVAMYBZwPklapvpR2Vbe60VYa5kCkY0SsuoqM
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=11ccc.5b2d9fe2.k1806; bh=AXIis3y8mVgm5crH/CL4h/A07K/a9dKvdL7oilvQGzA=; b=iMRMgh8y7F1DvegZZuDRzH11yaEKO1/xrl9OLZixKMW3KmcGx6y9VQcs+N56eHkqkskEA80WHJec1C4xIde4sl8u1ryPLjs3MRO1J7Haq7cadp5CgRWcgCgCQtOaM/oYYfKSI51zVNdfSdu+sEyaCL8wa/+KZCHwIeQcWMZt/6ErGNWy1mttNa0P5QGr2DZe6asxeyLSmtjq0vZ/MBtq7ihIqqbZz83BugltKpLSQvxkuO6ZyI8oda+HdHYuP1X7
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 23 Jun 2018 01:18:26 -0000
Date: Fri, 22 Jun 2018 21:18:25 -0400
Message-ID: <alpine.OSX.2.21.1806222114230.31259@ary.qy>
From: John R Levine <johnl@taugh.com>
To: Evan Hunt <each@isc.org>
Cc: dnsop@ietf.org
In-Reply-To: <20180623004010.GE83312@isc.org>
References: <CAJhMdTO2kj+nUqESg3ew=wwZuB9OzkJE6pST=mae7pHiEk4-Qw@mail.gmail.com> <20180619190213.B76962846E19@ary.qy> <20180622182752.GA83312@isc.org> <alpine.OSX.2.21.1806221517590.29829@ary.qy> <20180623004010.GE83312@isc.org>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BcBB4pD7kSjGegdWkPryTxEH52c>
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: Sat, 23 Jun 2018 01:18:31 -0000

On Sat, 23 Jun 2018, Evan Hunt wrote:
>> Either way we end up importing all of the failure modes of a recursive
>> server into an authoritative one.
>
> I wasn't disagreeing about it being regrettable, I just wanted to nip in
> the bud any repeat of the argument that the auth server would itself have
> to be upgraded into a recursive server.

Like I said, it's a disctinction without a difference.  I don't care 
whether the authoritative and recursive servers are in one process or talk 
to each other through some sort of IPC.  Either way the authoritative 
server has to deal with all of the ways that recursive queries can fail. 
I have an ANAME like kludge in the provisioning crudware for my 
authoritative server which ignores most of the failures, but that's not 
going to work past toy scale.

> The goal of ANAME is for the processing to be done on the resolver side.
> Addresses that are included in the authoritative response alongside
> ANAME should be ignored by the resolver and re-queried.  But, for the
> benefit of legacy resolvers that don't know what to do with an ANAME, the
> auth would need to provide some sort of usable answer, which means it has
> to be able to look up addresses for the target name (whether it does that
> internally or via resolv.conf). It would be nice if that could be avoided,
> but there's no straightforward way.

Well, yes, that's why ANAME is a mess, and I'd rather see if we can figure 
how to make CNAME coexist so the recursion is all done in the recursive 
code.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

v2.23.0 | Report a Bug | By Email