IETF Logo Mail Archive

Re: [DNSOP] Authoritative servers announcing capabilities

Patrick Mevzek <mevzek@uniregistry.com> Fri, 11 September 2020 23:26 UTC

Return-Path: <mevzek@uniregistry.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 84BF43A0B04 for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 16:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, 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=uniregistry.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 oOp2dbh01HNB for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 16:26:07 -0700 (PDT)
Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (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 22EBD3A0FA1 for <dnsop@ietf.org>; Fri, 11 Sep 2020 16:24:55 -0700 (PDT)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a-mx.uniregistry.com
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1599866694; bh=r7yupptDFYp3SPftGR2yByESy9yIMluwwHAlUH0BlfA=; h=Subject:To:References:From:Date:In-Reply-To; b=PmJCFccLBe6vs7rvPU+z0RecLfL+itrtEX2zjKIllrYJ5mdNwiFn/t67Mq8ZS/DQo R0Pc5VZbEe6yATBHa5xgh11CADr5U1UlUsqdO63Y+FsdtYcB/ObdSVcAqtwd5TV/eR vaR8SY1e0b/+1a/RPq7C/3jicFKKezOA3mJkxtJ/943BPbXYHawVst7I6pv3wMWJI1 Hlh8pJ1K4V3kSXHjWmjtjhV+c5JSRwsG2RqPYr0Mhb2VS+onbUNiKcPE6ZUexHGAnr YCBNoz3MH5Qgw9/9PtzkyHbXJE6ChCkEZBtWfBw+zlOlY/WjHW8px2SLiV0B1BdmRZ FLX/B7phxmbWg==
Received: from [10.8.204.86] (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 08BNOqHK031783 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 11 Sep 2020 23:24:53 GMT
To: dnsop@ietf.org
References: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <294f8ab0-285b-d5f2-705f-5db8c0da584d@uniregistry.com>
Date: Fri, 11 Sep 2020 18:24:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3PjeNd-4wqEkkJHH86uLYTX6QaU>
Subject: Re: [DNSOP] Authoritative servers announcing capabilities
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 11 Sep 2020 23:26:11 -0000

On 11/09/2020 15:37, Paul Hoffman wrote:
> Greetings. Puneet and I have an new draft, <https://tools.ietf.org/html/draft-pp-dnsop-authinfo>, that we would like DNSOP to consider. From the abstract:
>    This document defines a new DNS RRtype, AUTHINFO, that is used by

[..]

> We would like DNSOP to adopt this, and of course we are open to suggestions on how to improve the protocol.

I know it is unrelated, but EPP uses authInfo term extensively (for 
authentication purposes and in practice basically as synonym of 
"password"), so I really recommend using another name for this record 
type, because otherwise I am pretty sure somewhere somehow someone will 
confuse both things.

Plus, why couldn't this be extended in the future to recursive 
nameservers as well? In which case, the name should be resolver genre 
agnostic.

Maybe something like "CAPABILITIES" or "ABILITIES"?
(or shorter version)


-- 
Patrick Mevzek

v2.23.0 | Report a Bug | By Email