Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Wed, 10 July 2019 13:49 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 912971200F7 for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 06:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, 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 mgc9kXqJ1tfm for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 06:49:28 -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 6249C12003F for <dnsop@ietf.org>; Wed, 10 Jul 2019 06:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bambenekconsulting.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type: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=GNWoys8GSDxcgEyxWKw9HZWRWDMPKcya7j2GxNdAY9U=; b=D3SNX3X1McYxJ06VcIMBCPKw7 Yk2EmtfUDaTnlta1yyR1HBh34EeWrXPcn96DwO/bEKHpts5Ej/5o+sS73mCXbD9vPf2kShevZBTXR 15frrRt/UDjas0Cmgkq3hmmUpOdiW3c8dxjaB5LriYfAM/GNZiVzpUDAdg2cJjpLjI8LU=;
Received: from c-67-167-98-187.hsd1.il.comcast.net ([67.167.98.187]:56716 helo=[192.168.11.181]) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hlCyI-00013z-O1; Wed, 10 Jul 2019 09:49:22 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: John Bambenek <jcb@bambenekconsulting.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <m1hlCac-0000FUC@stereo.hq.phicoh.net>
Date: Wed, 10 Jul 2019 08:49:21 -0500
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B89FA18-86C4-42DC-A1A0-592729B36B86@bambenekconsulting.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>
To: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
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/tTFuEEO8MdXh9xdx7oErMvpEzsA>
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 13:49:31 -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 proposal assumes the above remains true but it is an assumption. 

That said, no additional functionality is created with this proposal. Most, if not all, commercial auth DNS providers already support free form text fields so can support this with no additional work. The idea here was to develop something using services people already run with functionality that already exists. The only “new” here is a standard way to structure the information. 

—
John Bambenek

On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sales@bambenekconsulting.com for details

On Jul 10, 2019, at 08:24, Philip Homburg <pch-dnsop-3@u-1.phicoh.com> wrote:

>> Im not sure the point
>> aside of illustrating if there is no response for the domain records
>> by the auth server that there would also be no response for a _whois
>> record. Thats true.
>> 
>> 1) Using _whois is completely optional, like SPF or any other
>> record.  2) I cant envision much legitimate need to contact a domain
>> owner for something that doesnt exist (aside of domain renewal spam
>> or trying to buy the domain).
>> 
>> Am I missing something?
> 
> I read this discussion from the point of view of someone how is very happy
> with the result of GDRP in this area.
> 
> With that in mind, it seems that this proposal doesn't address any technical
> issues with whois.
> 
> Where whois allows for querying of contact information associated with a 
> domain, this proposal does something similar.
> 
> Of course, whois has various technical issues, but it makes sense to first
> try to solve those technical issues within the whois system. And only when 
> it is clear that certain issues cannot be solved look for a different
> protocol. (And I mean cannot be solved for technical reasons, but because 
> of lack of consensus)
> 
> As far as I know, there is no issue with whois and the GDRP when it comes
> to voluntarily publishing information in whois. This draft clearly 
> advocates voluntary sharing of this information. 
> 
> As the Section 1 suggests, whois works.
> 
> So it seems to me that this draft does not solve a technical problem
> (or at most a minor one, 'internationalization')
> 
>