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

Joe Abley <jabley@hopcount.ca> Sun, 12 November 2017 14:37 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 DBD26129447 for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 06:37:25 -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 3wwi_n13jyu4 for <dnsop@ietfa.amsl.com>; Sun, 12 Nov 2017 06:37:24 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 420251200F1 for <dnsop@ietf.org>; Sun, 12 Nov 2017 06:37:24 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id f134so7336742lfg.8 for <dnsop@ietf.org>; Sun, 12 Nov 2017 06:37:24 -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=HPtUOEsTa+DgZw/+V3QRYr4tLdOhFwq1G/sz8wTaRL0=; b=Wk8srPfBVxSMoFDxg94pvlnAFQI996NlZP0bwGO9IMKuqikdDJvKtBqJL80KIwxaOR E2ICkv4cbmutyQKRp5PqpWhh/kCqaW19CeDnbtA69BHZQP0ZW8rEn76Dekc+aIP9S2c1 GkOjuOZF64jKUkb8biv9wnV4nWb5X1GMrjCE8=
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=HPtUOEsTa+DgZw/+V3QRYr4tLdOhFwq1G/sz8wTaRL0=; b=dn/OEQ2hYINonmKbtNPd8zeDXtCf2fZMKuvZTpzfcqT7kv/fcXH27vGb8tI+j90qE3 lcN9xVLapXeyXcyNdE7wUrhV+shCSZ28Fk1RB3R8lIz137Un1T5q+YZdytVfUEjaGFk6 8b9UW1irXaVcE4ZMZ0H1cmRPbhju9Rgj0dQqIs0fm7GO/TW9fF19HdVXWZhvyJlk1h8h 21X4xpY85YeOALUnF/Rm733/GxjswBQhY7zu2M9jI0J1P+FVCjK84RvH9Ag8ifxx2iKB s5Q20kBLecmlNSXtzZYIbYFx6acxgqyjYBm78O6ILUMoBEiZd7ooiP63JAsxUktYpQ3p ad3Q==
X-Gm-Message-State: AJaThX6SPt1GiS2oJzT0VmKLOzQL3hZwiMz474NOSy3df31hbPcpAXbO p2nBOLRRl/5FHqI7yMZ8OG9VlPrtZ1IJTmPcyrYYGA==
X-Google-Smtp-Source: AGs4zMaDYcFlSLvgCvM2XWha8QMtMuPvGe0Bme0SkHTWXVRqmYNqd4LAUsVvdaU3VkcUwTviw5PPQ2lPezBR1ezHS8o=
X-Received: by 10.25.22.24 with SMTP id m24mr712339lfi.185.1510497441343; Sun, 12 Nov 2017 06:37:21 -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> <-2659975464145644217@unknownmsgid>
In-Reply-To: <-2659975464145644217@unknownmsgid>
Date: Sun, 12 Nov 2017 22:37:19 +0800
Message-ID: <6798813822774553543@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="001a11407b5e6cfb07055dca17d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gs7sVKtRcdvNlBiMxA7ArD5VJJg>
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 14:37:26 -0000

An unbounded number of AS112 operators, not an inbound number.

I apologise to all present for sending mail to dnsop from a phone without
taking more time to check for autocorrect lunacy.

On Nov 12, 2017, at 11:26, Joe Abley <jabley@hopcount.ca> wrote:

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