[DNSOP] Sample experiments for resolver->auth privacy transport
Mukund Sivaraman <muks@mukund.org> Tue, 11 December 2018 05:25 UTC
Return-Path: <muks@mukund.org>
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 B8EDD128D68; Mon, 10 Dec 2018 21:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 EygOo9_5n5vq; Mon, 10 Dec 2018 21:25:50 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E02E7126CB6; Mon, 10 Dec 2018 21:25:49 -0800 (PST)
Received: from jurassic.lan.banu.com (unknown [27.5.197.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 9AF7A32C06F1; Tue, 11 Dec 2018 05:25:47 +0000 (UTC)
Date: Tue, 11 Dec 2018 10:55:43 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: dns-privacy@ietf.org, dnsop@ietf.org
Message-ID: <20181211052543.GA11647@jurassic.lan.banu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_qyv1A5c-0wgScfFv5N_Mm261Dg>
Subject: [DNSOP] Sample experiments for resolver->auth privacy transport
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Dec 2018 05:25:53 -0000
Hi all Some ideas on how to practically test resolver->auth secure transport was asked during yesterday's dprive meeting. Here are some examples to test. Simulate the case of queries for names in the DNS that are hosted topologically farthest away from the tester. Assume the test is conducted in the USA, and simulate the case where the names are hosted in India (other side of the planet) which would theoretically have among the highest physical latency. An example with some names follow - it is not possible to explain this with RFC 2606 names only, so please assume that the following names don't correspond to currently used real-world names, if any. Compare overall time to find the answer for the query vs. DNS over UDP that is used for the majority of DNS queries today. In each case, check both with and without using QNAME minimization. The following examples don't use QNAME minimization but have an extra label so that there is a difference in lookup when the zone cuts aren't known. (1) In-bailiwick nameservers ---------------------------- Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of devanagari for "hindi"). Let's say a query is results.2018.nationalexam.xn--j2bd4cyah0f /A. Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a university in India. i. The lookup in the case of cold cache would have to start at a root nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f. Assume the answer is an in-bailiwick delegation, so glue address records are returned as part of the delegation response for ns1.nationalexam.xn--j2bd4cyah0f and ns2.nationalexam.xn--j2bd4cyah0f, both of which are located in India. ii. The resolver then looks up results.2018.nationalexam.xn--j2bd4cyah0f/A from ns1.nationalexam.xn--j2bd4cyah0f. (2) Out of bailiwick nameservers #1 ----------------------------------- Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of devanagari for "hindi"). Let's say a query is results.2018.nationalexam.xn--j2bd4cyah0f /A. Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a university in India. i. The lookup in the case of cold cache would have to start at a root nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f. The delegation is to ns1.someuniversity.ac.in and ns2.someuniversity.ac.in. ii. Let's assume that .ac.in zone is also hosted in India. The resolver then looks up ns1.someuniversity.ac.in (and ns2.someuniversity.ac.in simultaneously usually). This involves following the delegation from root again for .in, and then for .ac.in, and then someuniversity.ac.in, and then the NS answer for ns1.someuniversity.ac.in. iii. The resolver then looks up results.2018.nationalexam.xn--j2bd4cyah0f/A from ns1.someuniversity.ac.in. (3) Out of bailiwick nameservers #2 (with more indirection) ----------------------------------------------------------- Assume the name queried is within the .xn--j2bd4cyah0f TLD (punycode of devanagari for "hindi"). Let's say a query is results.2018.nationalexam.xn--j2bd4cyah0f /A. Assume nationalexam.xn--j2bd4cyah0f is a zone that is hosted by a university in India. i. The lookup in the case of cold cache would have to start at a root nameserver (that would have short RTT in USA) for xn--j2bd4cyah0f. The delegation is to ns1.cs.someuniversity.ac.in and ns2.cs.someuniversity.ac.in. ii. Let's assume that someuniversity.ac.in zone is also hosted in India, by dnsoperator.co.in. The resolver then looks up ns1.cs.someuniversity.ac.in (and ns2.cs.someuniversity.ac.in simultaneously usually). This involves following the delegation for ac.in, and then someuniversity.ac.in from ac.in's nameservers. iii. A delegation is returned by .ac.in's nameservers for ns1.cs.someuniversity.ac.in to ns1.dnsoperator.co.in and ns2.dnsoperator.co.in. iv. The resolver has to lookup ns1.dnsoperator.co.in following its delegation from the nameservers for the closest zonecut it knows, .in., and then .co.in. v. The resolver then looks up ns1.cs.someuniversity.ac.in from ns1.dnsoperator.co.in and learns its address records. vi. The resolver then looks up results.2018.nationalexam.xn--j2bd4cyah0f/A from ns1.cs.someuniversity.ac.in. ---- These are the best scenarios where everything works. Simulate problems where there is trouble contacting nameservers and the resolver has to try others. Simulate a mix of nameservers under different domains. Note that a stub (client of the resolver) will timeout a query attempt in about 5 seconds. It will retry another time or two, but note that waiting that long for a normal resolution would be terrible for the user experience. Assume a cold cache when testing. I point out once again that resolver->auth is not like stub->resolver communications where (in the latter case) typically there is 1 resolver peer which is typically near the stub, and the stub can start an on-going TLS session and keep it going for the uptime of the stub. A resolver contacts many nameservers that are topologically far away, in a constantly changing internet. Many of these nameservers are new nameservers it has not talked to before, assuming it is not a resolver of a public DNS service (resolver->auth privacy is going to most help non-public resolvers case where the resolver is not shared greatly). Be warned that if you are going to design a protocol that will work reasonably only for the CDN nameserver case (where there would be an ongoing session) and perform very poorly for all other cases, you will encourage aggregation of zones into a few cloud operators to have any kind of usable experience at all. This will be very bad for the internet, where zones are still well-distributed. Mukund
- [DNSOP] Sample experiments for resolver->auth priā¦ Mukund Sivaraman