[DNSOP] abandoning ANAME and standardizing CNAME at apex

Petr Špaček <petr.spacek@nic.cz> Tue, 19 June 2018 13:18 UTC

Return-Path: <petr.spacek@nic.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 85CA8130EBC for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 06:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 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_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.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 DgeTS71NgwVo for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 06:18:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 8D957130DE4 for <dnsop@ietf.org>; Tue, 19 Jun 2018 06:18:43 -0700 (PDT)
Received: from [192.168.3.5] (ip-86-49-248-232.net.upcbroadband.cz [86.49.248.232]) by mail.nic.cz (Postfix) with ESMTPSA id D9358601BB for <dnsop@ietf.org>; Tue, 19 Jun 2018 15:18:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1529414321; bh=RhHglVWEVy4o82XkBezUTRZBthLTyot7Milx2ZYs3tg=; h=To:From:Date; b=s8vNUZP6IcKraclWTtD/f7UoFYDktw5VzwteIKmbpCur6WcALdxfmH3HfXLIeJ7Ym F4K6xbz4+5IZtqj3ZqCNcsq4sTRaEWcnY6EgA7qR8v2LcLiLyx4/7guViASAA1IlAn kzb9YZbyYO4BGR5eKdSWtwxL5PbZj0Di0T4Y2Jds=
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz>
Date: Tue, 19 Jun 2018 15:18:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/awmoLxtbQtQhSt9KDTr9JASy49k>
Subject: [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 13:18:48 -0000

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).

Opinions? Tomatoes? Can it work? If not, why not?

-- 
Petr Špacek  @  CZ.NIC