Re: [DNSOP] Fun with draft-pwouters-powerbind

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 30 April 2020 03:39 UTC

Return-Path: <ietf-dane@dukhovni.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 C5B2D3A0F25 for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 20:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 kJGU_cRGaeou for <dnsop@ietfa.amsl.com>; Wed, 29 Apr 2020 20:39:05 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A0F943A0F26 for <dnsop@ietf.org>; Wed, 29 Apr 2020 20:39:03 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id E0A19295BCB; Wed, 29 Apr 2020 23:39:01 -0400 (EDT)
Date: Wed, 29 Apr 2020 23:39:01 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20200430033901.GH41308@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <yblo8rb73v4.fsf@w7.hardakers.net> <20200428222655.3E27E1883A28@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200428222655.3E27E1883A28@ary.qy>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_6tROglCl5ecVFUnln1qhhjx2KE>
Subject: Re: [DNSOP] Fun with draft-pwouters-powerbind
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: Thu, 30 Apr 2020 03:39:07 -0000

On Tue, Apr 28, 2020 at 06:26:54PM -0400, John Levine wrote:

> I think we will find that the assumption that TLD zone files are
> delegation-only does not hold up very well in practice, so I am
> wondering how useful a hack to technically enforce it would really be.

There are indeed some TLDs which are not delegation-only.

For example, DeNIC is known for directly serving some small (IIRC ~5
RRsets) child domains directly out of the .DE parent zone with no zone
cut.

But that's just an implementation detail, and could change in the
future, if there was good reason to care.

But there are also some large TLDs that are delegation-only, and could
be a good place to get started.  I don't see ".com" or ".net" on your
list, most of those are brand domains without open registration, and
they are legitimately free to delegate or not delegate whatever they
want.

> 54952 info
> 28012 org
> 6610 pro

Pretty much the the only two or three with non-trivial numbers that
matter on the list.

> Some mystery names:

These two patterns have been around for ages, used for some sort of
automated monitoring, and don't matter.

> monitor-nominet.abogado has address 127.0.0.1
> emt-ns1.emt-t-1070866640-1587743943997-2-ag.aarp has address 198.41.1.167

My .com zone processing code has for many years now being moving right
past these:

    next if (m{^(emt-)?t-[^.]+-[^.]+-[^.]+-}io);

I am sure ways can be found to handle these sentinels (not real
child-domain delegations).  For example, the spec could exclude domain
names that start with "_" or "_sentinel".  And the sentinel names could
then all live there.

-- 
    Viktor.