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

Matthew Pounsett <> Tue, 19 June 2018 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4094130DED for <>; Tue, 19 Jun 2018 12:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Od860N2mOw4K for <>; Tue, 19 Jun 2018 12:06:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05DAE130EBF for <>; Tue, 19 Jun 2018 12:06:28 -0700 (PDT)
Received: by with SMTP id n7-v6so1974618itn.1 for <>; Tue, 19 Jun 2018 12:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jj4f+NK2RgyHzFFGqus22Isn2tu8XaRDIXuFFmmlN1I=; b=v/KZaGXeV5iSuEw3eAZ3OTLzJryhWMdV/wY+vMz6vvNPih++2nmZKb5xyePCz9LbSp NEipkch4X9/E0hwbbP+LuZXQZZ0VW62K86m95QzI15QXHldadRr76rlPS5lC7QLhvU12 cKaKJmq4ItJHtjEelduxCCnWYmg0yj24Xr90HCbltTGSzEmLyafqViES5u2YU19rNTDw CCkmzOe+Eekp17VIW8Fi+g9XM7xtybVWTNfLujuKbQYVfELYVkgDrOi2I0LY2Xw4YJHG iqeZaq0MLC6w9bESAPTE89gfxSVLfvkHayoFDM5qwtVt8dM9mC4EwkhH88NQw0+/+OyP cpdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jj4f+NK2RgyHzFFGqus22Isn2tu8XaRDIXuFFmmlN1I=; b=XOjk8DyXJepNNGH1qZ1MmEUCjzAWig2JMkKq0R4W7emL4Yo+C1OAmuIukiZ2M0OMhD pxh+pc65tuocwSfS8SQnmbQSWq3h+4zhYKgDnVlfuhh0H5zZboS5ZhrCRqQm9W1GnSFN rRpaEHRUVc/bxfdIopoRaW5LYw+95kF38cUOBOfkT6RiQlZWAa7JBC92VrESVfEeeBbL reFoUCbrROs3XoeK380tFbDZwP2L3/eGclgqDK3ImnHjVCGpNAODVIGRr83M7goeT3oB Vd0+bcwILCn0ybEVI8laVLndAPz+/FT9JGnGFu2YSWkdxYxW3p2YsYGk1zyUeuEL7zX3 HTrg==
X-Gm-Message-State: APt69E3KFuuvIwOQgErPmnk8DkPakNi4WbLO1cB+UaXQshygq5BgD3SW BlIgFOIZBqMVxzhJm0SvffSJJ0rOjpafBQ10Ul8e6CEU
X-Google-Smtp-Source: ADUXVKL1I06Kmd/ZL9ogR2mUu9aILDxw9MGxV62ZMPVdYC8lQuk1q72EZFzLT9tJHOo6tDOUZtskcI9sLe3xQTDqkSo=
X-Received: by 2002:a24:6514:: with SMTP id u20-v6mr14703299itb.38.1529435187340; Tue, 19 Jun 2018 12:06:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:5cd1:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:06:26 -0700 (PDT)
In-Reply-To: <20180619190213.B76962846E19@ary.qy>
References: <> <20180619190213.B76962846E19@ary.qy>
From: Matthew Pounsett <>
Date: Tue, 19 Jun 2018 15:06:26 -0400
Message-ID: <>
To: John Levine <>
Cc: dnsop <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="0000000000000c86d3056f03611d"
Archived-At: <>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jun 2018 19:06:32 -0000

On 19 June 2018 at 15:02, John Levine <> wrote:

> In article <CAJhMdTO2kj+nUqESg3ew=wwZuB9OzkJE6pST=mae7pHiEk4-Qw@
>> you write:
> >This sounds like a lot of work and likely to cause camel indigestion.
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
> authoritative servers do recursive lookups.
> But even after all that work, CNAME + other data is still not quite going
to work, because there's an install base for which the behaviour is
unspecified and ambiguous.  CNAME + other data fails in indeterminate ways
depending on which recursive implementation you happen to query for it.

I'm still of the mind that a protocol specific service type for HTTP is all
we need to fix the problem.  If ANAME seems like too much work, and SRV
isn't quite what the HTTP folks want, then maybe we should have a closer
look at ALTSVC or make up something entirely new that does precisely what
HTTP requires.