Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Tue, 09 July 2019 14: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 AFE281204EB for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:49:13 -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 Eb3GAZHbSfxK for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 07:49:12 -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 EA14D12049E for <dnsop@ietf.org>; Tue, 9 Jul 2019 07:49:11 -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=CaIYLisBYRctR9L93KDKz/hz4KY0GbpvMqDd8kuB2Rk=; b=YRhgUdx5L7j/J9iEnsgtDbwj7n lPN4laiNQ/fJE2/ukOfIsM0yJJoNE4HSqfylQp+71bJfKvBsyU/n8Yx3Xqryro2N+Ta/DOC0rGQDV P3HWxSRyo2VccDeN5WrIm3rCPbKbBZLDoxn2kfDcJl8qXJVvqcGCQmiM3F6LnRg7cJkk=;
Received: from [216.169.1.210] (port=6069 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 1hkrQZ-0000In-P9; Tue, 09 Jul 2019 10:49:07 -0400
To: Bjarni Rúnar Einarsson <bre@isnic.is>, Jim Reid <jim@rfc1035.com>
Cc: dnsop@ietf.org
References: <233E0AD8-97FE-466C-9B6C-D7A376031C3B@rfc1035.com> <FUkLTVMXAgJMiDybUjWJmf4VMxMskCZdtairxrSf2353@mailpile>
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <1ff4dcb0-f8aa-6fcd-eafd-ec8fe9a633ea@bambenekconsulting.com>
Date: Tue, 09 Jul 2019 09:49:06 -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: <FUkLTVMXAgJMiDybUjWJmf4VMxMskCZdtairxrSf2353@mailpile>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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/Cf3JQZbXCp-2YW_BobiTvSJp6uA>
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:49:14 -0000

> Hello everyone,
>
> Jim Reid <jim@rfc1035.com> wrote:
>
> > BTW, whois was originally intended to provide a way to publish
> > out-of-band contact data so the domain holder could be
> > contacted whenever their DNS or email was broken. Putting this
> > info in the DNS would defeat that.
>
> Implementation details aside, I think having a technical
> specification like this would be quite interesting from the point
> of view of automatically updates to existing Whois databases,
> without requiring the registrant directly (or indirectly)
> interact with complex APIs or provider-specific web interfaces.
>
> Much like CDS for DS records, and CSYNC for NS records, having a
> well defined vocabulary for this data in DNS could be a useful
> step towards such automation. Assuming a cautious implementation,
> this need not make whois any less reliable.
>
> So, that's a potential use-case which I haven't seen mentioned
> here yet.
Good view point, will consider.
>
> That said, I agree it cannot solve GDPR or other policy concerns.
Why? GDPR applies to IP addresses, that doesn't impact DNS yet. Contact
info can be on a webpage, why not in DNS as long as I am the one putting
it there (also bear in mind, role-based information is fine, thus you
can put non-PII records there, or nothing at all).
>
> Also, I really don't see this data as meaningfully useful in
> fighting abuse, if only because it's very unlikely to see wide
> adoption in the near future, and because it will be incredibly
> easy to just create plausible looking (or maliciously
> Joe-jobbing) fake records. 

I'm genuinely curious of something. The most I've engaged in this debate
about WHOIS records and what is or is useful in fighting abuse, the
opinions of those who actually fight abuse for a living are discarded a
priori. This is WHAT I DO. I can give you hundreds of others. We are in
near unanimous consent that this information is valuable in fighting
abuse EVEN WHEN ITS FAKE. And as someone who knows a thing or two about
deception, creating plausible fake records are a harder problem than you
think.

> This will largely boil down to 2 bits
> of information: "did someone in the domain's chain of tools &
> admins decide to implement this standard?" and "did anybody
> decide to fill out the relevant forms?" - neither of which are
> meaningful when combating abuse. I am extremely skeptical of any
> claims that there's more information to be extracted here.
>
> The fact that it will be easier to programmatically look up this
> information seems to me unlikely to actually make things better,
> I see it mostly adding complexity and more GI for the GO. Just my
> opinion, obviously.
>
> But I remain vaguely excited about the potential for automation!
I harbor no illusion, it depends on adoption. Agreeing on a standard is
the first step. If there is no standard, there can be no meaningful
adoption. Putting adoption before setting a standard is to ensure
failure from the start.
>
> Cheers,
>  - Bjarni
>