[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