From nobody Fri Aug 11 06:26:41 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE9E132574 for ; Fri, 11 Aug 2017 06:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 UlOgIvgqcbob for ; Fri, 11 Aug 2017 06:26:32 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 29A9B132507 for ; Fri, 11 Aug 2017 06:26:29 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p68so22228686ywg.0 for ; Fri, 11 Aug 2017 06:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OSjW1Zly4i0tbcYbzVoPhn1X+PmAUMD+zcCpqdluP7s=; b=byuyVBna68wNOcwtN+xAtPE9ny3vsOF4+fXpfZ3VvO0wS5E2loe26H7KSiAf4ef3DQ obHE8x4mxjdmn2e8RoNzH99VU4pgHTLPbKQkxGu2LV1pORJhC8k92JSRy9kt2Vf0Mxmi 1F6q/lg60uy3x3WJT3CnHErqqSIWQm0y73EUkVa6InNdpNxS2JYO3xA/v/jOz1NJKSqs uIWTgapWCsnAjns7yTwp30VxstaSXY9doFx35hvCR/E/5WpiYFbcDAyPpszMR0fUaYqL AdM+S8cjmiSrB5khPULZM/NkBbwycnnUFcojo+jVvgjLgFJ+/dF8+FpruYWGUznPbup4 rrLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OSjW1Zly4i0tbcYbzVoPhn1X+PmAUMD+zcCpqdluP7s=; b=BwmlxIDJ/z4+/4Cq0i2EQtSMjByAm/POJYDdfew6jBcZvBTLU1wz/7RYqdo46eN3Nd qOOD6TireTJFsrdHAzB5nQ+FxaGjwGO7uzSkNF9x31rOYRBjRcABA0uvVmq4gV6AJdo4 qh0e7eCVmaFpHATpkKG1UYjjXHqtYdbApK6IiABbvsZMkD+34MlLuXvvRa1NPGoFAKMF SmwpY7iztM2HandaSuoVTaIbXT1i68FB9FJGrfbqu33HMeOBN37TAvsK21kQ3e8FqXfe T3u9QqnTXnGfPCma5fEGVX9NdovjQ33Hab+Risb7dPmVPlvL56yhser5EPY3lROLtfCz qndg== X-Gm-Message-State: AHYfb5gfgqnQV7QcgmdX8OoTVlpslGo+Dvvz3FiWAYT0Q1XILpHQQYtA RSE+QNiPl7DQt4j+dk9eo19E3DUwBF/S X-Received: by 10.37.203.79 with SMTP id b76mr6434145ybg.256.1502457988386; Fri, 11 Aug 2017 06:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 11 Aug 2017 06:25:47 -0700 (PDT) In-Reply-To: <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> References: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> From: Eric Rescorla Date: Fri, 11 Aug 2017 06:25:47 -0700 Message-ID: To: Sara Dickinson Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05a962b0426d05567a4290" Archived-At: Subject: Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:26:34 -0000 --94eb2c05a962b0426d05567a4290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson wrote:---------------------------------------------------------------------= - I've reviewed the diff: 1. The bit about meta queries still seems kind of muddled. If you do an unauthenticated meta query to get the IP and then use that to do strict queries for the actual data, you suggest that that offers a DoS attack (if the attacker gives a bogus response) but couldn't they just inject an unverifiable response if you did it in strict mode? Also, doesn't it introduce a possibility of amplification: the attacker sends the client the IP of some victim and now the client sends multiple packets to that victim (as it retries) 2. I don't think the "limited or no mitigation" text in S 1 is right for opportunistic. Rather, it provides defense against passive attacks but not active ones. Note that an HSTS-like mechanism would provide more here.... widespread adoption of Strict Privacy. It should be employed > when > the DNS client might otherwise settle for cleartext; it provides > the maximum protection available. > > I don't think this statement is accurate. It provides the best > protection > that the attacker will allow. > > > Agreed - will update. > I don't think the parenthetical quite does the job here. The point is that it provides protection against passive attackers but not active ones. > Table 1 seems to have N and D paired, so maybe you can coalesce them? > > > That specific question was asked on the WG mailing list and the answer wa= s > =E2=80=98no, please keep both=E2=80=99: > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html > OK. -Ekr --94eb2c05a962b0426d05567a4290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson <sara@sinodun.com>= ; wrote:-------------------------------------------------------= ---------------
I've reviewed the diff:

