Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Paul Wouters <paul@nohats.ca> Thu, 20 April 2017 02:47 UTC

Return-Path: <paul@nohats.ca>
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 4923812EAEC for <dnsop@ietfa.amsl.com>; Wed, 19 Apr 2017 19:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 P9ySHO4Djbxc for <dnsop@ietfa.amsl.com>; Wed, 19 Apr 2017 19:47:30 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 6761C1293FF for <dnsop@ietf.org>; Wed, 19 Apr 2017 19:47:30 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w7jvg2DZZz37M for <dnsop@ietf.org>; Thu, 20 Apr 2017 04:47:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492656447; bh=AqUkzYbkAbhUV8Fi0zpj2ojpGm6IyWKa7kZssLs4HzE=; h=Date:From:To:Subject:In-Reply-To:References; b=efWs7TWtQnS21GaP9IhqgNeaFCMhNDQSgmCGR1PetRxMafsrAOteQ/XxD8MAVENAq vYY58koL0nZnS3MKa+Gu0Bjzsop/cnx1YvnWSp3kX9CVhUcHWGJh6viBKsfks7+JOk iv/sJqt2Ipy3Z3501ToBeF9oikKzyAo85qWetwJ0=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wEHKN2jZEC9k for <dnsop@ietf.org>; Thu, 20 Apr 2017 04:47:26 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Thu, 20 Apr 2017 04:47:26 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1A1F62648B; Wed, 19 Apr 2017 22:47:25 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1A1F62648B
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 026AF40D811F for <dnsop@ietf.org>; Wed, 19 Apr 2017 22:47:24 -0400 (EDT)
Date: Wed, 19 Apr 2017 22:47:24 -0400
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <CA3AE8E2-A54F-4F9D-A6F3-D754A6829B75@powerdns.com>
Message-ID: <alpine.LRH.2.20.999.1704191436580.15622@bofh.nohats.ca>
References: <20170414200316.86192.qmail@ary.lan> <CA3AE8E2-A54F-4F9D-A6F3-D754A6829B75@powerdns.com>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a1GH2on7mZUwt1hzhpo0fMjZ7ys>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Apr 2017 02:47:32 -0000

On Wed, 19 Apr 2017, Peter van Dijk wrote:

> Type bitmaps would preclude simple implementations that use getaddrinfo 
> to do their business. As much as I think the idea may have merit, I feel 
> this draft should stay close to the long list of existing ALIAS/ANAME 
> implementations if it wants any chance to succeed.

But the implementation really seems to do two things. Bundle A/AAAA
with other records and providing a level of indirection. By combining
these we are really adding a whole new type of behaviour to the DNS
that could be avoided.

> If after that (perhaps after some operational experience with ANAME!) 
> you want to draft up a more generic forwarding mechanism, I will happily 
> help you write it all down.

Which is why I don't agree with this.

ANAME could just be a regular RRTYPE without any special handling,
meaning "go look there for up to date information on A/AAAA". It could
come along A/AAAA records using one of the existing bitmaps multi-type
query proposals that have been suggested in the last two years.

Prepopulating or updating the A/AAAA records on the auth server should
also be a separate issue/draft and ideally not need the auth server
to require either recursion or validation. A new type of authenticated
XFR query seems to make more logical sense to me. It would also allow
much stricter firewalling on the auth server.

It seems dnsop is more and more getting these arguments of "but we
are just documenting existing behaviour", like with client-subnet and
RPZ. It's really not the best way to develop new DNS extensions, as I
also argued when we talked about RPZ.

Paul