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 DDAFA129550 for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 18:00:34 -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 o_mU1BdStbqp for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 18:00:33 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [200.160.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 46E1E129504 for <dnsop@ietf.org>; Mon, 3 Oct 2016 18:00:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 74C3D42DC; Mon, 3 Oct 2016 22:00:29 -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 DOEmAY1xgts4; Mon, 3 Oct 2016 22:00:27 -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 AF44F490E; Mon, 3 Oct 2016 22:00:27 -0300 (BRT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1475542827; bh=j5awKLFFI/aBPz9amf0rq2Gs+C/wG/mFOmafVJFMUqI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=CM47D14P+KPCPOObXfT36iWdQhJl2dFDTFQqBigcAICTGC0No6GDWGHge9GDHRs4R 3HcbFIJL4mQmpKjrwDqvP5HoFYF7nk0dJujolvpETQMx6cmXtMzfC1mVcPCuuAWJDd 5s+7i64qZCmdhG78Tff4Ow4U60WUcVrtnS4IVgHA=
Content-Type: multipart/alternative; boundary="Apple-Mail=_178891B3-3F0C-4350-9CFB-C2D7FC8B2BEA"
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:27 -0300
Message-Id: <D16C2EDE-B00F-4B34-B5FD-1CB4B058D619@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 AF44F490E
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QHS2PzsdwsNX6J4TXj4FU3hnbu8>
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:36 -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