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

Patrick Mevzek <mevzek@uniregistry.com> Thu, 30 July 2020 21:33 UTC

Return-Path: <mevzek@uniregistry.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 97B483A0D1B for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-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=uniregistry.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 5NUBJVUppqoo for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 14:33:43 -0700 (PDT)
Received: from a-mx.uniregistry.com (a-mx.uniregistry.com [64.96.177.8]) (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 AF9903A0D18 for <dnsop@ietf.org>; Thu, 30 Jul 2020 14:33:43 -0700 (PDT)
Abuse: Forward to abuse@uniregistry.com with full headers
X-Virus-Scanned: Content filter at a-mx.uniregistry.com
Powered-By: https://www.uniregistry.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniregistry.com; s=bravo; t=1596144822; bh=TgMNMdy9yO8fcgTEzseYwqC6TqnLVl9dLwQSoSnIIvc=; h=Subject:To:References:From:Date:In-Reply-To; b=FhJmYv/kWIN3PoP7JaVMeu2Xsh6GRKZITcFPQJB+JbAkhzjHpv0Y+/TTKZbTxWNrB T/jdpXgtaQtX8f6Ld5vvrs+K7mD5tC083AvdsDG8BjprUmEo556I13umi67HrIll3n +FGfhOHZaz6NsSgrVkT4V4kpYQE8w++vCQODkc9DdkFLUENfFE/7EOqPoXjITzqwMZ MljgFBLzRUcuPboACTrmEvWDMhKym+PeeSPiK5KwCSaZ2Jv9xECRfLhZpMt6HCHsl9 FIY70GybY26hi8pisX/eEA1Xt+c5pOPHXi8isUEl5v9wRTWh1Dj2KLndsTmk5DTywM bP3s5JiHhJ0ew==
Received: from [10.8.204.86] (b01.uniregistrar.net [52.204.70.64]) (authenticated bits=0) by a-mx.uniregistry.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 06ULXfjm046523 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2020 21:33:42 GMT
To: dnsop <dnsop@ietf.org>
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> <D028D3F2-F562-436C-B019-0C722C7E1FA1@hopcount.ca>
From: Patrick Mevzek <mevzek@uniregistry.com>
Organization: Uniregistry
Message-ID: <d328c82d-8770-25af-399c-50e5dd07196a@uniregistry.com>
Date: Thu, 30 Jul 2020 16:33:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <D028D3F2-F562-436C-B019-0C722C7E1FA1@hopcount.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_WDJlo_blZ9KXHDmoLuYur6gPZY>
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: Thu, 30 Jul 2020 21:33:46 -0000

On 30/07/2020 15:46, Joe Abley wrote:
> On 30 Jul 2020, at 16:36, Paul Wouters <paul@nohats.ca> wrote:
> 
>> Seems like .org needs to update an 18+ year old operation policy, and
>> just to clarify that has nothing to do with this draft as .org already
>> has this problem.
> 
> Again, I'm not a lawyer, but I think what we are doing is a consequence of the contract we have to operate the ORG registry. If that's right you are of course entirely at liberty to engage through the ICANN bottom-up policy-development process to advocate for individual contract changes for the 1,500 or so TLDs that are operated under essentially the same contract.

ICANN procedures and hence application process for new gTLDs have 
specific text/question to address the handling of "orphaned glue 
records" in the registry zonefile, in the sense that the operator needs 
to document what it does, which probably hints at the fact that there is 
no one size fits all solution here.

Question 28 of 
https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf
is:

Abuse Prevention and Mitigation: Applicants should describe the proposed 
policies and procedures to minimize abusive registrations and other 
activities that have a negative impact on Internet users. A complete 
answer should include, but is not limited to:

[..]

Proposed measures for removal of orphan glue records for names removed 
from the zone when provided with evidence in written form that the glue 
is present in connection with malicious conduct (see Specification 6);

</quote>


There is even a SSAC comment on this too.
[SAC048]: 	SSAC Comment on the Orphan Glue Records in the Draft 
Applicant Guidebook (12 May 2011)


https://www.icann.org/en/system/files/files/sac-048-en.pdf

Note specifically this part:

Orphaned glue can be used for abusive purposes; however, the dominant 
use of orphaned glue supports the correct and ordinary operation of the 
DNS.  Thus it is inappropriate to include the management of orphaned 
glue under the rubric of "abuse prevention and mitigation" and we 
suggest that it be removed


-- 
Patrick Mevzek