1. The bit about meta queries still seems kind of muddled. If you do an = unauthenticated
meta query to get the IP and then use that to do = strict queries for the actual data, you suggest
that that offers = a DoS attack (if the attacker gives a bogus response) but couldn't they=
just inject an unverifiable response if you did it in strict mod= e? Also, doesn't it
introduce a possibility of amplification:= the attacker sends the client the IP of
some victim and now the = client sends multiple packets to that victim (as it retries)

=
2.=C2=A0 I don't think the "limited or no mitigation&qu= ot; text in S 1 is right for opportunistic.
Rather, it provides d= efense against passive attacks but not active ones. Note
that an = HSTS-like mechanism would provide more here....


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0widespread adoption of Strict P= rivacy.=C2=A0 It should be employed
when
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0the DNS client might otherwise settle for cleartext; it provides
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0the maximum protection available.

I don&#= 39;t think this statement is accurate. It provides the best
protectionthat the attacker will allow.

=
Agreed - will update.=C2=A0
=
I don't think the parenthetical quite does the job here.= The point is that it provides protection against passive attackers but not= active ones.

=C2=A0
Table 1 seems to have N = and D paired, so maybe you can coalesce them?
<= div>
That specific question was asked on the WG mailin= g list and the answer was =E2=80=98no, please keep both=E2=80=99:
https://www.ietf.org/mail-archive/web/dns-= privacy/current/msg01541.html
<= br>
OK.

-Ekr

