IETF Logo Mail Archive

Re: [DNSOP] Mitigation of name collisions

Rubens Kuhl <rubensk@nic.br> Tue, 04 October 2016 01:00 UTC

Return-Path: <rubensk@nic.br>
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 9093E129550 for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 18:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.297
X-Spam-Level:
X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
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 sUVzTXSI4KXu for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 18:00:32 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (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 E1C8B1294C3 for <dnsop@ietf.org>; Mon, 3 Oct 2016 18:00:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id A3718490A; Mon, 3 Oct 2016 22:00:28 -0300 (BRT)
X-Virus-Scanned: Debian amavisd-new at mail.nic.br
Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br
Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGWIqBtM-6f1; Mon, 3 Oct 2016 22:00:26 -0300 (BRT)
Received: from [192.168.1.81] (unknown [177.94.147.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id CB65442DC; Mon, 3 Oct 2016 22:00:26 -0300 (BRT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1475542826; bh=/LsnK/0Re1Bfaht22BwaylkwVPD/kSn71twy9k0oPpk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dpMMYCB+mn9BfLP4cPvinDrcf7mZ85IL23EC3eviS1vxC3yQk2U/MeFuX/dRuArJX qSZgLVphqWurzkfTEy1YgAoV80TFg3LDa9OlEzdivLFz3p+HTAAZBhRkkPDUI1T3Py hZA43mxMJnyoX92k0H0cgsJB2p42oqBHXFvTizhY=
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F5DA283-C5E5-4051-950C-26B4D1FFFA23"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Rubens Kuhl <rubensk@nic.br>
In-Reply-To: <etPan.57f2f8ec.78e3fb2f.8936@virtualized.org>
Date: Mon, 03 Oct 2016 22:00:26 -0300
Message-Id: <4F616B8A-8987-436D-80F1-56C7D6E1A5CE@nic.br>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org> <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com> <etPan.57f2f8ec.78e3fb2f.8936@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.3124)
DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br CB65442DC
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Bp5LqtlCjF-yF_MDEnFCK4PKxd8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Mitigation of name collisions
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 04 Oct 2016 01:00:33 -0000

> 
>>  or if 
>> the name-servers serving the wildcard were required to collect and 
>> publish information and statistics. This would have allowed analysis 
>> of the effectiveness of the mitigations, etc. 
> 
> 
> This, however, is more interesting and should another round occur, I think it'd make sense to do this in a staged fashion, first to ICANN name servers, then to the registry's name servers.
> 
> Of course, IIRC, people were arguing that you shouldn't ask questions when you aren't sure what you'll do with the answers... 

David,

Add to that starting doing controlled interruption as soon as next round reveal day, long before evaluation, contention set resolution and contract signing, and you will see lots of happy people in many sides of this problem. 


Rubens

v2.23.0 | Report a Bug | By Email