Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Wed, 10 July 2019 01:07 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 A98331200F9 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 18:07:46 -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 XbNI5iKth34H for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 18:07:44 -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 D04081200F6 for <dnsop@ietf.org>; Tue, 9 Jul 2019 18:07:44 -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=kXofZEJCmK0fhWlIXAVvqqomNJCGwEN2gRF1p2kfLhE=; b=cg0jOt1SQli9b4RT2uB9Nty3E owDZYX90v/NOQVlqLmLGllVLRRZIr2N8HkuYxZzVDd4xMU1VVPpByGML2vshyjWoQdlit2dhShnVv SmCgmSCqYkUXji8zDFJJ3hT/wVqnz4EcvTUi0DSGy6vH7OBhW/OYQptRfUjO1zNW5sWcY=;
Received: from 154.sub-174-221-142.myvzw.com ([174.221.142.154]:6200 helo=[100.98.96.231]) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hl15C-0006SI-N9; Tue, 09 Jul 2019 21:07:42 -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: <4071a771-cfc8-0759-cde0-104382d382b8@redbarn.org>
Date: Tue, 09 Jul 2019 20:07:42 -0500
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFBF6579-6889-4ED9-8082-461DEED4A0F8@bambenekconsulting.com>
References: <1CA7BF1B-DF50-443B-9219-55259835FE23@bambenekconsulting.com> <3564488.2yaKDDZa9B@linux-9daj> <6ABF86DD-A4D6-459C-A790-B3406932C76E@bambenekconsulting.com> <2274465.ZR2O4vXfpM@linux-9daj> <A8E77F47-69BD-434D-8720-274CE77D14ED@bambenekconsulting.com> <4071a771-cfc8-0759-cde0-104382d382b8@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
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/dSmbbAMc5kwdqHUNdqUibARjyMs>
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 01:07:47 -0000


—
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 9, 2019, at 19:41, Paul Vixie <paul@redbarn.org> wrote:

> 
> 
> John Bambenek wrote on 2019-07-09 17:29:>
>> 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 9, 2019, at 19:13, Paul Vixie <paul@redbarn.org> wrote:
>>> whois and rdap servers are a dime a dozen. i can run one for all
>>> of my domains, and put it behind a rate limiter to make life
>>> harder for scrapers.
>> The reason scraping and rate-limiting make sense with registry operates servers is because scrapers want to query the whole portfolio.
> 
> this is wrong. stop being obstreperous and deflective about this topic
> for a few days if you want me to tell you why. i'm done otherwise.

How is it wrong? I’m not being deflective (or at least not trying to be). If I’m an attacker who wants lots of emails in whois, I’d hit up .com 140 million or so for each domain. In my proposal, you’d query the auth server for say bambenekconsulting.com once and have what you need. Why would an attacker query a whois record twice for the same domain?

Sincerely, I’m not being deflective I just don’t see rate limiting helping you in the proposed model. 

> 
>> In this scenario, the attacker only queries your record once and has what he needs to move on to next domain. Any rate limit beyond 0 doesn’t protect you.
> 
> same.
> 
>> And if you run DNS Auth, don’t have the ability to rate limit today?
> 
> i think you mean "don't you have", and no, because as i said up-thread,
> i can't ask my friendly secondaries to do custom name server settings
> for those of my zones they handle.

I meant if you run the authoritative (and secondary) NS for a domain you could. If you share that with a third party, obviously you are constrained by the rules of that third party. 

> 
> -- 
> P Vixie
>