IETF Logo Mail Archive

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

Jan Včelák <jv@fcelda.cz> Wed, 20 June 2018 09:40 UTC

Return-Path: <jv@fcelda.cz>
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 AECFB130D7A for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 02:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.022
X-Spam-Level:
X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 rMy8Hzuc0OKg for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 02:40:25 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 E43B312F295 for <dnsop@ietf.org>; Wed, 20 Jun 2018 02:40:24 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id o17-v6so1562758vka.2 for <dnsop@ietf.org>; Wed, 20 Jun 2018 02:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdRj6EER7DZOraZ1quYU42bMXKIUo2h73QjAoIWPKc8=; b=Jd+SFIIz/2O0ACgJ5Pmv2CMuhUdojrWupIz6xCfsf//wq0wAVj/L9pvf4LClPHcH9X E7D/2bd38Jz1PQIV5qBGnoqoLSTkjTs6dki9bxdbR/r4uDwLy/oLvwInU/Q/A0geuTE/ BVhJfIxHJmoi4r5Y1TLrWuwzPcXLAd17NkMVM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jdRj6EER7DZOraZ1quYU42bMXKIUo2h73QjAoIWPKc8=; b=U+NjiEhYP5h4MslxTCtPNKka+o+u7xFYaScoH83y+78V/J77Xxix6FD7WRbz6+4V4j 9TLo5Yi6IRy4lVCoAndtbR9urwYOyeWooEdl72XxEe5w5sS3Ow+TJ2f2+TAQp28NBby0 FVgpLtIy8vASuPM9LZLZIvNdMr7uSysCIcQj87U8YEwvWVL2lwlqEqHGnRL4yh/d8lwK WNOP4xDg0R1yYowzOQrB2a8Zhf7jCgfGTRkbB6ldftGluQmjPWHHapYIJHuuv5ZUoo0G qzosTwscAJSHoXLEr9F6ryd96bOBdauAQbmlbTt4zA7tWjrKFJd27HetM8QfAGT8JoiY YCCw==
X-Gm-Message-State: APt69E2s8uPsnuvSNL+01gu7Dok5Y0mT3fiBiPVM5itOrMRSV3ZKxe4V JzjJksClY2wH5BBY1XhGqdP9q/Oq+CT5iscLLfeQ8ZnI
X-Google-Smtp-Source: ADUXVKJQ8zelVi+FMFv0S+YqEp/uFrMUQgpP3dbxZKzQvXGYl2IkBMXciIhjcL0JichmqVrR+UCsFfx2Bpd3g0WZK3M=
X-Received: by 2002:a1f:3293:: with SMTP id y141-v6mr11611812vky.180.1529487623694; Wed, 20 Jun 2018 02:40:23 -0700 (PDT)
MIME-Version: 1.0
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk>
In-Reply-To: <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk>
From: Jan Včelák <jv@fcelda.cz>
Date: Wed, 20 Jun 2018 11:40:12 +0200
Message-ID: <CAM1xaJ9=HYn8vXjHxRW4i=Ww1e99CPN995_51y=RS2aOmsfnzQ@mail.gmail.com>
To: ray@bellis.me.uk
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yEzD2BFsK5jBtwUbGMkR5LC_Ado>
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: Wed, 20 Jun 2018 09:40:27 -0000

> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue.   CNAME was *never* the right answer for doing application
> level indirection in HTTP space.

SRV also trades CNAME at apex for wildcard names support. There is a
plenty of services that employ wildcards to provide customized site
for each user. For instance, userxyz.popularservice.test can be
resolved via *.popularservice.test but equivalent setup with SRV would
require _https._tcp.*.popularservice.test to work as a wildcard.

v2.23.0 | Report a Bug | By Email