Re: [DNSOP] Verifying TLD operator authorisation

Mark Andrews <marka@isc.org> Wed, 19 June 2019 23:41 UTC

Return-Path: <marka@isc.org>
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 E1D7A12041D for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2019 16:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KNoQs9b-S7B9 for <dnsop@ietfa.amsl.com>; Wed, 19 Jun 2019 16:41:12 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 7E4821202ED for <dnsop@ietf.org>; Wed, 19 Jun 2019 16:41:11 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E1F3F3AB1AD; Wed, 19 Jun 2019 23:41:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D00E4160050; Wed, 19 Jun 2019 23:41:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BE7CF160072; Wed, 19 Jun 2019 23:41:09 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0RiMkcRWnKXV; Wed, 19 Jun 2019 23:41:09 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C1909160050; Wed, 19 Jun 2019 23:41:08 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <95F7D9FF-D403-4638-B3C3-79D1EDC34054@hopcount.ca>
Date: Thu, 20 Jun 2019 09:41:06 +1000
Cc: Nick Johnson <nick=40ethereum.org@dmarc.ietf.org>, dnsop WG <dnsop@ietf.org>, Bjarni Rúnar Einarsson <bre@isnic.is>
Content-Transfer-Encoding: quoted-printable
Message-Id: <65032614-6B18-4518-97BD-524775904D26@isc.org>
References: <CAFz7pMvkQUz78Qow03RsFKHof3nrnGu3BUwUP0zstWgVtP3Msw@mail.gmail.com> <tqjbSfSi2Kv3DHpi6nBJVi2e6tCZFTdVyrKpxiud2348@mailpile> <4353B4DB-3F05-44B7-8272-A07EAF73B009@rfc1035.com> <CAFz7pMsAZvUybb=i50s4woCacZiFY938s-UVb5rMPSC-Fx27pw@mail.gmail.com> <95F7D9FF-D403-4638-B3C3-79D1EDC34054@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rAjfxycHMQjrseXSukiVpnrlIhE>
Subject: Re: [DNSOP] Verifying TLD operator authorisation
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, 19 Jun 2019 23:41:15 -0000


> On 20 Jun 2019, at 8:45 am, Joe Abley <jabley@hopcount.ca> wrote:
> 
> On 19 Jun 2019, at 18:28, Nick Johnson <nick=40ethereum.org@dmarc.ietf.org> wrote:
> 
>> On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson <bre@isnic.is> wrote:
>> The SOA record for a TLD contains two DNS names which should be
>> under the control of the NIC: that of the primary master
>> nameserver, and the e-mail of the responsible administrator
>> (which includes a domain name).
>> 
>> This seems like an excellent idea - thanks! I'll wait to see what others have to say.
> 
> I think you could probably build a heuristic around MNAME and RNAME that would work at least most of the time. However, there's no definitive identifier and there will always be exceptions you have to work around. Sometimes MNAME relates to a back-end registry provider, sometimes to a registry operator, and sometimes something else entirely. Ditto RNAME.
> 
>> I think I addressed this upthread: If someone has the ability to change a zone's DNS records and generate valid DNSSEC signatures for them (which we will be requiring and verifying), they're sufficiently 'in control' of the zone that I'm comfortable treating them as the authorised user. If someone malicious has that control, the TLD owner has much larger problems.
> 
> The organisation that generates the SOA/NS/A/AAAA RRSets in a delegation-only TLD zone is not always the same organisation that signs it. Also, not all signatures in a zone can be guaranteed to have been created by the same organisation. Also, not all TLDs are signed.
> 
> The contacts that the IANA relies upon to authorise changes for TLD operators can be found at whois.iana.org, for what that's worth, or in due course at the RDAP server specified in the object <https://data.iana.org/rdap/dns.json>. But if you're looking for something reliable you can validate using DNSSEC, I think you're out of luck.

And if you try sending to them you find the email addresses are often
do not exist, bounce because the mailbox is full, are gatewayed to a
restricted distribution list, or just ignored.  Some do work though.
My experience maybe biased because I’m always reporting problems when I
send to them and if the operator hasn’t already noticed the problem
there is a good chance the contact is also broken.

> Joe
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org