Re: [DNSOP] Mitigation of name collisions

Warren Kumari <warren@kumari.net> Mon, 03 October 2016 22:33 UTC

Return-Path: <warren@kumari.net>
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 4CA8B12953F for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 15:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level:
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 YaZlIWqC4mfC for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 15:33:08 -0700 (PDT)
Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) (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 7AB32129452 for <dnsop@ietf.org>; Mon, 3 Oct 2016 15:33:07 -0700 (PDT)
Received: by mail-qt0-f169.google.com with SMTP id 38so86532996qte.1 for <dnsop@ietf.org>; Mon, 03 Oct 2016 15:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4kngcOQ0IxSaQxtkWQquDAHTyPGtIUrdAW1Q7lI4MoQ=; b=c3s5EJqfP5QzffRCnQW5RZzvGoEBZaalpxmRk06JfHSwsnTRJKgBAe5SVsgvOu77/H 5s/p6NcODA+uRAcOLc7T8Auq3yO49Z38ck9F6FGC6fTSj3S2f4AoJ48hybzHe3J6tMwi sUDmxhEm+kUzaX47J5l5VJvvUZpuG72jNGN0WCZlRBhvcjOp86Aa6XgvcCinoQ9HPQRp 0kiper7QY6b7HVD6UiRJOKYdcxSN+bSeOPLdMvdbeo8IIilaKoLaH6agn9kbOpym2PbX z+nFFk3TjkevjQYGLMG+35dTAUrv9iPhWrISguhwY3vpJYoKaVmVb0SEe21W+rETe4Qp LVTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4kngcOQ0IxSaQxtkWQquDAHTyPGtIUrdAW1Q7lI4MoQ=; b=T9esvbm8FisVbsDAkcO7bvW5jaM0a3wRmd8LmhFtybfNPqUSuF4H8S5bbOdxO4ESAi j0wvAj7gM4CFRwBByYgtz9S1hrDP7RyuO8ItR4vZCE0qqnXoJLhYANWKXiSEy26OpxwE a75dE+GvTJFkX37UtK4SPV7tocWdcsnJwIFDsRYckArt/4Y2F9TkkkcBjLQaTbS1wy8j yJ8IutvBQjS96Aa24Od3lVxafpZBa2t1TT2Udj0vMMpXVU4q1mwK82aN43CtU9l6o4Sy btz02qgJfHsnkxHusR8gkyz57arWfzqgkQGCqClMhAyewoaU+rxtR3zC7t8yF9nmnhXk 6CIQ==
X-Gm-Message-State: AA6/9Rmedrlp9t580s7xM411LNI+GCP35dGa0M+YfAM98gQpBhY2O0pQt0Bu3/pzER8tDWTLJflMl2YlHSq4InfI
X-Received: by 10.237.34.149 with SMTP id p21mr464480qtc.84.1475533926488; Mon, 03 Oct 2016 15:32:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Mon, 3 Oct 2016 15:31:36 -0700 (PDT)
In-Reply-To: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 3 Oct 2016 18:31:36 -0400
Message-ID: <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PEkK5lGzQHzELh4FYKyw2XYXx-0>
Cc: dnsop <dnsop@ietf.org>, John Levine <johnl@taugh.com>
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: Mon, 03 Oct 2016 22:33:09 -0000

On Sun, Sep 18, 2016 at 6:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On 18 Sep 2016, at 14:10, John Levine wrote:
>
>>>> 4.2.4. Name Collision in the DNS ...
>>
>>
>>> This study is from before the new gTLD program.  The assumption in the
>>> report need to be tested against what actually happened in the round of
>>> new gTLDs before it can be included as part of the fact basis for this
>>> work.  We also need information on the degree of success that the
>>> various mitigation strategies had in overcoming possible problems to
>>> have a full picture of the problem as it has been shown in practice.
>>
>>
>> At a meeting a couple of weeks ago, I believe that someone said that
>> the junk traffic at the roots for each of .corp, .home and .mail still
>> greatly exceeds all of the traffic for the new gTLDs.  So I think it's
>> safe to say none of the mitigation strategies have worked.
>
>
> There is a difference between "mitigation" with "prevention". Few of use
> thought that publicity about upcoming collisions would have cause more than
> a few folks to fix the problem before it hit them.
>
>> The wildcard 127.0.53.53 and such are clever, but none of the domains
>> that have been delegated had significant collision issues to start
>> with so it's hard to argue they've been effective.
>
>
> It is impossible to measure the effectiveness without knowing how many
> collision queries are just noise (queries that will cause no noticeable
> damage if they started coming back with results). In the case of mitigation
> through wildcard-to-localhost, it is safe to assume that many organizations
> did in fact mitigate; we simply can't tell how many or when.

... and just for the record, much much more could have been determined
(and users better warned / informed) if the address handed out was a
server which displayed an error / links to more information[0], 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.

Yup, I'm beating a dead-horse here, but people keep rediscovering the topic.

W
[0]: This could have a webserver which localized the page (based on IP
/ Accept-Language), a mailserver with a useful error, SSH / telnet
banners, etc. I figured out ~20 protocols which allowed some sort of
useful banner return. The logs could have been anonymized, or only
statistics saved...

>
> --Paul Hoffman
>
> (Disclaimer: I'm now on ICANN staff, but well before I was, I wrote "Guide
> to Name Collision Identification and Mitigation for IT Professionals" for
> ICANN.)
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf