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

Joe Abley <> Thu, 30 July 2020 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 782923A0C70 for <>; Thu, 30 Jul 2020 13:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H8EBtORxg-cL for <>; Thu, 30 Jul 2020 13:21:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC0D33A0C60 for <>; Thu, 30 Jul 2020 13:21:40 -0700 (PDT)
Received: by with SMTP id t23so18237183qto.3 for <>; Thu, 30 Jul 2020 13:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6WrgEPO9QreqnQ8uZur6oK1KrQZVQiJF5ga1J9Phkxk=; b=dMUyApBg6QS8qt0rSl6v2ayF7Nrx3YTPUo3nYsqspBN5St1rh3JTtDH5olycdPLTMs HtYfsuKADkjDVTkhTzWjN2wFe0FQU0Q1VgPtb/J2BwaYraL7nP22x+1WAgPr86BrEnXx EEnHyxk/tF93ZkbH5UKtf5iOeMaJMtibaNB7o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6WrgEPO9QreqnQ8uZur6oK1KrQZVQiJF5ga1J9Phkxk=; b=enSjQjl7WlEFAjaVzG8xLywASnReUi0B56lJN95L0P/SeU8JxNoBCxKHPRmqiGifji xY4luQx+2AjTwFsMTXhab6wZPqdX1fcaLUA+MpwTyoLjMpDUsdm4GQ+Ewr+V9ysJgxnJ CSn/KmtlVmhSXEoD+75bFiSWy4IhQOx97pCNWpk3nJe2PG21z1rJz9UUYPpluwAylb3W /k0szEe30X7XRZsk1/RAHle9PZMBPJQZa2J5+D07p/9KcD4HtaZnpJaRpll40mg4UiPB YORjY4mKaCDlrqG+MyR/9xNy4JFlCHwIEmFBl1vR5SUbqPL0EVEmNOyfBUEnDbeD/96c 8b3A==
X-Gm-Message-State: AOAM5304aQwyusrclXGH2df9j1JMogQEoWxRtOs0aeBpRCaMt9/Zacp7 pAzhimj4S+i3bnPPhjnZFTX7Fcf5av3d7A==
X-Google-Smtp-Source: ABdhPJxBtdJIpvlNDWBUWyx3cbWa4lcI8A6/7X6Qo+ez8ac8/qAHKd2kjRZ19b9ZtpEzlJ5cELHrwQ==
X-Received: by 2002:ac8:154:: with SMTP id f20mr416783qtg.57.1596140499649; Thu, 30 Jul 2020 13:21:39 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb? ([2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb]) by with ESMTPSA id l64sm5000338qkc.21.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 13:21:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joe Abley <>
In-Reply-To: <>
Date: Thu, 30 Jul 2020 16:21:37 -0400
Cc: dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Paul Wouters <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 20:21:43 -0000

Hi Paul,

On 30 Jul 2020, at 15:43, Paul Wouters <> wrote:

> You are mixing up the generic policy of delegation only with the exact
> semantics of the bit.

I don't think so, but I would definitely appreciate some clarification if you think that's happening.

> The .org is definately what I would call a
> delegation-only domain. Now let's examine the corner case you have
> and see if/what we can do.

OK. Note that it's not a corner case, however; there are many thousands of examples of this and although I haven't examined every single serial that has ever been published, it seems entirely plausible that that there has never been an ORG zone published since 2002 which has been delegation-only.

> Rephrasing what you are saying is that "sometimes we need to take over
> our children and we currently do this in such a away that we would no
> longer appear to be delegation only".

That's a fairly clumsy way of saying what I mean, but it's entirely possible we are talking about the same thing :-)

> So you are saying that if serves
> and is suspended for abuse, that you will still service
> A records for and NS records for
> containing but no NS records for In
> the hopes that keeps working?

That also seems quite imprecise. Here's a more specific worked example to make sure we understand each other.




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.

To a certain extent, this behaviour is a consequence of (a) the venerable operaetional need to suspend domains because they have been implicated in abuse and (b) the EPP data model used in the ORG registry, which itself has its origins in the RRP data model used before the re-delegation of ORG to PIR in 2002. As such, it's tempting to assert that the behaviour is a contractual requirement shared with all other gTLDs that are operated subject to the same contract that exists between PIR and ICANN, hence my question about applicability.

> Wouldn't that already fail with DNS servers like unbound with:
> 	harden-glue: yes
> 	harden-dnssec-stripped: yes
> 	harden-below-nxdomain: yes
> 	harden-referral-path: yes
> which is the default in Fedora / RHEL / CentOS and maybe others?

If so, that sounds like a problem with Fedora/RHEL/CentOS. To the best of my knowledge, this has been the way that ORG has operated for the past 18+ years.