<= br> --94eb2c05a962b0426d05567a4290-- From nobody Sat Aug 12 13:49:33 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE0B132190 for ; Sat, 12 Aug 2017 13:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 CVE0w2Vd9V9S for ; Sat, 12 Aug 2017 13:49:29 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [IPv6:2a03:4000:2:33f::5353]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EBA13218E for ; Sat, 12 Aug 2017 13:49:28 -0700 (PDT) Received: from smtp2.strotmann.de (unknown [IPv6:fd00::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 483737FDB8 for ; Sat, 12 Aug 2017 22:49:24 +0200 (CEST) Received: from emacs.strotmann.de.strotmann.de (unknown [172.42.1.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.strotmann.de (Postfix) with ESMTPSA id 3xVDWS3WhBzlsBr for ; Sat, 12 Aug 2017 22:49:24 +0200 (CEST) User-agent: mu4e 0.9.16; emacs 25.2.1 From: Carsten Strotmann To: "dns-privacy\@ietf.org" Date: Sat, 12 Aug 2017 20:49:24 +0000 Message-ID: <861sogika3.fsf@emacs.strotmann.de> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [0.00 / 0.00] RCVD_COUNT_TWO(0.00)[2] TO_DN_ALL(0.00)[] RCVD_TLS_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] MIME_GOOD(0.00)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_VIA_SMTP_AUTH(0.00)[] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] PREVIOUSLY_DELIVERED(0.00)[dns-privacy@ietf.org] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.26 X-Rspamd-Queue-ID: 483737FDB8 Archived-At: Subject: [dns-privacy] some DNS privacy implementation benchmark X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 20:49:31 -0000 Hi, I did a simple (and naive) benchmark of different DNS privacy implementations available. The benchmark measures the time needed to query the Alexa top 1000 via "dig" (sequentially). OS is Linux (amd64, Core2Duo). Network is 100Mbit FTTH. DNS-over-TLS was done via the SurfNET DNS-over-TLS resolver. dnsfwd is a UDP-to-TCP forwarder that keeps the TCP session open Unbound (1.6.0) opens a new TLS session for each query :( The DNSCrypt resolver was randomly chosen by the software. Protocol/Software Time (Sec) Privacy DNSSEC -------------------------------------------------------------------- Google DNS (UDP) 64 -- + DNS-over-TLS (dnsfwd+stunnel) 67 ++ - local Unbound w/o DNSSEC 146 - - local Unbound w. DNSSEC 163 - + DNS-over-DNSCrypt (ns0.dnscrypt.is) 243 ++ + DNS-over-Tor 254 ++ - DNS-over-TLS (Unbound+dnsfwd+stunnel) 258 ++ + DNS-over-TLS (Unbound+stunnel) 444 ++ + DNS-over-TLS (Unbound buildin TLS) 647 ++ + "Stubby" is missing, I having issues getting it to work, I will update this list once I've got "Stubby" working. As I have this setup now, is there an working implementation that is missing and should also be in the list? DNS-over-QUIC? DNS-over-HTTP(S)? Best regards Carsten Strotmann From nobody Sat Aug 12 17:37:11 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154E0132380 for ; Sat, 12 Aug 2017 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 BA-Rrx1eKSBM for ; Sat, 12 Aug 2017 17:37:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24F21323B4 for ; Sat, 12 Aug 2017 17:37:06 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dggtn-00061v-HZ for dns-privacy@ietf.org; Sun, 13 Aug 2017 02:37:05 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dggtF-0006lS-KJ for dns-privacy@ietf.org; Sat, 12 Aug 2017 20:36:56 -0400 Received: (qmail 11890 invoked from network); 13 Aug 2017 00:36:23 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.186]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Aug 2017 00:36:22 -0000 To: dns-privacy@ietf.org References: <861sogika3.fsf@emacs.strotmann.de> From: Christian Huitema Message-ID: Date: Sat, 12 Aug 2017 17:36:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <861sogika3.fsf@emacs.strotmann.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYoNzrMVvavOgy+9M5kGys4ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23bWROh6/H1+1tQLE5wSFWONSM4jd3ClxbkF2U h0iAyfJ95+flvWPOwEzJbaeY40EjYOEkjsX7F8KmpUaZQHV+ScWIfGf9Fu8q9UhMPe0GR5O2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKs+iZ7+uSas6Kaz0EAgJQD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyTNwi+w0SChxHdK7tla39yzeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236P3lKmWAnD6TmGOcphJKQyWezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6+ln3SmdyWNNJvR4I+Hp8ZcbZXx2HvjUnW6/hzaO3hBYd4k9BQeV6h8mU exU1wyIBe+fIXY1E4hLwh/WcmhlU3xklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7f/DKzfOCXnJQjcl9DhaIFtxx9jwrAA4q8w8yByBTCtrrNAiDYl3JQgId/2uR tInPuw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dns-privacy] some DNS privacy implementation benchmark X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 00:37:09 -0000 On 8/12/2017 1:49 PM, Carsten Strotmann wrote: > Hi, > > I did a simple (and naive) benchmark of different DNS privacy > implementations available. =2E.. > > The DNSCrypt resolver was randomly chosen by the software. > > Protocol/Software Time (Sec) Privacy DNSSEC=20 > -------------------------------------------------------------------- > Google DNS (UDP) 64 -- + =20 > DNS-over-TLS (dnsfwd+stunnel) 67 ++ - =20 > local Unbound w/o DNSSEC 146 - - =20 > local Unbound w. DNSSEC 163 - + =20 > DNS-over-DNSCrypt (ns0.dnscrypt.is) 243 ++ + =20 > DNS-over-Tor 254 ++ - =20 > DNS-over-TLS (Unbound+dnsfwd+stunnel) 258 ++ + =20 > DNS-over-TLS (Unbound+stunnel) 444 ++ + =20 > DNS-over-TLS (Unbound buildin TLS) 647 ++ + =20 These are interesting measurements, but they mix three variables: the transport protocol, the RTT between stub and resolver, and the amount of caching at the resolver. In my simulations, the key variable is the Round Trip Time between stub and resolver. The various transports differ in how they handle connections, retransmission, and head of queue blocking, but these effects are always expressed in terms of "number of additional RTT times some probability", the probability generally being at most a few percents= =2E The other variable in a "stub to recursive" scenario is the amount of caching done by the resolver. In standard stub to recursive scenarios, the queries appear to be served from the cache 30% to 40% of the time -- with a better service at big resolvers such as large ISP or Google DNS. This is because the cache is populated from requests of multiple clients, plus probably some pre-fetching. Small resolvers typically have lower cache rate. This matters, because the "recursive to authoritative" part of the resolution is typically larger than the "stub to resolver" pa= rt. In the unbound scenarios, were you using unbound as a local recursive server? > "Stubby" is missing, I having issues getting it to work, I will update > this list once I've got "Stubby" working. > > As I have this setup now, is there an working implementation that is > missing and should also be in the list? > > DNS-over-QUIC? > DNS-over-HTTP(S)? You probably need to wait until at least October for realistic implementations of DNS over QUIC. --=20 Christian Huitema From nobody Mon Aug 14 01:00:10 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BED13203D for ; Mon, 14 Aug 2017 01:00:08 -0700 (PDT) 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 dS8BCoUM5dLT for ; Mon, 14 Aug 2017 01:00:06 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [IPv6:2a03:4000:2:33f::5353]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750A3132031 for ; Mon, 14 Aug 2017 01:00:06 -0700 (PDT) Received: from smtp2.strotmann.de (unknown [IPv6:fd00::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id 229E67FDB6 for ; Mon, 14 Aug 2017 10:00:03 +0200 (CEST) Received: from emacs.strotmann.de.strotmann.de (unknown [172.42.1.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.strotmann.de (Postfix) with ESMTPSA id 3xW7Lq0ZvjzBnhQ for ; Mon, 14 Aug 2017 10:00:03 +0200 (CEST) References: <861sogika3.fsf@emacs.strotmann.de> User-agent: mu4e 0.9.16; emacs 25.2.1 From: Carsten Strotmann To: dns-privacy@ietf.org In-reply-to: Date: Mon, 14 Aug 2017 08:00:02 +0000 Message-ID: <86mv72h94t.fsf@emacs.strotmann.de> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [0.00 / 0.00] TO_DN_NONE(0.00)[] RCVD_COUNT_TWO(0.00)[2] RCVD_TLS_ALL(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_HAS_DN(0.00)[] MIME_GOOD(0.00)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_VIA_SMTP_AUTH(0.00)[] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] PREVIOUSLY_DELIVERED(0.00)[dns-privacy@ietf.org] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 0.24 X-Rspamd-Queue-ID: 229E67FDB6 Archived-At: Subject: Re: [dns-privacy] some DNS privacy implementation benchmark X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 08:00:09 -0000 Hello Christian, Christian Huitema writes: > These are interesting measurements, but they mix three variables: the > transport protocol, the RTT between stub and resolver, and the amount of > caching at the resolver. Yes, I know. The goal for this measurements were not to judge the different protocols, but to give an indication of performance on implementations available today (this work is part of an magazine article about implementing DNS-Privacy on Linux/BSD). > > In my simulations, the key variable is the Round Trip Time between stub > and resolver. The various transports differ in how they handle > connections, retransmission, and head of queue blocking, There is a gap between the theoretical abilities of the transports and the available implementations. I was interested in the user experience today using the tools that are available in mainstream Linux distributions (except "dnsfwd", which is only available as [experimental] source but which I added to not hurt the reputation of DNS-over-TLS). > but these > effects are always expressed in terms of "number of additional RTT times > some probability", the probability generally being at most a few percents. > > The other variable in a "stub to recursive" scenario is the amount of > caching done by the resolver. In standard stub to recursive scenarios, > the queries appear to be served from the cache 30% to 40% of the time -- > with a better service at big resolvers such as large ISP or Google DNS. > This is because the cache is populated from requests of multiple > clients, plus probably some pre-fetching. Small resolvers typically have > lower cache rate. This matters, because the "recursive to authoritative" > part of the resolution is typically larger than the "stub to resolver" part. > I will re-do the test with a replay of some real-world DNS queries that will make use of caching. The test I've done now is somewhat artificial, as it asked 1000 different questions on a cold cache. But that was the best way to measure the DNS resolution performance trough the different transports. Getting an answer from a local cache is always 0 ms in a local LAN. > In the unbound scenarios, were you using unbound as a local recursive > server? Yes. The cache was cold at the beginning of each test. > >> "Stubby" is missing, I having issues getting it to work, I will update >> this list once I've got "Stubby" working. >> >> As I have this setup now, is there an working implementation that is >> missing and should also be in the list? >> >> DNS-over-QUIC? >> DNS-over-HTTP(S)? > You probably need to wait until at least October for realistic > implementations of DNS over QUIC. I'm excited about DNS-over-QUIC from the technical point of view, it has potential. From the point of DNS Privacy, I'm not so thrilled, as I fear that the one major implementation will be between Chrome Browser and Google-DNS, which is a Zero-sum game for DNS privacy. Anyway, I will test drive DNS-over-QUIC once it is available in some useable form. Best regards Carsten Strotmann From nobody Tue Aug 15 08:13:35 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC5132055 for ; Tue, 15 Aug 2017 08:13:33 -0700 (PDT) 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 mm48jHpsDfdp for ; Tue, 15 Aug 2017 08:13:31 -0700 (PDT) Received: from smtp3.strotmann.de (smtp3.strotmann.de [46.38.233.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533091321CB for ; Tue, 15 Aug 2017 08:13:30 -0700 (PDT) Received: from smtp2.strotmann.de (unknown [IPv6:fd00::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.strotmann.de (Postfix) with ESMTPS id E17D57FC8B for ; Tue, 15 Aug 2017 17:13:23 +0200 (CEST) Received: from emacs.strotmann.de.strotmann.de (unknown [172.42.1.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.strotmann.de (Postfix) with ESMTPSA id 3xWwwL5n8pz17NM1 for ; Tue, 15 Aug 2017 17:13:22 +0200 (CEST) References: <861sogika3.fsf@emacs.strotmann.de> User-agent: mu4e 0.9.16; emacs 25.2.1 From: Carsten Strotmann To: "dns-privacy\@ietf.org" In-reply-to: <861sogika3.fsf@emacs.strotmann.de> Date: Tue, 15 Aug 2017 15:13:22 +0000 Message-ID: <86d17whnjh.fsf@emacs.strotmann.de> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [0.00 / 0.00] RCVD_COUNT_TWO(0.00)[2] TO_DN_ALL(0.00)[] RCVD_TLS_ALL(0.00)[] FROM_HAS_DN(0.00)[] TO_MATCH_ENVRCPT_ALL(0.00)[] MIME_GOOD(0.00)[text/plain] RCPT_COUNT_ONE(0.00)[1] RCVD_VIA_SMTP_AUTH(0.00)[] FROM_EQ_ENVFROM(0.00)[] ARC_NA(0.00)[] PREVIOUSLY_DELIVERED(0.00)[dns-privacy@ietf.org] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 5.03 X-Rspamd-Queue-ID: E17D57FC8B Archived-At: Subject: Re: [dns-privacy] some DNS privacy implementation benchmark X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 15:13:33 -0000 Hello, here is a followup benchmark test, same setup, but 1000 queries collected from an office network replayed via "dig" (with duplicates and all, so the cache is being used). | Protocol | Time (Seconds) | Privacy | DNSSEC | |---------------------------------------+-----------------+---------+--------| | DNS-over-TLS (Unbound+dnsfwd+stunnel) | 10 | ++ | + | | local Unbound with DNSSEC | 11 | - | + | | local Unbound without DNSSEC | 11 | - | - | | DNS-over-TLS (dnsfwd+stunnel) | 21 | ++ | - | | DNS-over-TLS (Unbound+stunnel) | 24 | ++ | + | | Google DNS (UDP) | 30 | -- | + | | DNS-over-TLS (Unbound buildin TLS) | 40 | ++ | + | | DNS-over-DNSCrypt (ns0.dnscrypt.is) | 81 | ++ | + | | DNS-over-Tor | 103 | ++ | - | Looks not too bad. Carsten Strotmann