Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

Andreas Gustafsson <gson@araneus.fi> Mon, 18 January 2016 11:37 UTC

Return-Path: <gson@gson.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F741B352E for <dnsop@ietfa.amsl.com>; Mon, 18 Jan 2016 03:37:01 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham
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 6ppeB6gWNqso for <dnsop@ietfa.amsl.com>; Mon, 18 Jan 2016 03:36:59 -0800 (PST)
Received: from gusto.araneus.fi (gusto.araneus.fi [185.55.84.130]) by ietfa.amsl.com (Postfix) with ESMTP id D96771B3527 for <dnsop@ietf.org>; Mon, 18 Jan 2016 03:36:58 -0800 (PST)
Received: from guava.gson.org (unknown [10.0.1.240]) by gusto.araneus.fi (Postfix) with ESMTP id 6E1778BE36F; Mon, 18 Jan 2016 11:36:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=araneus.fi; s=mail; t=1453117017; bh=b5dKoNbEqUu3eIMLW52YQuED8R8qa8ZeZDTFSDJakbE=; h=Date:To:Cc:Subject:In-Reply-To:References:From; b=ak0Q8G7ujc3wF8FA+v/9ldEYE0ZKB3NE+Pndr05FlJi/LKyVli8n/oRYLekA8z38Q Z/vmbyzg/6dPgBg/hUjb54f4gOav9DpD7NrUelXYd3Xj7kh2NxVOYyIzSivY0293kI SNByol+yo8+RL2liQHrF8za4FqtDIFuRWW9ZLpLk=
Received: by guava.gson.org (Postfix, from userid 101) id DF6E074508B; Mon, 18 Jan 2016 13:36:53 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22172.52821.887433.918681@guava.gson.org>
Date: Mon, 18 Jan 2016 13:36:53 +0200
To: Tony Finch <dot@dotat.at>
In-Reply-To: <alpine.LSU.2.00.1601180947500.21715@hermes-2.csi.cam.ac.uk>
References: <566E329D.7010007@gmail.com> <CAJE_bqeR5nVGOnLWQ3CzWKR86===VoXWNsqyas3yJEG5zX2n=Q@mail.gmail.com> <alpine.LSU.2.00.1601131007410.8365@hermes-2.csi.cam.ac.uk> <CAJE_bqc53vizG54TS9yRCfP62EdnzyP=5piDRVKixAWB+_C+kw@mail.gmail.com> <alpine.LSU.2.00.1601141306000.8365@hermes-2.csi.cam.ac.uk> <22171.35498.720284.788325@guava.gson.org> <alpine.LSU.2.00.1601180947500.21715@hermes-2.csi.cam.ac.uk>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
From: Andreas Gustafsson <gson@araneus.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/skeHPZCqbggkPWlIUQn_1ZQogvQ>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Andreas Gustafsson <gson@araneus.fi>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 18 Jan 2016 11:37:01 -0000

Tony Finch wrote:
> Hmm, I am reluctant to introduce new layering. Is there a precedent for
> the distinction you are making?

Any web standard could be said to specify "requirements on HTTP clients",
yet most of them don't use that term or update the HTTP specification.

Any mail standard could be said to "specify requirements on SMTP clients",
yet most of them don't use that term or update the SMTP specification.

The requirements in Section 9 should apply to entities like DHCP
servers and IP management systems, whose functionality includes the
management of reverse mappings, and that may contain, call upon, or
(if we must use that term) "be" an UPDATE client to perform the
changes.  But an entity that only serves as an UPDATE client, like
the "nsupdate" program in the BIND distribution, should not be subject
to the requirements because it does not deal specifically with reverse
mappings, but with arbitrary DNS names and records.  Calling them
"requirements on UPDATE clients" when they only apply to entities
that are more than just UPDATE clients seems wrong to me.

> > I would even say that the requirement to follow CNAME and DNAME
> > redirections should apply equally when the updates are not performed
> > using the RFC2136 UPDATE protocol at all, but using some other
> > mechanism.
> 
> What deployed examples do you have in mind?

The RA-API REST interface used by dyn.com would be one if they only
supported PTR records.  I also recall implementing a different
proprietary update protocol to work around some limitations of RFC2136
as part of the NameSurfer IP management system back in the 90s.

In principle, the draft's requirement to follow CNAMEs and DNAMEs
could even be applied to tools that update zones through mechanized
editing of master files.

> Who here knows how Active Directory interacts with DNS aliases?

Not me...
-- 
Andreas Gustafsson, gson@araneus.fi