Re: [DNSOP] Proposal: Whois over DNS

John Bambenek <jcb@bambenekconsulting.com> Mon, 08 July 2019 22:06 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 DE745120077 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 15:06:04 -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 fVtMDZdh8_9j for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 15:06:02 -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 79715120090 for <dnsop@ietf.org>; Mon, 8 Jul 2019 15:06:02 -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=0EYINfiC9axdR1kiPdTYVup0PfVvuTwWkkOYRUJbWLw=; b=mFbwcIfOstxY7JsOeHc7jVG2y kSnJlbsb69T6nNAQJf8gr6IpgpfeC0FMsB8tEAk8/0j+JlFqkAWvxFvFOCwNESW83nrL75debz9E4 CMudXdJ4VN6hYiFOZ+fm8J6fPm7dFq2nk0su8EFwSQbjJ+3xGrr9lZle0MoVC+98XqsCg=;
Received: from [216.169.1.210] (port=14416 helo=[192.168.11.116]) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <jcb@bambenekconsulting.com>) id 1hkbln-00042J-Ut; Mon, 08 Jul 2019 18:06:00 -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: <3f3b0fcd-e09d-be29-7b85-ceb34a2e10f7@uniregistry.com>
Date: Mon, 08 Jul 2019 17:05:59 -0500
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9ED809E4-8121-4636-87D4-3A062FCC8C80@bambenekconsulting.com>
References: <1CA7BF1B-DF50-443B-9219-55259835FE23@bambenekconsulting.com> <3f3b0fcd-e09d-be29-7b85-ceb34a2e10f7@uniregistry.com>
To: Patrick Mevzek <mevzek@uniregistry.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/sqi7dGLwWDzJA3xA9u55ROuinq8>
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: Mon, 08 Jul 2019 22:06:05 -0000

For domains with no NS records? Who cares, they aren’t in actual use. (Or if they are something is broken or more likely malicious so block it). 

Yes, the onus is on domain owners (and that requires consensus and adoption which are not given but why its being brought up here). The registrars and registries don’t want it and won’t accept it (see other email). 

As to your last point, yes, whoever can modify DNS owns these records and if compromised means you can’t trust it in real time (but passive DNS helps solve this). Its distinct from a web server which means “most” of the time you have to compromise two separate systems. What is best is independent third-party verification but we don’t get that and we won’t. So, here we are. 

—
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 8, 2019, at 16:52, Patrick Mevzek <mevzek@uniregistry.com> wrote:

> 
> 
> 
> 
>> On 2019-07-08 16:38 -0500, John Bambenek <jcb=40bambenekconsulting.com@dmarc.ietf.org> wrote:
>> In response to ICANN essentially removing most of the fields in WHOIS for domain records, Richard Porter and myself created a draft of an implementation putting these records into DNS TXT records.
> 
> Not all registered domains are published (no NS records), so what about those?
> 
> Also your proposal puts the onus of (valid) information publishing on the registrant of each domain, no more on the registrar or the registry, because
> _whois.example.com is under the control of example.com and not under control of the registry under which example.com lives and neither its registrar as the DNS provider may not be the registrar.
> 
> So what did I not understand about who controls and where do the _whois.example.com RRs exist?
> 
> As for:
> "This means that if a domain owner were compromised,
>   someone else has contact information to get in touch with the true
>   own to organize remediation."
> It depends on how you define "domain owner were compromised".
> This could as well mean "have access to registrar panel to configure this domain" which in turns means "being able to put whatever nameservers, and hence DNS records as one wishes". But you may be relying on the TTLs of old records?
> (a point not discussed I think; would long TTLs be good for those records?).
> 
> Also, a similar idea was floated on the regext mailing list sometimes ago:
> https://www.ietf.org/archive/id/draft-brown-whoami-02.txt
> This was using well known URIs to publish whois data and the URI DNS RR.
> -- 
> Patrick Mevzek
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop