Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 14:36 UTC

Return-Path: <jcb@bambenekconsulting.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 C2307120183 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=bambenekconsulting.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 wlFjm0DeLpQz for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:36:56 -0700 (PDT)
Received: from chicago.bambenekconsulting.com (chicago.bambenekconsulting.com [99.198.96.122]) (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 0EA99120178 for <dnsop@ietf.org>; Tue, 9 Jul 2019 07:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bambenekconsulting.com; s=default; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=N0PC9gDwXWrfMk2MBrRr3eueZaLnSpHL/U1WA/E3KiY=; b=jE/qYwwPAFzx5Px+E2CVr2bfCE nAUn2xJ9v0UbrQUzdv+aW5Qwg4fuBfG1AUCp3RwfA887HuI0pnbXhXORAfSgEirQVvWK1/35JPW9R 6RKC/H2l3a0rwW0u8HS3rNXzgDzhtml81WrqjVxunYIgF9f/giy4TkjJYAh0KBPqZQok=;
Received: from [216.169.1.210] (port=5544 helo=jcb.local) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hkrEj-0008Vl-5o; Tue, 09 Jul 2019 10:36:53 -0400
To: Joe Abley <jabley@hopcount.ca>
Cc: Jim Reid <jim@rfc1035.com>, dnsop@ietf.org
References: <1CA7BF1B-DF50-443B-9219-55259835FE23@bambenekconsulting.com> <233E0AD8-97FE-466C-9B6C-D7A376031C3B@rfc1035.com> <93244821-6C22-457F-BA06-CF43CA9FD12B@bambenekconsulting.com> <EDE98437-E0B8-4B2E-8AA5-2F6B0079CE8B@hopcount.ca>
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <0ece2408-a1ec-fa5f-f8d1-ff65572de1ed@bambenekconsulting.com>
Date: Tue, 09 Jul 2019 09:36:50 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <EDE98437-E0B8-4B2E-8AA5-2F6B0079CE8B@hopcount.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - chicago.bambenekconsulting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bambenekconsulting.com
X-Get-Message-Sender-Via: chicago.bambenekconsulting.com: authenticated_id: jcb@bambenekconsulting.com
X-Authenticated-Sender: chicago.bambenekconsulting.com: jcb@bambenekconsulting.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UUoABgDz7TY-l0xHSI8UI4EdcIA>
Subject: Re: [DNSOP] Proposal: Whois over DNS
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: Tue, 09 Jul 2019 14:36:58 -0000

Below

On 7/9/19 9:25 AM, Joe Abley wrote:
> On 9 Jul 2019, at 10:07, John Bambenek <jcb=40bambenekconsulting.com@dmarc.ietf.org> wrote:
>
>> On Jul 9, 2019, at 08:32, Jim Reid <jim@rfc1035.com> wrote:
>>
>>> 2. These policy problems are out of scope for the IETF. It deals with technical and operational matters around protocol design and deployment. Policy issues are handled in other fora - like ICANN. The IETF should keep well away from the whois policy swamp. The wrangling over whois policy at ICANN has gone on and on for 20+ years. It shows no sign of reaching a consensus. Dragging the IETF in to that screamfest is not going to improve matters.
>> This creates a protocol and standard to facilitate voluntary information exchange. No more. If I want to publish these DNS records, it is not ICANN’s business. What we are discussing here is a workable standard should someone wish to. There is a policy backdrop, sure. That’s driving the need to move to a self-disclosure system without middlemen.
> The principal reason for standardising this behaviour is presumably to allow and promote interoperability.
>
> Interoperability is required for there to be a useful, common framework for general data exchange: that is, data exchange between parties on a scale or of a kind that precludes simple, bilateral agreement. To me, that's indistinguishable from policy. The idea of both the IETF and ICANN working on different policies for disseminating this kind of information is simply a headache. The conversation is already difficult; I think there is harm in making it more difficult.
>
> I agree with pretty much everything else Jim said, but really this seems like the core issue: this seems like a proposal in the wrong venue.

If the proposal is to create a standard by which to put contact
information into DNS records, what venue would you suggest?

>
> I also agree that without any widespread incentive to implement, test and maintain, the data is going to be noisy and sparse to the point where it's useless for any practical use anyway.

You could say the same for SPF.


>
> Joe
>