Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 31 July 2020 01:01 UTC

Return-Path: <brian.peter.dickson@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 669583A02BE for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 18:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 klGLKRFH3XwK for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 18:01:34 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 326CF3A0141 for <dnsop@ietf.org>; Thu, 30 Jul 2020 18:01:33 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id p8so7505389vsm.12 for <dnsop@ietf.org>; Thu, 30 Jul 2020 18:01:33 -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=O+VFZjpZu++jL39dYUngrlj6+riuvfclasc/5LInxzs=; b=QfnfgEGTqf0ZPF6oFjJJmKu22Yw8n3R/xfAUQOB6eElCb+n45V4fe+YCnB1qyQDMPO WBH+XO6Rz0V+V8z8SLt1lZ0M8k6JWpOU06Ga/KJ4w9PfMXbWi3Z4nvyniVbQUDUzRgXW f/1RYMJNY2nz6/7DA34OczAISKMt7BwCDR8thWhlk0b0a71zCUfIlXFGynN7vJC7eW3l qtJ6bdyH3hrBbhSr6IyVJ7tkY52I9/0UTuYZk7EoEU0Cxr1cfdT7HnZ7nUIU6gSLtz3U i3+yGTkj+2jWxdOJSM43hzNkIl4+APq0F1oy4iE67olnuK4nZtophjV9xyn0BIm+Ec/h TozA==
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=O+VFZjpZu++jL39dYUngrlj6+riuvfclasc/5LInxzs=; b=I5vEW58AKJJq4einUYeb+mcobH89W8ODt7tbdFxI1Ivm/+YCLyvZjeqrZTxBjMg5QP x4ehepueUSn7MlMobTlOXuNxNI6HjwVu5t77CM7d1w5NfFyCD1C6TJ+/VlawQONjoEcq v4EGKEsjWpX+QmaI7YZ/i0dDfIWOq7k+T/t7x9AQavB07n5LdslcbRg/Icd7o3+TcwWl /ooEq0AY7O2kxuU6iq75Sr8wDvtX02ywp0EPSxySHTXxGgRbT24br1tG8chp2PF3NHda SwUhe+8ssrQoZcbGB7izr22YjmmpYMAJuTwOdEPfyti5UZlIDChdMnIXfBnbhKIjiF3B O8XA==
X-Gm-Message-State: AOAM532RK+efJHW6wV30iOqjwhevKTmzFnsTR730DRPka7tbz8bYvwtt yQZvXjUUvx/lFphu/AgJYuv5BbvdMjxjqe1MZ4U=
X-Google-Smtp-Source: ABdhPJzYRZOb2gs4LutmS0DGHWZ2uWTtFd/rt8j8E3O/9T/yrzr7t0dWTuRowSpOfnDKLzSobQYj2oXsl9cKaFltd5s=
X-Received: by 2002:a67:e81:: with SMTP id 123mr1567379vso.75.1596157292947; Thu, 30 Jul 2020 18:01:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca> <alpine.LRH.2.23.451.2007301446380.418549@bofh.nohats.ca> <31548781-6B30-4198-810F-32245590C7D6@hopcount.ca> <alpine.LRH.2.23.451.2007301630050.418549@bofh.nohats.ca> <FA4E316A-E42C-4653-8B92-C505F28E7FD2@hopcount.ca>
In-Reply-To: <FA4E316A-E42C-4653-8B92-C505F28E7FD2@hopcount.ca>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 30 Jul 2020 18:01:21 -0700
Message-ID: <CAH1iCiqQLFpNTm31b7UXV=xcg-wZ6z+RisZLYTEtazzTobxW9Q@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: Paul Wouters <paul@nohats.ca>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073ad7205abb25433"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZKrYLwYaO68A23a_fiQG_RMVLT4>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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, 31 Jul 2020 01:01:38 -0000

On Thu, Jul 30, 2020 at 1:44 PM Joe Abley <jabley@hopcount.ca> wrote:

>
> There are some 20,000 examples in the ORG zone, of which at least 7,000
> are due to the domain suspension mechanism I gave as an example. There are
> lots of well-functioning domains that would fail if all of those A/AAAA
> records suddenly stopped resolving.
>
>
> That also seems quite imprecise. Here's a more specific worked example to
> make sure we understand each other.
>
> $ORIGIN ORG.
>
> BADDOMAIN NS ...
> BADDOMAIN NS ...
> NS1.BADDOMAIN A 192.0.2.1
>
> GOODDOMAIN NS NS1.BADDOMAIN.ORG.
> GOODDOMAIN NS ...
>
> If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some
> equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be
> removed (the BADDOMAIN.ORG NS set will disappear) but the A record above
> will remain, since it is linked to another domain, GOODDOMAIN.ORG, that
> depends upon it. Without a zone cut, that makes the ORG servers
> authoritative for the A record.
>
> I realize this is close to going down a rabbit/rat hole, so I'll try to
keep it as focused as possible.

Those two numbers (7000 and 20000) raise a question in my mind:
What's the typical range of domains impacted for each suspended domain?
I.e. given BADDOMAIN and GOODDOMAIN_1 through GOODDOMAIN_N, what would the
median value of N be, and the max or 95%ile value of N?
(I'm guessing it would be easier for you to get the answer than it would be
for me.)

The reason to ask is, what is the reasonableness of alternatives to the
current method depend? Those very much on the expected size of N.

If N is most typically about as many fingers as there are on one hand, that
suggests that changing the glue for the remaining domains, on a per-domain
basis, is not an unreasonable amount of work.
(I.e. replace all instances of "NS NS1.BADDOMAIN.ORG" with "NS
NS1.GOODDOMAIN_1.ORG", and replace NS1.BADDOMAIN A <value> with
NS1.GOODDOMAIN_1 <value> everywhere it occurs in the ORG zone.)

It's unclear whether this crosses the line of what registrars should do vs
what registries should do.
If the "suspend" action is not literally accompanied by the registrar doing
the removal of the NS records, then the (temporary) renaming of the object
by the registry on behalf of the registrar(s) involved, would seem to not
be unreasonable.

It keeps the GOODDOMAIN_N delegations functioning, and avoids promoting
glue to authoritative.

Of course, the OTHER question is, of those 20000 instances, in how many of
those cases is the registrant for BADDOMAIN and GOODDOMAIN_N the same
party? Is the expectation of the registrant that their error (lapse) or
action (abuse) on BADDOMAIN should not also have the same impact on the
related domains operated by the registrant a reasonable expectation?
(That's probably a lawyer question.)

I'm happy to stick to the technical aspect, on the renaming option: for
each suspended domain, what is the number of domains sharing a nameserver
below the delegation point, and thus how many actual renaming things and
address substitutions would be expected/required?

Brian