Re: [DNSOP] Mitigation of name collisions

william manning <chinese.apricot@gmail.com> Tue, 20 September 2016 04:29 UTC

Return-Path: <chinese.apricot@gmail.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 BC09B12B5FE for <dnsop@ietfa.amsl.com>; Mon, 19 Sep 2016 21:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 enpE6g05JGgK for <dnsop@ietfa.amsl.com>; Mon, 19 Sep 2016 21:29:04 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 1777312B0A8 for <dnsop@ietf.org>; Mon, 19 Sep 2016 21:29:04 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id o3so87799232ita.1 for <dnsop@ietf.org>; Mon, 19 Sep 2016 21:29:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z1q9svEbuD/BrHXyt9d1kbkjWTc/YJpALdlhx+H9HFc=; b=BIJH8gsfHr3p0c+TOcC8UkSce3noVPbeYaweBObUX0IJpfHK5ZmNwe8EVtWpXPjtx0 2++AIE7cTEbTkCSLH3/dlWe6WHm2e7ruQ6b6li92BukBiycxBDLY/qX70Vn10sw4H5ee w51N0TiQQXXhrGSMvyzzRM1Kk86fgVHH9obbEzccR1bNKeuCDNo8jROZkGMaSIjX/Xjg ndUWEL3hHuvk8mIVIQImiDc4ICeSCguyrOdKqVEFvlxnRuzMG1GClF1yUNHkO+IYKOJf lNAg0mNrBMKmouK1hk8x/4Ftqx2HyQtFN+1Rw1Oicg0/1lgwDfpBoI91ii1biYBmlFdb uetw==
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=Z1q9svEbuD/BrHXyt9d1kbkjWTc/YJpALdlhx+H9HFc=; b=T/tv6aop6sF9rpxfdCP6VjeZ7a5RYpzSNdQco/anVqjO9FPYOhl5mBl3biR7W+CJ63 vVwvn3SjjlAeSeImyGeJim6+pIvAXrDhduHURrsvkqJ8sft/JNyrbWOsQAxzIzbN24MI IK4GFUl0XjoyNjdGJllin/z5WckJx2t0q+y5ZpXBxG1JxXsOhw3+ze1HrDtXf5YZmOrr rZ3TEMMc8jSSOO7UaCantQxSS4ALYIFK1x5s6uzuqBpI+gaS71gEJSF5iHKsjeleG131 mBxgOwvy9ncEU/tYc0FXmleH+cvPn/4KuQHF9hXTjZ3mFJ++EbBRZVES40mw/Au3Up4Z PwrQ==
X-Gm-Message-State: AE9vXwNVRTeaEGtpplcs7gLpaTBg2lau1WMnOdM4IVXxcdbqxaxpUhJ3wQ6SgvtCuNUGpwi0Ybzm17vG9nk/cw==
X-Received: by 10.36.37.194 with SMTP id g185mr1698752itg.89.1474345743426; Mon, 19 Sep 2016 21:29:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.173.78 with HTTP; Mon, 19 Sep 2016 21:29:02 -0700 (PDT)
In-Reply-To: <D971E304-F572-4B90-9210-3C887F870E35@vpnc.org>
References: <90CF5269-0443-45AB-83BA-BE9F9D03831A@vpnc.org> <alpine.OSX.2.11.1609181816130.6589@ary.lan> <D971E304-F572-4B90-9210-3C887F870E35@vpnc.org>
From: william manning <chinese.apricot@gmail.com>
Date: Mon, 19 Sep 2016 21:29:02 -0700
Message-ID: <CACfw2hgQCHkaOf73Oxn4WZ4sahN7Z+ZQfmtd+4k6vjdStooM_g@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a11441afe502919053ce8de72
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/P3J83OdpPwDSAu45qzMsEmYvL08>
Cc: dnsop <dnsop@ietf.org>, John R 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: Tue, 20 Sep 2016 04:29:07 -0000

this bit of thread jumped out.

> 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.
>>
>
> How come?
>

back in the early days of potentially confusing assignments/delegations,  I
was asked to stand up authoritative servers for the RFC 1918 space.   The
first iteration was just a wildcard to TXT.    Clients (early microsoft
clients in particular) panic'ed and flooded the links looking for an
authoritative answer.  Second iteration (some 15 minutes later) did the
wildcard to link-local.   Some 90 minutes later, Mockapetris, Postel, and
the university legal walked into the office and and asked (politley) to
take the servers offline.   Which was done.   The RFC 1918 space
authoritative DNS service was tweeked after it moved to ICANN,  Joe Abley
took on that role.   The traces still exist. DNS-OARC was not interested,
neither was SDSC, nor ICANN (at the time)...



On Sun, Sep 18, 2016 at 7:01 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On 18 Sep 2016, at 15:21, John R Levine wrote:
>
> 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).
>>>
>>
>> Agreed.  I don't see how to find that out in ways that are not hard to
>> back out if it turns out the damage is as bad as we fear.
>>
>
> I do see that, but that's a discussion for a different time and place.
> (Unless this WG re-adopts corp/home/mail, of course.)
>
>
>> 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.
>>>
>>
>> How come?
>>
>
> Because a few of them told me they did.
>
> I'm not denying it's possible, but I've never seen any evidence that there
>> were collisions to mitigate.
>>
>
> You of all people should know that "people do dumb things with the DNS".
> :-)
>
> Before the 127.0.53.53 approach, some TLDs tried reserving the names that
>> showed up in DITL snapshots, and those names looked to me totally random,
>> likely generated by something that was trying to see whether some piece of
>> namespace was wildcarded.
>>
>
> As we saw at the collisions workshop (https://www.ietf.org/id/draft
> -thomas-namecollisions-workshop-report-05.txt), DITL data is poorly
> suited for following collisions because you can't tell how much is coming
> from organizational resolvers that are in front of a poorly-chosen name and
> how many are from upstream ISPs.
>
> (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.)
>>>
>>
>> A fine document for people who already realize they need to deal with
>> collisions, not so much for people who don't realize they exist or assume
>> they're someone else's problem.
>>
>
> Correct. It has been helpful, though, at least to organizations seeing
> 127.0.53.53.
>
> --Paul Hoffman
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>