Re: [DNSOP] Mitigation of name collisions

Warren Kumari <warren@kumari.net> Mon, 03 October 2016 23:28 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 1BFD41293EE for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 16:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 4YjfN1KOVRJt for <dnsop@ietfa.amsl.com>; Mon, 3 Oct 2016 16:28:22 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 93F5D1293E0 for <dnsop@ietf.org>; Mon, 3 Oct 2016 16:28:22 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id 38so87001513qte.1 for <dnsop@ietf.org>; Mon, 03 Oct 2016 16:28:22 -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=rF5DzQyEOhwpw6gw2Dnd86PiPME2ag4h/cUHPKHPFxA=; b=yBpr2qT5p+AfN9OxXaBOMdSIswhY4Mj49apq8iFmudvO5f53WYl40fJc7TMnlVxXwH ayHr88pYRtc1z6Ur+pQ5Kr3AA1e6WS4kPoUmRGVne+y7WBSWeQnzdhQY3To7IYi20mjd rbByx+0BMLfYZ+6SPF5hjET+sVXYsd42rbkh3ojQoF15AOfOwT3fErOzxuFQsHBFsr4M zkAHQfhH46YtJHjMGY2l89vpWRvCvOHlCVdYc2mWOD3VwCRd39yddNX612HbHNDGIvF5 02pv8tzFaKbDB9/9HpUk9RE0sxhCYP9RtFeLk7MYu19IcbGcyMWO3D7fhpT654dz9+u2 uKCg==
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=rF5DzQyEOhwpw6gw2Dnd86PiPME2ag4h/cUHPKHPFxA=; b=FpQl2UGoawXo1WdxtR9jD7aVnCOdmFVbWtbajZOZXfr8/Xy19Gsj2v1FQD3iA2fVqw Jht/zEJo906ZpC0uXz7ZiHLhX/jOuhTDoXhNsdw/O68G1EGzAIMKFaxnLMr+BMA4T3ef gbq09ckIUNxnKadwBzpoUBcsUt0fuJgvC7mFWUMqUTpakTrVfks5xKk/Rutv3+lr7Hjk ti675ilSLEBr2xvqrgAyoyVi90HmT9GVt/udpMuZoR2dB+jmDg4zzuvfV1SBcRkakgP9 aZus09QuiNHOyuDYF2I5bIjq/nyhXsEFMFyQLx0TP/NM8wp+0pT9NjUjcnwnbiwjB8Cm 3mlg==
X-Gm-Message-State: AA6/9RmpJ64gMsOPrSsSugj+RJyBJEzmUGEtbhUwBSgflDghfW3bHlqkRW0Vc65ObGrtaS4haKvd2FEG7TcTclAt
X-Received: by 10.200.37.52 with SMTP id 49mr685560qtm.62.1475537301576; Mon, 03 Oct 2016 16:28:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Mon, 3 Oct 2016 16:28:21 -0700 (PDT)
In-Reply-To: <alpine.OSX.2.11.1610031921000.28732@ary.qy>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org> <CAHw9_i+NaU8RtC3sraO2ZwDKQSiYtmtFOYXPGV=5q0bwTdkOpA@mail.gmail.com> <alpine.OSX.2.11.1610031921000.28732@ary.qy>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 3 Oct 2016 19:28:21 -0400
Message-ID: <CAHw9_i+HEtdjF30pfUeRnTmrx7YjcCiOmAnP_ogjds8kkYS0-w@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a1135b1ecb6d0d9053dfe4c30
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/j2qWFnEm6qwY37-lRrAUQkzCjr0>
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: Mon, 03 Oct 2016 23:28:24 -0000

On Monday, October 3, 2016, John R Levine <johnl@taugh.com> wrote:

> 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.
>>>>
>>> ...
>>>
>>
> ... 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],
>>
>
> Gee, I'd think you of all people would be aware that there's more to the
> Internet than the web.


>
>
... Did you read the footnote?

W

>
>  A wildcard with a live IP in those domains would be a terrible idea for
> the same reason that *.com was.
>
> 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.
>>
>
> That, on the other hand, would be a good idea.  Since all of the new TLDs
> use the same dozen back ends, I wonder if any of the back ends could be
> persuaded to release anonymized data.
>
> R's,
> John
>


-- 
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