Re: [DNSOP] Mitigation of name collisions

Keith Mitchell <keith@dns-oarc.net> Wed, 28 September 2016 15:39 UTC

Return-Path: <keith@dns-oarc.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 B031E12B18B for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 08:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.317
X-Spam-Level:
X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dns-oarc.net
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 3sf3-fVueP6B for <dnsop@ietfa.amsl.com>; Wed, 28 Sep 2016 08:39:23 -0700 (PDT)
Received: from ix1.dns-oarc.net (ix1.dns-oarc.net [IPv6:2620:ff:c000::198]) (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 5033D12B0D8 for <dnsop@ietf.org>; Wed, 28 Sep 2016 08:39:23 -0700 (PDT)
Received: from zen-keith.smoti.org (cpe-173-91-22-163.neo.res.rr.com [173.91.22.163]) (authenticated bits=0) by ix1.dns-oarc.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u8SFdEG5026586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Sep 2016 15:39:22 GMT
To: "dnsop@ietf.org" <dnsop@ietf.org>
From: Keith Mitchell <keith@dns-oarc.net>
X-Opacus-Archived: none
Organization: OARC
Message-ID: <57EBE422.8030604@dns-oarc.net>
Date: Wed, 28 Sep 2016 11:39:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dns-oarc.net; s=ix1; t=1475077162; bh=tKaBLCNoaa3z/2pRRaQpbbQTwhldIg4c3yIUjNt0HjM=; h=To:From:Subject:Date; b=fFNTS4ZC0ABPpLmDjBVpA7Zwep6RsqQrBNjZ93dOyi8YRrdtWgRn8L4Cv8lCIOdYA TtcrYpkOWoqNgJz3waCRRr7//hRrpfMl5KKm+fe2iPGvGYxGzaNcM09AUO0aQoWYff lzHGw+jTppQmIXCTzTXclArT5d/stE812Gtyzt9o=
Authentication-Results: ix1.dns-oarc.net; dmarc=fail header.from=dns-oarc.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-2UV-zUtPsgIzClSktorkCunpiY>
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: Wed, 28 Sep 2016 15:39:25 -0000

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

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

>From an OARC point of view, we did some back-checking of our
institutional memory such as it is, and were unable to track down these
traces being offered, or by whom/at what point they were declined. Which
is not to say this didn't happen.

Anyway, on the basis that the volume of this historic trace data is
unlikely to be large by modern storage infrastructure standards, if the
offer for OARC to take on these traces and preserve and make them
available under our usual terms is still open, and there is community
interest for doing so, we'd be happy to.

Please Bill follow-up with me offline if you'd like to explore this.

Keith