Re: [DNSOP] getting back to our work on special use names

Bob Harold <rharolde@umich.edu> Tue, 17 January 2017 14:31 UTC

Return-Path: <rharolde@umich.edu>
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 C6D2012952B for <dnsop@ietfa.amsl.com>; Tue, 17 Jan 2017 06:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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=umich.edu
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 YI1GB3LPRgKx for <dnsop@ietfa.amsl.com>; Tue, 17 Jan 2017 06:31:08 -0800 (PST)
Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 C6AD6129521 for <dnsop@ietf.org>; Tue, 17 Jan 2017 06:31:07 -0800 (PST)
Received: by mail-yw0-x244.google.com with SMTP id 17so11686564ywk.2 for <dnsop@ietf.org>; Tue, 17 Jan 2017 06:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZYIJyS/BYHmJnCd38v12dpoVSGWWMrOSWfXJpKuGf8A=; b=Vm6Y3iMDfrwboq9qDqP1dcnWh5cG69T3ATvsun7rWH9FV6PvkpHLlBLFzt0PhjHhPZ QagQF6p4F50kQGAnUdq4xMSEtQM7noXqzgGldoozzotYYA0NJyxsGXs4mzxY6nKQH6g5 6W78yDgCLq6CSU/FjrKeT/QIDXxvgpXUorjJHDIDDTdgvRTllheUPucO0LYKE8kty5yy i4foA3dIsRFinwLXI/X9TvCLa675mdPZuqIyA/0/INp1h8kbasKKpzwI1FSSvNQCKRQV 1g7Xrwyd/SLUf1TRaeRyc8Y/KqEsqqOwz4YFFE0UblrZhiDA12vOIGSQDT+Z4k5i4YpW aBXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZYIJyS/BYHmJnCd38v12dpoVSGWWMrOSWfXJpKuGf8A=; b=KMyml0fJmjpGxKiZykYTNvHuGzZsc6+WUI6RDuYbQRF8N+9qKlvdapjct2Kppu20yz xFDBO5L9JJj0uVzBQf4IvDKDuiMExP7hauP8hY2OTq+oOO1Wg3dkjg3KrdVuS9+Uq5aR VH1V4El5Uvirh6zZuhyRMwoPNvLq51ug6hN5rLULi5Xr/xwACD3Do5fvUkohZQN02s7H xeCViUO4ceP0GeXObmeoNdRuE6HvDC/8Ny/aj1Sop/n1yzhBFVqwu+/Zh20BdhLc8F+i DpdcV2bqFTHRPTp/l80DavJd3oYZ/heSAExrOzuS5YESN+dFj9R+jO1VmmcCwO/Dp0Mp NR4g==
X-Gm-Message-State: AIkVDXLbwOAjqvmjNSIukf/qqCpr35DAV6KdHDJrujmCjZTwt+b20AzhZzC66J2pv20al6/PA47PnpC2cn2mJEmo
X-Received: by 10.129.110.133 with SMTP id j127mr30171897ywc.214.1484663466951; Tue, 17 Jan 2017 06:31:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.169.130 with HTTP; Tue, 17 Jan 2017 06:31:06 -0800 (PST)
In-Reply-To: <CAHw9_iJRKL+YOX3Y=wX5gBcTYdPdLWwrKuFizxPOWtFcAoktrg@mail.gmail.com>
References: <83494B60-401D-476E-916F-3388137BAB16@gmail.com> <CAHw9_iKCUnB0o-_pfdp0u+8rQ+3AG2W2JuUp=pw1iiteA8iNNQ@mail.gmail.com> <CAHw9_iJRKL+YOX3Y=wX5gBcTYdPdLWwrKuFizxPOWtFcAoktrg@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Tue, 17 Jan 2017 09:31:06 -0500
Message-ID: <CA+nkc8Ade4SMk43Fs5QD9LT+WdJ5RJ+yKZDiSqYhY2vn=WCB5A@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Content-Type: multipart/alternative; boundary=001a11492a148f341105464b2665
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a_ruPf8osSzi_hCzCqOxYLXhYoA>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] getting back to our work on special use names
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, 17 Jan 2017 14:31:17 -0000

On Mon, Jan 16, 2017 at 8:22 PM, Warren Kumari <warren@kumari.net> wrote:

>
> On Fri, Jan 13, 2017 at 9:47 PM Warren Kumari <warren@kumari.net> wrote:
>
>> ...
>>
>> We have had a proposal, for the ALT TLD, before us for some time now,
>> which we put aside while we worked on the problem statement. As part of
>> assessing solutions, we need to review https://datatracker.ietf.org/
>> doc/draft-ietf-dnsop-alt-tld/ and determine what the WG wants to do with
>> it. Comments to the list, please.
>>
>>
>> Yes please. The document is still parked, but please send me comments *on
>> the draft* and I'll try keep track of them to incorporate. I know that
>> there is much background which can be culled, I'll post a new version to
>> GitHub with that done soon.
>>
>
> ... and I just posted a new version at https://github.com/wkumari/
> draft-wkumari-dnsop-alt-tld
>
> Please take a look and provide any feedback.
> This document has been in limbo for a really long time - I apologize if I
> have forgotten any of the comments -- please resend, or just provide
> pointers to the emails and I'll go reread them.
>
> We *know* that this doesn't solve everyone's issues, but, had it existed,
> it may have provided an option for e.g homenet.alt. Also, we will need to
> decide what to do about the insecure delegation question -- .onion didn't
> need one, but perhaps we do? This will add an interesting wrinkle to the
> whole "coordination with ICANN" discussion.
> >> W
>

In this section:

4.1. Domain Name Reservation Considerations
3. In general, writers of name resolution APIs and libraries do not
       need to perform special handing of these names.  If developers of
       other namespaces implement their namespace through a "shim" or
       library, they will need to intercept and perform their own
       handling.

-- I was hoping that name resolution APIs and libraries would be encouraged
to filter out these names.  So that over time all the major OS versions
would filter them for privacy.  That would greatly reduce the chances of
them reaching DNS if accidentally used on a device that is not expecting
them.

-- 
Bob Harold