Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

Joe Abley <jabley@hopcount.ca> Fri, 01 May 2020 00:07 UTC

Return-Path: <jabley@hopcount.ca>
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 832BD3A16CC for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 17:07:18 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=hopcount.ca
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 M6LRNcnVVKVg for <dnsop@ietfa.amsl.com>; Thu, 30 Apr 2020 17:07:17 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 1CB103A16CB for <dnsop@ietf.org>; Thu, 30 Apr 2020 17:07:17 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id k12so6773688qtm.4 for <dnsop@ietf.org>; Thu, 30 Apr 2020 17:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2Zufp8gSV/AYBtp5X6ExK/0c4v40TbkwpqGSmBIKc+s=; b=c7Iu6wrxApA+UAOYgUiQtYfcEgId0APrnMcuu9izrYy9m6qCqiSNZCBcASLJGblFwH RTsXV1bndD3ykRGy6MFpKW6+/+X+HRe7XIFkoHmcgES9FNst5152yHdtWI6NGYJpcV/i Mtg28RuXgshlJmxjiw5eM+ecL/76Jbtycqgt0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2Zufp8gSV/AYBtp5X6ExK/0c4v40TbkwpqGSmBIKc+s=; b=aAnPyYF+V1WwiGk1+0g5s9tCK0I+aN16wOLqdkOnQ5HO9ZbogNbGa315CDKHcaveEh PKfJEzoZJZpdONWu29ubugvWcaa7nKLqcjGF+koNuvQAJVQCgtgD9k0l/zPCD9ZqK7O1 CVE82qxZj+U7fR22Dp3i2t3wCYZIEkRR2k2oyH6ODThgI5bDNQLmQG2O3rD7mm7Dcgyb CwEfYPBaRH3+DMLGSPr8BRNmvWzZ6CXOlYv5lSHlxUdV8FMdrrVR+XXwAzjviIaggj2H qGHQsiiWKaZdEOB/EF6GAaJ7yUmA1dkO2EDGGFI8Z8t7EqB3gTPHFebrdIT6fBjIXOAj /dzQ==
X-Gm-Message-State: AGi0PuZbCL3eYD6fDOYmpeEpAcPWknObKmJP55B6imdIGM5Cbzc27GdB WDobRmFHmoZdQITg2ggyvPcPmA==
X-Google-Smtp-Source: APiQypIKv6QLzC4nn9kEiGhMOrtfjYzdw+jMHLWJNWe7CZhLoJqzHVC02CjdiVMQmqHVThkj0zkTpg==
X-Received: by 2002:ac8:65cc:: with SMTP id t12mr1222853qto.310.1588291635943; Thu, 30 Apr 2020 17:07:15 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:8838:194f:518f:74ce? ([2607:f2c0:e784:c7:8838:194f:518f:74ce]) by smtp.gmail.com with ESMTPSA id c4sm1406865qkf.120.2020.04.30.17.07.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 17:07:14 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <C45C4CF8-FD43-49B2-B273-FAEDA05885F6@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_300B4B4E-180D-4FC0-8B13-4AE342893ABB"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 30 Apr 2020 20:07:12 -0400
In-Reply-To: <8F265AC8-9369-40B6-9AE8-C8D8ED190320@isc.org>
Cc: Wes Hardaker <wjhns1@hardakers.net>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
To: Mark Andrews <marka@isc.org>
References: <CADyWQ+FLrTy0gy8iCyAPsDpiumDNQHX4TGPni43ThA=W3fmZew@mail.gmail.com> <EB400743-8B25-45DA-B4BD-5B27F47AE9E3@hopcount.ca> <ybl5zdg4po9.fsf@w7.hardakers.net> <7262A449-1171-49E8-BDF6-69601DB034EE@hopcount.ca> <yblr1w438fb.fsf@w7.hardakers.net> <8F265AC8-9369-40B6-9AE8-C8D8ED190320@isc.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gx0yrncpkvZ7_ZYs1ImEYaKvpGI>
Subject: Re: [DNSOP] Call for Adoption: 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: Fri, 01 May 2020 00:07:19 -0000

Hi Mark,

On 30 Apr 2020, at 19:52, Mark Andrews <marka@isc.org> wrote:

> On 1 May 2020, at 08:39, Wes Hardaker <wjhns1@hardakers.net> wrote:

> 
>> Yep, I suspect some of the bigger TLDs probably couldn't opt in to this
>> draft simply because they're full of, um, "history".  Until that history
>> is cleaned, they probably couldn't deploy it.
> 
> I doubt there is any real history here other than “we didn’t properly clean
> up the records when the delegation was removed”.  If a DNS provider goes belly
> up then all the zones dependent on that provider should FAIL.  Its just poor
> zone hygiene that leaves orphaned glue in the ORG zone.

I don't want to speculate on the actual reasons that orphan glue exists in the ORG zone before actually taking the time to investigate, but I'll note that the EPP data model provides some constraints around host objects and domain objects (e.g. domain objects can't be deleted when there subordinate host objects that exist) and there are reasons for delegations to be removed from the TLD zone while the corresponding domain object in the registry still exists (e.g. as part of domains that are suspended through the normal processes by registrars when they are found to be abusive).

I also don't understand the theory that any of these glue records exist because a DNS provider ceases operations. DNS providers don't feature in the RRR model. A failure in a set of nameservers could cause delegations to become lame, but there is no process that I'm aware of where orphan glue is a direct or necessary consequence.

Anyway, I am fairly confident in saying that there are legitimate, normal operational processes that can result in orphan glue, and that it's not correct to infer that they all exist for reasons of poor hygiene.

This is a topic of interest in a number of places right now. It is definitely on the list of things to investigate.


Joe