IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

Warren Kumari <warren@kumari.net> Fri, 05 January 2018 13:56 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 8F229126D45 for <dnsop@ietfa.amsl.com>; Fri, 5 Jan 2018 05:56:38 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 JBHcYEyku6qz for <dnsop@ietfa.amsl.com>; Fri, 5 Jan 2018 05:56:36 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 58B48124319 for <dnsop@ietf.org>; Fri, 5 Jan 2018 05:56:36 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id f206so2606577wmf.5 for <dnsop@ietf.org>; Fri, 05 Jan 2018 05:56:36 -0800 (PST)
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:content-transfer-encoding; bh=HOeTJ03PLrNAd+xsKSX1+yKKuwh7+f43E2BRbE+MfwA=; b=twBbC6RhWWwYP5mfDHU8hGp3CWXWITvp1q3ClU4Fem91ldHONeWmZmixnxPSmS94Sl r90ksLrLGnFe0/zl+NiG9sBqXXi/rKoZDAEiJZjehOLfcrtA69hq05U6z0Ul63vK7SbX 96zrvHaYSNOeG5pY8egh3sS98JJTMw5wMwVaPbtOeQ+jFpcK3EebptzW/o+TSMIi6thn v9lHSDdPFlgRihC3b2NTJMkQR36bcgcDQ2G4P2PVgn6GVh9jFIoZfuAOSHxWCwr3+L9I mqo09e9eZUY/dcKH9itryManfkeNkD1zgsWKS21e/vbkZPnpjfUgHGF0I8vmYp8s+Hrl 5w/A==
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:content-transfer-encoding; bh=HOeTJ03PLrNAd+xsKSX1+yKKuwh7+f43E2BRbE+MfwA=; b=gTaCGjUyY/6CetUwFIAf0h5tKFQuxXKaUADUKCyUWew2k0FFK4rq3KtZBnKiXoKLJm XFM8omqqJYNo2/qsNE+fBXb5RU6DGbBIOk7lsfr0UdRXMF7pmsijIlszEhaO0JCChruq escJfG90p2pqJxoISFqrVU1gAtZnqWyPZFJE5KGiTg52I+ozCaIXSewSTVVVDiM+rKjD HhHkTCdEeAZBJA1kiNmnRF8TMwTqku4i4N9ThH0jNZlXoqF7ujGQQks1uMjQVF4qDsgI kO1jgBpmdoz0Pz3Ft13nNXNTwcemY2wIY8LgyXsWERiJRtdvM6qlwriLLqx9hCNhcbRU 65pg==
X-Gm-Message-State: AKGB3mJMwO6scyItgNum1ahrAeIcmdqBkyGLrP94gGm/uwlPUTxOZER/ aNK10pMu3VWUHYcM3mAwcq9kUO3A7EjMohpyogINug==
X-Google-Smtp-Source: ACJfBosQaDy4Q8oORrxOSWkUgQSm3UnkzsSNgVbGT73l3yRNoQ7QtQViojHPkqi3aug1Ho9A7rQjsc4GFj1td9u98qs=
X-Received: by 10.28.135.142 with SMTP id j136mr2187793wmd.132.1515160594465; Fri, 05 Jan 2018 05:56:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.190.138 with HTTP; Fri, 5 Jan 2018 05:55:53 -0800 (PST)
In-Reply-To: <0a82884a-f32b-0535-a831-6bcd9ee81d25@nic.cz>
References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> <-2659975464145644217@unknownmsgid> <0a82884a-f32b-0535-a831-6bcd9ee81d25@nic.cz>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 05 Jan 2018 08:55:53 -0500
Message-ID: <CAHw9_iKxp3WG-YWjTOXkiyfc3667x7DiBdVpp4dUZp9bTcHvJA@mail.gmail.com>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9oDqDo7BBzFSLU_Su_UgaUvRp_U>
Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 05 Jan 2018 13:56:38 -0000

... so, after the reception this document received in Singapore
(IETF100) I've decided to abandon doing this work in the IETF.

I may still push it in the ICANN world, but not sure I have the
stomach for that.

Sorry for wasting people's / the WGs time,
W

On Fri, Jan 5, 2018 at 6:55 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
>
>
> On 12.11.2017 04:26, Joe Abley wrote:
>> On Nov 12, 2017, at 10:51, Kim Davies <kim.davies@icann.org
>> <mailto:kim.davies@icann.org>> wrote:
>>
>> We haven't studied what would be involved, but I feel confident in
>>> predicting the whole exercise would be non-trivial.
>>
>> It seems to me that you could implement this using lawyers as easily as
>> you could using developers; it is after all arguably a static change in
>> procedure that doesn't need to be especially repeatable. If the root
>> zone maintainer is contracted to include a record, surely the record
>> will be included.
>>
>> However, I think the more general idea that queries for internal names
>> should be leaked towards unknown AS112 operators is problematic. As an
>> end-user I would prefer my leaked queries to be jealously hoarded by one
>> of twelve root server operators than an inbound number of anonymous and
>> potentially ephemeral AS112 operators.
>>
>> The potential for complete data collection at the root servers goes down
>> as resolvers implement aggressive NSEC caching. In the case of a
>
> Unfortunatelly aggressive use of NSEC will not help because the name
> will exist (either with NS or DNAME).
>
> I wonder whether this is sufficient reason not to request the delegation
> and let users to configure an exception for .internal (which is needed
> anyway). This needs more thought.
>
> Petr Špaček  @  CZ.NIC
>
>> delegation or redirection, that potential is reduced since the
>> non-existence of individual names under internal is then the thing that
>> is cached, not the non-existence of the right-most label in the namespace.
>>
>>
>> Joe
>
> _______________________________________________
> 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

v2.23.0 | Report a Bug | By Email