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

tjw ietf <tjw.ietf@gmail.com> Tue, 19 June 2018 14:44 UTC

Return-Path: <tjw.ietf@gmail.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 BF198130E19 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:44:03 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 Quc8o_B1UK7d for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:44:01 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 79946130DCB for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:44:01 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id x34-v6so18567282qtk.5 for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9hCHqD5LulOP+/70AuYzWKZsNRuAfNRh2CDWqKjtNIY=; b=hGmpZ8zAYHAgCylvuECK/hHray4BA3XqZHNWSfC5jwMvXX+9k0FkvuFm5b77+xv897 Z/gsNtPYJi2kil83Uo3KeHf7HWfVI7cbZNm2PgJ3n93fZa+JO7DUXgc8vpBOhZi2IWE3 tLOfXJ9r20Ig69oZRwrcaRdfSZZQrZ+b0dS0P7k94WFFSBoY8nmRJEfPdXVly2zDBqi3 ecA/VIFd80LmqvOKDYybVgs8woojVLc06CCNylHIUl06Wh4zLcQTPoccV7+pn1mn6U9i WNaRdhQzc6xDmAWUxMr2KHfgQ9Kg1SYB5eXlbmiUDTiCAoJl6bZLCCz/onhnq6yY+1EW gcNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9hCHqD5LulOP+/70AuYzWKZsNRuAfNRh2CDWqKjtNIY=; b=kfEtn13zwjOlDA+PeeptZ73oro1fBxbsPDuG01K/L8qnxP32DKohCW35NQ6vSk+LMV nWFn6Hhu/deramgm8ej1MnB3ZyLBBYUl9trpsK/XLYetLzp2acgYV+R1z716/VM2Jiyp /ySjEEgmnORu2eSDPyM6meyH96oduHyVZoqnDrPNUzIJRlBvxrfOjPHSlbltDVQgi0vD gedj83ewPOrrY9oLHn8uutGiSfClGbMKCakJ8XPhKOOLK9gvflWK4WvwdhMDVBYaA+ko E2BT5dl5CjTEM57aJr6h0d3gWKaSMwxB7OPXdj09h43LymYkOQc3OpiBqxonGExlhRcz G4+g==
X-Gm-Message-State: APt69E2M6u8r/xLdaeiZnmXK6sYhOuzitf8FNHsS0U8idmZLXR/QhgqC bIkXY8/POGRc2uP+20TYUPLlVZy+
X-Google-Smtp-Source: ADUXVKImjwXe4IU46B1W9KkYUcr/lXJUpVlxEEE4PnlvlwQc91R3ECcQMw+4GgR5EwtIl0HHD2er4g==
X-Received: by 2002:ac8:387d:: with SMTP id r58-v6mr15562196qtb.413.1529419440394; Tue, 19 Jun 2018 07:44:00 -0700 (PDT)
Received: from ?IPv6:2600:380:9277:db7:c47b:71b:e569:8186? ([2600:380:9277:db7:c47b:71b:e569:8186]) by smtp.gmail.com with ESMTPSA id x1-v6sm13572554qtc.19.2018.06.19.07.43.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 07:43:59 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: tjw ietf <tjw.ietf@gmail.com>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk>
Date: Tue, 19 Jun 2018 10:43:58 -0400
Cc: Petr Špaček <petr.spacek@nic.cz>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o26uumwXdlzKgEzWMdbEGE0vA5g>
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 14:44:04 -0000

With all of you here. 

As an Operator who gets these requests regularly (just 10 minutes ago!) when you tell users the  world of BIND/PowerDNS/NSD/Knot do not support such a mechanism they say “we’re off to use route 53. okthxbai “

I find it personally appalling we can spend so many cycles injecting dns into http but we can’t be bothered to fix what end users want. 

Tim
Just an infrastructure operations person. 
From my high tech gadget

> On Jun 19, 2018, at 10:20, Tony Finch <dot@dotat.at> wrote:
> 
> Petr Špaček <petr.spacek@nic.cz> wrote:
>> 
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
> 
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deeply hierarchial subdomains in my main
> zone. CNAME at apex does not need to be (and I think should not be treated
> as) a special case.
> 
> As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
> other records, but that led to consistency problems. eg, if you have a
> CNAME cached for a particular name, and you get a query for MX at the same
> name, do you go and ask the CNAME's owner or its target for the MX? And do
> you get a different answer to the MX query when you don't have a CNAME
> cached?
> 
> My guess is that it was hard to fix this at the time because the semantics
> of negative cache entries was not well developed (e.g. RFC 1034 section
> 4.3.4 says it was still a new and experimental feature). For
> CNAME-with-siblings to work, a resolver needs to remember whether it
> already asked for the other data, for each RR type. 1980s caches couldn't
> do this, so CNAMEs were made exclusive instead.
> 
> I think the resolver's algorithm for handling CNAMEs can be updated to
> allow CNAME-with-siblings and preserve compatibility. There will be some
> latency cost for later queries that can no longer immediately follow the
> CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.
> 
> I'm much less sure about whether it's possible to publish
> CNAME-with-siblings in a reliably compatible way. I would feel a lot more
> comfortable with an ANAME implementation that copies the sibling records
> from the target to the owner when the zone is published or signed.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
> moderate until later in southeast, otherwise moderate or rough. Thundery
> showers, fog patches later. Moderate or good, occasionally very poor later.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop