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

Joe Abley <jabley@hopcount.ca> Sun, 12 November 2017 03:27 UTC

Return-Path: <jabley@hopcount.ca>
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 2ABD81292C5 for <dnsop@ietfa.amsl.com>; Sat, 11 Nov 2017 19:27:47 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 k4cy4A0mgB4Y for <dnsop@ietfa.amsl.com>; Sat, 11 Nov 2017 19:27:45 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 22375129453 for <dnsop@ietf.org>; Sat, 11 Nov 2017 19:26:49 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id e143so14894062lfg.12 for <dnsop@ietf.org>; Sat, 11 Nov 2017 19:26:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=DwKmSQtDT4bFn3VtsDohcL4TLKtOSpbskpjowDSmTkU=; b=Un4Wlg9Npvn/nn0u8px+xIN8XEuwfwJqNPFWrz7ev/A5xJ5Qdv23PcwLV7/Z6+rC9T cvYAWY9NAPn/5Tk4R+FJMMaZgsneB5LKlulGJPxu88I+grVVeGDir9QszlLGdll9+H2j 3cg/NEKg/Plo/pZQGT+eB7i8PK7Yh0wIfrPfY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=DwKmSQtDT4bFn3VtsDohcL4TLKtOSpbskpjowDSmTkU=; b=AoBgwkCnh0QzuL9KqlZY5Y7SE8PwNCpDiU3BPlgEYJtSY/a45LkrPG9hAmevC/c/mU 71TvPYt2wGPrggswhstWEWRMXzeAT3mgwu5QrPct61eE5Dd8B0CHUkHSOPEYcCoCTd59 e+gAkfILSz+II5fC7V5R66xDvMVIV7dJQJUV4ow57UqK9ee9bvY9uAuyOk9HSGyRWf/w juclCEHVDWrw194xBqDN9yUBeE16fPIRY+MRa4YZ4bdn6zhqdT6O6tMV5D5EIgQn8cCX gsaF2XyeME4Z1PBTtSW2SIWCS/od4j2c2uViJnCIkr2ylB9P0d3xYJ08aymhxsd5e4c5 V/yw==
X-Gm-Message-State: AJaThX7VCDoCC2j4tJGu1ngBf2ajb2RbojZuMPnIFBwledhUW+8EJefr dYEPZw9GWkhmZ+2Brj/8Fxazr6jeHYzwv/vjZq5Wrw==
X-Google-Smtp-Source: AGs4zMatHIsFr2mrpX7T5U5qWMEr/G90XNIaWAYKLs/1Hiw5fTTZbhrH4+0BOKro51ZrBLNpBEMNWQ1bQ/SvCINBO00=
X-Received: by 10.25.15.161 with SMTP id 33mr1944550lfp.57.1510457207299; Sat, 11 Nov 2017 19:26:47 -0800 (PST)
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
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>
In-Reply-To: <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org>
Date: Sun, 12 Nov 2017 11:26:42 +0800
Message-ID: <-2659975464145644217@unknownmsgid>
To: Kim Davies <kim.davies@icann.org>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Matt Larson <matt@kahlerlarson.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f22004a39dd055dc0b930"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4ZN0dKIJRmmt8rY7hVFitgQVxS0>
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: Sun, 12 Nov 2017 03:27:47 -0000

On Nov 12, 2017, at 10:51, Kim Davies <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 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