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

Anthony Eden <anthony.eden@dnsimple.com> Tue, 19 June 2018 16:06 UTC

Return-Path: <anthony.eden@dnsimple.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 100B412777C for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 09:06:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnsimple.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 ZBCsVsAailWY for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 09:06:05 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 610DB130DF2 for <dnsop@ietf.org>; Tue, 19 Jun 2018 09:06:05 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id j15-v6so1501565wme.0 for <dnsop@ietf.org>; Tue, 19 Jun 2018 09:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnsimple.com; s=mail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KtSCCwba/azKq5KlmsD0Ex5LItcpFs+OkOzN7rUfKbk=; b=PbeaPxX7Vqdxrym3+9eobm8WgDpm2Po2YsPGBmz8YS4EZRh8DPu6jEXKkWQlqxFyYM q1xjy+kZPqqtFshrGBT6rXJex/OCt3WoBDtEilcMK6X3TWnFgRH/iraUzEF3STH3aRm+ vIDcx6g1bekpj3mBP3Gsu+jSb3GGnl8RSlN7I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KtSCCwba/azKq5KlmsD0Ex5LItcpFs+OkOzN7rUfKbk=; b=W32cWGie7CDFqjE7h0wphWpI/F74ilJ2V6xbn3M76ZZo8hjYSjgECHDMHLbyuE+n8C /cdka2/BpIPDCuC1PJk8uZa0KLGg8XqWDQzdPmV3ME1JNKOLaR8mLTPQ43Zw3/odDdxo TcF9lo+mZKR6GkbhFaoW+i++wbErT2Jzfa0eQKUhdUSZtdRDEEj4Q3lJT/cf3pB5SoAP gAPT7sj5zJpa8ZAZLbsZAZY4ppRpfdOJcRY6/qlGU56bTNqiJZjwmfBhIf116mCEGECF hsjw1bfWNaWlwWQL+s9bPVHdOdzRdrudNyDu7yK88Lf7WMp1CfyZY00+36PCRckVTMsY pgsA==
X-Gm-Message-State: APt69E0QqedM6rUGpllg6ikPq8Mp50IrvmrQKMUTUJI/mTSFIgCNpTui x8ub7I91JhBgmGYRBtVYx5tT6nEx4CKGkKXQPk5OiA==
X-Google-Smtp-Source: ADUXVKKvBx6wkgad3XBtoDuCqPK/GKtiv9VFXJqPsDDLenmgstucFkpByc5nZcMmAe6AKfoaShytfu/6AIENFsbEXe8=
X-Received: by 2002:a1c:ad09:: with SMTP id w9-v6mr13415892wme.95.1529424363750; Tue, 19 Jun 2018 09:06:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1c:7c08:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 09:06:03 -0700 (PDT)
In-Reply-To: <CANLjSvVoCkKycYiqz1TEaigO_-pfdDKXr0EAYAXoG0awKCtoMg@mail.gmail.com>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <CANLjSvVoCkKycYiqz1TEaigO_-pfdDKXr0EAYAXoG0awKCtoMg@mail.gmail.com>
From: Anthony Eden <anthony.eden@dnsimple.com>
Date: Tue, 19 Jun 2018 18:06:03 +0200
Message-ID: <CAOZSDgAbg-mJT=UCTFm1ZaHwXPx-JuNcH8Hz6rVjxyezh9DZLw@mail.gmail.com>
To: Lanlan Pan <abbypan@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e9a0e9056f00db1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/J4iLUbV5Gmyncvvb3knUcI3u3JA>
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: Tue, 19 Jun 2018 16:06:08 -0000

On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan <abbypan@gmail.com>; wrote:

>
>
> Petr Špaček <petr.spacek@nic.cz>于2018年6月19日周二 下午9:19写道:
>
>> Hello dnsop,
>>
>> beware, material in this e-mail might cause your head to explode :-)
>>
>> This proposal is based on following observations:
>> - It seems that DNS protocol police lost battle about CNAME at apex,
>>    is is deployed on the Internet.
>> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>>    already have code to cope with the "impossible" case of CNAME at the
>>    apex and deal with it in ways which do not break stuff on resolver
>>    side.
>> - Authoritative servers of vendors named above refuse to serve CNAME at
>>    apex.
>> - There are CDNs etc. which allow users to create CNAME at apex
>>    no matter what the standards and "normal" servers say and do.
>> (We have found out this because Knot Resolver is missing hacks for CNAME
>> at apex and users complain that "it works with every other resolver".)
>>
>>
>> Take a deep breath!
>>
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>>
>> It is very clear violation of the standard, but almost everyone found
>> his way around it using different hacks. These hacks are not going away
>> because all the CDNs just don't care about standards so we will have
>> to maintain this code no matter what a great solution we will invent for
>> future. I.e. adding ANAME will just increase complexity because CNAME at
>> apex will be there for a long time (if not forever).
>>
>> I personally do not like this but it seems better to think though
>> corner cases in code we already have in production (i.e. think through
>> current hacks for CNAME at apex) instead of inventing new things like
>> ANAME (or whatever else).
>>
> I think ANAME RR is hard to compatible with many old version resolvers.
> If there are mutiple ANAME RR at compatible resolvers, authoritatives may
> not know that resolvers will choose which A RR for client response.
>
> ANAME can ease apex CNAME configuration, maybe a work round is that
> authoritatives directly return A RR to resolvers (but not ANAME RR).
>

This is essentially what those of us who implemented ANAME in authoritative
name servers do right now. The original draft I started about ALIAS records
also spelled out only this solution with some operational guidance on best
practices.


>
>> Opinions? Tomatoes? Can it work? If not, why not?
>>
>> --
>> Petr Špacek  @  CZ.NIC
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> --
> 致礼  Best Regards
>
> 潘蓝兰  Pan Lanlan
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>


-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple