Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel
Joe Abley <jabley@hopcount.ca> Mon, 27 November 2017 19:59 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 B939A128854 for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 11:59:58 -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, 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 UIKu-PTgyK1Y for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 11:59:57 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 D3DF21275C5 for <dnsop@ietf.org>; Mon, 27 Nov 2017 11:59:56 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id x13so22581966iti.4 for <dnsop@ietf.org>; Mon, 27 Nov 2017 11:59:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQPH3UfOT5sKwppbM8S2Q7HwzBq4zOXqqckZBjpYUfE=; b=nRiOXLaFHQpUM1DU7AjDIJNvUF27ilhyo3tRhHwAMRnfnCvq+AFqT7cie2ZGZ3MJ3N kAYiwBfX/E7m7cMCjl0VbBsi9UuK3mR5YuSvyY9fOchOMwOtOjAmVbIUuECQ1X9gTpxD zzGu4F6pjuMCWzPgH8ki52Y0NgzjtIznh2Fg0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQPH3UfOT5sKwppbM8S2Q7HwzBq4zOXqqckZBjpYUfE=; b=F5kygXnZr3zObqpJ5KZAi0jZFlfpXXO/bzSSPuhRoffRQ0XS3DLDHMTyCaGJkxCbX2 UBrjtxx/7aaJO8crsZArzW2qIQwL6lVZ+noUMiViQ3EWpWuT4KRsD4NwRC9hdhQeZpuF 7tl1+3IXXaYd7Bv9lx8Hau8Gygl+bBkXI12s3WGvSUmy9xEvrD3YKa/ga4lY/tlV1WqH Ga4B+RauTqvfzHObd/jt7VQ0TJg8ZKZ4c406BjAuFn2J+iPDpiZ4rteR9lqlVU/dwt8/ HntaVufq6ZIRibmDrhlWIiLfzRHOZUiMf8WAZPPFjTF0lJ9ERD0/jfkQp+tuR94+H+04 soHw==
X-Gm-Message-State: AJaThX5VJuXZDRRMDL/ebhKTIZ758T2osie73Teb4ktdaF8iG+5tnCan WdauirnZLHQfVBKtcO/uLIhGSw==
X-Google-Smtp-Source: AGs4zMaFtRdIOCgwGS9GPLSUxQOjoA/M8hM679+xMHwQzuGjw7P3V63ZO3weQpVulOO4bFWtpIq5dQ==
X-Received: by 10.36.124.197 with SMTP id a188mr30272212itd.63.1511812795992; Mon, 27 Nov 2017 11:59:55 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:202:c849:dad7:a94e:7c1e? ([2607:f2c0:101:202:c849:dad7:a94e:7c1e]) by smtp.gmail.com with ESMTPSA id m72sm11927119ioe.40.2017.11.27.11.59.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:59:55 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <CAL02cgRyzri3YKGxj6EYn=O_nfvQ_Hd-b5JR3mPFvp3sPQTgHQ@mail.gmail.com>
Date: Mon, 27 Nov 2017 14:59:50 -0500
Cc: George Michaelson <ggm@algebras.org>, tjw ietf <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <14790688-9023-4D64-8752-1C9859A82C43@hopcount.ca>
References: <CADyWQ+Fhzybt-aNNF+yJxQfWDM56W+rzWxZ2YB3yf6wy4m_uxA@mail.gmail.com> <CAKr6gn07V7s0Q8czQR3v6uAujj4t1-SRt7xqi=zDNVpsryXhVQ@mail.gmail.com> <CAL02cgTZq2+F5Ki6B-042oBdng=tn3jZagb_EKUNFpS7XYgXbQ@mail.gmail.com> <CAL02cgTawPPjWRZ=iMHQOyT+N_cU1r74N+Cp2+Fxn_qLoMh7cQ@mail.gmail.com> <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> <CAL02cgRyzri3YKGxj6EYn=O_nfvQ_Hd-b5JR3mPFvp3sPQTgHQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a6G-MLH5-yFE-V2wRKvOAQOnE0M>
Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel
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: Mon, 27 Nov 2017 19:59:59 -0000
On 27 Nov 2017, at 14:47, Richard Barnes <rlb@ipv.sx> wrote: > As tempting as it may be to do the easy thing, it's not always the best use of resources. Looking at the closest tree might be easy for one observer, but when you try to do it with enough observers to have a result that's useful for the King of the Jungle, you end up with similar tangles. > > I don't think that it make sense to infer from the failure of RFC 8145 that resolver/authoritative telemetry isn't possible -- just that it's not possible with the heavy-weight machinery in that mechanism. To the degree that the DNS still works at all, there must be some channel by which information can be faithfully passed from authoritative to resolver, which can presumably be used to bootstrap telemetry. Maybe it's a TXT record with an HTTP URL; maybe it's a funny CNAME. In the case of the root zone, the additional complications include the procedural difficulty in installing experimental records in the zone itself, the amount of effort which has gone into reducing legitimate reasons for resolvers to send queries to the root servers at all, e.g. through the use of aggressive negative caching and even the TTLs on delegation NS sets, and the effort required to do data collection on the root servers, whose twelve operators manage many hundreds of instances. The existence of caching (and the degree to which people take liberties with what they can or should cache) also adds complication, not all of which is deterministic. Although it is intuitively obvious that collecting data from millions of end-users is harder than collecting data on hundreds of root server instances, it turns out that there is a whole industry that more or less exists to collect data from end-users already and no corresponding mechanism for authority servers. Also counter-intuitively, some root server operators view the traffic they receive as containing PII whilst the privacy concerns with kskroll-sentinel seem benign. When it comes down to it, you can more often rely upon an end-user's query being sent and a response being generated by a recursive server than you can rely upon queries and responses being exchanged within a (potentially complex) graph of resolvers and authority servers. That potential complexity means that understanding whatever data you do collect can be difficult. > Maybe you can't build a road through the jungle, but there are still rivers that make it through, which can carry a message in a bottle. You might see a river go in and a river come out and be tempted to assume that the bit in the middle is river-shaped, or that the two parts you can see are connected, but you won't always be right. Joe
- [DNSOP] Call for Adoption: draft-huston-kskroll-s… tjw ietf
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… George Michaelson
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Paul Wouters
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Petr Špaček
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… A. Schulze
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… manu tman
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Matthew Pounsett
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Benno Overeinder
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Paul Hoffman
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… tjw ietf
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Daniel Shaw
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Richard Barnes
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Richard Barnes
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Richard Barnes
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Wessels, Duane
- Re: [DNSOP] [Ext] Re: Call for Adoption: draft-hu… Edward Lewis
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… David Conrad
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Matt Larson
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… tjw ietf
- Re: [DNSOP] Call for Adoption: draft-huston-kskro… Mehmet Akcin