Re: [DNSOP] Proposal: Whois over DNS

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Wed, 10 July 2019 14:14 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 032F2120044 for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 07:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 NdDZAFV9Mr2J for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 07:14:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 5706012002F for <dnsop@ietf.org>; Wed, 10 Jul 2019 07:14:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hlDLy-0000FCC; Wed, 10 Jul 2019 16:13:50 +0200
Message-Id: <m1hlDLy-0000FCC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: John Bambenek <jcb@bambenekconsulting.com>
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
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> <0ece2408-a1ec-fa5f-f8d1-ff65572de1ed@bambenekconsulting.com> <B520D17D-F258-41C3-97DD-3CE5C3A8E952@hopcount.ca> <6F0B44AA-902D-46E9-9E3B-DB88F5AC1419@isc.org> <A7A3C5BB-2705-47F2-9870-19552756423B@bambenekconsulting.com> <m1hlCac-0000FUC@stereo.hq.phicoh.net> <3B89FA18-86C4-42DC-A1A0-592729B36B86@bambenekconsulting.com>
In-reply-to: Your message of "Wed, 10 Jul 2019 08:49:21 -0500 ." <3B89FA18-86C4-42DC-A1A0-592729B36B86@bambenekconsulting.com>
Date: Wed, 10 Jul 2019 16:13:49 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xl30B_zuvZ4xjMJ0ZuLV19ptxQk>
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: Wed, 10 Jul 2019 14:14:36 -0000

> The technical issue with
> whois is that its dark in many places and getting darker with
> minimal to no prospect of coming back (in a usable form).
> 
> While GDPR applies only to EU natural persons because there is no
> way to distinguish between natural persons and legal persons and
> no way to distinguish EU from other countries, many have adopted
> applying strong redaction to all records.

This doesn't make any sense to me.

Previously, information was published in whois without the consent (as
defined in the GDRP) of the subjects.

So obviously, registrars had to stop publishing that kind of information.

However that doesn't say anything about voluntarily providing that information.

Support for voluntary information has a cost to implement. It is possible
that registrars don't want to provide that feature because it would not
make them any money. Of course ICANN could require registrars to support
domain holders adding information in whois voluntarily. 

So I guess the argument then becomes that DNS TXT records have to be used
because it doesn't require additional investments in many cases. Maybe you
should list that argument in the draft. Because that means that as soon
as DNS TXT records are rejected, there is no basis anymore for the
the draft.

>From a technical point of view, having structured information in TXT
records is bad. Having large RRsets is also bad. So the obvious solution
would be to define a new resource type for this kind of information.
However, that defeats your argument that existing zone editiors can be used.

In the end you are reinventing whois to get around policy issues and the
lack of a business case.