Re: [DNSOP] Verifying TLD operator authorisation

Tim Wicinski <tjw.ietf@gmail.com> Fri, 21 June 2019 13:33 UTC

Return-Path: <tjw.ietf@gmail.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 5DE6812026B for <dnsop@ietfa.amsl.com>; Fri, 21 Jun 2019 06:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 rSkgXRwQLDIf for <dnsop@ietfa.amsl.com>; Fri, 21 Jun 2019 06:33:45 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEF9120265 for <dnsop@ietf.org>; Fri, 21 Jun 2019 06:33:45 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id v186so4656635oie.5 for <dnsop@ietf.org>; Fri, 21 Jun 2019 06:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MagAXFOsBklRO37HYO0KK1/pMhcYv2VBk7/FuWzUws0=; b=ONz4HWTxq9r4S4JESqcnXbDnQ0pvrLJKNQzsvVcigiPJYY1dF4BKZdU3smDNJFY6s8 3xLyLxRUr9H843rTgVQFJjn7loQSMGjUeBVzsMJxgWi0bwmMThVTRCihHcSne4jr1apW qX4uZPAZzTKtMjO2IWZ5u/JbKByVZv81besdi/dlasutSLnIQGlxm3mVO4y/GKJz/EC0 p/7Q/AWdqsXDUU6iJDinjNz52pSppDmHS7z4EGarvWPVUboACLf8uV8oQCd2DpXJ8tD4 3oztYNM02n+GK6B2/63+NszYtIgE2riaEm/knZ+SgGKH6AVLlt0vPXUaFvHa+HuVMZKC Vf6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MagAXFOsBklRO37HYO0KK1/pMhcYv2VBk7/FuWzUws0=; b=sab2z1ogMnscJViaD/2r2llZDCOZiXvXbyIF7MOn8lUrvZwr0q4YCs0sUzafLRUICb hk5wT0Mkw9QiixMGgvgA+gxIakBUs0Z+EPQMsK0BgA06gYK+FnQDsznDK6LZBzPYWVIR JopIDkDnRiq0KQf9Z56lOGuCzfWFDNxNSW/lNTOaJWICXfUQtp+wL6b+Emx0ySbHKmBx mUGUvin2z59j0vauNzEjfrv82fEgi2h1lc9pKLb2l3x39dc8zGmaYI57IlVhwmrqcM+M 2djFRVdzFUJULzAcfyZraHF1GDcXIsF3WO9iJcJl1dxAi6J0n45wCcpO+RQtiY2XZpWn SVaQ==
X-Gm-Message-State: APjAAAXy1v5jnF+btbQkm0YAyMpwNaZs5pytMcBd7HNu84JlJERZPnMr USofKVMhyfhcZWZ/jApqyhKYcUX/UvJREQafaYEjCn7D
X-Google-Smtp-Source: APXvYqwv2GUj42EHChoVKXCV4mqZFvXf0vObrutiDkr+zwOLuShTUSQfIlu0NQEBh1hD8BmfzkTEPnf7nnDiEI7wCL4=
X-Received: by 2002:aca:b90a:: with SMTP id j10mr226478oif.170.1561124024884; Fri, 21 Jun 2019 06:33:44 -0700 (PDT)
MIME-Version: 1.0
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> <65032614-6B18-4518-97BD-524775904D26@isc.org>
In-Reply-To: <65032614-6B18-4518-97BD-524775904D26@isc.org>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Fri, 21 Jun 2019 09:33:33 -0400
Message-ID: <CADyWQ+HVYAfVE0WSEPAG7Zz_OL+uM4DmHRLn6Y=mAPQZE5M7eQ@mail.gmail.com>
To: dnsop WG <dnsop@ietf.org>
Cc: Seth Blank <seth@valimail.com>, "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f422e2058bd58200"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/C39rujdz6l1Aka7vMxQDwYKh6Kc>
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: Fri, 21 Jun 2019 13:33:49 -0000

If y'all care what gets published in a TLD, please take a look at
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
which is an experimental draft that will go into WGLC last call soon.
This was driven by wanting to add _dmarc records
into TLDs, per ICANN rules it needs to be an RFC.

Tim

(Murray Kucherawy, Seth Blank and myself may have something to do with the
DMARC working group management).



On Wed, Jun 19, 2019 at 7:41 PM Mark Andrews <marka@isc.org> wrote:

>
>
> > 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>