From nobody Wed Nov 1 07:31:22 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224013F996 for ; Wed, 1 Nov 2017 07:31:20 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 H6d4-1I5sZFx for ; Wed, 1 Nov 2017 07:31:19 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 32DBC13FC82 for ; Wed, 1 Nov 2017 07:31:18 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id x65so1528091vkx.1 for ; Wed, 01 Nov 2017 07:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vKE3UC/cBU6dVdbxkkKl6VGOClJZ9slgO19Ae+v8Aak=; b=PaFFfgwjH0I9GcwXm1/wHJSJCNeytK0h4htxxzW3tvU201Il+eWkWcnPFq/kD2KWLD oW0xR1gh12i0eBNpHclS4Ye15ZVtOhjPtx34T6onuaQwqu5J5Lm6Tnrjfs2mJqkwc33F jtEHcs0U0bJJ0qmC8qJoCbPXMYzCDIJ/88mvAywcSIH7LZ5JcOkXZ6mU09zHXvmXzgn3 0AgLLaSL0xaKxq300To/DZ3Tl+5h9Wzez7Q3Tb44tHlsxxSMg2jt9iGC7CL1gVzEbPy+ 3lcgiDzojDFOrpGTlmjWXlAsihhaek520TsA6Kvrioizb5FnRQtLPh7eSJOOQO6+IsiR MN2A== 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; bh=vKE3UC/cBU6dVdbxkkKl6VGOClJZ9slgO19Ae+v8Aak=; b=OghDVng3ILxzLz0taGm6BpC4FtpPprtrK8QaR3h6wHceWJcD/88XcgRiA0+hqwqjgs 1B6CYwJn5tJnm8uPmOrwB/qYIh2QN4g2D6bv/jcFqzvpGj8S5nsmkdp1cTLkh9zhChyp tMVtS1orqPuFjvQTDbRvL4CAT2lyIRiSPgTsxuWHHYxqXqVxbD+p05ILCGG/vlQFPtvE QKL+FKi67iHrXwILA6zOYI/OghbHDf4v5hTgeNvU7H2GOlgMmP/GSWUdlrQwkaPQBBwQ QIBgeD47KYrhsKAYlgaeeo5dxHQT9CTxLomtlxU57Nh9nqNM+ZKZT4/xLkoM+IazdX9y T80g== X-Gm-Message-State: AMCzsaUYlXfltS+zXQy4Wexcv6En6KNb3e5ADv6MPvXcxzS4WzOlmfBS f5RQvvviw2AoX8zRCJtYoupJWWGuHvVyZiTOObDxMAf3E0Y= X-Google-Smtp-Source: ABhQp+QNu+5VnKl/dqGcabPs0vr+udY1wDzaXo2CxiLnUIs/XEQhCOVHfXZD/ngCGof+7Z6VkUSfBljm0GXtUOFIjXM= X-Received: by 10.31.124.73 with SMTP id x70mr47169vkc.8.1509546676761; Wed, 01 Nov 2017 07:31:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Wed, 1 Nov 2017 07:31:16 -0700 (PDT) In-Reply-To: References: From: Ben Schwartz Date: Wed, 1 Nov 2017 10:31:16 -0400 Message-ID: To: doh@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c14c7d678797e055cecb939" Archived-At: Subject: Re: [Doh] Status update X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:31:21 -0000 --94eb2c14c7d678797e055cecb939 Content-Type: multipart/alternative; boundary="94eb2c14c7d671533b055cecb939" --94eb2c14c7d671533b055cecb939 Content-Type: text/plain; charset="UTF-8" FYI, the issue tracker is now at https://github.com/dohwg/draft-ietf-doh-dns-over-https, and we are ready for pull requests. Substantive discussion should remain on this mailing list. On Tue, Oct 31, 2017 at 2:53 PM, Ben Schwartz wrote: > 1. We have formally adopted Paul and Patrick's draft: https://datatracker. > ietf.org/doc/draft-ietf-doh-dns-over-https/ . Further comments > definitely welcome! > > 2. We have opened a "project" on Github for anyone who would prefer to > track issues there. (However, our ADs have advised the substantive > discussion should stay on this mailing list.). The issue tracker is here: > https://github.com/dohwg/drafts/issues. The draft text is not yet on > github, so we're not yet ready for pull requests. > > 3. Please contact the list or the chairs ASAP if you would like agenda > time. > > --Ben, for the chairs > --94eb2c14c7d671533b055cecb939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, the issue tracker is now at=C2=A0https://github.com/dohwg/dra= ft-ietf-doh-dns-over-https, and we are ready for pull requests.=C2=A0 S= ubstantive discussion should remain on this mailing list.

On Tue, Oct 31, 2017 at 2:5= 3 PM, Ben Schwartz <bemasc@google.com> wrote:
1. We have formally adopted Paul and P= atrick's draft:=C2=A0https://datatracker.ietf.o= rg/doc/draft-ietf-doh-dns-over-https/ .=C2=A0 Further comments def= initely welcome!

2. We have opened a "project"= on Github for anyone who would prefer to track issues there.=C2=A0 (Howeve= r, our ADs have advised the substantive discussion should stay on this mail= ing list.).=C2=A0 The issue tracker is here:=C2=A0https://github.com/dohwg/d= rafts/issues.=C2=A0 The draft text is not yet on github, so we're n= ot yet ready for pull requests.

3. Please contact = the list or the chairs ASAP if you would like agenda time.

--Ben, for the chairs

--94eb2c14c7d671533b055cecb939-- --94eb2c14c7d678797e055cecb939 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCXg/0M8IYqjB4AWBXvmQel /FKvM8GY9Fsn7wXJNzLhHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzExMDExNDMxMTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFnOq1Vin5/a8GMWEq/sOBetklHhZZlERObof8fO2 oQ/qC0iRa8t2fAe6gF78+QDQLMgwWWTsutsvZJTwd73Gh78vMs3Cp4km9uFVgiNRQaqiptb3qH1t 6jjMwri5t3f8VWt7cwpGdl2vTvruMcycu6RoUkDXPJyJnm4V0pk4hx5omBdgNZNgNzq2fv25ByUl nsc266pQV0/Lg/uPcgZQGHJeWvraD1KCK6AiBZUfAhiJYFXLOy/+dr4nAy5mfeDoBvPWeq6OTqrB IZQ9XsxCIAX/ZdSpPdF/pzfOIROJYKZ/UKMwOleVwIBf+C70ODdwrOWa8UgmglnB8BOMwpXIEg== --94eb2c14c7d678797e055cecb939-- From nobody Fri Nov 3 13:16:06 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6003D13FF7D for ; Fri, 3 Nov 2017 13:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 b3kRy-taZ9uy for ; Fri, 3 Nov 2017 13:16:03 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 86F2E13FF48 for ; Fri, 3 Nov 2017 13:16:03 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id l8so3479903wre.12 for ; Fri, 03 Nov 2017 13:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Mjo1bacR0hkJimM1IGlxulJf+ps9RCClQT6DDXqQ98=; b=h4jK8494dtVk7uotdBkIx9G4Thq/yh9W64o0uqmw9J9Y8uAcK9LZImbbn9ZdVBh6Wh b0YYkVfuYE977h26p+8Hb8EZO/ATYS+qbjJ+0qVsl1O8JO3ZwgPuK9OS8WnLMGZPGRux FXYgNJ+V1M8wdssoo3cLE62QDJI3SZU7nYFQXBPIZ+/HXGmCKyKdD84Jk9C+Lo3zshuD cEqg7V0X/5ko8Fqb9eCmQiT4ur6plSlBlVpY670t2y18qBumS3b4eBJaV4A302+h3S7N YUT9sSOkPDrgrGzLKJYQHWmhRLls9SyUG5DoSoRUSMo+P1DDRtOejIUghWOEi7r5a/Lj t3FQ== 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=7Mjo1bacR0hkJimM1IGlxulJf+ps9RCClQT6DDXqQ98=; b=jFfOkFZlVOI3q7b0xov1H8PwnVbWE3Ug3gv4fsOqkZzfHd6V2LjwK/WVaUyhcrl/ow CBz3gMmrg8rTzHHThMIaPlj6IzKpu3O312DlCeTEVTfo4W19r9v5b0Bm8p96tzgJZLm/ Gb8yTLgkmUgO0ZFsztBUAM327Ew4Vdy+v2yTWKDx2KjyLyzXLZVIUSTfRUjzhUxXZ6RM f9ObOI5xSjryj+mHAaaqjX4x46f6hFFQ4CWkGbAcSzFjsJLn73zv1zUK6G0GFFVhXfvt tpRcz28E190A1qum0qGQPuXSTdH4c864giO7IEEwmhPOedSWY2SHvOKCfeeESO92xLHj PKVw== X-Gm-Message-State: AMCzsaXKOD1mG6XxnIn/nGclEaQINRNm+OBOmdUxRYFFgDf+UB88aswY GqX+540ZtmIHEo+8t2k6en4QOq5VSXgl87w19NQ= X-Google-Smtp-Source: ABhQp+QRVg6I11Eq0DHcxPtFbqHjSuI5M4gkvW+A9FqEIpsUyBRmB+yZYzSQaoaWOvEO5W56ozTJWJLz7ZC83n93/Ug= X-Received: by 10.223.168.45 with SMTP id l42mr6706631wrc.15.1509740162138; Fri, 03 Nov 2017 13:16:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Fri, 3 Nov 2017 13:16:01 -0700 (PDT) In-Reply-To: References: From: tjw ietf Date: Fri, 3 Nov 2017 16:16:01 -0400 Message-ID: To: Patrick McManus Cc: Eliot Lear , doh@ietf.org Content-Type: multipart/alternative; boundary="f403045f4c221145eb055d19c65f" Archived-At: Subject: Re: [Doh] operational issues with doh X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:16:05 -0000 --f403045f4c221145eb055d19c65f Content-Type: text/plain; charset="UTF-8" Agree with Patrick, this should be more of an operational considerations document. On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus wrote: > I think I would prefer a separate document if people were interested in > working on that. > > On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear wrote: > >> Hi everyone, >> >> Just to follow up on the lengthy discussion that took place during >> chartering, there are some operational issues that use of doh can >> create, particularly with regard to load balancers and split DNS. Do >> those go into the draft or do they go into a separate doc? It's quite >> possible they can be mitigated against, and if they can be, and if the >> text isn't too long, can I suggest that we start out by having some text >> in the draft, and if it starts to get lengthy we split it off? >> >> Eliot >> >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --f403045f4c221145eb055d19c65f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with Patrick, this should be more of an operational = considerations document.=C2=A0

On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus <pm= cmanus@mozilla.com> wrote:
=
I think I would prefer a separate document if people were = interested in working on that.

On Tue, Oct 31, 2017 at 2:57 = PM, Eliot Lear <lear@cisco.com> wrote:
Hi everyone,

Just to follow up on the lengthy discussion that took place during
chartering, there are some operational issues that use of doh can
create, particularly with regard to load balancers and split DNS.=C2=A0 Do<= br> those go into the draft or do they go into a separate doc?=C2=A0 It's q= uite
possible they can be mitigated against, and if they can be, and if the
text isn't too long, can I suggest that we start out by having some tex= t
in the draft, and if it starts to get lengthy we split it off?

Eliot



________________________________________= _______
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh



_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--f403045f4c221145eb055d19c65f-- From nobody Fri Nov 3 13:36:01 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4EB13FFC2 for ; Fri, 3 Nov 2017 13:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 y2i0uc58g2yc for ; Fri, 3 Nov 2017 13:35:58 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 268F313FFBB for ; Fri, 3 Nov 2017 13:35:58 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id i133so2516901vke.9 for ; Fri, 03 Nov 2017 13:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jd3FF3JVY+eBx3PUp/qoWO0LWXIo3warXbMz205Wt8M=; b=RgsAfZ0rrYNYUIufRS8WdMVgMLwrtxLEdZUwvT1vL7VL32TNlHERieyM+GfRZd4u5U dGI5aMGiuqaIaAZQxlyyKXtD/4S7sQVcmR3jWSzRfSkSzqvBQkohJW5ZNynCt9Faz4yt fWgiE3IUBpVPrjAE2eF60fHItYYmguHZi0dpHw0YoYpVWPtizYW60g6HG9VQVwdRJRMk 3IJgCx8rj0PF9dKTe5QaCk8fI0dwleP2dFivqIogvWMCJ8Jo2UXK6kn75UkBkwX6Ofae 7QLhn6M4WP2uiJOWOw3Tdq+wFHueYfC4Vdp6CWaO/9tuW0K45jGZ7gNuKfkKvue2hKKm smKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jd3FF3JVY+eBx3PUp/qoWO0LWXIo3warXbMz205Wt8M=; b=WB9sXjD2th2qMCmx+k66sTMQi/UGymJCn2rWWCLKHBc75l+R0KQcqHfNs3IM8GgFBQ fVFUHGi1rrS+IFpMbphCSliX2+KcG9/vfD3VvB73bxHVx6SOS0ZT9ikp+dwNd3ryQsaL K4runUmytYz58T190YjKeJWseWklMA0ucst8orgLFzlxPU1CjXK2DI0+bOk36lddOOTn RWGpkhcx5gUGUvSgQmVHJUXDrl9GNNnYD66R1IvLJduKj2AeqLHSX+FWWu30Qdmdu2qJ 14fbsiNl6yOzwDPoTcge+kfc0A6VYte+OooUyyV2Fh8YHh8lN6l+uS0f9C+bT2ToxawD 8gCw== X-Gm-Message-State: AMCzsaUb3F4n+DWeG09ewMVU2x/0mOsaFdpacHCMfvtF5SUHt5RvcLG6 hEPi/RaPlLaxhykWjTgez62Rad+12Qy3ZWBds7zZbKQCFFo= X-Google-Smtp-Source: ABhQp+Ta1blMQHW6iHbi3PBsgrugjSWp8+BxWq5tjimuH033grwdnjZzZrkFkcRBy1etuEyQefUzzTvyQxtvts6vF/k= X-Received: by 10.31.212.134 with SMTP id l128mr5873028vkg.184.1509741356794; Fri, 03 Nov 2017 13:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.170.145 with HTTP; Fri, 3 Nov 2017 13:35:56 -0700 (PDT) From: Ben Schwartz Date: Fri, 3 Nov 2017 16:35:56 -0400 Message-ID: To: doh@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07dcaa4e0c43055d1a0dcf" Archived-At: Subject: [Doh] DOH Agenda X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:36:00 -0000 --94eb2c07dcaa4e0c43055d1a0dcf Content-Type: multipart/alternative; boundary="94eb2c07dcaa46c6d2055d1a0d30" --94eb2c07dcaa46c6d2055d1a0d30 Content-Type: text/plain; charset="UTF-8" FYI, preliminary agenda is up: https://datatracker.ietf.org/meeting/100/materials/agenda-100-doh/ Please suggest changes and request time ASAP. The deadline for the final agenda is midnight UTC on Monday. --Ben, for the chairs --94eb2c07dcaa46c6d2055d1a0d30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, preliminary agenda is up:=C2=A0https://datatracke= r.ietf.org/meeting/100/materials/agenda-100-doh/

Ple= ase suggest changes and request time ASAP.=C2=A0 The deadline for the final= agenda is midnight UTC on Monday.

--Ben, for the = chairs
--94eb2c07dcaa46c6d2055d1a0d30-- --94eb2c07dcaa4e0c43055d1a0dcf Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t /WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo 7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm 9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/ UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDdjly/guvgp30RbZg8P1mq Z+E1xO67AOArBcwif3EP/TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzExMDMyMDM1NTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAjcWDr0oYyl4tGBBSHkXeZTCI3D22/MKFZLU24xu1 h/gSV67QrDzK8oUBLrDDJWDbCCIUadnuN2t7mbEGY0PiklhGs7/VnPlxnckGfbeOUyCsI9NkA/dO 4QVG/sv0tS2Olw56CvWkmP2JPnG/RBbdfoGfGLdqYHG/Es8AJdKRRrOy7y5UFn0EAnnnwaayzy6q dfoFwoTdaZKReJvtkonY4W9YIobWPmWJ3fQ7/exmSV/yc9r2ErPZvF9SijBAZ0qPMAneo2rxWmQN 2dZ6nLGNYGi+bDrS8L0Tlo0YZZttFCpzB2TEFBQ7mT+X+TOdaXNQ50H6UDKHg1H46JW9+9YLIw== --94eb2c07dcaa4e0c43055d1a0dcf-- From nobody Fri Nov 3 15:33:42 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F305613FEC2 for ; Fri, 3 Nov 2017 15:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6dMIFus0_hnS for ; Fri, 3 Nov 2017 15:33:40 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 6ED0F13FE6A for ; Fri, 3 Nov 2017 15:33:40 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id 96so3905070otw.11 for ; Fri, 03 Nov 2017 15:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pNfGT3ftJ8mfFTh3V8mdpWysmzN8IbS2YShp5a5/prU=; b=HWtoHpg3V6D/mUgV8gs+KXhK2VwkgStjx835p2dpjoHoHC2hV0lnkpMNltbgC8lSwJ wey6vOURYqyND3KdLrS2pNLO59PoLJvrxJszx7NWjmW86JQkxgKozhOvwwzDlJj5Mx84 L79uk9ZTUJZuZoN9r0uDQ3KbQd06Lo3Fu+0iiIGv9E31zFN2nA/8hV3LzZJ1/MyZWIYJ DajkIygnBsCMK2bnCa+OyIeEyfM0WxuBf1k8J7t8nHNeqkv3MEwmm39NePRPThUOFfKR 9Qp2Jk8VMn+sp3a1UDR8ozPvLeazi9On3+uaUJzd7CpsHnseeoVkivnDJDbohfsHKsO9 4zOQ== 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=pNfGT3ftJ8mfFTh3V8mdpWysmzN8IbS2YShp5a5/prU=; b=hStxixtEqWluRZFM2PbR/TbdG3ftxLFu+0SwklKZ7r2xZpDyHnOwbpB9VT7J4tt5mK OBbds2zRK7larR1p3ejKXx4JsheX/yR1akx4u/UzTZmnBMLDQT5aWU0p/kBLyAPTVTFv l6art5CKsJLdC1ChrGDdFq/efLTbCTvEA3lHwunSDRSwB6LuzBi9dzouYyRxoH49O1UY 0ybGbZ5gwG5AsHsSfMOAJkzo5VVUXFwb7LrtkQZDPPvSq8+YObNaAH4daYkN5OSxeph8 ZRVcn4WjKeula8GKeM8jDf0N7WRSKHLeGPowH5L8g3WXywoMqigWywj/fvCrVkGCfOfn QOfg== X-Gm-Message-State: AJaThX6zRlcUKmAa6Altxh+k7vUco7A8W4LOekg1I66z0fPQ/pmw9Cfx 0ew9rrcNTP1CnSBHlYmVlWVFEmZgfLsXnP2drgs= X-Google-Smtp-Source: ABhQp+RaM0xIhx7rIqdXNYhEzGrzdspW0veZfUiyhCQnsGpqg17ArBXhlWpb0/RN74eOOYeeR6OaZDA3Gy/Q80MORPA= X-Received: by 10.157.87.75 with SMTP id x11mr5604151oti.112.1509748419728; Fri, 03 Nov 2017 15:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Fri, 3 Nov 2017 15:33:39 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 4 Nov 2017 09:33:39 +1100 Message-ID: To: tjw ietf Cc: Patrick McManus , doh@ietf.org, Eliot Lear Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] operational issues with doh X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 22:33:42 -0000 Maybe someone can send an email outlining the operational concerns to the list and we can discuss them first. I don't know what these concerns are. On Sat, Nov 4, 2017 at 7:16 AM, tjw ietf wrote: > Agree with Patrick, this should be more of an operational considerations > document. > > On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus > wrote: >> >> I think I would prefer a separate document if people were interested in >> working on that. >> >> On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear wrote: >>> >>> Hi everyone, >>> >>> Just to follow up on the lengthy discussion that took place during >>> chartering, there are some operational issues that use of doh can >>> create, particularly with regard to load balancers and split DNS. Do >>> those go into the draft or do they go into a separate doc? It's quite >>> possible they can be mitigated against, and if they can be, and if the >>> text isn't too long, can I suggest that we start out by having some text >>> in the draft, and if it starts to get lengthy we split it off? >>> >>> Eliot >>> >>> >>> >>> _______________________________________________ >>> Doh mailing list >>> Doh@ietf.org >>> https://www.ietf.org/mailman/listinfo/doh >>> >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > From nobody Sun Nov 5 00:30:16 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664C213FB59 for ; Sun, 5 Nov 2017 00:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2Q_q2_7DmIar for ; Sun, 5 Nov 2017 00:30:12 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D2313FA6E for ; Sun, 5 Nov 2017 00:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10387; q=dns/txt; s=iport; t=1509867011; x=1511076611; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=GJf+ffnrvnAJ0R1TwB7+D1LVqFEci/AghS+NQtQMzCc=; b=W/cZMoRI+5b6W1hJ2T2k08vMKxVOBlpv7I4gAPkhoQVM12hTwjtI2yGX QxKBpPpSpGUgmj4mSDxChWgWCOBkRhU0ajzl3BrVyWvJYX83DSAu2qYh5 ilS+ManXj/pTFt3qmK9GeIOUgZrtDCp1m/YPOPWaZCn6eMg6MbzwbdZWp k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAADVvP5Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ih90j3IJJohRiC+FRhCCAQcDGAEKhRgChRYYAQEBAQE?= =?us-ascii?q?BAQEBayhCEIRNAQEBAwEBIUIJCxALGCoCAiEGMAYBDAYCAQGKBwMVEKkUgicmh?= =?us-ascii?q?woNg0YBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWDLoVsC4J2gmqBdAESAQmDK4J?= =?us-ascii?q?iBaFSPIRCgiOEaIQ2hHmLeIc8jRqIfIE5HziBA2k0IQgdFUmCZIRgQDaEAoU6g?= =?us-ascii?q?jUBAQE?= X-IronPort-AV: E=Sophos;i="5.44,346,1505779200"; d="asc'?scan'208,217";a="30573" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2017 07:30:09 +0000 Received: from [10.61.199.115] ([10.61.199.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA57U9xG023563; Sun, 5 Nov 2017 07:30:09 GMT To: Martin Thomson , tjw ietf Cc: Patrick McManus , doh@ietf.org References: From: Eliot Lear Message-ID: <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com> Date: Sun, 5 Nov 2017 08:30:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RQUqWbJcAuBtwcHo3oi8NojhSwh1fMPGc" Archived-At: Subject: Re: [Doh] operational issues with doh X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 07:30:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RQUqWbJcAuBtwcHo3oi8NojhSwh1fMPGc Content-Type: multipart/mixed; boundary="kjCsvu9MTC1a1RvcAvBH980N3q0B5LNsf"; protected-headers="v1" From: Eliot Lear To: Martin Thomson , tjw ietf Cc: Patrick McManus , doh@ietf.org Message-ID: <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com> Subject: Re: [Doh] operational issues with doh References: In-Reply-To: --kjCsvu9MTC1a1RvcAvBH980N3q0B5LNsf Content-Type: multipart/alternative; boundary="------------90C7F4E62AC2856A4C12761A" Content-Language: en-US This is a multi-part message in MIME format. --------------90C7F4E62AC2856A4C12761A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are several: * Use of this mechanism can cause problems with split DNS, where the internal DNS is not the same as what is made available externally.=C2= =A0 Many corporate networkers hide their internal topology from the external DNS.=C2=A0 If an end host queries an external DNS for an internal resource, the result would be NXDOMAIN.=C2=A0 To avoid this,= at a minimum, the browser should have some configuration as to what is internal.=C2=A0 I conjecture that this would reflect what is commonly= found in a proxy.pac file. * When an HTTP server offers this service for domains it is not responsible for, it has the potential to impact DNS-based load balancing by masking the IP address of the sender and substituting its own.=C2=A0 The remedy here is that any service offering DoH shoul= d sufficiently distributed as to minimize such an impact. * Use of DoH will bypass protection mechanisms commonly used to efficiently detect and prevent access to known malware-infested sites.=C2=A0 There are two mitigation mechanisms available, but one i= s incomplete:=C2=A0 deployments make use of in-path blocking methods su= ch as IP access lists.=C2=A0 This is partial because there is a performance/memory impact in doing so, and the query itself can indicate that the device itself is infected.=C2=A0 The other mitigati= on here is to have a configuration mechanism to turn on/off DoH in order to use the existing infrastructure.=C2=A0 This has the least im= pact on surrounding infrastructure (and takes the least text ;-). Eliot On 11/3/17 11:33 PM, Martin Thomson wrote: > Maybe someone can send an email outlining the operational concerns to > the list and we can discuss them first. I don't know what these > concerns are. > > On Sat, Nov 4, 2017 at 7:16 AM, tjw ietf wrote: >> Agree with Patrick, this should be more of an operational consideratio= ns >> document. >> >> On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus >> wrote: >>> I think I would prefer a separate document if people were interested = in >>> working on that. >>> >>> On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear wrote: >>>> Hi everyone, >>>> >>>> Just to follow up on the lengthy discussion that took place during >>>> chartering, there are some operational issues that use of doh can >>>> create, particularly with regard to load balancers and split DNS. D= o >>>> those go into the draft or do they go into a separate doc? It's qui= te >>>> possible they can be mitigated against, and if they can be, and if t= he >>>> text isn't too long, can I suggest that we start out by having some = text >>>> in the draft, and if it starts to get lengthy we split it off? >>>> >>>> Eliot >>>> >>>> >>>> >>>> _______________________________________________ >>>> Doh mailing list >>>> Doh@ietf.org >>>> https://www.ietf.org/mailman/listinfo/doh >>>> >>> >>> _______________________________________________ >>> Doh mailing list >>> Doh@ietf.org >>> https://www.ietf.org/mailman/listinfo/doh >>> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> --------------90C7F4E62AC2856A4C12761A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

There are several:

  • Use of this mechanism can cause problems with split DNS, where the internal DNS is not the same as what is made available externally.=C2=A0 Many corporate networkers hide their internal topology from the external DNS.=C2=A0 If an end host queries an external DNS for an internal resource, the result would be NXDOMAIN.=C2=A0 To avoid this, at a minimum, the browser should h= ave some configuration as to what is internal.=C2=A0 I conjecture tha= t this would reflect what is commonly found in a proxy.pac file.
  • When an HTTP server offers this service for domains it is not responsible for, it has the potential to impact DNS-based load balancing by masking the IP address of the sender and substituting its own.=C2=A0 The remedy here is that any service offering DoH should sufficiently distributed as to minimize such an impact.
  • Use of DoH will bypass protection mechanisms commonly used to efficiently detect and prevent access to known malware-infested sites.=C2=A0 There are two mitigation mechanisms available, but o= ne is incomplete:=C2=A0 deployments make use of in-path blocking met= hods such as IP access lists.=C2=A0 This is partial because there is a= performance/memory impact in doing so, and the query itself can indicate that the device itself is infected.=C2=A0 The other mitigation here is to have a configuration mechanism to turn on/off DoH in order to use the existing infrastructure.=C2=A0 Thi= s has the least impact on surrounding infrastructure (and takes the least text ;-).

Eliot


On 11/3/17 11:33 PM, Martin Thomson wrote:
Maybe someone can send an email outlining the operat=
ional concerns to
the list and we can discuss them first.  I don't know what these
concerns are.

On Sat, Nov 4, 2017 at 7:16 AM, tjw ietf <tjw.ietf@gmail.com> wrot=
e:

Agree with Patrick, this should be more of an oper=
ational considerations
document.

On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus <pmcmanus@mozilla.com&=
gt;
wrote:

I think I would prefer a separate document if people were interested in
working on that.

On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear <lear@cisco.com> wrote:

Hi everyone,

Just to follow up on the lengthy discussion that took place during
chartering, there are some operational issues that use of doh can
create, particularly with regard to load balancers and split DNS.  Do
those go into the draft or do they go into a separate doc?  It's quite
possible they can be mitigated against, and if they can be, and if the
text isn't too long, can I suggest that we start out by having some text
in the draft, and if it starts to get lengthy we split it off?

Eliot



_______________________________________________
Doh mailing list
Doh@ie=
tf.org
https://www.ietf.org/mailman/listinfo/doh



_______________________________________________
Doh mailing list
Doh@ie=
tf.org
https://www.ietf.org/mailman/listinfo/doh



_______________________________________________
Doh mailing list
Doh@ie=
tf.org
https://www.ietf.org/mailman/listinfo/doh



    

    

  


--------------90C7F4E62AC2856A4C12761A--

--kjCsvu9MTC1a1RvcAvBH980N3q0B5LNsf--

--RQUqWbJcAuBtwcHo3oi8NojhSwh1fMPGc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ/r4AAAoJEIe2a0bZ0noztsoIAJXW46e+Ov8tDzajhfsG5fbL
Nw7aCV0O7/Bin2MmE+Rj4+4/dK1RbuxQwpIBjWlYLdXYsLju3xvdQ6DH3VkArMKs
w4hRWKzcAtwYkOOgVvIoPhjpNHgOg2yvLAXjtoJhiyKXFXdxAj/2p4DktV68oT+s
CP0N6XwjtQQJBlFY8OyjOqYrx2Pz9CqzAIPVb1c8JJjWGL8eeGDNx+XzApZnfPkZ
xojgxQBW71ui/fiz2DR6v//xkfNt/PF8PP2Ijzpl4FxFnSJ2q+IwyI6hE0kAO3Cz
lPDcA8/FKqcYdkPagbZzmBHP1aNAGstM46VuQWIWy+2xFleukgFYkwygNpBWZb0=
=TTWv
-----END PGP SIGNATURE-----

--RQUqWbJcAuBtwcHo3oi8NojhSwh1fMPGc--


From nobody Sun Nov  5 07:46:05 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB713FA91 for ; Sun,  5 Nov 2017 07:46:04 -0800 (PST)
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] 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 p4ttiS0ChVhE for ; Sun,  5 Nov 2017 07:46:03 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DE74313F979 for ; Sun,  5 Nov 2017 07:46:02 -0800 (PST)
Received: from [169.254.97.244] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA5FiWrg013668 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Nov 2017 08:44:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.97.244]
From: "Paul Hoffman" 
To: "Eliot Lear" 
Cc: doh@ietf.org
Date: Sun, 05 Nov 2017 07:45:55 -0800
Message-ID: 
In-Reply-To: <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com>
References:     <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: Re: [Doh] operational issues with doh
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:46:04 -0000

In order to make the conversations easier to follow, I'm going to split 
these out into separate threads.

--Paul Hoffman

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

> There are several:
>
>   * Use of this mechanism can cause problems with split DNS, where the
>     internal DNS is not the same as what is made available 
> externally. 
>     Many corporate networkers hide their internal topology from the
>     external DNS.  If an end host queries an external DNS for an
>     internal resource, the result would be NXDOMAIN.  To avoid this, 
> at
>     a minimum, the browser should have some configuration as to what 
> is
>     internal.  I conjecture that this would reflect what is commonly
>     found in a proxy.pac file.
>   * When an HTTP server offers this service for domains it is not
>     responsible for, it has the potential to impact DNS-based load
>     balancing by masking the IP address of the sender and substituting
>     its own.  The remedy here is that any service offering DoH should
>     sufficiently distributed as to minimize such an impact.
>   * Use of DoH will bypass protection mechanisms commonly used to
>     efficiently detect and prevent access to known malware-infested
>     sites.  There are two mitigation mechanisms available, but one is
>     incomplete:  deployments make use of in-path blocking methods 
> such
>     as IP access lists.  This is partial because there is a
>     performance/memory impact in doing so, and the query itself can
>     indicate that the device itself is infected.  The other 
> mitigation
>     here is to have a configuration mechanism to turn on/off DoH in
>     order to use the existing infrastructure.  This has the least 
> impact
>     on surrounding infrastructure (and takes the least text ;-).


From nobody Sun Nov  5 07:46:38 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A113FA91 for ; Sun,  5 Nov 2017 07:46:37 -0800 (PST)
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] 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 QaDWDv7jc_GE for ; Sun,  5 Nov 2017 07:46:36 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 71C5113F979 for ; Sun,  5 Nov 2017 07:46:36 -0800 (PST)
Received: from [169.254.97.244] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA5Fj9J8013678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Nov 2017 08:45:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.97.244]
From: "Paul Hoffman" 
To: doh@ietf.org
Date: Sun, 05 Nov 2017 07:46:33 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: [Doh] DOH and split DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:46:37 -0000

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

>   * Use of this mechanism can cause problems with split DNS, where the
>     internal DNS is not the same as what is made available externally. 
>     Many corporate networkers hide their internal topology from the
>     external DNS.  If an end host queries an external DNS for an
>     internal resource, the result would be NXDOMAIN.  To avoid this, at
>     a minimum, the browser should have some configuration as to what is
>     internal.  I conjecture that this would reflect what is commonly
>     found in a proxy.pac file.


From nobody Sun Nov  5 07:47:56 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BBE13FB1D for ; Sun,  5 Nov 2017 07:47:54 -0800 (PST)
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] 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 tQeRocXrfB09 for ; Sun,  5 Nov 2017 07:47:53 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5A0AE13FA91 for ; Sun,  5 Nov 2017 07:47:53 -0800 (PST)
Received: from [169.254.97.244] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA5FkOaQ013729 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Nov 2017 08:46:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.97.244]
From: "Paul Hoffman" 
To: doh@ietf.org
Date: Sun, 05 Nov 2017 07:47:48 -0800
Message-ID: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:47:54 -0000

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

>   * When an HTTP server offers this service for domains it is not
>     responsible for, it has the potential to impact DNS-based load
>     balancing by masking the IP address of the sender and substituting
>     its own.  The remedy here is that any service offering DoH should
>     sufficiently distributed as to minimize such an impact.


From nobody Sun Nov  5 07:48:26 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9072213FB1F for ; Sun,  5 Nov 2017 07:48:24 -0800 (PST)
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] 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 CU0mz9Iosb5e for ; Sun,  5 Nov 2017 07:48:23 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 9D85A13FA91 for ; Sun,  5 Nov 2017 07:48:23 -0800 (PST)
Received: from [169.254.97.244] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA5FkOaR013729 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 5 Nov 2017 08:46:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.97.244]
From: "Paul Hoffman" 
To: doh@ietf.org
Date: Sun, 05 Nov 2017 07:48:21 -0800
Message-ID: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: [Doh] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:48:24 -0000

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

>   * Use of DoH will bypass protection mechanisms commonly used to
>     efficiently detect and prevent access to known malware-infested
>     sites.  There are two mitigation mechanisms available, but one is
>     incomplete:  deployments make use of in-path blocking methods such
>     as IP access lists.  This is partial because there is a
>     performance/memory impact in doing so, and the query itself can
>     indicate that the device itself is infected.  The other mitigation
>     here is to have a configuration mechanism to turn on/off DoH in
>     order to use the existing infrastructure.  This has the least impact
>     on surrounding infrastructure (and takes the least text ;-).


From nobody Sun Nov  5 07:49:01 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7513FB1D for ; Sun,  5 Nov 2017 07:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ToAyHJq6JKt3 for ; Sun,  5 Nov 2017 07:48:58 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 AF8B213FA91 for ; Sun,  5 Nov 2017 07:48:57 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id y83so9662985wmc.4 for ; Sun, 05 Nov 2017 07:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fp5bIyZz2fxRu7thDD5aYRD8pBfcdkl/HBG1ts82X9E=; b=rjJgdHuN+8zKfWr5FVud42iF5WXbUn31yMbXIcTsKeQDbEQqK7cTIVHg65526nm0E+ QafydgXuApg1VrATR0aZ9ivOj4s7SAY3c531c78KYhBW30RGBDzvsFrECqnvxFy75mia wKmC8j/yERZ2JfS5vacdML/4GfWnyCtTA/WrdjkBQyAYRJinw38qWOLkpuRw4TjPSmkC btyawGZ52HwTjIlSsvMEpLIX45KEr9n7V5ChTULiKTU/h5ClcOZWqkMhOGCrfacVkt7W qMEbEczxP6pxYr65ttbvkUlgXwJwXeK9DJMOsiQIxTQ74dAoMo2ENnuXaH1l2XPbFrqy AZKw==
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=Fp5bIyZz2fxRu7thDD5aYRD8pBfcdkl/HBG1ts82X9E=; b=DwLJIRf8YK40UvTKL0ULIGw/S5tEmn/g1et23M4Ijvs4mm70L62zmUEXpNfohKCJ+9 bKiQXrNKRiGOdtj8+iCmHXbDdjosqsgy1/ZwYqmJM7DzYix/AH169ba/Ebeez8M2tOc0 OTBd+riemviz5k6FcLbIkWQWvy2r0gwsICKGTyx9FdZB6leN+ICAtdB3murZDhix47LF X1Z8eC4d7A1rgPo5c74d1Uz0/Eu67w+bXl1BrxSFmA7jKoR+az77srYknbci1spmrCdB 3rPHryd5Qka7URFyYSA2WZWK/5xhmLZWieKaxvz7XT61Be/190GaDsXAFQgoUmdgfO+D FH9Q==
X-Gm-Message-State: AJaThX6nBNK0R45XDFfYZFq9cRIK9PP09xuMICpBI1LcZERonu4ez/uy jNFfdHHzprNICRIijvvbdMxh/LIfboMd41CJLKLomw==
X-Google-Smtp-Source: ABhQp+R7cXCkIhv4bvLTVSJMSP4K2LRtTdIjElYZw3tbhWxajOIImlf88HASg/lfSCB2soi6zIMwwMZBDcQgDIvGiqY=
X-Received: by 10.28.100.212 with SMTP id y203mr3492270wmb.64.1509896936083; Sun, 05 Nov 2017 07:48:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.196.169 with HTTP; Sun, 5 Nov 2017 07:48:55 -0800 (PST)
In-Reply-To: 
References:     <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com> 
From: tjw ietf 
Date: Sun, 5 Nov 2017 10:48:55 -0500
Message-ID: 
To: Paul Hoffman 
Cc: Eliot Lear , doh@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0531c085d78e055d3e468a"
Archived-At: 
Subject: Re: [Doh] operational issues with doh
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:49:00 -0000

--94eb2c0531c085d78e055d3e468a
Content-Type: text/plain; charset="UTF-8"

in the case of detect and prevent access to known malware-infested
sites, could;n't DoH deploy an RPZ like mechanism?

On Sun, Nov 5, 2017 at 10:45 AM, Paul Hoffman  wrote:

> In order to make the conversations easier to follow, I'm going to split
> these out into separate threads.
>
> --Paul Hoffman
>
> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
>
> There are several:
>>
>>   * Use of this mechanism can cause problems with split DNS, where the
>>     internal DNS is not the same as what is made available externally.
>>     Many corporate networkers hide their internal topology from the
>>     external DNS.  If an end host queries an external DNS for an
>>     internal resource, the result would be NXDOMAIN.  To avoid this, at
>>     a minimum, the browser should have some configuration as to what is
>>     internal.  I conjecture that this would reflect what is commonly
>>     found in a proxy.pac file.
>>   * When an HTTP server offers this service for domains it is not
>>     responsible for, it has the potential to impact DNS-based load
>>     balancing by masking the IP address of the sender and substituting
>>     its own.  The remedy here is that any service offering DoH should
>>     sufficiently distributed as to minimize such an impact.
>>   * Use of DoH will bypass protection mechanisms commonly used to
>>     efficiently detect and prevent access to known malware-infested
>>     sites.  There are two mitigation mechanisms available, but one is
>>     incomplete:  deployments make use of in-path blocking methods such
>>     as IP access lists.  This is partial because there is a
>>     performance/memory impact in doing so, and the query itself can
>>     indicate that the device itself is infected.  The other mitigation
>>     here is to have a configuration mechanism to turn on/off DoH in
>>     order to use the existing infrastructure.  This has the least impact
>>     on surrounding infrastructure (and takes the least text ;-).
>>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

--94eb2c0531c085d78e055d3e468a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


in the case of=C2=A0detect and prevent access to known malware-infested sites,=C2=A0co=
uld;n't DoH deploy an RPZ like mechanism?

On Sun, Nov 5, 2017 at 10:45 AM, P=
aul Hoffman <paul.hoffman@vpnc.org> wrote:
In order to make the conversations easier to follow, I=
'm going to split these out into separate threads.



--Paul Hoffman



On 5 Nov 2017, at 0:30, Eliot Lear wrote:





There are several:



=C2=A0 * Use of this mechanism can cause problems with split DNS, where the=


=C2=A0 =C2=A0 internal DNS is not the same as what is made available extern=
ally.=C2=A0

=C2=A0 =C2=A0 Many corporate networkers hide their internal topology from t=
he

=C2=A0 =C2=A0 external DNS.=C2=A0 If an end host queries an external DNS fo=
r an

=C2=A0 =C2=A0 internal resource, the result would be NXDOMAIN.=C2=A0 To avo=
id this, at

=C2=A0 =C2=A0 a minimum, the browser should have some configuration as to w=
hat is

=C2=A0 =C2=A0 internal.=C2=A0 I conjecture that this would reflect what is =
commonly

=C2=A0 =C2=A0 found in a proxy.pac file.

=C2=A0 * When an HTTP server offers this service for domains it is not

=C2=A0 =C2=A0 responsible for, it has the potential to impact DNS-based loa=
d

=C2=A0 =C2=A0 balancing by masking the IP address of the sender and substit=
uting

=C2=A0 =C2=A0 its own.=C2=A0 The remedy here is that any service offering D=
oH should

=C2=A0 =C2=A0 sufficiently distributed as to minimize such an impact.

=C2=A0 * Use of DoH will bypass protection mechanisms commonly used to

=C2=A0 =C2=A0 efficiently detect and prevent access to known malware-infest=
ed

=C2=A0 =C2=A0 sites.=C2=A0 There are two mitigation mechanisms available, b=
ut one is

=C2=A0 =C2=A0 incomplete:=C2=A0 deployments make use of in-path blocking me=
thods such

=C2=A0 =C2=A0 as IP access lists.=C2=A0 This is partial because there is a<=
br>
=C2=A0 =C2=A0 performance/memory impact in doing so, and the query itself c=
an

=C2=A0 =C2=A0 indicate that the device itself is infected.=C2=A0 The other =
mitigation

=C2=A0 =C2=A0 here is to have a configuration mechanism to turn on/off DoH =
in

=C2=A0 =C2=A0 order to use the existing infrastructure.=C2=A0 This has the =
least impact

=C2=A0 =C2=A0 on surrounding infrastructure (and takes the least text ;-).<=
br>




_______________________________________________

Doh mailing list

Doh@ietf.org

https://www.ietf.org/mailman/listinfo/doh





--94eb2c0531c085d78e055d3e468a--


From nobody Sun Nov  5 07:57:53 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0613FBB2 for ; Sun,  5 Nov 2017 07:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GvNF-D52DUZZ for ; Sun,  5 Nov 2017 07:57:50 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF03713FBB1 for ; Sun,  5 Nov 2017 07:57:49 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Nov 2017 07:57:47 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 5 Nov 2017 07:57:47 -0800
From: Paul Hoffman 
To: "doh@ietf.org" 
Thread-Topic: [Ext] [Doh] DOH bypassing protection mechanisms
Thread-Index: AQHTVk2G6fE5avEYsUuvAF4TGD9ExaMGdyUA
Date: Sun, 5 Nov 2017 15:57:46 +0000
Message-ID: <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org>
In-Reply-To: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5C4BBFBD1B08CA43B50C6E6BEA3616B3@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] [Ext]  DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 15:57:51 -0000

> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
>
>>   * Use of DoH will bypass protection mechanisms commonly used to
>>     efficiently detect and prevent access to known malware-infested
>>     sites.  There are two mitigation mechanisms available, but one is
>>     incomplete:  deployments make use of in-path blocking methods such
>>     as IP access lists.  This is partial because there is a
>>     performance/memory impact in doing so, and the query itself can
>>     indicate that the device itself is infected.  The other mitigation
>>     here is to have a configuration mechanism to turn on/off DoH in
>>     order to use the existing infrastructure.  This has the least impact
>>     on surrounding infrastructure (and takes the least text ;-).

On 5 Nov 2017, at 7:48, tjw ietf wrote:

> in the case of detect and prevent access to known malware-infested
> sites, could;n't DoH deploy an RPZ like mechanism?
>

Yes. A DOH server is just like any DNS recursive resolver that a user might=
 choose (such as from DHCP). It could use RPZ, it could offer anti-malware,=
 it could be be malicious itself, ...

As to Eliot's main question: The policy to choose a DOH server is similar t=
o the policy to choose a DNS resolver, it's just done in a different applic=
ation. For the latter, the typical is "trust whatever DHCP tells you", but =
there are also commonly policies of "ignore DHCP, always use one of these".=
 Both those policies could be mirrored in a browser for DOH.

--Paul Hoffman=


From nobody Sun Nov  5 08:29:33 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183F013FC80 for ; Sun,  5 Nov 2017 08:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1tK18Ejr837G for ; Sun,  5 Nov 2017 08:29:30 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D25513F6BC for ; Sun,  5 Nov 2017 08:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1509899370; x=1511108970; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=f+UWN8HKfpULO9aE2j5yUWyHS+aMiGGAXuKmfAwzSJI=; b=aDorG5BmhKqaC3ALlzdFh0CDQ3gkTOZaqr+MuSy9S6PmjLGWhSP/jg1u yfynqWUxtchGF1jl6MifBdtmXmBy1rNekrSYiB4iYn549GZ8R485D3XSe jAuIULbgXfqOLl4gUMnHGIUyn0XhbGlfwMU3PdDt6bi4MThUMOiqNkYnA M=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQAXO/9Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIsTkCGWRoIRBwOFOwKFGBYBAQEBAQEBAQFrKIUfAQUjZgs?= =?us-ascii?q?YKgICVwYBDAgBAYofqXKCJ4sDAQEBAQEBBAEBAQEBAQESD4MuhWyDAYR7gyuCY?= =?us-ascii?q?gWiDoRCgiOOF4F8iXyHPJYWgTkmCCmBbDQhCB0Vgy6EX0CMKgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,348,1505779200"; d="asc'?scan'208";a="80680"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2017 16:29:28 +0000
Received: from [10.61.199.115] ([10.61.199.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA5GTRvZ012825; Sun, 5 Nov 2017 16:29:28 GMT
To: Paul Hoffman , "doh@ietf.org" 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
From: Eliot Lear 
Message-ID: <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
Date: Sun, 5 Nov 2017 17:29:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bMH5GoWk9rBhVhfBoH30joXNmc9twtNkn"
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 16:29:32 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bMH5GoWk9rBhVhfBoH30joXNmc9twtNkn
Content-Type: multipart/mixed; boundary="vgb4UWWjghRmBv4q0FA7e0BnfCBLqhRdL";
 protected-headers="v1"
From: Eliot Lear 
To: Paul Hoffman , "doh@ietf.org" 
Message-ID: <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org>
 <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
In-Reply-To: <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>

--vgb4UWWjghRmBv4q0FA7e0BnfCBLqhRdL
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 11/5/17 4:57 PM, Paul Hoffman wrote:
> As to Eliot's main question: The policy to choose a DOH server is simil=
ar to the policy to choose a DNS resolver, it's just done in a different =
application. For the latter, the typical is "trust whatever DHCP tells yo=
u", but there are also commonly policies of "ignore DHCP, always use one =
of these". Both those policies could be mirrored in a browser for DOH.
>

That's the theory.=C2=A0 In reality, for the enterprise, you would be har=
d
pressed to find examples in which the enterprise itself doesn't control
where a query goes on a client (DHCP is not the only control function).

Eliot



--vgb4UWWjghRmBv4q0FA7e0BnfCBLqhRdL--

--bMH5GoWk9rBhVhfBoH30joXNmc9twtNkn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ/zxeAAoJEIe2a0bZ0nozzzAIAL6oLiGLQPBkU4B69N7wrqkM
rhE0kQqOcBmnUjbgmDhq0MQ3MDPGHyWLi+i9PgAkXOE6G52hTxVT/Ld2ST7YQX1X
N0qhyip1F5nXOqNOlVJz7354mAFwc89P3TNuCBxpCYrF+UVJFSHVGqEmRjqtlRyj
L/glDg686pBVUJp7dr+GZKT2YDay+6js4nTiL8/FiG6pFJq/g1zV5Mh6OornVbTt
m9ZX+5RXQlcRgYIDjsFimyV8yjhgzr/egvS+MY9GSDy7CEiDtoJZylsWFK/Kp7ZI
YyIGeTmiN4Qlmr4ujJM7gnCnnsbdGepuw5e0wg6SdJwEOPQa8B0IAD9zQrOoPY8=
=5Ej9
-----END PGP SIGNATURE-----

--bMH5GoWk9rBhVhfBoH30joXNmc9twtNkn--


From nobody Sun Nov  5 11:31:19 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7875E13FCDC for ; Sun,  5 Nov 2017 11:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 C4FwGKjEYbQa for ; Sun,  5 Nov 2017 11:31:16 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE913FCDB for ; Sun,  5 Nov 2017 11:31:16 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Nov 2017 11:31:14 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 5 Nov 2017 11:31:14 -0800
From: Paul Hoffman 
To: Eliot Lear 
CC: "doh@ietf.org" 
Thread-Topic: [Doh] [Ext] DOH bypassing protection mechanisms
Thread-Index: AQHTVlNGGJz6sewrrE6MDSqtCTxTIaMGsr2A
Date: Sun, 5 Nov 2017 19:31:14 +0000
Message-ID: 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
In-Reply-To: <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_8CC080E7-8D43-49D6-8747-FA2A6442A70F"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 19:31:17 -0000

--Apple-Mail=_8CC080E7-8D43-49D6-8747-FA2A6442A70F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 5, 2017, at 8:29 AM, Eliot Lear  wrote:
> On 11/5/17 4:57 PM, Paul Hoffman wrote:
>> As to Eliot's main question: The policy to choose a DOH server is =
similar to the policy to choose a DNS resolver, it's just done in a =
different application. For the latter, the typical is "trust whatever =
DHCP tells you", but there are also commonly policies of "ignore DHCP, =
always use one of these". Both those policies could be mirrored in a =
browser for DOH.
>>=20
>=20
> That's the theory.  In reality, for the enterprise, you would be hard
> pressed to find examples in which the enterprise itself doesn't =
control
> where a query goes on a client (DHCP is not the only control =
function).

It sounds like the operational document might say something like "an =
enterprise that cares about which DNS resolver its users access needs to =
also make that policy in DOH-enabled web clients".

--Paul Hoffman

--Apple-Mail=_8CC080E7-8D43-49D6-8747-FA2A6442A70F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAln/ZwEACgkQsZnCoeEP
RXt2hwgAqWUViOPxqWxvAq4w3F5u7UjqT4VGmgh8UcYJ6Fp075fDlaigZT/+DQ3S
rUCcUAGHf3fl+pfeUWYL7ATTGFpBc7LWpWAnNw5KNcxYPzZiuHM1L4B/6cOcofDZ
ejfgyfZG+86lDBPYtR/m6eS0RFByKG2gP0ftyGGVcQVIxoliqk9qVibiFggPkfRk
kfKdJ2i+RJK7Bo/brNmP00EPNQ7BwaFblF1Xd8IR6WZV9E3AgBagD/6uhHrhTzg+
/oZmDW0FURo/VqA0vltROjJSPBj8sFvFIYFdJd9iZeQ2zJnwA04JeNueBHhpaiJH
THeZOl/Zf6HqoSO6b3nK3FOpPxSzhQ==
=bTQ5
-----END PGP SIGNATURE-----

--Apple-Mail=_8CC080E7-8D43-49D6-8747-FA2A6442A70F--


From nobody Sun Nov  5 11:49:12 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FDF13FCDA for ; Sun,  5 Nov 2017 11:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 28xggxanz-1B for ; Sun,  5 Nov 2017 11:49:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A2CBC13FB72 for ; Sun,  5 Nov 2017 11:49:10 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA5JmhkE062588 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 5 Nov 2017 13:48:45 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Paul Hoffman , Eliot Lear 
Cc: "doh@ietf.org" 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com> 
From: Adam Roach 
Message-ID: <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com>
Date: Sun, 5 Nov 2017 13:48:38 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 19:49:11 -0000

[as an individual]

On 11/5/17 1:31 PM, Paul Hoffman wrote:
> On Nov 5, 2017, at 8:29 AM, Eliot Lear  wrote:
>> On 11/5/17 4:57 PM, Paul Hoffman wrote:
>>> As to Eliot's main question: The policy to choose a DOH server is similar to the policy to choose a DNS resolver, it's just done in a different application. For the latter, the typical is "trust whatever DHCP tells you", but there are also commonly policies of "ignore DHCP, always use one of these". Both those policies could be mirrored in a browser for DOH.
>>>
>> That's the theory.  In reality, for the enterprise, you would be hard
>> pressed to find examples in which the enterprise itself doesn't control
>> where a query goes on a client (DHCP is not the only control function).
> It sounds like the operational document might say something like "an enterprise that cares about which DNS resolver its users access needs to also make that policy in DOH-enabled web clients".

s/web clients/DNS clients/, right? I don't get the impression that the 
use cases are intended to be restricted to web browsers as clients.

/a


From nobody Sun Nov  5 11:58:49 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A422713FCE5 for ; Sun,  5 Nov 2017 11:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fgRUS_C1Qyh1 for ; Sun,  5 Nov 2017 11:58:46 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809B713FB72 for ; Sun,  5 Nov 2017 11:58:46 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Nov 2017 11:58:44 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 5 Nov 2017 11:58:44 -0800
From: Paul Hoffman 
To: Adam Roach 
CC: "doh@ietf.org" 
Thread-Topic: [Doh] [Ext] DOH bypassing protection mechanisms
Thread-Index: AQHTVlNGGJz6sewrrE6MDSqtCTxTIaMGsr2AgAAE3gCAAALRgA==
Date: Sun, 5 Nov 2017 19:58:44 +0000
Message-ID: 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>  <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com>
In-Reply-To: <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 19:58:48 -0000

On Nov 5, 2017, at 11:48 AM, Adam Roach  wrote:
>=20
> [as an individual]
>=20
> On 11/5/17 1:31 PM, Paul Hoffman wrote:
>> On Nov 5, 2017, at 8:29 AM, Eliot Lear  wrote:
>>> On 11/5/17 4:57 PM, Paul Hoffman wrote:
>>>> As to Eliot's main question: The policy to choose a DOH server is simi=
lar to the policy to choose a DNS resolver, it's just done in a different a=
pplication. For the latter, the typical is "trust whatever DHCP tells you",=
 but there are also commonly policies of "ignore DHCP, always use one of th=
ese". Both those policies could be mirrored in a browser for DOH.
>>>>=20
>>> That's the theory.  In reality, for the enterprise, you would be hard
>>> pressed to find examples in which the enterprise itself doesn't control
>>> where a query goes on a client (DHCP is not the only control function).
>> It sounds like the operational document might say something like "an ent=
erprise that cares about which DNS resolver its users access needs to also =
make that policy in DOH-enabled web clients".
>=20
> s/web clients/DNS clients/, right?

Maybe?

> I don't get the impression that the use cases are intended to be restrict=
ed to web browsers as clients.

They are not restricted to web clients (I was careful not to say "browsers"=
), but I don't expect current DNS clients to add DOH capabilities any time =
in the near future. We have had approximately zero success in getting stub =
resolvers deployed with DNS-over-TLS (RFC 7858), and getting them to do tha=
t would be easier than DNS-encoded-in-HTTP-over-TLS. DNS clients are a use =
case listed in Section 3 of the draft, but not one that we've heard much in=
terest in.

--Paul Hoffman=


From nobody Sun Nov  5 16:13:28 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCC13FB05 for ; Sun,  5 Nov 2017 16:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=bEhQADgI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UAuHW9Gy
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 HGNYHh7Jg-w4 for ; Sun,  5 Nov 2017 16:13:24 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456FE13FBC5 for ; Sun,  5 Nov 2017 16:13:24 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6885A20AFF; Sun,  5 Nov 2017 19:13:23 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 05 Nov 2017 19:13:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=yK52Hqc7pmnhECIGNwKe2yDaVp7Nw ADyzCOJt1hkBek=; b=bEhQADgIPgOswJBn5mtt2Gm87cDZN3duV5v1PaqA3RQPb T4bf2PTcr3urtgX9aEx9fxzLx44aROJ33KIy+FQrgdPYFVG9+ps87TTTsqNQNyv5 zOcEcPtSbIWoqgklbBI+66Kg/rMyYxj8ZNzxJeM4uiNFKSCTWpiWLPveXNqG0FPD LoHnEWMgKt49kPS7fnh+iMwlzjOnhfyPRRr1V2zO3gEcjUfUtuW8zMvt8Y/DuKmL Pm9iJsBr6sgW95GIndB5vUCGnCQtJRMw/40kCPCSkspoN4ouFgRtr6U3AlPafQvq 7oNGB6Us/p8EUcbB9nZg6cw0EeTW6d2GlwTSf0IAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yK52Hq c7pmnhECIGNwKe2yDaVp7NwADyzCOJt1hkBek=; b=UAuHW9Gy1X9AIuRRVllQ6V oA2CqLxeHPR/8sfRZtVhXDGDzB7H9vQz0GRrujPJ4ouO5wqYfSuMU+1C6lK+Kglr EE8UHlYUF0RkuCn7uezZsEX3wPD5/B//EE3KDcILCVjp/knKgPzeRYerqRHS1Eu9 BWfrUrveXnJR0VAiK0OGsshlI8a/6qisVkLKGHqPMNl4ThpZybsnf4zBfMmxQzr7 IxIEOZ8XQdvFF7sJwdc4adMAM0msWnA0bmGPe3REurLf8zh6bjhLB6YdpEIqvJV3 rzB8weggJZTZDzR5i3TpIJdprxn/ZmPVh6G2Uk4XHxhrcFQjMqqZ2bV+smssoW+g ==
X-ME-Sender: 
Received: from frankexeofviews.lan (dtf2586697.lnk.telstra.net [149.135.121.88]) by mail.messagingengine.com (Postfix) with ESMTPA id 590B1240B2; Sun,  5 Nov 2017 19:13:22 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 6 Nov 2017 11:13:19 +1100
Cc: doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net>
References: 
To: Paul Hoffman 
X-Mailer: Apple Mail (2.3445.1.6)
Archived-At: 
Subject: Re: [Doh] DOH and split DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 00:13:27 -0000

If the user takes a positive step to configure a DOH server (e.g., in =
their browser), this is directly analogous to manually configuring an =
alternative DNS server -- except that the network can try to take active =
measures to block other DNS servers, and that's more difficult with DOH.

Regardless of that, once the user has done something to the =
configuration, it's reasonable to say that they've taken responsibility =
for the consequences of that action -- including the sudden =
disappearance of "internal" resources. Some careful wording around the =
configuration mechanism should help.

Allowing something like proxy.pac to override DOH doesn't make any =
sense, given that the primary purpose of DOH is to NOT allow the local =
network to impose policy on communication with the DNS server.

Cheers,


> On 6 Nov 2017, at 2:46 am, Paul Hoffman  wrote:
>=20
> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
>=20
>>  * Use of this mechanism can cause problems with split DNS, where the
>>    internal DNS is not the same as what is made available externally.=20=

>>    Many corporate networkers hide their internal topology from the
>>    external DNS.  If an end host queries an external DNS for an
>>    internal resource, the result would be NXDOMAIN.  To avoid this, =
at
>>    a minimum, the browser should have some configuration as to what =
is
>>    internal.  I conjecture that this would reflect what is commonly
>>    found in a proxy.pac file.
>=20
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham   https://www.mnot.net/



From nobody Sun Nov  5 16:16:05 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2C113FB05 for ; Sun,  5 Nov 2017 16:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=qRJhTowx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lEvZLEfY
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 np8hs05Qrrhs for ; Sun,  5 Nov 2017 16:16:01 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA2B13F979 for ; Sun,  5 Nov 2017 16:16:01 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 08A65205E1; Sun,  5 Nov 2017 19:16:01 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 05 Nov 2017 19:16:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=M/fnXvYfPuiCcMIVJICcf2VIXrdKN VPY73DaAwgAk+s=; b=qRJhTowxOFbsOrectk47IMMg4YM7A69XQFI1sqDgeE4xV sLA2hHuCZgH2UdRt+52RzsSJViPPipUme0ki6KfOxhDK7szmxrRKNhifGCL1BhvO +Kk8hAbcCPdw4KNFkyABc1P7ZPa9qJKeZ0vsRnjtnhjUlguRXROBhh5xSBlSPG/8 7wTcDY9RoUwv76JBwV4Cw82557KwFOVtRYt/5ht6bPPvsL85Ln1vG2+XRmdcm6AH wybP7OQXRbvFkUgMaOKHux1oKAi43GXsA+R8udcLwUztj/UjmSrOCmbDoFfnn5y8 kNlanxg1/HoVHToyb+4GmLG00qDje+aJBs09PfhTw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=M/fnXv YfPuiCcMIVJICcf2VIXrdKNVPY73DaAwgAk+s=; b=lEvZLEfYhWgfZqCJsVl5xG vJksZXdGHq9YqF++SyOq45cVEzdVCiKVLqFLZKUmgeLINAuHz1VgZJSu3uc27Y5w EiOsTSWedHzIoc/+w+LOM+BZlq9iWXZ0kGL0c4i+Tna4D49d5geNoRPoAl4rUSBk DrIcTBc69bnzM50lJeSogruNYBCP3B90wK+eox1j4xemcE+Zlo14eDjSHhZfdDr6 1wz1gDIOkoCOBcJvFGv+Dgje40x8+d00JbG91RT3+J+RLmA8kjKvVtCkUaj5SSQu iWGh88CIj9xL3MDg+5psTVGtoipIE6jAxfAj2YjD9PkO7jdIufE6OQpjuARBf7Sg ==
X-ME-Sender: 
Received: from frankexeofviews.lan (dtf2586697.lnk.telstra.net [149.135.121.88]) by mail.messagingengine.com (Postfix) with ESMTPA id E55A2248BA; Sun,  5 Nov 2017 19:15:59 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: Mark Nottingham 
In-Reply-To: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
Date: Mon, 6 Nov 2017 11:15:56 +1100
Cc: doh@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
To: Paul Hoffman 
X-Mailer: Apple Mail (2.3445.1.6)
Archived-At: 
Subject: Re: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 00:16:03 -0000

I'd think the remedy here would be RFC7871 (EDNS client subnet) support.

Cheers,


> On 6 Nov 2017, at 2:47 am, Paul Hoffman  wrote:
> 
> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
> 
>>  * When an HTTP server offers this service for domains it is not
>>    responsible for, it has the potential to impact DNS-based load
>>    balancing by masking the IP address of the sender and substituting
>>    its own.  The remedy here is that any service offering DoH should
>>    sufficiently distributed as to minimize such an impact.
> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham   https://www.mnot.net/



From nobody Sun Nov  5 16:21:55 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919CC13FD18 for ; Sun,  5 Nov 2017 16:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nY3OwrjW0B_p for ; Sun,  5 Nov 2017 16:21:53 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9096713FD17 for ; Sun,  5 Nov 2017 16:21:53 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 5 Nov 2017 16:21:51 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 5 Nov 2017 16:21:51 -0800
From: Paul Hoffman 
To: "doh@ietf.org" 
CC: Mark Nottingham , Eliot Lear 
Thread-Topic: [Ext] [Doh] Servers offering responses for domaines they are not responsible for
Thread-Index: AQHTVpU9Uh7uOA3OSEGfsyhA7xhVRA==
Date: Mon, 6 Nov 2017 00:21:51 +0000
Message-ID: <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] [Ext] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 00:21:54 -0000

On Nov 5, 2017, at 4:15 PM, Mark Nottingham  wrote:
>=20
> I'd think the remedy here would be RFC7871 (EDNS client subnet) support.
>=20
>> On 5 Nov 2017, at 0:30, Eliot Lear wrote:
>>=20
>>> * When an HTTP server offers this service for domains it is not
>>>   responsible for, it has the potential to impact DNS-based load
>>>   balancing by masking the IP address of the sender and substituting
>>>   its own.  The remedy here is that any service offering DoH should
>>>   sufficiently distributed as to minimize such an impact.

Client Subnet is fairly controversial in the DNS world due to privacy reaso=
ns.

In fact, I don't understand Eliot's concern here. DNS recursive resolvers (=
which is what a DOH server would be fronting for) are not "responsible for =
domains". Authoritative servers are responsible for domains.

Eliot: can you say more about your concern here?

--Paul Hoffman=


From nobody Sun Nov  5 20:57:48 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB49313FAFE for ; Sun,  5 Nov 2017 20:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MaEmIK7zK8xa for ; Sun,  5 Nov 2017 20:57:46 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C30613FAFB for ; Sun,  5 Nov 2017 20:57:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2684; q=dns/txt; s=iport; t=1509944266; x=1511153866; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ugJZU+xUcfrPeWcaMy0eUiCP8VG3FUjWzvk9rko9SNs=; b=lMmcUchZ1dmkjLfkYd12vlIH74CxX70FaC2Wzq0p4J34391KzEcoEeEx shYMFvd/pLESn6OtmpXxx6e8YRxpJMvO7567LDSUjcHOWHwoN8sOnTNrK CZpgsFIBbWQL050utac9QDPuhsQ8GoZbsKrfNkyLSWeDou6bUh76x5xDe 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQDa6v9Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIsTj3smmFcHA4U7AoUZFQEBAQEBAQEBAWsohR8BBAEjVgU?= =?us-ascii?q?LC0ICAlcGAQwIAQGKFwiqIYIniwYBAQEBAQEBAQEBAQEBAQEBAQERD4MuhWwLg?= =?us-ascii?q?naEe4MrgmIFog6EQoIjjhcCi3aHPJYWgTk1IoFsNCEIHRWDLoMQgU9AjRgBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,351,1505779200"; d="asc'?scan'208";a="42004"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 04:57:44 +0000
Received: from [10.61.224.245] ([10.61.224.245]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA64vhqC027195; Mon, 6 Nov 2017 04:57:43 GMT
To: Paul Hoffman , "doh@ietf.org" 
Cc: Mark Nottingham 
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>  <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>
From: Eliot Lear 
Message-ID: <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
Date: Mon, 6 Nov 2017 05:57:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2T134KpqloUdSKwiMm8lNsVRUSiUnJGL3"
Archived-At: 
Subject: Re: [Doh] [Ext] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 04:57:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--2T134KpqloUdSKwiMm8lNsVRUSiUnJGL3
Content-Type: multipart/mixed; boundary="KKxAwxJRTNjShFQh559fj0LLMVQfjDtcH";
 protected-headers="v1"
From: Eliot Lear 
To: Paul Hoffman , "doh@ietf.org" 
Cc: Mark Nottingham 
Message-ID: <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
Subject: Re: [Ext] [Doh] Servers offering responses for domaines they are not
 responsible for
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
 
 <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>
In-Reply-To: <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>

--KKxAwxJRTNjShFQh559fj0LLMVQfjDtcH
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Paul,

> In fact, I don't understand Eliot's concern here. DNS recursive resolve=
rs (which is what a DOH server would be fronting for) are not "responsibl=
e for domains". Authoritative servers are responsible for domains.
>
> Eliot: can you say more about your concern here?

Sure.=C2=A0 DNS-based load balancing mechanisms assume that the source of=
 a
query is going to be proximate to the originator.=C2=A0 Use of DoH may up=
set
that assumption.=C2=A0 In the extreme case, imagine having just one DoH
caching resolver out there, and all queries flowing to it, from anywhere
in the world.=C2=A0 Especially if it is caching, any number of queries wo=
uld
end up returning addresses that are local to that one DoH server and not
to the originator.

I mentioned authority here only in as much as I don't care what a DoH
server does for services that are related to it, but if they are not,
and if it really is just acting as a caching resolver, then this issue
comes into play.

Eliot


--KKxAwxJRTNjShFQh559fj0LLMVQfjDtcH--

--2T134KpqloUdSKwiMm8lNsVRUSiUnJGL3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ/+u/AAoJEIe2a0bZ0nozi6UH/1cmRtNyuKS/cbiftZ3jcwYu
sIHbQgf6PQU9SDFv4aCmWK6WYY2fEQCo3Mc+S1A9VqfKVL9TCMe1+X9OMV+2282X
35d5kGCB8N/t1sRn8c+ChriJ6iN+hRsiWaorAa4PyOsO/mwVtBywgw2ZL7yUDG1h
cMawwaL7Fm8VcQMShhs9jf9u0crEfHe+GMIfG1dPjCXXcjr0CNPyizourbGeC6uC
jNfsBHa3iNeNF/rDKzwbgqB+VmKP95K7+qmTt7cNusr6pY3NKP1BomUr1UXscNrp
tWGc1j2KjfE5CFhuB/rkVeecG3qDX1vRrN8aUKTPRTQIpEL7KOpnOQ9SUSr4Y6k=
=3rTh
-----END PGP SIGNATURE-----

--2T134KpqloUdSKwiMm8lNsVRUSiUnJGL3--


From nobody Sun Nov  5 21:12:26 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371A513FB01 for ; Sun,  5 Nov 2017 21:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DxE30eRLew3I for ; Sun,  5 Nov 2017 21:12:24 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C910A13FAFE for ; Sun,  5 Nov 2017 21:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2423; q=dns/txt; s=iport; t=1509945144; x=1511154744; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=gFre3CbRqL2qs0hIvH5s92CN4lN2bGaBmat3oPjgbzA=; b=RzPVBUYr9/Nwl5e8MTp6+QxaZi5Fg/5pkV5EelagRKGZVqkJY/xrbJjd E4huhKuFQO0tp9NA/ylxHPgr9B7hJD0iLOsvjJwQDFzqJZFgEqGNWAuXH +/PH8r/1isO7ec+sC7TuvL2dHfwSH+lCqHead91Ozh30G6BCJ9cL2ajRa A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACM7v9Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuhCSKH3SPeyaWRoIRBwOFOwKFFhgBAQEBAQEBAQFrKIUfAQU?= =?us-ascii?q?jVhALGCoCAlcGAQwIAQGKH6odgieLBgEBAQEBAQEBAQEBAQEBAQEBAREPgy6Fb?= =?us-ascii?q?AuCdogmgmIFog6EQoIjjheBfIl8hzyWFoE5HziBbDQhCB0Vgy6EX0CNGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,351,1505779200"; d="asc'?scan'208";a="42168"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 05:12:22 +0000
Received: from [10.61.224.245] ([10.61.224.245]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA65CLlQ030457; Mon, 6 Nov 2017 05:12:21 GMT
To: Paul Hoffman , Adam Roach 
Cc: "doh@ietf.org" 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>  <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com> 
From: Eliot Lear 
Message-ID: <29fcdcc6-2644-6014-fc05-04289f4f2ea3@cisco.com>
Date: Mon, 6 Nov 2017 06:12:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b9cKKL3suhNa6LTRCgIjSDpSqwQOePLSo"
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 05:12:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--b9cKKL3suhNa6LTRCgIjSDpSqwQOePLSo
Content-Type: multipart/mixed; boundary="XqiR9ef7eXXXIkOIBrPJPCH9tbIaGQtaG";
 protected-headers="v1"
From: Eliot Lear 
To: Paul Hoffman , Adam Roach 
Cc: "doh@ietf.org" 
Message-ID: <29fcdcc6-2644-6014-fc05-04289f4f2ea3@cisco.com>
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org>
 <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
 <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
 
 <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com>
 
In-Reply-To: 

--XqiR9ef7eXXXIkOIBrPJPCH9tbIaGQtaG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US


On 11/5/17 8:58 PM, Paul Hoffman wrote:
>
> They are not restricted to web clients (I was careful not to say "brows=
ers"), but I don't expect current DNS clients to add DOH capabilities any=
 time in the near future. We have had approximately zero success in getti=
ng stub resolvers deployed with DNS-over-TLS (RFC 7858), and getting them=
 to do that would be easier than DNS-encoded-in-HTTP-over-TLS. DNS client=
s are a use case listed in Section 3 of the draft, but not one that we've=
 heard much interest in.
>

Indeed.=C2=A0 That is why I suggested some practical approaches that do
consider browsers.

Eliot


--XqiR9ef7eXXXIkOIBrPJPCH9tbIaGQtaG--

--b9cKKL3suhNa6LTRCgIjSDpSqwQOePLSo
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ/+8sAAoJEIe2a0bZ0nozagcIAJF7ywrGjT6kcKLZluUDUEy/
kcJY2cHOdKggbKoUNQ4AckSfFiqhKtHZ6ipkBnJhSn5s9QbFmujV9XsZr7E9qCFk
bmWeS4cMwyE5HeOtGLg09Ppw4iAZp5RyBSN74y2UFFiFTyY1yPAVfTv0KDgAb1mA
7SzKIWyZ/GuS+KSuk8Wm1J5j7HnGB3KMUm6GlptZAgNiBr6bOuiJnt5rBe0orvfE
BAXPK48mBEDXJeH51bf6S4QFG0C4nC1vV8R8FMdH6HoEA8szBetxpRyTGKnLXYcc
WuSeE3dSNAuKnZugv0OiD6i1rFzn8jSB7ezWwUeHBsw+Oyqo5pFRVkQ11bitTQA=
=MpTk
-----END PGP SIGNATURE-----

--b9cKKL3suhNa6LTRCgIjSDpSqwQOePLSo--


From nobody Sun Nov  5 21:18:50 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27113FB78 for ; Sun,  5 Nov 2017 21:18:48 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8XYT8so-JTu7 for ; Sun,  5 Nov 2017 21:18:46 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B12D713FB0B for ; Sun,  5 Nov 2017 21:18:46 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id q4so6220867oic.7 for ; Sun, 05 Nov 2017 21:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aqJXSevCZXvhlqw0DQTj8pSKUQen/FP7/Y/d2hRaXpk=; b=cA685ThD2TSrBGyPMn/EgMyl2FogeIUe8yI40gColRyIz6v3Jcllg2SIhEQbf39Gmf ZQKWKAj7k6BIfjmVrE47rp45SWIPH0IbhSgmHL9ZQtYbMPazIw6tccKAOJjLbshupO/W x2Gr4Ys/9lO+iybNMHLzYQgMbcRyXFti8xb7LmaSKWEMV3D8xcOOOeZ2tM8oKT3l96JD djNcJW/qa+ISA87qIoyoTHttPPKoW9aZqXLm2tvtMYtp+DZsUS/NsaYSQYW8aTB02tFB tcgzwGBVPeY03f63ufhASDtp9WJTmjtaFkpAFthU6ygEQJHYjwb4ldhzzJlTqASx9bGy AJgA==
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=aqJXSevCZXvhlqw0DQTj8pSKUQen/FP7/Y/d2hRaXpk=; b=qRwKiG0f0RKrId0XTxmev4AvyWz0auXAf09wRpcBBVkwntDMOrXlrZ4eHlpr/+VRqG Jnzuh462FmqmWHj6ZEfBAaqMOWBptnQFXHuRoBhJrBiWgmiIKrztaDmFcBykhoyPse+W TW9Dm8S1SOV/KThPbkwG+E/YoDgdzRlTrgD3ahGlhCK8p/BshzdlvHjqYhBWucLL7MxI 5XCFFeSLo9c4Tm3O428HVkq//nb9vIwvc+9hJ2peEph60iPkBiFrr2HTXI8OLyfCzpQQ 6khtPEVSuLmhhedA659AVekF6NcXmbGf2uMJxPgWgS6oI360ZgQhSFvoHr8d4zf5qpyV dqkw==
X-Gm-Message-State: AMCzsaVHamOicE1dLb8i49QEBQUPv1I4CCpJJkWq3cb5IjZms2qdG1t3 fqXJK7Y/zO8ozkbA477IqRcnUUNu8nZdI3SeCwk=
X-Google-Smtp-Source: ABhQp+RugMzavL1zoEmBoQKwTdMucROjpFHzRaf/NLIR0hgUAh/N8c/gtbMQg/CsER/MClIcZaUKWxfG1UzMMMFmTvU=
X-Received: by 10.202.75.140 with SMTP id y134mr7609504oia.3.1509945525986; Sun, 05 Nov 2017 21:18:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.15.155 with HTTP; Sun, 5 Nov 2017 21:18:45 -0800 (PST)
In-Reply-To: <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>  <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org> <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
From: Martin Thomson 
Date: Mon, 6 Nov 2017 16:18:45 +1100
Message-ID: 
To: Eliot Lear 
Cc: Paul Hoffman , "doh@ietf.org" ,  Mark Nottingham 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [Doh] [Ext] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 05:18:48 -0000

Eliot, are you assuming that the DNS client will be looking at
responses from origins other than the one it has configured as a DOH
server?

That is, say that https://example.net is configured (or just
example.net), but if I talk to https://somesite.example and it
provides what is an otherwise valid DOH response, are you assuming
that this response is used?

Generally speaking, even if the DNS client shared a cache with a web
browser, this wouldn't happen without the DNS client taking special
steps to enable it, so I'm not sure why you would be specially
concerned about this.

Of course, I would still be supportive of text that made it clear that
this particular model is not in scope.

I don't want to categorically rule this possibility out forever.  For
instance, we might be able to convince ourselves that
https://somesite.example can be trusted to speak for itself.  But I
agree that anything that differs from the accepted model would be
difficult to get right for more than just this reason.

FWIW, I think that the notion that we use HTTP caching ultimately
enables better operational stories here, not worse.  Tighter control
over caching might avoid certain performance problems.  See for
example the stale-while-revalidate option previously mentioned .

On Mon, Nov 6, 2017 at 3:57 PM, Eliot Lear  wrote:
> Hi Paul,
>
>> In fact, I don't understand Eliot's concern here. DNS recursive resolvers (which is what a DOH server would be fronting for) are not "responsible for domains". Authoritative servers are responsible for domains.
>>
>> Eliot: can you say more about your concern here?
>
> Sure.  DNS-based load balancing mechanisms assume that the source of a
> query is going to be proximate to the originator.  Use of DoH may upset
> that assumption.  In the extreme case, imagine having just one DoH
> caching resolver out there, and all queries flowing to it, from anywhere
> in the world.  Especially if it is caching, any number of queries would
> end up returning addresses that are local to that one DoH server and not
> to the originator.
>
> I mentioned authority here only in as much as I don't care what a DoH
> server does for services that are related to it, but if they are not,
> and if it really is just acting as a caching resolver, then this issue
> comes into play.
>
> Eliot
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>


From nobody Sun Nov  5 22:16:49 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058A613FB2D for ; Sun,  5 Nov 2017 22:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 r_tCvgIKYMTx for ; Sun,  5 Nov 2017 22:16:46 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CB86B13FB24 for ; Sun,  5 Nov 2017 22:16:46 -0800 (PST)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA66Gim4026485 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 00:16:45 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Paul Hoffman 
Cc: "doh@ietf.org" 
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>  <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com> 
From: Adam Roach 
Message-ID: 
Date: Mon, 6 Nov 2017 00:16:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 06:16:48 -0000

On 11/5/17 13:58, Paul Hoffman wrote:
> On Nov 5, 2017, at 11:48 AM, Adam Roach  wrote:
>>> It sounds like the operational document might say something like "an enterprise that cares about which DNS resolver its users access needs to also make that policy in DOH-enabled web clients".
>> s/web clients/DNS clients/, right?
> Maybe?
>
>> I don't get the impression that the use cases are intended to be restricted to web browsers as clients.
> They are not restricted to web clients (I was careful not to say "browsers"), but I don't expect current DNS clients to add DOH capabilities any time in the near future. We have had approximately zero success in getting stub resolvers deployed with DNS-over-TLS (RFC 7858), and getting them to do that would be easier than DNS-encoded-in-HTTP-over-TLS. DNS clients are a use case listed in Section 3 of the draft, but not one that we've heard much interest in.

Right. And if we're talking about text that we're planning to add to 
documents that will be published as RFCs, I think we'd want them to be 
valid for a pretty long period of time, rather than just for "the near 
future."

/a


From nobody Sun Nov  5 22:27:53 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2EE13FAFA for ; Sun,  5 Nov 2017 22:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZtPLMfytN4Vy for ; Sun,  5 Nov 2017 22:27:49 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5CA13FADC for ; Sun,  5 Nov 2017 22:27:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3035; q=dns/txt; s=iport; t=1509949669; x=1511159269; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=LB6S43yJ/DqxSUpzCMtFuUcVAwTTEefkl6h7TPiQIEI=; b=fm9z7ghNxa/KNeOP3ElmQ8IM+uDYitFGSw2aZ6qrpSOjVzwhynFECnYq 0coOlN/PogEaNXK3LmBcpMfBAFC+iNo8nOnTdotAXMl+Wa8Nt1dPSj1wa R3F2F1nJhz2WrC8vM2VyiCElWH9RzDWUL0FfT6Nt5OEl0nFPyVlE1E0ue A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCtAABa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ixOQIZZGghEHAxuFIAKFGBYBAQEBAQEBAQFrKIUfAQU?= =?us-ascii?q?jQhQQCxgqAgJXBg0IAQGKH6o5gieLBQEBAQEBAQEDAQEBAQEBARIPgy6FbIMBh?= =?us-ascii?q?HuDK4JiBaIOhEKCI4EBjRaCdIkEhzyWFoE5JgEwT4EdNCEIHRWDLQmCUxwZgU9?= =?us-ascii?q?ANoxiAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,351,1505779200"; d="asc'?scan'208";a="35350"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 06:27:47 +0000
Received: from [10.61.224.245] ([10.61.224.245]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA66Rj1g012133; Mon, 6 Nov 2017 06:27:46 GMT
To: Martin Thomson 
Cc: Paul Hoffman , "doh@ietf.org" , Mark Nottingham 
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>  <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org> <06878054-f48c-0877-d556-a108a6241d01@cisco.com> 
From: Eliot Lear 
Message-ID: <10d32115-63e0-ef77-804d-f43fba94af97@cisco.com>
Date: Mon, 6 Nov 2017 07:27:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="69iPqQJOjfseaEAKkCqjDhKvKT521wxQT"
Archived-At: 
Subject: Re: [Doh] [Ext] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 06:27:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--69iPqQJOjfseaEAKkCqjDhKvKT521wxQT
Content-Type: multipart/mixed; boundary="2u6fVL1238HCTUKcME9T2jf8skJBNES0V";
 protected-headers="v1"
From: Eliot Lear 
To: Martin Thomson 
Cc: Paul Hoffman , "doh@ietf.org" ,
 Mark Nottingham 
Message-ID: <10d32115-63e0-ef77-804d-f43fba94af97@cisco.com>
Subject: Re: [Doh] [Ext] Servers offering responses for domaines they are not
 responsible for
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
 
 <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org>
 <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
 
In-Reply-To: 

--2u6fVL1238HCTUKcME9T2jf8skJBNES0V
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Good evening(?) Martin,


On 11/6/17 6:18 AM, Martin Thomson wrote:
> Eliot, are you assuming that the DNS client will be looking at
> responses from origins other than the one it has configured as a DOH
> server?

No, although I have a good joke about that re certain all-encompassing
apps and 4-engine aircraft.=C2=A0 Find me next week ;-)

My presumption is simply that the common case will be that HTTP will be
used as a substrate for DNS queries, separate from any other subsystem,
at least initially.=C2=A0 I think this is Paul's view as well, if I
understand him correctly.

What I am getting at is that introducing a new operating model entails
certain operational aspects, most of which can be addressed.=C2=A0 But le=
t's
not kid ourselves: in the case of global load balancers, if this
mechanism isn't going to disturb them, then at least for the moment, one
should expect to have an infrastructure similar to that used by Google
for 8.8.8.8, whereas Eliot's home system would be an exceedingly poor
choice for general use ;-)

Sorry for not sticking to example.com examples- I am trying to convey
some notion of scope and scale.

Eliot



--2u6fVL1238HCTUKcME9T2jf8skJBNES0V--

--69iPqQJOjfseaEAKkCqjDhKvKT521wxQT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaAADSAAoJEIe2a0bZ0noz/kcIAI/djwJoPY4OoCRwkLexoEv0
RzZFL/98lbYpqD8sDKGKflpFaZ+BsMSOof8a54njKp7k+6qZHeaz23pe6Id56836
58QOZaecFF4THyX67JTh4tL8SQ/xxAKcPXdkssxw9JmWJFvLaFMYYbO41mGefoTS
R1VeW+GIAdEpQSl1PVYkl8P5r+IdcW1s2cVvZjMf1V2wuUbUZqw0qpNyyZTlagWA
r8B3Bs4VOD7CKNvJglIXBnCu3DaZ36sSpQlONCA44FIZxAZ3sXNeDPs8omL0V14r
gUMPvgFnF5deRa1Z5UKeFhv9kzzz9qYxKujhQcZxXGyOYBBwug360pnukUXXCRY=
=Xih/
-----END PGP SIGNATURE-----

--69iPqQJOjfseaEAKkCqjDhKvKT521wxQT--


From nobody Sun Nov  5 23:25:35 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8D113FB02 for ; Sun,  5 Nov 2017 23:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hsP9mRTpeT4p for ; Sun,  5 Nov 2017 23:25:32 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB50A13F963 for ; Sun,  5 Nov 2017 23:25:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1509953132; x=1511162732; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=FJbZ10muS70xzKVsSmjLvfrpsIdMtMMVw9oCyhpI+U4=; b=V55HLLwGETioMDJUB6nQicog+qsQwM/jWv7zah6N2WNQ9sS+O80dG/ac Re7E8nsordy4KKyL+GvzQyzpu4DntszAbpMJ8vyFBQt1n99Tm2LPLeFRG 1Bd9jwhdg3JbPzIerZHeSeb4vg7+6GVGuJceLYNYOAvMPxT4EUWh2kVCh c=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQBNDQBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIsTkCGYVwcDhTsChRwVAQEBAQEBAQEBayiFHwEFI1YQCw4?= =?us-ascii?q?KKgICVwYBDAgBAYofqlCCJ4sFAQEBAQEBAQEBAQEBAQEBAQEBEQ+DLoE1hA4pg?= =?us-ascii?q?i5TiCaCYgWiDoRCgiOOF4F8AYl7hzyWFoE5NSKBbDQhCB0Vgy6EX0CNGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,351,1505779200"; d="asc'?scan'208";a="35969"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 07:25:30 +0000
Received: from [10.61.96.180] (dhcp-10-61-96-180.cisco.com [10.61.96.180]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA67PTZ8027482; Mon, 6 Nov 2017 07:25:29 GMT
To: Mark Nottingham , Paul Hoffman 
Cc: doh@ietf.org
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org> 
From: Eliot Lear 
Message-ID: <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
Date: Mon, 6 Nov 2017 08:25:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0vQnaeV74jJim0nLiP4qV0vtFkUETVWAJ"
Archived-At: 
Subject: Re: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 07:25:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0vQnaeV74jJim0nLiP4qV0vtFkUETVWAJ
Content-Type: multipart/mixed; boundary="jkuvxI0NU13koPNc5JIF2a4GsW7dKRdqW";
 protected-headers="v1"
From: Eliot Lear 
To: Mark Nottingham , Paul Hoffman 
Cc: doh@ietf.org
Message-ID: <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
Subject: Re: [Doh] Servers offering responses for domaines they are not
 responsible for
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
 
In-Reply-To: 

--jkuvxI0NU13koPNc5JIF2a4GsW7dKRdqW
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Mark,


On 11/6/17 1:15 AM, Mark Nottingham wrote:
> I'd think the remedy here would be RFC7871 (EDNS client subnet) support=
=2E

It is a *a* remedy, and could certainly be mentioned.=C2=A0 However,
precisely because of the warnings in that document, it probably
shouldn't be listed on its own as the sole recommended approach.

Eliot



--jkuvxI0NU13koPNc5JIF2a4GsW7dKRdqW--

--0vQnaeV74jJim0nLiP4qV0vtFkUETVWAJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaAA5eAAoJEIe2a0bZ0nozmQwIANwDhhh9FldxSnSr670KlvXZ
Uu51SYIBniAfxjpCwTPSJGNbKcglKKpOdSQ1Y5DQSg+9O4W9e1I0d/6yXtNZShg2
MG9rR4B8XmuuAPLHJvnyd3Ltajcue0bxLICTI9Eiqh9XccWPMAtHTw+JQdAMt4rL
wAqdpo8KwOxlbRFfS/BWUWIgACF0StQP6ZwSv53lGEtBaM67IRzXkltkfg5AkqxX
p4i+3sebyqglQG8FS2LPS8KDWwRV9Rv87GTZA2/JU2mD4nWnR8nJF0MrJgg4qoEc
1Infi6hvjdXOTA0Q1KJxFdkauaXhD5L+96KWd2zAeXPV60oHZdxKOiLPWDU1ha0=
=YgN+
-----END PGP SIGNATURE-----

--0vQnaeV74jJim0nLiP4qV0vtFkUETVWAJ--


From nobody Mon Nov  6 04:00:57 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5813FBE9 for ; Mon,  6 Nov 2017 04:00:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=l78FZFDb; dkim=pass (1024-bit key) header.d=yitter.info header.b=NY48VnGQ
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 1DdFZnIMEnsk for ; Mon,  6 Nov 2017 04:00:55 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C3613FBE8 for ; Mon,  6 Nov 2017 04:00:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9C3E9BF56B for ; Mon,  6 Nov 2017 12:00:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509969624; bh=cjfvRlTHQUBlui2MuD/YOYWwM2BpjQyBkKAd1GPBfDU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=l78FZFDbQLx7vBUNIkPtlcg7iajQE9fgNgnK02kks4Dfx5YGJxGINIUx4HhsUhAZ1 0hGANqXIx+xD1UxLTjMrPtvO+T7eLB6tJAiWTsSreBOJ8//YCEK5K26yqapjnrgYRo IBYaaoUof7dqQcJ5/wToUCeiMG3b6vgDBmLaTVic=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCCzog7lYDfx for ; Mon,  6 Nov 2017 12:00:14 +0000 (UTC)
Date: Mon, 6 Nov 2017 07:00:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509969614; bh=cjfvRlTHQUBlui2MuD/YOYWwM2BpjQyBkKAd1GPBfDU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NY48VnGQ7X4OW6amw2dmRzU3ydGhmN94HAKTBkDaFkYTp3EQqf6H8HnTDdqQLYKZu XnaBDZblVxQUwndVCVi4mm/t48qunurWQdFHfzag7Ur/Uxw1fgiTE4MzdzhK8sa11k lQp0RcFuKtsF6FCsdtGfYmZvvFzUgpNt+T4NNQDQ=
From: Andrew Sullivan 
To: doh@ietf.org
Message-ID: <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
References:  <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net>
Archived-At: 
Subject: Re: [Doh] DOH and split DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 12:00:56 -0000

On Mon, Nov 06, 2017 at 11:13:19AM +1100, Mark Nottingham wrote:
> 
>  Some careful wording around the configuration mechanism should help.
> 
> Allowing something like proxy.pac to override DOH doesn't make any sense, given that the primary purpose of DOH is to NOT allow the local network to impose policy on communication with the DNS server.
> 

That careful wording had better be pretty careful.  I don't believe
for an instant that most users have a workable theory for which
resolution mechanism they're using, and if they configure DOH and
suddenly all the "internal sites" don't work they're going to be
pretty surprised.

It strikes me as pretty strange, too, to suggest that, if a user
configures proxy.pac, they don't want the local network to offer such
policies.  If the user is prepared to use the proxy, presumably the
user is prepared to use it to impose local policy, no?

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Mon Nov  6 04:07:27 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B444F13FBE9 for ; Mon,  6 Nov 2017 04:07:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=HTannUPr; dkim=pass (1024-bit key) header.d=yitter.info header.b=L2hiikOD
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 U5_ojzkVaitN for ; Mon,  6 Nov 2017 04:07:19 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9D713FB9E for ; Mon,  6 Nov 2017 04:07:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9D9B7BF56B for ; Mon,  6 Nov 2017 12:07:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509970038; bh=05uzazE/bTjzLpNhNMVAc7MjqbtW3U4ejb6l/YOu7ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HTannUPrIamZAPzqltenXkSzfG0WhEHF0hji41EURDnjAOJgfz1aPQ+9Cl12/CNYB IXaz0xG/AzCPt6C0JCByySyih0xR/vXGm2qChzMQu9f2ogz8LCncVMfgqRBPNqcUez Qtcd0ygF6n6souZXTJzmTX9yH19YLYO/jU46mpXU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id masGpBr8-SJZ for ; Mon,  6 Nov 2017 12:07:12 +0000 (UTC)
Date: Mon, 6 Nov 2017 07:07:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509970032; bh=05uzazE/bTjzLpNhNMVAc7MjqbtW3U4ejb6l/YOu7ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=L2hiikODd3Z8SMbQoQHNlTaBWF8N3P1StyCbRbFFDVWuvUUXIYU00oeI5qeT9oGdl fedtZnEtduoYQhXhIUHUgaV2Bt6nGoPwJJy4r2FdZNPLN3kNUUqM+p0wX3meAb0Mbf 7m4DjrPAJP322/Jl6HKO+sjjG/CG1ErwXE+kv9rY=
From: Andrew Sullivan 
To: doh@ietf.org
Message-ID: <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>  <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
Archived-At: 
Subject: Re: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 12:07:26 -0000

On Mon, Nov 06, 2017 at 08:25:17AM +0100, Eliot Lear wrote:
> 
> It is a *a* remedy, and could certainly be mentioned.  However,
> precisely because of the warnings in that document, it probably
> shouldn't be listed on its own as the sole recommended approach.

It's the only thing we have that solves this problem today, however.
If you want geo- or even (and more accurately) network-topologically
sensitive answers to work, you need to know where the query originator
was.  For years we used the network address of the resolver as a proxy
for the location of the query originator, but in a world where
resolvers may be quite distant from the query originator that doesn't
work, and it doesn't matter whether the query travels via UDP port 53
or some other mechanism.

And indeed, given the DOH use case (which as we're currently
discussing it is really just last hop), I'm not sure what the problem
is.  This is directly analagous to a stub contacting a full service
resolver, and that's exactly the problem the large authoritative DNS
tricks have and that edns-client-subnet addresses.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com


From nobody Mon Nov  6 07:12:11 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A413FC38 for ; Mon,  6 Nov 2017 07:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 W8iad9P6Alin for ; Mon,  6 Nov 2017 07:12:02 -0800 (PST)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A813FC33 for ; Mon,  6 Nov 2017 07:12:01 -0800 (PST)
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5A1FD3A021 for ; Mon,  6 Nov 2017 10:11:59 -0500 (EST)
Received: by mail-lf0-f51.google.com with SMTP id e143so10840752lfg.12 for ; Mon, 06 Nov 2017 07:11:59 -0800 (PST)
X-Gm-Message-State: AMCzsaUmwlI8NBJggoS7Xpq0+l9bxFVU3rDI7LJahxifYcq4tqxMEqbJ LR8Ri4/vx+8+nQ5NM/SNFi8FDhgh1K8E5xQ0k1w=
X-Google-Smtp-Source: ABhQp+TOhec8zYPRsQiQ9mA7rTPvhqWps/E6oZ2I3CtRMpz1biWyM56T7mo6I7QexYINPBQHwFdZsaVnUeTzPXrjgpg=
X-Received: by 10.46.84.84 with SMTP id y20mr6866706ljd.89.1509981118084; Mon, 06 Nov 2017 07:11:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.22 with HTTP; Mon, 6 Nov 2017 07:11:57 -0800 (PST)
In-Reply-To: <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
References:  <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net> <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
From: Patrick McManus 
Date: Mon, 6 Nov 2017 10:11:57 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Andrew Sullivan 
Cc: doh@ietf.org
Content-Type: multipart/alternative; boundary="f403045fb58e293c2d055d51e09b"
Archived-At: 
Subject: Re: [Doh] DOH and split DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 15:12:09 -0000

--f403045fb58e293c2d055d51e09b
Content-Type: text/plain; charset="UTF-8"

If we were to do an operational doc, it seems fine to note that who you ask
determines what the answer is and therefore you need to consider who you
are asking. Uncontroversial - indeed its really a motivator for DoH in the
big picture.




On Mon, Nov 6, 2017 at 7:00 AM, Andrew Sullivan 
wrote:

> On Mon, Nov 06, 2017 at 11:13:19AM +1100, Mark Nottingham wrote:
> >
> >  Some careful wording around the configuration mechanism should help.
> >
> > Allowing something like proxy.pac to override DOH doesn't make any
> sense, given that the primary purpose of DOH is to NOT allow the local
> network to impose policy on communication with the DNS server.
> >
>
> That careful wording had better be pretty careful.  I don't believe
> for an instant that most users have a workable theory for which
> resolution mechanism they're using, and if they configure DOH and
> suddenly all the "internal sites" don't work they're going to be
> pretty surprised.
>
> It strikes me as pretty strange, too, to suggest that, if a user
> configures proxy.pac, they don't want the local network to offer such
> policies.  If the user is prepared to use the proxy, presumably the
> user is prepared to use it to impose local policy, no?
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

--f403045fb58e293c2d055d51e09b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If we were to do an operational doc, it seems fine to=
 note that who you ask determines what the answer is and therefore you need=
 to consider who you are asking. Uncontroversial - indeed its really a moti=
vator for DoH in the big picture.




On Mon, Nov 6, 2017 at 7:00 AM, Andrew Sullivan <ajs@anvilwalrusden=
.com> wrote:
On Mon, Nov 06, 2017 at 11:13:19AM +1100, Mark Nottingham wrote:

>

>=C2=A0 Some careful wording around the configuration mechanism should h=
elp.

>

> Allowing something like proxy.pac to override DOH doesn't make any=
 sense, given that the primary purpose of DOH is to NOT allow the local net=
work to impose policy on communication with the DNS server.

>



That careful wording had better be pretty careful.=C2=A0 I don't=
 believe

for an instant that most users have a workable theory for which

resolution mechanism they're using, and if they configure DOH and

suddenly all the "internal sites" don't work they're goin=
g to be

pretty surprised.



It strikes me as pretty strange, too, to suggest that, if a user

configures proxy.pac, they don't want the local network to offer such
policies.=C2=A0 If the user is prepared to use the proxy, presumably the
user is prepared to use it to impose local policy, no?



Best regards,



A



--

Andrew Sullivan

ajs@anvilwalrusden.com




_______________________________________________

Doh mailing list

Doh@ietf.org

https://www.ietf.org/mailman/listinfo/doh





--f403045fb58e293c2d055d51e09b--


From nobody Mon Nov  6 09:07:55 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8313FBB2 for ; Mon,  6 Nov 2017 09:07:53 -0800 (PST)
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] 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 Dvy3LGO1iDyb for ; Mon,  6 Nov 2017 09:07:51 -0800 (PST)
Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4081513FB6E for ; Mon,  6 Nov 2017 09:07:50 -0800 (PST)
Received: by sudo.sh (Postfix, from userid 1000) id 23BCA42BEA0; Mon,  6 Nov 2017 17:07:50 +0000 (UTC)
Date: Mon, 6 Nov 2017 17:07:50 +0000
From: dagon 
To: doh@ietf.org
Message-ID: <20171106170750.GA24665@sudo.sh>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 17:07:54 -0000

I might have missed something in the draft, but I worry about a misuse
of the DOH protocol.  To my knowledge, there exists no practical means
(outside of Flash, java applets, and special, limited DNS prefetch
circumstances) for web sites to provoke third-party clients into
performing mass (million+) DNS queries.  Indeed, for this reason,
projects such as the ICSI Netalyzr resort to signed applets, which
users must inspect and intentionally approve.  Outside of these
limited and off-by-default cases, HTML visits can't generate arbitrary
volumes of DNS queries. A handful, yes, but not DoS-levels.

But depending on how the DOH stubs are implemented, DNS traffic could
be induced through trivially crafted javascript.  For example, if
GET/POST primitives are all that's needed, javascript and 'document
write' calls can generate random child label queries towards a target
zone, e.g. repeated GETs for the encoding of "${UNIX_EPOCH}.\
victimzone.example.com". Instead of doing a handful of DNS lookups
(mostly prefetch), a web visitor could perform thousands or millions
of queries.

Consider these scenarios: could one purchase ads which induce DOH
queries non-stop?  Likewise, could one insert such content on popular
forums, troll links on popular sites, or otherwise attract enough
views to generate streams of repeated DOH queries from browsers?  A
few thousand web views would turn into millions of DNS queries.  At
present, misuse of HTML may trigger only a few dozen DNS prefetches,
if such resolution is not already turned off by the site (as it is
with https by default).

If these concerns are valid, and not a misreading of the draft, then I
offer these further comments and suggestions:

  a) UI proof-of-life?  Perhaps DOH resolution should be tied to
intentional user action, somehow known to the stubs, based on UIX
feedback, and perhaps presented as proof to the recursive and
authority through new EDNS fields.  I recognize this idea as bad and
unworkable, but offer it to suggest a larger goal: DOH queries should
reflect a browser user's express desires, and not the worst intentions
of the HTML/js author.

  b) Recursive BMPs?  I appreciate that the draft is only focused on
wire format issues.  But perhaps the DOH draft could address various
implementation choices, such as aggregate query limits, same-origin
limitations on DOH-based queries, and the like?  Some stub
implementation guidelines seem prudent.

  c) Header-only?  If we assume implementation mistakes will always
occur in DOH stubs and recursives, perhaps the wire encoding should
appear only in HTTP headers, since these are less easily manipulated
by crafted javascript and HTML.  At the same time, the headers are
presumably within reach of the stub.  Header fields seem more likely
to reflect browser user decisions, and not the HTML author's malicious
whims.  (At least the problem would only be as bad as DNS prefetch, in
terms of volume.)

  d) Recursion only?  I assume non-recursive queries would be rejected
by the DOH servers.  Should the protocol require this?  The same
question applies to invalid DNS messages.  Should DOH proxies/stubs
and recursives parse and validate the query, or may they naively put
the DNS message on the wire, "as is"?  Naive DOH recursive
implementations may do the latter, enabling a large range of proxied
DNS probes and protocol attacks.  (E.g., 0-day "query of death" packets
can be delivered via Tor, perhaps.  Maybe this is slightly more
convenient than spoofed UDP.)

  e) ECS opt-in?  I suspect all DOH enabled recursives will also be
ECS speakers.  A standard concerned with privacy might suggest that
DOH stubs be ECS-disabled (or scope 0) by default, since EDNS client
subnet payloads communicate information about the stub.

  At the least, DOH stubs must expose this switch to the user, even if
the vendor decides to use an opt-out approach.  A DOH stub without ECS
opt-outs effectively mandates subnet leaks to arbitrary websites,
unbalancing the privacy trade-off in RFC 7871.  Likewise, a malicious
website could discover the client IP, and deliver ALL the client
octets (and just not the network), to any DOH recursive, via crafted
GETs.

                           *    *    *

DOH is a tectonic shift in how users produce DNS queries.  It
potentially lets any normal html author wield a "Great Cannon"
capability, https://citizenlab.ca/2015/04/chinas-great-cannon/
assuming crafted HTML/js can appear on enough browsers.  It further
raises interesting questions about user intention, DNS privacy, and
authority DDoS query flooding.  It greatly expands the attack surface
that malicious site operators can use, to either expose more user
information or exfiltrate data.  Absent firm DOH stub guidelines, and
DOH recursive best practices, it seems to expand the surveillance and
measurement capabilities of DNS researchers.

If I have not misunderstood the draft protocol, then hopefully my
suggestions point to practical solutions.

-- 
David Dagon
dagon@sudo.sh
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717


From nobody Mon Nov  6 10:21:43 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E542A13FC62 for ; Mon,  6 Nov 2017 10:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 B2ona5reabjw for ; Mon,  6 Nov 2017 10:21:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A3F8313FADC for ; Mon,  6 Nov 2017 10:21:40 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6ILcgm007417 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 12:21:39 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: dagon , doh@ietf.org
References: <20171106170750.GA24665@sudo.sh>
From: Adam Roach 
Message-ID: <4f7a2ff7-494d-04f5-6aec-bff8cfa12d40@nostrum.com>
Date: Mon, 6 Nov 2017 12:21:33 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171106170750.GA24665@sudo.sh>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:21:42 -0000

On 11/6/17 11:07 AM, dagon wrote:
> I might have missed something in the draft, but I worry about a misuse
> of the DOH protocol.  To my knowledge, there exists no practical means
> (outside of Flash, java applets, and special, limited DNS prefetch
> circumstances) for web sites to provoke third-party clients into
> performing mass (million+) DNS queries.  Indeed, for this reason,
> projects such as the ICSI Netalyzr resort to signed applets, which
> users must inspect and intentionally approve.  Outside of these
> limited and off-by-default cases, HTML visits can't generate arbitrary
> volumes of DNS queries. A handful, yes, but not DoS-levels.
>
> But depending on how the DOH stubs are implemented, DNS traffic could
> be induced through trivially crafted javascript.  For example, if
> GET/POST primitives are all that's needed, javascript and 'document
> write' calls can generate random child label queries towards a target
> zone, e.g. repeated GETs for the encoding of "${UNIX_EPOCH}.\
> victimzone.example.com". Instead of doing a handful of DNS lookups
> (mostly prefetch), a web visitor could perform thousands or millions
> of queries.

So you mean something equivalent to:

var date = new Date();
while (1) {
   var img = document.createElement('image');
   img.src = date.getTime() + date.getMilliseconds() + 
".victimzone.example.com";
   document.body.appendChild(img);
}

It's not clear that you're describing something new.

(It's also worth noting that, in the scenario you're describing, the 
victim DOH server would have to opt-in to allowing the attacking site to 
query it, unlike the script above. See [1] and [2] for background)

/a

____
[1] https://en.wikipedia.org/wiki/Same-origin_policy
[2] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing


From nobody Mon Nov  6 15:33:00 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34B13F698 for ; Mon,  6 Nov 2017 15:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XExW77Cc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hce0i4Vz
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 NQWRW1UQpJOF for ; Mon,  6 Nov 2017 15:32:57 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D3613FB59 for ; Mon,  6 Nov 2017 15:32:57 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9712C20C7A; Mon,  6 Nov 2017 18:32:56 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 06 Nov 2017 18:32:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=nN10TEnAbhFrqhl2yRzjIICknXKyM NIIOzvvmoco8/I=; b=XExW77CcCXhFTmlPspN3tMjt24CqnXJUK4ZRklBG1ps29 z7B2cPTSgi98tf0Z/9dMTrJxdJvSZRcMY5ipvjF3TlfZCwV96rjXYIkxQ6I3H/sJ QKzdaQt2siQ+KXiKEqO+nmdh8BBAwP7Q9E2P0QQtWXJ1wN+7PNHh0VHN/2MEFW+7 a08FokmouDUjniXL9QgzgmSD3Xk2vkslHuN1PZLl3Bi9hLWM9ptHTDroXhoggd0v h+OwUe2mJqGqPlImd1POUyf0SG7xf8ybraasey8upWGqvkisxnahulIJtd/GVrY1 FW0hricFtzlMT7vwYawV8qPai7r4unod30EAUAlIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nN10TE nAbhFrqhl2yRzjIICknXKyMNIIOzvvmoco8/I=; b=Hce0i4VzpK9bULOp/UoV3n eXJYsWjkisoa0LO5uE606QmPwdGWSPFmYONpsm6R9Trj6sG19bhOI6TTRJF/7zHh UKNWunT5+eZ4UAUuzIm5LotxxPMueT4javIhH75R3RwpUy3gnqXP7Xabk3DBi2Yr 1FixOHOp3Ndze18eg4bKIaQp4lanUPb+GUhsbu4CdLTPLNmH6d79dqQto3wGqSHa hMQ42AvyUUz3IhMBeDnb+cHsLCUzFWLBkid1WRaBSQkgtFJeB0xpsm0vXaaNXUYU i/tIif1tXDMZyGX30Q0p4f/SaWKcV2sIUlw+IKs3zTueQHGgLqC40NwDDBbNl3UA ==
X-ME-Sender: 
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id A8F13242CF; Mon,  6 Nov 2017 18:32:55 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Mark Nottingham 
In-Reply-To: <20171106170750.GA24665@sudo.sh>
Date: Tue, 7 Nov 2017 10:32:52 +1100
Cc: doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20171106170750.GA24665@sudo.sh>
To: dagon 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 23:32:59 -0000

> On 7 Nov 2017, at 4:07 am, dagon  wrote:
>=20
>  c) Header-only?  If we assume implementation mistakes will always
> occur in DOH stubs and recursives, perhaps the wire encoding should
> appear only in HTTP headers, since these are less easily manipulated
> by crafted javascript and HTML.  At the same time, the headers are
> presumably within reach of the stub.  Header fields seem more likely
> to reflect browser user decisions, and not the HTML author's malicious
> whims.  (At least the problem would only be as bad as DNS prefetch, in
> terms of volume.)

It's trivial for scripts to modify headers, EXCEPT those starting with =
Sec-:
  https://fetch.spec.whatwg.org/#forbidden-header-name

If this is a concern, it might be workable to define a header that looks =
something like:

Sec-Doh: 1

to indicate that the request was generated by the browser / client =
internals, not script.

Cheers,

--
Mark Nottingham   https://www.mnot.net/


From nobody Mon Nov  6 15:39:49 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1E13FB59 for ; Mon,  6 Nov 2017 15:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 WYdVBXDlDGfB for ; Mon,  6 Nov 2017 15:39:45 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 22A0713F698 for ; Mon,  6 Nov 2017 15:39:44 -0800 (PST)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6Ndg1i041193 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 17:39:43 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Mark Nottingham , dagon 
Cc: doh@ietf.org
References: <20171106170750.GA24665@sudo.sh> 
From: Adam Roach 
Message-ID: <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com>
Date: Mon, 6 Nov 2017 17:39:42 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 23:39:47 -0000

On 11/6/17 5:32 PM, Mark Nottingham wrote:
>
>> On 7 Nov 2017, at 4:07 am, dagon  wrote:
>>
>>   c) Header-only?  If we assume implementation mistakes will always
>> occur in DOH stubs and recursives, perhaps the wire encoding should
>> appear only in HTTP headers, since these are less easily manipulated
>> by crafted javascript and HTML.  At the same time, the headers are
>> presumably within reach of the stub.  Header fields seem more likely
>> to reflect browser user decisions, and not the HTML author's malicious
>> whims.  (At least the problem would only be as bad as DNS prefetch, in
>> terms of volume.)
> It's trivial for scripts to modify headers, EXCEPT those starting with Sec-:
>    https://fetch.spec.whatwg.org/#forbidden-header-name
>
> If this is a concern, it might be workable to define a header that looks something like:
>
> Sec-Doh: 1
>
> to indicate that the request was generated by the browser / client internals, not script.

If the notion here is to prevent JS-initiated queries, I'll point out 
that this is explicitly prohibited by the working group charter: "While 
access to DNS-over-HTTPS servers from JavaScript running in a typical 
web browser is not the primary use case for this work, precluding the 
ability to do so would require additional preventative design. The 
working group will not engage in such preventative design."

/a


From nobody Mon Nov  6 15:42:54 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711E013FC96 for ; Mon,  6 Nov 2017 15:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=CJ0QD8XG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BRR5MdtK
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 fqfW_OUeutvg for ; Mon,  6 Nov 2017 15:42:51 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14BA13F698 for ; Mon,  6 Nov 2017 15:42:50 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4701F20D21; Mon,  6 Nov 2017 18:42:50 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 06 Nov 2017 18:42:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MbCyosn95C//h8VRKsZIAwBgmFdKo fQim941/O9XSJw=; b=CJ0QD8XGiBJzdII4ioRqeZQFhEgwCuqmu6335pVNp4IsL E+ua4LY1q2LUixTFHnlClISy+MAiBEY+BwfdDZZLYYncxyFD/38TjrCvVi/jkR2f z4TmCkzmqF4v6G7jpVfjTPHbUTAj4OKp9g+oQ8BiRpzTDRHcHDKhjwEm/MfR116W +LyYY8gpU0F+2w2M3Mf3fUFckLXrm1ZmRYbGWANNrRKlEUt3W/8JO6cHij5XLgih vx6FY9yL7CqTl+L3Sc4SXBk2+MR7lRvecs1pIebpvtudzym6Vecw9Ee/FLFVdgYg D8qR4DJTPI6Uqzoxwr3hOu2Ky1Gt4z/cR4vzyVVJA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=MbCyos n95C//h8VRKsZIAwBgmFdKofQim941/O9XSJw=; b=BRR5MdtKijDOhNCuql5tXZ FEy4CueKx97oEzD4W7RZBVkpDp15PauhnKtQfDq5jb3cPe5N6x+SYdtYwTVc+fdz qiGVMMw+PcMl6tJCDBybk2W7Hykxeu6Lh5KgIPVh7YNbS/QhzOpEeA2nHdOGq8UO ZjMlfExdcTsMXEUoILdQ1Z0uNhuQIOKhmWbeHatnLQlud1NFjHoy7n9h5LFFqUfJ BZw1sz0xDa8K14sK9wKsWVqauvzh3/GNnP3CW1IbUg1RDbkhcKRfLIBrT0aRa1WZ yyziSWddVRssWreqmOXRNz8ijDJtLIIBKHYz0mu9hywhqhOXG/SOJuWgCUdQO6Xg ==
X-ME-Sender: 
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 286BD7F8DC; Mon,  6 Nov 2017 18:42:48 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Mark Nottingham 
In-Reply-To: <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com>
Date: Tue, 7 Nov 2017 10:42:48 +1100
Cc: dagon , doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <24074F51-B167-42A4-83F0-29FCB750ACEB@mnot.net>
References: <20171106170750.GA24665@sudo.sh>  <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 23:42:52 -0000

> On 7 Nov 2017, at 10:39 am, Adam Roach  wrote:
>=20
> If the notion here is to prevent JS-initiated queries, I'll point out =
that this is explicitly prohibited by the working group charter: "While =
access to DNS-over-HTTPS servers from JavaScript running in a typical =
web browser is not the primary use case for this work, precluding the =
ability to do so would require additional preventative design. The =
working group will not engage in such preventative design."

No, the intent is to allow a DOH server to distinguish between =
JS-initiated requests and "native" ones, making up its own mind what to =
do with that information.


--
Mark Nottingham   https://www.mnot.net/


From nobody Mon Nov  6 15:47:10 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443FA13FB7E for ; Mon,  6 Nov 2017 15:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 iHFq8xoPZVyJ for ; Mon,  6 Nov 2017 15:47:07 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 816FB13F698 for ; Mon,  6 Nov 2017 15:47:07 -0800 (PST)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6Nl5II041958 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 17:47:06 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Mark Nottingham 
Cc: dagon , doh@ietf.org
References: <20171106170750.GA24665@sudo.sh>  <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com> <24074F51-B167-42A4-83F0-29FCB750ACEB@mnot.net>
From: Adam Roach 
Message-ID: 
Date: Mon, 6 Nov 2017 17:47:05 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <24074F51-B167-42A4-83F0-29FCB750ACEB@mnot.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 23:47:08 -0000

On 11/6/17 5:42 PM, Mark Nottingham wrote:
>
>> On 7 Nov 2017, at 10:39 am, Adam Roach  wrote:
>>
>> If the notion here is to prevent JS-initiated queries, I'll point out that this is explicitly prohibited by the working group charter: "While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The working group will not engage in such preventative design."
> No, the intent is to allow a DOH server to distinguish between JS-initiated requests and "native" ones, making up its own mind what to do with that information.

It seems that the information in the "Referrer" header field would 
already provide this ability, and with far better granularity than a 
simple "yes/no".

/a


From nobody Mon Nov  6 15:50:31 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F97A13F698 for ; Mon,  6 Nov 2017 15:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=BH96VWvx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mBKs+vMc
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 kDUIc3MPTI5E for ; Mon,  6 Nov 2017 15:50:23 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA10813FB7E for ; Mon,  6 Nov 2017 15:50:23 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 42F0D20830; Mon,  6 Nov 2017 18:50:23 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 06 Nov 2017 18:50:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=l0wJ49A8Kge8PNVd6X0jAO5K0JGVr K5oqLM4FBEc9dw=; b=BH96VWvxmN63RZD8qcW6eF3QGaNMzltMaO31vycSQZkwQ PihN1CqBF10MUOTo+8Gdy/7YLb3+boE0BYIT7Z5roP+nH9esu9tyL0BASS3Qvs0l dQrJO6zxqP3CrLn4/3T06zJPqXnfSDAsQSUvBhT0byNMrSRtFD9DeZZRrT/iJU3L 6q1ho1s/AkEAbx+XxPwTSUdbO/YdnnNfP9/pqTZLZ6qno7B5Vs+NB0OXFG7S97HM vJPQOQCnD7EZZ8tvfKTrAO1WGB6rbhGjZ6LRErqG+5r98tPcdQIQYf+euT1JgplI 8XtOJvE9TyHYjUmhdgMBKapo2Uc2RJq2+0dPAYjsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=l0wJ49 A8Kge8PNVd6X0jAO5K0JGVrK5oqLM4FBEc9dw=; b=mBKs+vMcpjzxFrwD8O5MnP e6Wpr5WWc2+YaOUpssA5k3WcDxiFewrh2T4offVfvsucptDosTOWRVWAc5uraAXg F7/ZNTwA+DMBPA7aGmxRkJio0HdbA30LmILgh3V1FMYlMjixQgVKWKlgnduS/JAP 4Yflzjk/trZYZf/3Y5/rQ9qpYGH20hqYufIBZpEJunOaMMEhB6XZ+zbzduWdNmba 4GpWMWyiDU5yj0ahXKbwm6Bl4NTBdbe9lztkqUbFScrfG3IweJBksyNjhkr+Elyd GCeVtRaz6/PKV/MwSuIKaCtIZG47JZ7K5Dq3zs7p+AchsWW7gaOZ4xLzlc+ynzzw ==
X-ME-Sender: 
Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 22668242CF; Mon,  6 Nov 2017 18:50:21 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 7 Nov 2017 10:50:18 +1100
Cc: dagon , doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <908CFC85-4F7C-46CF-A53D-6271740EFC4C@mnot.net>
References: <20171106170750.GA24665@sudo.sh>  <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com> <24074F51-B167-42A4-83F0-29FCB750ACEB@mnot.net> 
To: Adam Roach 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 23:50:29 -0000

> On 7 Nov 2017, at 10:47 am, Adam Roach  wrote:
>=20
> On 11/6/17 5:42 PM, Mark Nottingham wrote:
>>=20
>>> On 7 Nov 2017, at 10:39 am, Adam Roach  wrote:
>>>=20
>>> If the notion here is to prevent JS-initiated queries, I'll point =
out that this is explicitly prohibited by the working group charter: =
"While access to DNS-over-HTTPS servers from JavaScript running in a =
typical web browser is not the primary use case for this work, =
precluding the ability to do so would require additional preventative =
design. The working group will not engage in such preventative design."
>> No, the intent is to allow a DOH server to distinguish between =
JS-initiated requests and "native" ones, making up its own mind what to =
do with that information.
>=20
> It seems that the information in the "Referrer" header field would =
already provide this ability, and with far better granularity than a =
simple "yes/no".

It could -- or Origin.



--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Nov  9 02:46:55 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01312F29A for ; Thu,  9 Nov 2017 02:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RNyLxvM6lisp for ; Thu,  9 Nov 2017 02:46:51 -0800 (PST)
Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE3312EC8E for ; Thu,  9 Nov 2017 02:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3339; q=dns/txt; s=iport; t=1510224411; x=1511434011; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=62go2c3/zUmhSXR4nseesRnckjrPqoj3sm3qETOrZaI=; b=W5iu/VxftOvJbivsCAqIYOjbodzzjtaRRMpv5g9KIXWSwJgNnAbHUg1d +dnl9vnn1DPRxBzA29O+21+7Z1/0yUQKdbGABVT21zmOqTw5tv44WXWEQ 5Ug6mrUYHgL6O3VSLwol06AGm//n7p/oMWFIKoH97SCJFwICubxvnd8N+ U=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAAOMQRa/xjFo0hcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUGhCSKH3SQL5ZNghEHA4U7AoUmGAEBAQEBAQEBAWsohR4BAQE?= =?us-ascii?q?BAgEjZgsOCioCAlcGAQoCCAEBihcIqVOCJ4sVAQEBAQEBAQMBAQEBAQEBAQEBA?= =?us-ascii?q?Q4PgzCBNYQ4gi5TiCuCYwWSc48nhEOCI44Yi3mHP5YhgTkfOIFxNCEIHRWDLoR?= =?us-ascii?q?mOYxAAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,369,1505779200";  d="asc'?scan'208";a="55909176"
Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 10:46:48 +0000
Received: from [10.232.4.170] ([10.232.4.170]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA9AklXi029962; Thu, 9 Nov 2017 10:46:48 GMT
To: Andrew Sullivan , doh@ietf.org
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>  <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com> <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>
From: Eliot Lear 
Message-ID: <5d2b439b-c070-48a0-c36c-834582e15daf@cisco.com>
Date: Thu, 9 Nov 2017 16:16:37 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="usDfahooFfVo5CuGk2QDGTrAK0WLkEeGF"
Archived-At: 
Subject: Re: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 10:46:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--usDfahooFfVo5CuGk2QDGTrAK0WLkEeGF
Content-Type: multipart/mixed; boundary="CXJriAOks48LT3sprqiKoUhiTjP40gINc";
 protected-headers="v1"
From: Eliot Lear 
To: Andrew Sullivan , doh@ietf.org
Message-ID: <5d2b439b-c070-48a0-c36c-834582e15daf@cisco.com>
Subject: Re: [Doh] Servers offering responses for domaines they are not
 responsible for
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org>
 
 <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
 <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>
In-Reply-To: <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>

--CXJriAOks48LT3sprqiKoUhiTjP40gINc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Andrew,


On 11/6/17 5:37 PM, Andrew Sullivan wrote:
> On Mon, Nov 06, 2017 at 08:25:17AM +0100, Eliot Lear wrote:
>> It is a *a* remedy, and could certainly be mentioned.=C2=A0 However,
>> precisely because of the warnings in that document, it probably
>> shouldn't be listed on its own as the sole recommended approach.
> It's the only thing we have that solves this problem today, however.
> If you want geo- or even (and more accurately) network-topologically
> sensitive answers to work, you need to know where the query originator
> was.  For years we used the network address of the resolver as a proxy
> for the location of the query originator, but in a world where
> resolvers may be quite distant from the query originator that doesn't
> work, and it doesn't matter whether the query travels via UDP port 53
> or some other mechanism.
>
> And indeed, given the DOH use case (which as we're currently
> discussing it is really just last hop), I'm not sure what the problem
> is.  This is directly analagous to a stub contacting a full service
> resolver, and that's exactly the problem the large authoritative DNS
> tricks have and that edns-client-subnet addresses.

Having thought about this a bit, what got me was this:

1.=C2=A0 I get the impression through my own experience that it doesn't s=
eem
to be used (I see odd localizations that could have been avoided were it
so); and
2.=C2=A0 Given that, DOH can exacerbate the problem if the service is not=

deployed as a CDN itself.

So I think Mark's right to out the remediation.=C2=A0 I just am wary that=

it's enough.

Eliot



>
> Best regards,
>
> A
>



--CXJriAOks48LT3sprqiKoUhiTjP40gINc--

--usDfahooFfVo5CuGk2QDGTrAK0WLkEeGF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaBDINAAoJEIe2a0bZ0nozdC0H/1830nJnsAifzIRcTt1Kt9t+
VVCgyNRSnZwI6DndD97gWr9GKxntbnUpoyqwY5iM+GI7ufw92BPipE2doGmWZbzs
ljlr4nVbwwmglUSLxky+0+0/qHmN4DSj+UGy/lewQzEcTFhScABInhCi05tfsSGu
1aFGZSYrvzaVJq6EfQxxdc5d5mtGQX/NQCP5aZKih9Eu0sDTZFbxbdkuxFAt6mFy
TkIsfz+ouq829BJpQutH4TtJBEVEl9w3Rd20CwjG0RQs2/ZzqhCa04xl7c5FzbUB
b9RRBWWUvpNOTdhuTfkDD490ttr7TocNPbzdIbvnNmQbD8wy1OT+x2EIwdB/ccM=
=SOct
-----END PGP SIGNATURE-----

--usDfahooFfVo5CuGk2QDGTrAK0WLkEeGF--


From nobody Thu Nov  9 03:06:12 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746812F3D0 for ; Thu,  9 Nov 2017 03:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Y4a85NTWd7IO for ; Thu,  9 Nov 2017 03:06:09 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F8C12EC8E for ; Thu,  9 Nov 2017 03:06:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3147; q=dns/txt; s=iport; t=1510225569; x=1511435169; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=zbKxuLmG1joCgB4xPtlVPmvPZMJi9cfVTF4+6xj8XXo=; b=SxgRAewNiBEjW1Beiyjk4mcN8eLPV343K3L8CPZMM3h1O4Y6SdnnhAe1 wsuCxeukB3mN8uynuFHZLkNcBlEpBMbHaz09OE0UyQ+JF1orXOKYt0Sqs CRHpLN8TA1uI0Za7WMejpXy0XKHa5lBCV6vP9xWT4wea5NReXS1K2Phdk o=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADHNQRa/xjFo0hcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUGhCSKH3SQL5ZNEIIBBwOFOwKFARgBAQEBAQEBAQFrKIUfAQU?= =?us-ascii?q?jZgsOCioCAlcGAQoCCAEBih+pVIInixUBAQEBAQEEAQEBAQEBAQERD4MwhW2DA?= =?us-ascii?q?YRaJoMrgmMFkWGBEo8nhEOCI44Yi3mHP5YhgTkfOIFxNCEIHRWDLoRmOYxAAQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.44,369,1505779200";  d="asc'?scan'208";a="78753363"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 11:06:05 +0000
Received: from [10.232.4.170] ([10.232.4.170]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA9B65nY028558; Thu, 9 Nov 2017 11:06:05 GMT
To: Andrew Sullivan , doh@ietf.org
References:  <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net> <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
From: Eliot Lear 
Message-ID: 
Date: Thu, 9 Nov 2017 16:35:54 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QQsFSLEb6novaOe4LNk92xsHiEu1kvRIO"
Archived-At: 
Subject: Re: [Doh] DOH and split DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 11:06:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QQsFSLEb6novaOe4LNk92xsHiEu1kvRIO
Content-Type: multipart/mixed; boundary="N63DCFKW3hrWdaTEbbT1nWqOMDODXb5wU";
 protected-headers="v1"
From: Eliot Lear 
To: Andrew Sullivan , doh@ietf.org
Message-ID: 
Subject: Re: [Doh] DOH and split DNS
References: 
 <644FB18C-3B6A-4DF2-88C9-31A0C870055D@mnot.net>
 <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>
In-Reply-To: <20171106120014.ybhkqptllbx75vsg@mx4.yitter.info>

--N63DCFKW3hrWdaTEbbT1nWqOMDODXb5wU
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 11/6/17 5:30 PM, Andrew Sullivan wrote:
> On Mon, Nov 06, 2017 at 11:13:19AM +1100, Mark Nottingham wrote:
>>  Some careful wording around the configuration mechanism should help.
>>
>> Allowing something like proxy.pac to override DOH doesn't make any sen=
se, given that the primary purpose of DOH is to NOT allow the local netwo=
rk to impose policy on communication with the DNS server.
>>
> That careful wording had better be pretty careful.  I don't believe
> for an instant that most users have a workable theory for which
> resolution mechanism they're using, and if they configure DOH and
> suddenly all the "internal sites" don't work they're going to be
> pretty surprised.
>
> It strikes me as pretty strange, too, to suggest that, if a user
> configures proxy.pac, they don't want the local network to offer such
> policies.  If the user is prepared to use the proxy, presumably the
> user is prepared to use it to impose local policy, no?
>

That was my thinking, but I will add that this needs some more
thinking.=C2=A0 proxy.pac files can contain many things to match off of, =
and
if it's an IP address range, it won't be useful.=C2=A0 If it's a domain n=
ame
or wildcard (like .mydomain.example.com) then perhaps so.=C2=A0 Also, the=
re
are some corner cases when it might not work- in some environments a
proxy may be required internally.=C2=A0 As such, when something is not
"direct" it might still be within one side of a split DNS fence, as it
were, and so the proxy.pac file would give the wrong answer.=C2=A0

Eliot





--N63DCFKW3hrWdaTEbbT1nWqOMDODXb5wU--

--QQsFSLEb6novaOe4LNk92xsHiEu1kvRIO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaBDaTAAoJEIe2a0bZ0noz6lgH/1DhVqVBFVxav8aA3L7OVrNm
wkTZB+L0k3uV3WOsLmAowCiLr4HJkBEkn5O75NX2h+8Gha8zISuTj+PW8iLebfHV
dyF42wPZVLWqsDwjPIJ1cjGEIp4u4CWWZ9oB9TU2l7giV4LM78+3ch6eSEeK8m9j
pVy9X2q5WKr8d0JVyQqanKihuMXc99XtlFhCi1iyB62ySDmZ0TvlYWUiUnbMwfzj
aISOp8dOk+HAhOqUBs4Gy20jmbsKqcwXPWc7hKSins9yO/gYyLn6Tf/g/T11ISZI
6dRFWuTcCRHcK5VjRJoy4tLGvYY7uAFgOhOWhwADU/ilx5KISUQwaN4+tGNpxqA=
=z+ZH
-----END PGP SIGNATURE-----

--QQsFSLEb6novaOe4LNk92xsHiEu1kvRIO--


From nobody Sun Nov 12 03:06:21 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E463129410 for ; Sun, 12 Nov 2017 03:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no 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 LdYW_g296gh8 for ; Sun, 12 Nov 2017 03:06:18 -0800 (PST)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id A4307128D44 for ; Sun, 12 Nov 2017 03:06:18 -0800 (PST)
Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0CB873A01B for ; Sun, 12 Nov 2017 06:06:17 -0500 (EST)
Received: by mail-lf0-f52.google.com with SMTP id a2so15377155lfh.11 for ; Sun, 12 Nov 2017 03:06:16 -0800 (PST)
X-Gm-Message-State: AJaThX4cGPOFRrw1DJsVxMPXj1mzCqO3+J8ZYXw7zoSxZAWScaDtj9BX uyG7TkiHZxjgq0vgNdEFgMbRG61GdJd9c50FiIA=
X-Google-Smtp-Source: AGs4zMasrHudar4p4xmnYeXxDbw+XKV/8XecuBfTyqv0WgSUbqjQ85r4Wb1o8ZL8dQC9MN2RDhzlf+Yk5mJb4bqKN3g=
X-Received: by 10.25.190.8 with SMTP id o8mr1349585lff.15.1510484775698; Sun, 12 Nov 2017 03:06:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.151.9 with HTTP; Sun, 12 Nov 2017 03:06:14 -0800 (PST)
From: Patrick McManus 
Date: Sun, 12 Nov 2017 19:06:14 +0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: doh@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1a1dcc7e893f055dc72466"
Archived-At: 
Subject: [Doh] DoH issues merged
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 11:06:20 -0000

--94eb2c1a1dcc7e893f055dc72466
Content-Type: text/plain; charset="UTF-8"

FYI, the editors copy of the DoH draft has closed a few issues. The issue
tracker on github is primarily a management tracking tool - merging of PR
into the editor's copy is not a declaration of consensus (though obviously
all changes are in service of getting to consensus); that remains the duty
of the chairs and ultimately WGLC. There will be Internet-Draft's
snapshotted from the editor's copy at a normal cadence. We'll try and
summarize on the list when issues are closed to help readers keep track of
the changes and potentially maintain a tighter feedback loop.

as always substantive discussion belongs on the list.

This is such a summary:

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/13 - make the
http freshness lifetime <= dns ttl

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/9 - clarify
an example is fictitious

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/7 - use
shorter parameter names

-Patrick

--94eb2c1a1dcc7e893f055dc72466
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI, the editors copy of the DoH draft has closed a f=
ew issues. The issue tracker on github is primarily a management tracking t=
ool - merging of PR into the editor's copy is not a declaration of cons=
ensus (though obviously all changes are in service of getting to consensus)=
; that remains the duty of the chairs and ultimately WGLC. There will be In=
ternet-Draft's snapshotted from the editor's copy at a normal caden=
ce. We'll try and summarize on the list when issues are closed to help =
readers keep track of the changes and potentially maintain a tighter feedba=
ck loop.

as always substantive discussion belongs =
on the list.

This is such a summary:
=


https://github.com/dohwg/draft-ietf-doh-dns-over-http=
s/issues/13 - make the http freshness lifetime <=3D dns ttl



-Patrick

<=
/div>

--94eb2c1a1dcc7e893f055dc72466--


From nobody Tue Nov 14 01:02:40 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2F124B09 for ; Tue, 14 Nov 2017 01:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 u2UAh29_yzaQ for ; Tue, 14 Nov 2017 01:02:31 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 A043C12008A for ; Tue, 14 Nov 2017 01:02:31 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAE92TLu027071 for ; Tue, 14 Nov 2017 09:02:29 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=mime-version : content-type : content-transfer-encoding : message-id : date : from : to : subject; s=jan2016.eng; bh=LELQEdz65U//qsV+JWeIu5YZDiqGzbKnT/ImQQEOQO8=; b=K89UKSHYqvsRzgQJniGb4p22sZXG6deBEgkKg30fyYAf4BZFDVgXaJgkO29YFm+dXJLY dPCaEPzaHIS18rTaENxyEzsBonQhL8YEfVcFf3/YNxMBKJR/wka88RgODBsTQuPvIStO gvanzxTP/bCdQzAWULkeA6+SZ9DIQfP1bNFLAhFSM+adFUWgH4NIOezH9LuporHR86M3 i9IeHbYBhLPhmEVljPisjXGSg9bD3JcqmDnxgjRqVCt3JzW1AO7TVc44jTfwpGlX7bhI tLvw+IHJwu9pKOHpDD8XCVLd1jUu9mkJY75FjvggAyHWsAewtx03bni1PcsChInM9b4Q bA== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2e7p3y8x5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 14 Nov 2017 09:02:29 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAE91YRA017129 for ; Tue, 14 Nov 2017 04:02:28 -0500
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2e7p4018xu-1 for ; Tue, 14 Nov 2017 04:02:27 -0500
Received: from tale.kendall.corp.akamai.com (tale.kendall.corp.akamai.com [172.28.11.28]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id B637780C48; Tue, 14 Nov 2017 02:02:27 -0700 (MST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23050.45347.520184.901957@tale.kendall.corp.akamai.com>
Date: Tue, 14 Nov 2017 04:02:27 -0500
From: David C Lawrence 
To: doh@ietf.org
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=34 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140122
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=34 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140122
Archived-At: 
Subject: [Doh] doh wg minutes and jabber scribe
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 09:02:37 -0000

For Thursday's meeting we'll need a minutes-taker or two, as well as a
Jabber scribe. It'd be great if we could get those volunteers in
advance instead of arm-twisting as the meeting starts.

Thanks!


From nobody Wed Nov 15 07:07:14 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC2A12949B; Wed, 15 Nov 2017 07:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YgfLO2_7n9hs; Wed, 15 Nov 2017 07:07:06 -0800 (PST)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 3756412944E; Wed, 15 Nov 2017 07:07:06 -0800 (PST)
Received: by mail-lf0-x244.google.com with SMTP id f125so26575282lff.4; Wed, 15 Nov 2017 07:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=mFMhGvg+P4rMIkNFdIjnPG8CZtJMVFqvC/DQJXwynTc=; b=f5Q5wKbwX+LFInwkBrjdG70fMqgeQuttYrPTkHJ2EwU4DpY8lzqONP6vTgctXSpOln IpTUDxB41ici1nmIl9d6FDfbWuSZzNoFC9HhQxh/226+USjeazLQmOn4zJdhShg1mK9o W/maIJ0xTE2iHtokzMOgZooGBOMaQ+4cuVCISXXiCC/tScx+AYbygu2jutiwg/uVNNA5 wwoLTUzn48zRHgvEkpfD5LOPa8LgUtD4l19ZDVxoRG0bcdQV/xIGs6E4feGE32UjLDrR cQNznRfW8wfCVApRXGH0irlzi0BAjNJnaUqnmKwuVlyGS5AYuuLpaNNRq1zGY2lVKNq7 3TVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mFMhGvg+P4rMIkNFdIjnPG8CZtJMVFqvC/DQJXwynTc=; b=tAad0dj5U8++BW7NyntBeuH/P1Ljmmz9HWpUd18LgnY5ydw55GHj0LE/dNFhnaGO1V DNdLJIwZKO3ieZjhZOlxx2tjSzYmJFM0wVfEGiKu+hI4nQ2ielLxV7RkJXEN68yCz3xZ 7VK/qgpRxPeule8Qf+oI8PODejbeY6SIVYjpP7+dRXfjGOM6lIuzqRmBBtT6Cfb8CcMu AkoE3alm5RGJ0g2XnU1h6xBYEn7alwT6AC2sWyuSwTN+ILkuofcM2x/ebEik/rnbTHa4 /qccgkKUj3aWE4Alpsm1wyYhT4+udOpQJdX2WWeUOnWrq8WuetCxjMQJymaB7g2DBFWW 6PcA==
X-Gm-Message-State: AJaThX6DlbeG8sLguj6Vq4fXXwLNyayJ69pIMWNFiN6VSammkMl/jE/z Fe17sWSo+AKpgPL9RucZpw/EjYa8D2CLnUWvmBiX1ETZ
X-Google-Smtp-Source: AGs4zMbCfpHbcf8tx6M5opI8O0+9nvBgxcbmvfjudElAjygenCszhy7mj/cA1JdnS/o2ggp+g8a0A9e2ZLh4gouvnRI=
X-Received: by 10.46.16.76 with SMTP id j73mr6560370lje.170.1510758423997; Wed, 15 Nov 2017 07:07:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.150.200 with HTTP; Wed, 15 Nov 2017 07:07:03 -0800 (PST)
From: manu tman 
Date: Wed, 15 Nov 2017 23:07:03 +0800
Message-ID: 
To: dns-privacy@ietf.org, doh@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1a647e3433ba055e06db37"
Archived-At: 
Subject: [Doh] DOH proxy
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 15:07:12 -0000

--94eb2c1a647e3433ba055e06db37
Content-Type: text/plain; charset="UTF-8"

Hi,

As mentioned during the DPRIVE BOF, during IETF 100 hackathon, I hacked a
proof of concept DNS-over-HTTPS proxy.

At the end of the hackathon, it was using HTTP1 and only had a test client.

I got a stub resolver working today as well as using HTTP2.

The code can be found at https://github.com/chantra/doh-proxy

The README has example usage. For the stub and client, there is a hidden
`--insecure` option that will allow to run the stub against a server with a
self-signed cert.

Keep in mind that this is only a POC, so don't expect all the goodness of
HTTP2, TFO, 0-RTT, pipelining, connection pool... to be leveraged.

Manu

--94eb2c1a647e3433ba055e06db37
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

As mentioned during the DPRIVE BOF,=
 during IETF 100 hackathon, I hacked a proof of concept DNS-over-HTTPS prox=
y.

At the end of the hackathon, it was using HTTP1=
 and only had a test client.

I got a stub resolver=
 working today as well as using HTTP2.

The code ca=
n be found at=C2=A0https:/=
/github.com/chantra/doh-proxy=C2=A0

The README=
 has example usage. For the stub and client, there is a hidden `--insecure`=
 option that will allow to run the stub against a server with a self-signed=
 cert.

Keep in mind that this is only a POC, so do=
n't expect all the goodness of HTTP2, TFO, 0-RTT, pipelining, connectio=
n pool... to be leveraged.

Manu


--94eb2c1a647e3433ba055e06db37--


From nobody Wed Nov 15 22:15:18 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C916B129510 for ; Wed, 15 Nov 2017 22:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RTgxJdBLFoGG for ; Wed, 15 Nov 2017 22:15:14 -0800 (PST)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 B9FAA1294D8 for ; Wed, 15 Nov 2017 22:15:13 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id z14so3627388wrb.8 for ; Wed, 15 Nov 2017 22:15:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=8BTUTW7TpeoD566QHwypGGRV0nsvQrGCmq4og0DIzuc=; b=uLewkhl4NgKvzzgxR/bz9H0HTnxTo2134W64dob4JeTdb5WOWTC2nXndrAqZXhTMp8 4xYEEEx+0BWFCO2QYDILr0KqKWLBwfMpeAOiRQxCaZYnfyiktHTkHZYWAfadQUzD0xv6 4m/oOIhec7VC0M4zrbzYc0L5sUxACrwKIzW2I5s61RXV+pz2rdOnog9/S5cdTyVQN0C3 VGM7NXoG9u11G2nj6yns4hJSpXIEt3UnOMyHSotd0teNnUaEx55iteulvdgaD27hxeYB tjNiMz4/Pw7TWD794TXeE9S4OMXZ7700XC2F2QkZo/eNgvzjAaf8Iu6YbLPgHjpDXT1+ SSqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8BTUTW7TpeoD566QHwypGGRV0nsvQrGCmq4og0DIzuc=; b=E6SVDfHxjFkVlQGyAmsi+kOFSS+4uyP/eaimQ+w/+U3KsMyS9pmP2NiE95rQuYFXup CVs1IrcwlZYsQCnOy/tqg3Fuu1AmE1rZXSvkrYjRXbUKkKWW0+Q30X1T59kuSMIZKLBJ 8UxzCBcSxawJiscv/SZm70PhxVPv5gAihgyLN8IHVQL4IB7HB2AuUn4P/LQalRP0KCFm d9gihrDbCPGcezvZw3CrGuX1qYjhfCyxO8CG615FjRNU278Yea28NmveqEqO71fH9iAy /Q7dsZFZj94tdiAFNxtzImdAP/y8eMcfYhAUuSW/2O5QgcvsMjocQMGgnmTkTYwc1+vg PwMw==
X-Gm-Message-State: AJaThX53MP/IAbbeFZNrKq5LJMGjeDit3sfMZheDYSLR4npxupdvrvBS WBm+PqNs/oUPUpzuyvDqOQk2ZKAZuH/DHmjEZN21Tw==
X-Google-Smtp-Source: AGs4zMbOCmoaskcO30cnpc+FDst9N93Y65Xp2oK+X6Aw0Lh34ZxmtKxXafJemjTz2dYjX7I15ufZtq/JDyE6hFGZIBo=
X-Received: by 10.223.168.23 with SMTP id l23mr429751wrc.15.1510812912131; Wed, 15 Nov 2017 22:15:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.146.229 with HTTP; Wed, 15 Nov 2017 22:15:11 -0800 (PST)
From: tjw ietf 
Date: Thu, 16 Nov 2017 14:15:11 +0800
Message-ID: 
To: doh@ietf.org
Content-Type: multipart/alternative; boundary="f403045f4f4af3220c055e138af8"
Archived-At: 
Subject: [Doh] DNS Terminology documents
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:15:16 -0000

--f403045f4f4af3220c055e138af8
Content-Type: text/plain; charset="UTF-8"

This is the draft

https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis

--f403045f4f4af3220c055e138af8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable






--f403045f4f4af3220c055e138af8--


From nobody Wed Nov 15 22:16:14 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9228129510 for ; Wed, 15 Nov 2017 22:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DfNLgefN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AoYGYPG9
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 1PsYeOEddQ2x for ; Wed, 15 Nov 2017 22:16:10 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED7F1294D8 for ; Wed, 15 Nov 2017 22:16:10 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1098621165 for ; Thu, 16 Nov 2017 01:16:10 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 16 Nov 2017 01:16:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=OiLmS0N0Oi/gMBythzqwyN0hxUsHJPBbSSTihqEembw=; b=DfNLgefN 8RwY3JCPEF+Jz9B+5BZ+/NZCNQP+RVOP48syKzh7qDReOewOhy0YWa5/Wvk1lX4Y vUFfu2FnisS7QRuL0I7iiaJoH6BM4bNaBaBzHTmZkCRjZHpdCoRAj5yH5oSfuOO6 GGBy32pKpDs7VMasyWKbVhUchCXNDD1x6SwREJIptIxoxe9pcTFccbjYUORPXisY 0zl89F7Dswj/xdJVdWD0bnl0gBCOUDvX62v94J4jPBd+yrNjCSvw4s9e5spj1O66 udPjg1WWfyaBI6IxegAAn5o1/EUATvBPZekI338swbmecGyeiYIYvAqUUYgGn9j/ UlFeUJJU7BZAjA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OiLmS0N0Oi/gMBythzqwyN0hxUsHJ PBbSSTihqEembw=; b=AoYGYPG9zAL+71JQlBEKdgNSQMoaq3hChOXRXdBFIk3j+ cnJvlMltvFvGN//MABHeiB3CTC7c7qr1PbkPssa38jwA7U078wyFuFWFLwQ82YC4 fZt3tZ59I7Epmq/mgh5xWv5vL+LjGWBfprwGYGw9DaK3vPSA9gDgivVSGT3ASIQ1 kkm7DPtXy16h3E2KL5rdB5NO05zIlJ02brtDLRZLe+/TmK9otJoGFVSLCwtc6Ky0 HP3j3y+qPK1oQ4QmiJ4eNz0nxA6knDMbchxL9pdXrbwMeFKhI7evz2mdJHk4WFx/ mUQgvE7drRrCnYVhYr8IQtAb1TH60G4ZZOmcc7stQ==
X-ME-Sender: 
Received: from dhcp-80a4.meeting.ietf.org (dhcp-80a4.meeting.ietf.org [31.133.128.164]) by mail.messagingengine.com (Postfix) with ESMTPA id 47D0F7E804 for ; Thu, 16 Nov 2017 01:16:08 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <315BDE22-68DE-47CB-856A-785986A908E9@mnot.net>
Date: Thu, 16 Nov 2017 14:16:54 +0800
To: doh@ietf.org
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: [Doh] HTTP documentation
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:16:13 -0000

... is at:
  http://httpwg.org/specs/



--
Mark Nottingham   https://www.mnot.net/



From nobody Wed Nov 15 23:53:19 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E25126DEE for ; Wed, 15 Nov 2017 23:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nTnVM6Oi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AxDJ/BFM
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 pyYL5H1PGglK for ; Wed, 15 Nov 2017 23:53:16 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC89A120724 for ; Wed, 15 Nov 2017 23:53:15 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2253B21627 for ; Thu, 16 Nov 2017 02:53:15 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 16 Nov 2017 02:53:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=rSkVUHYtmQ8ML4qjA6Pkp4sytDH+elQq2nyTK/R8GXM=; b=nTnVM6Oi JdIV9AOE9SN88Uq7gF438ThooKrXULEXbjSQAysG9OnK2QsGKVS3UCPahMG4UP6o JCZvIAM+ih9deuSxejBRAzwjdsuzh4CRI6lO25dVNbjGPCp2PExIOw9QQAOM1AEp T+JyzxajCLUKtPQqiigXPYDjpmh4JjCx9RW8zdHjepob4Y5TEvE7omOjMHwr4zPn GthrVQ0MGgfImk9ULNlWm4Fu/SOq1Byj5xB0fAkpnM6ztNXSAmjEk6wvncARVsHf 9wwbIAZcdt2fC9tbsJYus910Z0t0+20N9ky5Mx50k/XYkHNnLWzXRaIOV0k/rvB3 BpdI8qGVg+Bbvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=rSkVUHYtmQ8ML4qjA6Pkp4sytDH+e lQq2nyTK/R8GXM=; b=AxDJ/BFMycghv928e4jGainHsOmdvizVKK7wvhIBzFPf1 5rccq5LayAEAxwE0eo746wpZ3+kSWVdPmb4sE5YAXmb+C6LNCYL6nH3HEIcbuXwm 4YCa5PLPZF7/J63+h7EzE+1pJwFfdj+iHaAKQgVwyOaOvicMizCtjraflhiPZ9yY lw0iJrFpildIzZjxY0/uSR8HlCyQBzOWX+UhW2p9XQV3Pl/h/ZQS+xciAFxAoLL4 YvFZ+qgyiWndmAxjfuw3GtMrzYth+GlxGXDmckbBQrOwqQHv7Z8KZGnufGTdfyay 3/6IVsCG2mQdqRcXVo5sAExh2P7d3tBMUewrA/pkA==
X-ME-Sender: 
Received: from dhcp-92b4.meeting.ietf.org (dhcp-92b4.meeting.ietf.org [31.133.146.180]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6A37FACF for ; Thu, 16 Nov 2017 02:53:13 -0500 (EST)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
Date: Thu, 16 Nov 2017 15:53:59 +0800
To: doh@ietf.org
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: [Doh] Use Cases
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 07:53:18 -0000

In the meeting, I said that it might be helpful to have an explicitly =
defined use case. Paul mentioned the document already covers this:

"""
3.  Use Cases


   There are two primary use cases for this protocol.

   The primary use case is to prevent on-path network devices from
   interfering with native DNS operations.  This interference includes,
   but is not limited to, spoofing DNS responses, blocking DNS requests,
   and tracking.  HTTP authentication and proxy friendliness are
   expected to make this protocol function in some environments where
   unsecured DNS ([DNS]) or DNS directly on TLS ([RFC7858]) would not.

   A secondary use case is web applications that want to access DNS
   information.  Standardizing an HTTPS mechanism allows this to be done
   in a way consistent with the cross-origin resource sharing security
   model of the web [CORS] and also integrate the caching mechanisms of
   DNS with those of HTTP.  These applications may be interested in
   using a different media type than traditional clients.
"""

That speaks to the motivations, but not how it will actually be achieved =
using this protocol. I suggest:

"""
3. Use Cases

There are two initial use cases for this protocol.

The primary use case is to prevent on-path network devices from =
interfering with DNS operations. This interference includes, but is not =
limited to, spoofing DNS responses, blocking DNS requests, and tracking.=20=


In this use, clients -- whether operating systems or individual =
applications -- will be explicitly configured to use a DOH server as a =
recursive resolver by its user (or administrator). They might use the =
DOH server for all queries, or only for a subset of them. The specific =
configuration mechanism is out of scope for this document.

A secondary use case is allowing web applications to access DNS =
information, by using existing APIs in browsers to access it over HTTP.=20=


This is technically already possible (since the server controls both the =
HTTP resources it exposes and the use of browser APIs by its content), =
but standardisation might make this easier to accomplish.=20

Note that in this second use, the browser does not consult the DOH =
server or use its responses for any DNS lookups outside the scope of the =
application using them; i.e., there is (currently) no API that allows a =
Web site to poison DNS for others.
"""

--
Mark Nottingham   https://www.mnot.net/



From nobody Thu Nov 16 00:32:36 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD1126BFD for ; Thu, 16 Nov 2017 00:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 fKXcPNuB-0Yg for ; Thu, 16 Nov 2017 00:32:33 -0800 (PST)
Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5847124217 for ; Thu, 16 Nov 2017 00:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5119; q=dns/txt; s=iport; t=1510821153; x=1512030753; h=to:from:subject:message-id:date:mime-version; bh=MMxuiaeRlmQH1YwV3Yl5PZxSCKVmJ6CmaPgY96frrV4=; b=C+ONpSgfWDBC7OgtcFqCY20aHlWGd4QUTl5+Ju69XYI+8SHD96gldC4V X4dY1VhOo0SceU6lNBSwagUd6HSNQA0GPAWVeyjtPUM2kRZN6La94Vicz oFYrKKvgyvOx3f/JabP3dZ2JEKJP3hFaR28KCNDZcQLiOBHfSLRpczMrI g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AQBCTA1a/xjFo0heGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUIhCaLE6E+hUmCEQcDixIWAQEBAQEBAQEBax0LhUh1PgJTDA0?= =?us-ascii?q?IAQGKIKlVgicmim4BCgEBAQEUD4M0gWaDXymIA4MrgmMFijmIS48zhEeCJY4ai?= =?us-ascii?q?3+HRZYugTkmCieBdDQhCB0VSYJlhGs0i2IBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200";  d="asc'?scan'208,217";a="44511795"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 08:32:29 +0000
Received: from [10.70.234.2] ([10.70.234.2]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAG8WSkZ013799 for ; Thu, 16 Nov 2017 08:32:29 GMT
To: "doh@ietf.org" 
From: Eliot Lear 
Message-ID: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
Date: Thu, 16 Nov 2017 16:31:43 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5ccs5LPPrxCcaAirO4tO7OT558rcWEvAO"
Archived-At: 
Subject: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 08:32:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5ccs5LPPrxCcaAirO4tO7OT558rcWEvAO
Content-Type: multipart/mixed; boundary="jUQwi0crHU12baRTRQbiAMPrh0kHF6nKr";
 protected-headers="v1"
From: Eliot Lear 
To: "doh@ietf.org" 
Message-ID: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
Subject: operational considerations

--jUQwi0crHU12baRTRQbiAMPrh0kHF6nKr
Content-Type: multipart/alternative;
 boundary="------------134DDEA3A006B7CE20105714"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------134DDEA3A006B7CE20105714
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Before I get into the operational considerations part of this message, I
agree with the idea that it might be useful to have a wiki to build out
text, particularly if people find other operational considerations to
address.

What we discussed was a paragraph to talk about operational
considerations.=C2=A0 Here is what I propose as a starting point.=C2=A0 I=
t's not
that long.=C2=A0 I propose not to add text around GSLB/the EDNS option.

Operational Considerations

Because DOH uses an encrypted channel that may extend beyond an
administrative boundary, several operational issues may arise.=C2=A0 We
discuss these below, and provide at least one possible mitigation for
each issue (there may be others).

  * When used, split-horizon DNS provides different answers based on the
    source of a query [RFC6950].=C2=A0 The common case of this is an
    enterprise that does not expose the existence of internal services
    to the outside world.=C2=A0 If a DOH server residing on the Internet =
may,
    therefore, provide an inconsistent answer than an internal resolver
    would.=C2=A0 To address the common case, a DOH client MAY contain som=
e
    configuration, such as a list of local domains that should use UDP-
    or DPRIVE-based queries.
  * Many deployments review DNS queries and responses on the wire to
    detect for malware or other policy concerns.=C2=A0 Where such exposur=
e is
    required by policy, DOH the user may wish to not configure DOH.

Eliot


--------------134DDEA3A006B7CE20105714
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
Hi everyone,

    
Before I get into the operational considerations part of this
      message, I agree with the idea that it might be useful to have a
      wiki to build out text, particularly if people find other
      operational considerations to address.

    
What we discussed was a paragraph to talk about operational
      considerations.=C2=A0 Here is what I propose as a starting point.=C2=
=A0 It's
      not that long.=C2=A0 I propose not to add text around GSLB/the EDNS=

      option.

    

    
Operational Considerations

    
Because DOH uses an encrypted channel that may extend beyond an
      administrative boundary, several operational issues may arise.=C2=A0=
 We
      discuss these below, and provide at least one possible mitigation
      for each issue (there may be others).

    

    
    
      
  • When used, split-horizon DNS provides different answers based
        on the source of a query [RFC6950].=C2=A0 The common case of this=
 is
        an enterprise that does not expose the existence of internal
        services to the outside world.=C2=A0 If a DOH server residing on =
the
        Internet may, therefore, provide an inconsistent answer than an
        internal resolver would.=C2=A0 To address the common case, a DOH
        client MAY contain some configuration, such as a list of local
        domains that should use UDP- or DPRIVE-based queries.
    • 
      
  • Many deployments review DNS queries and responses on the wire
        to detect for malware or other policy concerns.=C2=A0 Where such
        exposure is required by policy, DOH the user may wish to not
        configure DOH.
    • 
    

    
Eliot

    

  


--------------134DDEA3A006B7CE20105714--

--jUQwi0crHU12baRTRQbiAMPrh0kHF6nKr--

--5ccs5LPPrxCcaAirO4tO7OT558rcWEvAO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaDUzvAAoJEIe2a0bZ0nozSXoH/35IrfSke+Qsb+4yhttq5pBt
n9GWWW6WcBViN/4mvSzqCkr3R5EvKjrLP5FUUGW+PUN+oE5/NNfsSP1Ff2JWIDJV
jdHbb1yA13B61t+42bjUb1JGz9Twoy70bYGNvhSK1dnvtLCHLzo3SxHN5Gb9j0me
Z4AjqFMK2SUYtJjD4Q4qbw+GoT052Bjn0cuiwzhsBo/V8Dm+wJrtJTLsm7V939NU
5CSS6MAIP2S43xbIrh0ac4GU9FTuUA8pmQT0Usyf3i44wDjMjRlJ4Qfq1lwvPIy7
k+Mcd72xVik38CB5HnDTel2AL8P3MxyOJTsb+Ksbv1thcfU0jo154i/xQoBoq28=
=84gD
-----END PGP SIGNATURE-----

--5ccs5LPPrxCcaAirO4tO7OT558rcWEvAO--


From nobody Thu Nov 16 01:48:05 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13EF128D0D for ; Thu, 16 Nov 2017 01:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 OFv1vU-g5YbT for ; Thu, 16 Nov 2017 01:48:02 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 EA865127201 for ; Thu, 16 Nov 2017 01:48:01 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAG9lvNB009299 for ; Thu, 16 Nov 2017 09:48:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=mime-version : content-type : content-transfer-encoding : message-id : date : from : to : subject : in-reply-to : references; s=jan2016.eng; bh=yfznWgObudaglyl5QkwpPentMh8JdaKe2SUvc5S0FZU=; b=Fxnm0JYkIxjJqI5wzh7C4aNibr+Lwm7bj6boQZ4hiDginOX6JUdesS6dGRe1sL98M/Gv 6m1ejGJDUkeQQ63jPHclasirIMJThRuwGga9pPFvDIk1llSp4JnsdegGfK+iZIUw661Q Ap5SPlu6ftP935ctxjmqngjfIGCuKetvcADYOV/SXbEnMZUMAGPrax6hl2cNQjLhLl1E VDdHJ+MI7BrleBvFhhxvb+kQJfCT7YAF12NhgzHATwLkM9MB0IXPzmngDWlRIal8i9Ys 7AYbLbt9n8y0YMk433zYgTuSCLkNWJRXdUSs/rkKfYbjnAOODyxg6KF48cCArkSPruhu JQ== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2e8d5km4xr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Nov 2017 09:48:00 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAG9kpiU031764 for ; Thu, 16 Nov 2017 04:47:59 -0500
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wrvsy-1 for ; Thu, 16 Nov 2017 04:47:59 -0500
Received: from tale.kendall.corp.akamai.com (tale.kendall.corp.akamai.com [172.28.11.28]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F3FA832D10; Thu, 16 Nov 2017 09:47:58 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23053.24270.974074.930141@tale.kendall.corp.akamai.com>
Date: Thu, 16 Nov 2017 04:47:58 -0500
From: David C Lawrence 
To: doh@ietf.org
In-Reply-To: <315BDE22-68DE-47CB-856A-785986A908E9@mnot.net>
References: <315BDE22-68DE-47CB-856A-785986A908E9@mnot.net>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160135
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160135
Archived-At: 
Subject: Re: [Doh] HTTP documentation
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 09:48:04 -0000

Mark Nottingham writes:
> ... is at:
>   http://httpwg.org/specs/

FWIW ISC also keeps a list of DNS specs, although not as an official
IETF thing.   Have fun going through all bazillion of them.  I didn't
count them exactly but if all the blocks are 20 each, it seems that
they've currently got 185 RFCs catalogued:

https://www.isc.org/community/rfcs/dns/

Once upon a time there was an effort to harmonize all this into the
one current source of DNS specifications.  It didn't go well.
Occasionally the thought crosses my mind to try again, but then I
quickly regain my sense of self-preservation.


From nobody Thu Nov 16 02:17:17 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93052126C2F for ; Thu, 16 Nov 2017 02:17:15 -0800 (PST)
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] 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 RBhQL67ADsis for ; Thu, 16 Nov 2017 02:17:14 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 812191200CF for ; Thu, 16 Nov 2017 02:17:14 -0800 (PST)
Received: from [10.32.60.89] (dhcp-8904.meeting.ietf.org [31.133.137.4]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vAGAFgP9097771 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2017 03:15:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host dhcp-8904.meeting.ietf.org [31.133.137.4] claimed to be [10.32.60.89]
From: "Paul Hoffman" 
To: "Mark Nottingham" 
Cc: doh@ietf.org
Date: Thu, 16 Nov 2017 18:17:01 +0800
Message-ID: <2F9A25F9-920E-4E69-BCB6-52578D92DF6F@vpnc.org>
In-Reply-To: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
References: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: Re: [Doh] Use Cases
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:17:15 -0000

On 16 Nov 2017, at 15:53, Mark Nottingham wrote:

> """
> 3. Use Cases
>
> There are two initial use cases for this protocol.
>
> The primary use case is to prevent on-path network devices from 
> interfering with DNS operations. This interference includes, but is 
> not limited to, spoofing DNS responses, blocking DNS requests, and 
> tracking.
>
> In this use, clients -- whether operating systems or individual 
> applications -- will be explicitly configured to use a DOH server as a 
> recursive resolver by its user (or administrator). They might use the 
> DOH server for all queries, or only for a subset of them. The specific 
> configuration mechanism is out of scope for this document.
>
> A secondary use case is allowing web applications to access DNS 
> information, by using existing APIs in browsers to access it over 
> HTTP.
>
> This is technically already possible (since the server controls both 
> the HTTP resources it exposes and the use of browser APIs by its 
> content), but standardisation might make this easier to accomplish.
>
> Note that in this second use, the browser does not consult the DOH 
> server or use its responses for any DNS lookups outside the scope of 
> the application using them; i.e., there is (currently) no API that 
> allows a Web site to poison DNS for others.
> """

This seems like a good replacement.

--Paul Hoffman


From nobody Thu Nov 16 04:04:20 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E7129480 for ; Thu, 16 Nov 2017 04:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 lgemRwZ3yuJ0 for ; Thu, 16 Nov 2017 04:04:17 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 7BCC412947C for ; Thu, 16 Nov 2017 04:04:17 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47314) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eFIu0-000jda-0c (Exim 4.89) (return-path ); Thu, 16 Nov 2017 12:04:16 +0000
Date: Thu, 16 Nov 2017 12:04:16 +0000
From: Tony Finch 
To: Mark Nottingham 
cc: doh@ietf.org
In-Reply-To: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
Message-ID: 
References: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: 
Subject: Re: [Doh] Use Cases
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 12:04:19 -0000

Mark Nottingham  wrote:
>
> That speaks to the motivations, but not how it will actually be achieved
> using this protocol. I suggest:

I like this suggestion - very clear.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: West 7 to severe gale 9. Very rough or high. Squally
showers. Good.


From nobody Thu Nov 16 23:15:47 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB83128C84 for ; Thu, 16 Nov 2017 23:15:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 spO_a1sTF6xm for ; Thu, 16 Nov 2017 23:15:43 -0800 (PST)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0099.outbound.protection.outlook.com [104.47.93.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2194E12741D for ; Thu, 16 Nov 2017 23:15:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kVyLQkHR7cB1AsocGGxbKCj3UZjtraqSFsnS9tY1UuM=; b=rzylj0eYyUOlytvNjs0Fu89oTbV+UwePyDcoflyASr2Snf7UabiKA0tHmSne1D8QkkG+23Kxgb+YDTi8K42DwX0bY/W0zY3bRPd3bhhl7FTmirx0L7jyVC7GGr+wFrgnGLNW6ftqux5ZGdcxnCjrlnQEJDLZh3U2xjqtZQST2xo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; 
Received: from [100.70.12.254] (133.2.59.36) by KAWPR01MB0243.jpnprd01.prod.outlook.com (10.161.28.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Fri, 17 Nov 2017 07:15:39 +0000
To: Eliot Lear , "doh@ietf.org" 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= 
Organization: Aoyama Gakuin University
Message-ID: <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
Date: Fri, 17 Nov 2017 16:15:35 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [133.2.59.36]
X-ClientProxiedBy: OS2PR01CA0123.jpnprd01.prod.outlook.com (10.174.152.17) To KAWPR01MB0243.jpnprd01.prod.outlook.com (10.161.28.142)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4163882f-36c5-41f7-2687-08d52d8b0249
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:KAWPR01MB0243; 
X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 3:U06HFs1WT1rAaHCnM3NgsqG1Lw6jAy5Pp7wajfkMLUv6jmbSqJDdO3c6NVTHBcpEgp3kKho0kIuZRNSHyA5NPG6t6LzhaaSnVk0jkcv/MPLGBVCo/3TsWLHv8lD+E7dRRl79gxf9+AjdLQCS4e1cIwrCb74Ao4umGoaVXyImidtQCTPneblRkTSFCep+syxKXsQaM9P4KfdcXhCETu1kh4STbSyc+0MqRhGcPlde2EzaxqrBHePhYv6qfcZMbmor; 25:O4novMOUVDp5fTZQU4AySi1L5tnGy9g6PaX78DwapgtDM38S+VNKWDT3QZCAW4yzZAKpiwNE9u6OnsF9tnjpUj28maBPHtnpfOgH1X185asjnxTmIAqPxef0o4BK1Zo9vNVx3toBSWEXuJci9xeYLCOUZdMy3QQbgLZJPizXreDE2O0/EiAf7N1A2Q5cQKK5YIB0AAFypZEOQn9ClY/jmBV9hiG9RoXyoIV9t7/hsfe0Vp2CtNNPmrXOQe3fw2Z6ynMn/rxJ0g9vufzeYHRwzRNGzSja27FFqPXfljiJFCNVP+oL2q+i1ZGucLjKcIkoqbL9prwX0vc1k166DZpxIA==; 31:mpJe0DjlFUvMU/e/LWnQhpZOCATIHXMw6kQzfAdS9QECXNHG5OkdewDLFj3Put/oLwsD8MUlcsaDYVQTy4Qs1TGAyi7TMpM8QjFfBkyqqK/V/3NfosO9TIVT72RPnT9jxnegPNRFdjAzm+VFaw1RHuETwgL/5Aq60V6jyvu1s7QyHZjRwWud7MshDCKm6SY1FnFueZZoGG1truLzVJbVLFbYpPlCcix1mftkpPn01JA=
X-MS-TrafficTypeDiagnostic: KAWPR01MB0243:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:KAWPR01MB0243; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:KAWPR01MB0243; 
X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 4:xCeqOO8/FNw+1HVFuGzMTKsU4wfvDrDQe/Kne11BdDpfZo5hf0+XP2c/ovpdJ/FNLm/Y4SgUTphv0WCV7MtxtAjg+xKTfARj2S/M51bApaGX4nka6S5brlJOXZiKHXMY+TqC1KVzOQzQrbb0Xgavsvi2qB9fDvoh2ONr57i9ew0yGXfky7XoHb6VTeXKfUny75MmbxUWONumixi+Zkrtf0OIRr0MSCindQhSeai2U91y8e8mMWqPTOdGF1JTEmQ8kQ7wi4Zyc5VehgJ1k9axnGUk65JuwfEXBKIMOAE/5H1DwA/SQ7/VYbGvaJZuvkc3
X-Forefront-PRVS: 049486C505
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(39830400002)(376002)(346002)(189002)(199003)(24454002)(316002)(106356001)(49976008)(478600001)(67846002)(81166006)(23676003)(8676002)(101416001)(229853002)(33646002)(81156014)(83506002)(53546010)(50986999)(54356999)(31686004)(90366009)(305945005)(7736002)(74482002)(76176999)(68736007)(2501003)(110136005)(6246003)(5660300001)(16576012)(58126008)(786003)(25786009)(16526018)(2870700001)(3846002)(97736004)(189998001)(6116002)(50466002)(2950100002)(42882006)(8936002)(6666003)(6486002)(2906002)(65826007)(31696002)(47776003)(105586002)(64126003)(65806001)(53936002)(65956001)(86362001)(66066001)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0243; H:[100.70.12.254]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMjQzOzIzOlpFRWhFbkdYWlF3NkxMT0pxSWJjc2hDTnZl?= =?utf-8?B?V3BBZS9Bak9rS1FhYVBNNVF3Z1d6SFFhL2dMSFhCZTFlT0ordmhIV2pIMkd0?= =?utf-8?B?aTBzeEVBdVY2Y1hwN0VTdHBrTTRIYUFmMXZuNldmbDYzQkI0VFA3S2VLa2xY?= =?utf-8?B?b2xJY2lsaVBsc2g3OWdHZXVZcUpJTGlNU1duYU9uZ0hMcTE3YVRQMDQzS211?= =?utf-8?B?MXQyUDJJSlYraWo5cFY4dlJMb0NNTjlmUEJYSHd1NjkvcG00ZHdBMVlNRDJC?= =?utf-8?B?ZU1jNHp4dzVXaTUySDM2czFCK2ZJV0FhNkpWTDhOVkZEWkRtWkVJWUdtSDEv?= =?utf-8?B?QnY2WTB0amEwLzVBK2NmRGVjcDR1ajMrNzdGRCtXMTN0YU02WjY0bUFRVXl5?= =?utf-8?B?V3NqU3hmdmJVWGZyWDgrTXFLemplTVhiQ0dkOTcvendhUHJmaTlET2M0WFFi?= =?utf-8?B?VGlRK2Z3L2w2L282QS9xNHhheFBrRzhKemVGb09TbEVjOVlYSzN2UDdFd21q?= =?utf-8?B?ZkNySHRvSFZyZkJyVm9TaTdTSEVKTGp6YitzRDlNeVhhNmN0L2NYbGRJQWdZ?= =?utf-8?B?NlNEQ0VqcmU3RzRUeHEyOEJGbDlXdUtxTWtQbmpkNkJuRjBPWi9xL0I1YlFs?= =?utf-8?B?bno3M1BCL3MrNGluQ01UejlKMk1FNFFvbHkzeEo5eWlESm54QzFFZVF3b3hp?= =?utf-8?B?WitXMGRhSFppbHR0eFBxekxwQU9XbHN0VERxbkFXL1IvNU42MHlVbGswMTd1?= =?utf-8?B?SVRNUFo0dytZRUZHZDNXbEJPNjJPNUJiOXBmTGJER2c0elIyTDdQUmZwS0p0?= =?utf-8?B?dE9peEJtVDhJUWtmQmhWVWdOSXAzVnlWa214R3NjME5HRGV1dEJLMGpWNE5q?= =?utf-8?B?YW9GTld2SUNaZWtyaE1oUFp5N0VjNDkvMXg3eDZVaGFGaU5ta2RIMW9mamR1?= =?utf-8?B?UVorbktVVVpLem8xWXNxaDhtdkh4MlpuZ3FKS1MwVmI5Smdlb0ZSQ2lBak8r?= =?utf-8?B?cCtXeFpKNHp0eHNJNHM1RTNRM0xQSVZyNUlObFBXZzFUOERuMEt5TDlvd0hW?= =?utf-8?B?cUVFazFVK1J2OTk5bmdWVHhyMHVTUnpkR3RCZklWR1RBeUZvbEpVZWQxeklT?= =?utf-8?B?Szk4UWhpWmtCYlVUSVhLTFFVZDZhL1VRUWpFOEptZlAzUlQ3RDBxWUlyRmFT?= =?utf-8?B?WVF4OU5sV0ZlTmd1S1dZZy9QbW4wS2tjOFAzV3RBdzlMNWNpYStnczhJU1dY?= =?utf-8?B?Wkt6NmQyRDFjdWZPbituYUFBeEcxVmlzbWRCNkJkbysxNTk5YitnNkt3UGRO?= =?utf-8?B?UFd4RU9hUGJod3BENm5ac3F0aGgrbVpBdmlpRGJuZmJrWWUzVDRIS0dCcTU0?= =?utf-8?B?RnA0YXc5Y3EvNkU1eUtnNDVRQ0FsdXk3VldmWk9qUkNjOVU4T3NJUXVUb1NR?= =?utf-8?B?ZTdLczV5QWxncVJTQ3Q3eVZpeFFLWnFPT1NzTWtqRlRkc3lkakpBWm1LK01o?= =?utf-8?B?MmpVU1pwUEF3S2dsd3N0Y0RLcDBsTDIxRGw2UTFNMEJ0QnVCQWNXRUYzOWJG?= =?utf-8?B?YnczQng5aWJhbk15OUpiYTFvd05Wb1FRQkJBYlFvQ0l4VzlJMXZoQjFTTERs?= =?utf-8?B?QXlGTjhVRjRqdmhFTlJsS0NRUU1QWllzV0ZaL3JRaXZ3bzZIc1FGUWlDbVBo?= =?utf-8?B?dG5BemRJTkhCVTF4blRWTkhBeXNIa0RCajdVWm0vdytNbUJLTkdKN3dzTnZk?= =?utf-8?B?eU11NTBqZGZVa1ozaStQcDlIVTRqTHd2U0JaZnExYno3WTJzR2YyM0hFdzd5?= =?utf-8?B?V1l3M2IrYmUrZ04xTElSeFREYkMrdm4wWW4zNXZSV2FFTWhLWXU2SzAwQVgw?= =?utf-8?B?SVJSZXNVNUYxN2ZKcUVBUlZCbEpiTmZ1c1hNditjNlprU0JOSlMrczdVS0hH?= =?utf-8?Q?ng20vOAtHpC5AT0b86Fn1RZTuzZRgE=3D?=
X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 6:eJVeHBS/m4OXvD77i42p6hbej7CxUPEfw229rt9UZLHVk1OmsMWG+oiv4xFm9nTxH/PmwazAYEkI92oD+1PAXCFpU3p/TJPupSX7rfllnGfIW+jNSiZj1pqXQW33vS7TBXO0661O94MhhdVvqj4YPDKj6UI8OIPgqWco1ynCgwHR3l7775AE21EVsHenq9rw6wQfoICBNj7oIcTFGpPVP2z+F2Cjojv/0fDz8dm0UxG+LtKwp50pBHR1hxzl6ifCo+f9xb/FRTrUmDFhO+HHAnR16DpwCL/iRZnQxQfEKceIYTJ8kDP9Y8OXjxrIsyT5ZiSLo3M3+hXX6BdDNFgCOtS2SMHP2BwsBt47cpRYrb8=; 5:DGszc4EjF56z3C/kK3Yn9O2mzAPVl4+C4OT5wl7Cf6nw07BCfurMTtht16TF7uArnQaXZSoUh75an8p1WRFX7D6XunxH9N0Y6I+XyhRWn++U7vCEY8cn+6AcuVboyp7/sXT9q20ZNtgWcX70whzerZlb9n/kYBuQXpNbC0FZNVE=; 24:xgjGtFQbo2PLlB/MY348XV6qasXzhnKdbI+NAsQMZBrt6NrWw2+6b7YOTc3J68LAOh4bI46JYWWGy8o+JRj8aR0HVTdRo8vFtKWZ8MeP6Tg=; 7:Hbm+M3yEeOd/trG1OtUBmNSyClusHCB/JSpGZg/uywt6CQWhWY6g1D2XQauTjVW9Dkectz+zpO9HWPNf+IRXiCsy0dfWr5T11asJe+XdivDEjZKUg1Ocv4BBzEBAaYwBiikTPq3Fir0u0tkrWFhCsmfDtInBXbCgz5489t8kaKC2pO1EnexVV2mSg53Hx2k7+tFcYx3fMMFlDzhEGjVepShzpk5ox1+SpPcvhQImwt/99ZRCJB7UkGBDDYl8/7IB
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Nov 2017 07:15:39.5001 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4163882f-36c5-41f7-2687-08d52d8b0249
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0243
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 07:15:45 -0000

Hello Eliot,

On 2017/11/16 17:31, Eliot Lear wrote:

>    * When used, split-horizon DNS provides different answers based on the
>      source of a query [RFC6950].  The common case of this is an
>      enterprise that does not expose the existence of internal services
>      to the outside world.

>                             If a DOH server residing on the Internet may,
>      therefore, provide an inconsistent answer than an internal resolver
>      would.

This sentence doesn't make sense for me. I suggest a rewrite.

Regards,   Martin.


>              To address the common case, a DOH client MAY contain some
>      configuration, such as a list of local domains that should use UDP-
>      or DPRIVE-based queries.
>    * Many deployments review DNS queries and responses on the wire to
>      detect for malware or other policy concerns.  Where such exposure is
>      required by policy, DOH the user may wish to not configure DOH.
> 


From nobody Thu Nov 16 23:20:22 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAED8128D0F for ; Thu, 16 Nov 2017 23:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uTBQz0auVpTz for ; Thu, 16 Nov 2017 23:20:19 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC18127B73 for ; Thu, 16 Nov 2017 23:20:19 -0800 (PST)
Received: from dhcp-91b2.meeting.ietf.org (dhcp-91b2.meeting.ietf.org [31.133.145.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id EA4502420D43; Fri, 17 Nov 2017 07:20:16 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid 
In-Reply-To: <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
Date: Fri, 17 Nov 2017 07:20:14 +0000
Cc: Eliot Lear , DOH Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F02C6A1-6D83-4EDB-B67B-BEC27A11BAD4@rfc1035.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
To: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 07:20:20 -0000

> On 17 Nov 2017, at 07:15, Martin J. D=C3=BCrst =
 wrote:
>=20
>>                            If a DOH server residing on the Internet =
may,
>>     therefore, provide an inconsistent answer than an internal =
resolver
>>     would.
>=20
> This sentence doesn't make sense for me. I suggest a rewrite.

So rewrite it!


From nobody Fri Nov 17 02:09:27 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879E9126C25 for ; Fri, 17 Nov 2017 02:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IonGCGwzN92p for ; Fri, 17 Nov 2017 02:09:24 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A87120724 for ; Fri, 17 Nov 2017 02:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2703; q=dns/txt; s=iport; t=1510913363; x=1512122963; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=SMa01Jhiv5IQxajwAtkv1OZCREKMZTfAM4iopLdXOI4=; b=fnyDsH0JpqEj+R6SBs/DHYhTlpdcgzxc1i1NJTfIJVgXHNARZ7mFGLCN toKRpv4nvByhW9XabyPOcBQKQ+26EPXbqcDX5JV3e2YqHpx4pS+mmTqXI 0uUQE93xYjY7mnYXGyyJZjQwHwKglmFGXeDR1kFYZixPIv/2vgVzfc/Zc o=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQBPtA5a/xbLJq1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGFDoQmixOPfwkmlmKCEQcDhTsCGoULFwEBAQEBAQEBAWsohR8?= =?us-ascii?q?BBSNmCQIYKgICAlUGAQwIAQGKIYwrnWiCJ4sCAQEBAQEBAQECAQEBAQEBARIPg?= =?us-ascii?q?zSFbguCd4UFLYJ+gmMBBKI+hEmCKI4bjASHSJYygTohATaBdDQhCB0Vgy6EH0B?= =?us-ascii?q?AiwwBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,408,1505779200"; d="asc'?scan'208";a="328520"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2017 10:09:21 +0000
Received: from [10.61.227.56] ([10.61.227.56]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAHA9L2q030191; Fri, 17 Nov 2017 10:09:21 GMT
To: "=?UTF-8?Q?Martin_J._D=c3=bcrst?=" , "doh@ietf.org" 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
From: Eliot Lear 
Message-ID: <6cba7182-3ffb-2155-7df5-2557a2aa6a60@cisco.com>
Date: Fri, 17 Nov 2017 11:09:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iJgCeBdmltt2dQQrt3ExqK2MDs2SWCdLR"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 10:09:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--iJgCeBdmltt2dQQrt3ExqK2MDs2SWCdLR
Content-Type: multipart/mixed; boundary="98No0UJsJAS1rpDx03c2rdF8rj6GQCOhV";
 protected-headers="v1"
From: Eliot Lear 
To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= ,
 "doh@ietf.org" 
Message-ID: <6cba7182-3ffb-2155-7df5-2557a2aa6a60@cisco.com>
Subject: Re: [Doh] operational considerations
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
 <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>
In-Reply-To: <22166e53-71e4-8787-08f4-7528559076d2@it.aoyama.ac.jp>

--98No0UJsJAS1rpDx03c2rdF8rj6GQCOhV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Language: en-US

SGkgTWFydGluLAoKVGhlIHNlbnRlbmNlIG5lZWRzIHdvcmsuwqAgU2VlIGJlbG93OgoKCk9u
IDExLzE3LzE3IDg6MTUgQU0sIE1hcnRpbiBKLiBEw7xyc3Qgd3JvdGU6Cj4gSGVsbG8gRWxp
b3QsCj4KPiBPbiAyMDE3LzExLzE2IDE3OjMxLCBFbGlvdCBMZWFyIHdyb3RlOgo+Cj4+IMKg
wqAgKiBXaGVuIHVzZWQsIHNwbGl0LWhvcml6b24gRE5TIHByb3ZpZGVzIGRpZmZlcmVudCBh
bnN3ZXJzIGJhc2VkIG9uCj4+IHRoZQo+PiDCoMKgwqDCoCBzb3VyY2Ugb2YgYSBxdWVyeSBb
UkZDNjk1MF0uwqAgVGhlIGNvbW1vbiBjYXNlIG9mIHRoaXMgaXMgYW4KPj4gwqDCoMKgwqAg
ZW50ZXJwcmlzZSB0aGF0IGRvZXMgbm90IGV4cG9zZSB0aGUgZXhpc3RlbmNlIG9mIGludGVy
bmFsIHNlcnZpY2VzCj4+IMKgwqDCoMKgIHRvIHRoZSBvdXRzaWRlIHdvcmxkLgo+Cj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBJ
ZiBhIERPSCBzZXJ2ZXIgcmVzaWRpbmcgb24gdGhlIEludGVybmV0Cj4+IG1heSwKPj4gwqDC
oMKgwqAgdGhlcmVmb3JlLCBwcm92aWRlIGFuIGluY29uc2lzdGVudCBhbnN3ZXIgdGhhbiBh
biBpbnRlcm5hbCByZXNvbHZlcgo+PiDCoMKgwqDCoCB3b3VsZC4KPgo+IFRoaXMgc2VudGVu
Y2UgZG9lc24ndCBtYWtlIHNlbnNlIGZvciBtZS4gSSBzdWdnZXN0IGEgcmV3cml0ZS4KCkEg
RE9IIHNlcnZlciByZXNpZGluZyBvbiB0aGUgSW50ZXJuZXQgbWF5LCB0aGVyZWZvcmUsIHJl
c3BvbmQgd2l0aCBhbgphbnN3ZXIgdGhhdCBpcwppbmFwcHJvcHJpYXRlIGZvciBpbnRlcm5h
bCBob3N0cy4KCkJldHRlcj8KCkVsaW90Cg==

--98No0UJsJAS1rpDx03c2rdF8rj6GQCOhV--

--iJgCeBdmltt2dQQrt3ExqK2MDs2SWCdLR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaDrVHAAoJEIe2a0bZ0nozFwIIANvpLt6NfP+Biy/kzZiSZstf
IS+dqcsP0gAQWUz2+Q4dFX5TvF6QMXNbivc0n5zMNbI9Zi8uWcbj8UMg/NIBVkjw
Z58D6v9VOrseDZhNFsZxGucEEVnEJ+Km2ySKlrVtW4vW8CZxIJ8bCMcKYrdmh4s4
5WG0mwFcarMFLaiaPFva8m0W4OrT8U5WiM+4P2kQM7s2TzDxMGGkesXc1ILP6QhL
8cUvnU6oF/iCF3y5FGWWQY/i0Mg2KiWJO9xoQUsK6uBLgIXCW5AiCFzm9lPdva5G
/pAn7i2mplH13HrOH4gqi1wM8Rzhp+xp5nABxfbFn/HzuMmco9HR+Z5GdCza5F8=
=xB64
-----END PGP SIGNATURE-----

--iJgCeBdmltt2dQQrt3ExqK2MDs2SWCdLR--


From nobody Sat Nov 18 17:48:12 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BC4126B7F for ; Sat, 18 Nov 2017 17:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no 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 P4i_ng3HqXNi for ; Sat, 18 Nov 2017 17:48:09 -0800 (PST)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2A3126557 for ; Sat, 18 Nov 2017 17:48:09 -0800 (PST)
Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6A3693A0A9 for ; Sat, 18 Nov 2017 20:48:06 -0500 (EST)
Received: by mail-lf0-f45.google.com with SMTP id i14so6492989lfc.1 for ; Sat, 18 Nov 2017 17:48:06 -0800 (PST)
X-Gm-Message-State: AJaThX4pk6fBGevvdsAbHxBRI3xXvV3t6Kv38tzxixJWGQmoIIeHOip5 aXEQkgIHa8SMxs9mjxJNzIxR0oZJ5LLbXc9r1zg=
X-Google-Smtp-Source: AGs4zMaYCFNJoyaK8VoLjfUsNEpESvApbNQoAhczbs1qNQ4+fGdqLZsyqHBs2wJdziPuClUuxOy7/R+yJ5fCtKwLvh0=
X-Received: by 10.46.2.87 with SMTP id 84mr2532728ljc.0.1511056085130; Sat, 18 Nov 2017 17:48:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.151.9 with HTTP; Sat, 18 Nov 2017 17:48:03 -0800 (PST)
In-Reply-To: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
From: Patrick McManus 
Date: Sun, 19 Nov 2017 09:48:03 +0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Eliot Lear 
Cc: "doh@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1a168230a5b4055e4c2938"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 01:48:11 -0000

--94eb2c1a168230a5b4055e4c2938
Content-Type: text/plain; charset="UTF-8"

Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it to
this scope I'm ok - but if the section begins to grow organically we should
really discuss moving to a different doc. I have a proposed  minor rework
of your text below which I believe to be more concise and a bit more
illuminating on the root issues. Let me know what you think.

Operational Considerations

Different DNS servers may provide different results to the same query. It
logically follows that which server is consulted influences the end result.
Split-horizon DNS [RFC6950] is a specific example of this approach where
the answers are derived from the (potentially natted) source of the query.
A client that chooses to query a non-default resolver for a name that is
using this style of algorithm may not obtain correct results.

The HTTPS channel used by this specification establishes secure two party
communication between the DNS API Client and the DNS API Server. Filtering
or inspection systems that rely on unsecured transport of DNS will not
function in a DNS over HTTPS environment.

--94eb2c1a168230a5b4055e4c2938
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it =
to this scope I'm ok - but if the section begins to grow organically we=
 should really discuss moving to a different doc. I have a proposed=C2=A0 m=
inor rework of your text below which I believe to be more concise and a bit=
 more illuminating on the root issues. Let me know what you think.

Operational Considerations

Different DNS ser=
vers may provide different results to the same query. It logically follows =
that which server is consulted influences the end result. Split-horizon DNS=
 [RFC6950] is a specific example of this approach where the answers are der=
ived from the (potentially natted) source of the query. A client that choos=
es to query a non-default resolver for a name that is using this style of a=
lgorithm may not obtain correct results.

The HTTPS=
 channel used by this specification establishes secure two party communicat=
ion between the DNS API Client and the DNS API Server. Filtering or inspect=
ion systems that rely on unsecured transport of DNS will not function in a =
DNS over HTTPS environment.


--94eb2c1a168230a5b4055e4c2938--


From nobody Sun Nov 19 04:49:43 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13843127B5A for ; Sun, 19 Nov 2017 04:49:42 -0800 (PST)
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] 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 3Jd2D2cIkXkf for ; Sun, 19 Nov 2017 04:49:40 -0800 (PST)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28745127077 for ; Sun, 19 Nov 2017 04:49:39 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 2028E2420D43; Sun, 19 Nov 2017 12:49:37 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid 
In-Reply-To: 
Date: Sun, 19 Nov 2017 12:49:36 +0000
Cc: Eliot Lear , DOH Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <80FD186F-DB77-4590-BD7D-293E7AC7CA4A@rfc1035.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> 
To: Patrick McManus 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 12:49:42 -0000

> On 19 Nov 2017, at 01:48, Patrick McManus  =
wrote:
>=20
> Different DNS servers may provide different results to the same query. =
It logically follows that which server is consulted influences the end =
result. Split-horizon DNS [RFC6950] is a specific example of this =
approach where the answers are derived from the (potentially natted) =
source of the query. A client that chooses to query a non-default =
resolver for a name that is using this style of algorithm may not obtain =
correct results.

I think the last sentence could be improved by deleting the reference to =
"non-default" and "correct results=E2=80=9D. First, it=E2=80=99s not =
clear what a default resolver is. Or what that means. Second, the result =
that one of these non-default resolvers may well be correct since the =
correct DNS response depends on the context: ie someone on the internal =
net gets back the correct internal web site (or whatever) instead of the =
incorrect public-facing one. We could probably lose =E2=80=9C(potentially =
natted)=E2=80=9D too since that doesn=E2=80=99t seem to add anything =
useful IMO.

How about the following instead?

Different DNS servers may provide different results to the same query. =
It logically follows that which server is consulted influences the end =
result. Split-horizon DNS [RFC6950] is a specific example of this =
approach where the answers are derived from the source of the query. A =
client that chooses to query a resolver which uses these sorts of =
policy-based approaches can expect to sometimes be returned different =
answers from the responses given by resolvers which do not use them.



From nobody Sun Nov 19 22:06:03 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70B1275F4 for ; Sun, 19 Nov 2017 22:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uX9Jh-H1T_z4 for ; Sun, 19 Nov 2017 22:06:01 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B47127599 for ; Sun, 19 Nov 2017 22:06:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3043; q=dns/txt; s=iport; t=1511157960; x=1512367560; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ovBnLgA+ADIxWl6eNhpSVOOBz1gONAw0pvpyUMXhk4k=; b=E9VV3m9H/2zI6eUVpEdz4n4UsH3JIx4qCaXpFAlmeYfft0eQskDd5mIW BuefCS5hFJ5g8hB+cjCgqbe+Drvj8uPYnR+msYaIllu+3pnAojeY2zGuk p2sYEJFHZybnzlMBcuF49PmZriSXDRnzMdJk05f6bPTYd/LEaSSEkZ45m 8=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQCtbxJa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQiboQmixOQMJZiEIIBBwOFOwKFKBYBAQEBAQEBAQFrKIUfAQU?= =?us-ascii?q?jVhALGCoCAlcGDQgBAYohqSyCJ4p0AQEBAQEBAQEBAQEBAQEBAQESD4M0hW6DA?= =?us-ascii?q?oRfJoMrgmMFkXSQSoRJgiiOG4wEh0iWMoE6JgIwgXQ0IQgdFYMuhF9AjAwBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,425,1505779200"; d="asc'?scan'208";a="324697"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 06:05:58 +0000
Received: from [10.61.215.6] ([10.61.215.6]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAK65wpA028392; Mon, 20 Nov 2017 06:05:58 GMT
To: Patrick McManus 
Cc: "doh@ietf.org" 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> 
From: Eliot Lear 
Message-ID: 
Date: Mon, 20 Nov 2017 07:05:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IGegKV8psAMiq1WXqf1xfhswTQm7bwwSk"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 06:06:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IGegKV8psAMiq1WXqf1xfhswTQm7bwwSk
Content-Type: multipart/mixed; boundary="gARctE1VvofN7jrLnnh3WejbhknSnk2wf";
 protected-headers="v1"
From: Eliot Lear 
To: Patrick McManus 
Cc: "doh@ietf.org" 
Message-ID: 
Subject: Re: [Doh] operational considerations
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
 
In-Reply-To: 

--gARctE1VvofN7jrLnnh3WejbhknSnk2wf
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Patrick,

This is good text.=C2=A0 I think Jim has a point about "default resolver"=
=2E=C2=A0
Also, further reduction is possible.=C2=A0 See below:


On 11/19/17 2:48 AM, Patrick McManus wrote:
> Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it
> to this scope I'm ok - but if the section begins to grow organically
> we should really discuss moving to a different doc. I have a proposed=C2=
=A0
> minor rework of your text below which I believe to be more concise and
> a bit more illuminating on the root issues. Let me know what you think.=

>
> Operational Considerations
>
> Different DNS servers may provide different results to the same query.
> It logically follows that which server is consulted influences the end
> result. Split-horizon DNS [RFC6950] is a specific example of this
> approach where the answers are derived from the (potentially natted)
> source of the query. A client that chooses to query a non-default
> resolver for a name that is using this style of algorithm may not
> obtain correct results.

s/chooses to query/queries/

s/non-default resolver/resolver that is not proximate/

How's that?
>
> The HTTPS channel used by this specification establishes secure two
> party communication between the DNS API Client and the DNS API Server.
> Filtering or inspection systems that rely on unsecured transport of
> DNS will not function in a DNS over HTTPS environment.

Eliot


--gARctE1VvofN7jrLnnh3WejbhknSnk2wf--

--IGegKV8psAMiq1WXqf1xfhswTQm7bwwSk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaEnDGAAoJEIe2a0bZ0nozDssH/jODt+eAJMuliG2LFREf1h5l
nWjAf7PFnp8Kl9oNK0S3n4g/U92dvU+6KSIebQoMiJlr120HG42fHZL+ucseWr64
kdKDzwo3y39Cmbptoks8DQAK5CvIqGicfYNf6s6op9/I52KUchzPc07wNN2VpTQ+
U1nN58mLkvYJY2iQ+j5llAKH0mE9ELSKvnUXWQy9GZD2hzNCOfw5+JNy/mN316sp
tfMtpLvRUwZ62oPBL5pKHoPrm2Gt9+JH8fgUa40aaLZIvjNHqiUILCUdXaDYxdo0
CkyBejiCLZEryh+t5uhfF5T6ryx+S9FG3phCcaJ4+/j/VQWzbfDzNm2l4PrTEuU=
=keZs
-----END PGP SIGNATURE-----

--IGegKV8psAMiq1WXqf1xfhswTQm7bwwSk--


From nobody Mon Nov 20 12:39:28 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24A12EAA8 for ; Mon, 20 Nov 2017 12:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level: 
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 02cs3q86kwWM for ; Mon, 20 Nov 2017 12:39:25 -0800 (PST)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7EB120713 for ; Mon, 20 Nov 2017 12:39:25 -0800 (PST)
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 92C523A0BC for ; Mon, 20 Nov 2017 15:39:23 -0500 (EST)
Received: by mail-lf0-f46.google.com with SMTP id y2so10662117lfj.4 for ; Mon, 20 Nov 2017 12:39:23 -0800 (PST)
X-Gm-Message-State: AJaThX62mMz7DxnViggtjlIotUjEVMohfoStqOZj+0trW+pxItxKgDJ2 Nbnl6Q65e5A9y1UyjsJ8APREEkgKM3JdkbTJdcA=
X-Google-Smtp-Source: AGs4zMb1OAeRMhTr1+yJJI10nmTeOPePHATKjPWqHeeA0QsB3XWdE/fg/aaOXAi91a6va1Kba8MJqg0EYWqipXqP8kA=
X-Received: by 10.25.159.196 with SMTP id i187mr3193309lfe.150.1511210362229;  Mon, 20 Nov 2017 12:39:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.151.9 with HTTP; Mon, 20 Nov 2017 12:39:21 -0800 (PST)
In-Reply-To: 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>  
From: Patrick McManus 
Date: Mon, 20 Nov 2017 15:39:21 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Eliot Lear 
Cc: Patrick McManus , "doh@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411bbed26070055e701437"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:39:27 -0000

--001a11411bbed26070055e701437
Content-Type: text/plain; charset="UTF-8"

I've taken the (imo) best bits from Eliot, Jim, and myself.. (I've tried to
reject 'non-default', 'proximate', and 'policy' all as things that muddy
the issue.) what do we think of this iteration?

Operational Considerations

Different DNS servers may provide different results to the same query. It
logically follows that which server is consulted influences the end result.
Split-horizon DNS [RFC6950] is a specific example of this approach where
the answers are derived from the source of the query. A client that queries
a resolver which uses this style of algorithm can expect to sometimes be
returned different answers from the responses given by resolvers which do
not use them

The HTTPS channel used by this specification establishes secure two party
communication between the DNS API Client and the DNS API Server. Filtering
or inspection systems that rely on unsecured transport of DNS will not
function in a DNS over HTTPS environment.

On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear  wrote:

> Hi Patrick,
>
> This is good text.  I think Jim has a point about "default resolver".
> Also, further reduction is possible.  See below:
>
>
> On 11/19/17 2:48 AM, Patrick McManus wrote:
> > Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it
> > to this scope I'm ok - but if the section begins to grow organically
> > we should really discuss moving to a different doc. I have a proposed
> > minor rework of your text below which I believe to be more concise and
> > a bit more illuminating on the root issues. Let me know what you think.
> >
> > Operational Considerations
> >
> > Different DNS servers may provide different results to the same query.
> > It logically follows that which server is consulted influences the end
> > result. Split-horizon DNS [RFC6950] is a specific example of this
> > approach where the answers are derived from the (potentially natted)
> > source of the query. A client that chooses to query a non-default
> > resolver for a name that is using this style of algorithm may not
> > obtain correct results.
>
> s/chooses to query/queries/
>
> s/non-default resolver/resolver that is not proximate/
>
> How's that?
> >
> > The HTTPS channel used by this specification establishes secure two
> > party communication between the DNS API Client and the DNS API Server.
> > Filtering or inspection systems that rely on unsecured transport of
> > DNS will not function in a DNS over HTTPS environment.
>
> Eliot
>
>

--001a11411bbed26070055e701437
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I've taken the (imo) best bits from Eliot, Jim, a=
nd myself.. (I've tried to reject 'non-default', 'proximate=
', and 'policy' all as things that muddy the issue.) what do we=
 think of this iteration?

Operational Consider=
ations

Different DNS servers may=20
provide different results to the same query. It logically follows that=20
which server is consulted influences the end result. Split-horizon DNS=20
[RFC6950] is a specific example of this approach where the answers are=20
derived from the source of the query. A client that queries a resolver whic=
h uses this style of algorithm can expect to sometimes be returned differen=
t answers from the responses given by resolvers which do not use them

The
 HTTPS channel used by this specification establishes secure two party=20
communication between the DNS API Client and the DNS API Server.=20
Filtering or inspection systems that rely on unsecured transport of DNS=20
will not function in a DNS over HTTPS environment.

On Mon, Nov 20, 2017 at 1:05 A=
M, Eliot Lear <lear@cisco.com> wrote:
Hi Patrick,



This is good text.=C2=A0 I think Jim has a point about "default resolv=
er".=C2=A0

Also, further reduction is possible.=C2=A0 See below:





On 11/19/17 2:48 AM, Patrick McManus wrote:

> Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it<=
br>
> to this scope I'm ok - but if the section begins to grow organical=
ly

> we should really discuss moving to a different doc. I have a proposed=
=C2=A0

> minor rework of your text below which I believe to be more concise and=


> a bit more illuminating on the root issues. Let me know what you think=
.

>

> Operational Considerations

>

> Different DNS servers may provide different results to the same query.=


> It logically follows that which server is consulted influences the end=


> result. Split-horizon DNS [RFC6950] is a specific example of this

> approach where the answers are derived from the (potentially natted)
> source of the query. A client that chooses to query a non-default

> resolver for a name that is using this style of algorithm may not

> obtain correct results.



s/chooses to query/queries/



s/non-default resolver/resolver that is not proximate/



How's that?


>

> The HTTPS channel used by this specification establishes secure two
> party communication between the DNS API Client and the DNS API Server.=


> Filtering or inspection systems that rely on unsecured transport of
> DNS will not function in a DNS over HTTPS environment.




Eliot







--001a11411bbed26070055e701437--


From nobody Mon Nov 20 13:26:57 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ABA126FDC for ; Mon, 20 Nov 2017 13:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 hGFFb8rL9Ieo for ; Mon, 20 Nov 2017 13:26:53 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 08D4212711D for ; Mon, 20 Nov 2017 13:26:52 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAKLLcbp026935; Mon, 20 Nov 2017 21:26:50 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=wsw8gThAYpBHHFv27iQjzgaQOzkviKONqn4jOgC2El0=; b=jLYRJiRaCeXpQWyNQY0qLs4O+17F/xi3ZgIaNK5NDmMgOzeXAnWsg1tqBNgkMaRTdzfv hSoUHgUwPHQC5mkRBN4wBlmpX13WNzC4uzY3DBosHs6ojQWHo1mrpI+kTN6c93S99nJq 8zhWiZjJTRAPbjUHIvcJ9PthljpCujoTz+q5RYRD0DzDHK0U0vL9SRsc+1S/QOxL8hEF Ko4ZCCC/Ubw6TVWBm778WQOOzZ97eIA53RtHOPhY0ZwWYxFB+rqR9X06hQ6JG90PQVdL 40nfiV0JVm08TIDuhoRdCXQ8PdpCGtEbrg3oq0onzc2JfgH8beY2gcl8mZGdDzfg4YOb NQ== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2eaatfr7cu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Nov 2017 21:26:50 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAKLQdIk007211; Mon, 20 Nov 2017 16:26:49 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2eah2xysyu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 20 Nov 2017 16:26:42 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 20 Nov 2017 13:25:56 -0800
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 20 Nov 2017 16:25:56 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Mon, 20 Nov 2017 16:25:55 -0500
From: "Hewitt, Rory" 
To: Patrick McManus , Eliot Lear 
CC: "doh@ietf.org" 
Thread-Topic: [Doh] operational considerations
Thread-Index: AQHTXrV5T3VOxBXQTESW8iflmtLdi6MbR0aAgAHaY4CAAPQHgP//uDpg
Date: Mon, 20 Nov 2017 21:25:55 +0000
Message-ID: <2c94f0d7e86248ffa870b4852218bbe6@usma1ex-dag1mb3.msg.corp.akamai.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.116.210]
Content-Type: multipart/alternative; boundary="_000_2c94f0d7e86248ffa870b4852218bbe6usma1exdag1mb3msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-20_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711200287
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-20_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711200286
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:26:56 -0000

--_000_2c94f0d7e86248ffa870b4852218bbe6usma1exdag1mb3msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QSBjb3VwbGUgb2YgYWRkaXRpb25hbCB0d2Vha3MgKHdoaWNoIHlvdSBjYW4sIG9mIGNvdXJzZSwg
aWdub3JlOg0KDQpEaWZmZXJlbnQgRE5TIHNlcnZlcnMgbWF5IHByb3ZpZGUgZGlmZmVyZW50IHJl
c3VsdHMgdG8gdGhlIHNhbWUgcXVlcnkuIEl0IGxvZ2ljYWxseSBmb2xsb3dzIHRoYXQgd2hpY2gg
c2VydmVyIHRoZSBzZXJ2ZXIgd2hpY2ggaXMgY29uc3VsdGVkIGluZmx1ZW5jZXMgdGhlIGVuZCBy
ZXN1bHQuIFNwbGl0LWhvcml6b24gRE5TIFtSRkM2OTUwXSBpcyBhIHNwZWNpZmljIGV4YW1wbGUg
b2YgdGhpcyBhcHByb2FjaCB3aGVyZSB0aGUgYW5zd2VycyBhcmUgZGVyaXZlZCBmcm9tIHRoZSBz
b3VyY2Ugb2YgdGhlIHF1ZXJ5LiBBIGNsaWVudCB0aGF0IHF1ZXJpZXMgYSByZXNvbHZlciB3aGlj
aCB1c2VzIHRoaXMgc3R5bGUgb2YgYWxnb3JpdGhtIGNhbiBleHBlY3QgdG8gc29tZXRpbWVzIGJl
IHJldHVybmVkIGRpZmZlcmVudCBhbnN3ZXJzIGZyb20gdGhlIHJlc3BvbnNlcyBjb21wYXJlZCB3
aXRoIHJlc3BvbnNlcyBnaXZlbiBieSByZXNvbHZlcnMgd2hpY2ggZG8gbm90IHVzZSB0aGVtDQoN
Cg0KVGhhbmtzLA0KDQpSb3J5DQoNClJvcnkgSGV3aXR0DQpTZW5pb3IgU29sdXRpb25zIEFyY2hp
dGVjdA0KR2xvYmFsIFNlcnZpY2VzICYgU3VwcG9ydA0KQWthbWFpIFRlY2hub2xvZ2llcw0KVGVs
OiAoNDA4KSA2NTAtMDAzNQ0KDQpGcm9tOiBQYXRyaWNrIE1jTWFudXMgW21haWx0bzpwbWNtYW51
c0Btb3ppbGxhLmNvbV0NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjAsIDIwMTcgMTI6MzkgUE0N
ClRvOiBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4NCkNjOiBkb2hAaWV0Zi5vcmc7IFBhdHJp
Y2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogW0RvaF0gb3Bl
cmF0aW9uYWwgY29uc2lkZXJhdGlvbnMNCg0KSSd2ZSB0YWtlbiB0aGUgKGltbykgYmVzdCBiaXRz
IGZyb20gRWxpb3QsIEppbSwgYW5kIG15c2VsZi4uIChJJ3ZlIHRyaWVkIHRvIHJlamVjdCAnbm9u
LWRlZmF1bHQnLCAncHJveGltYXRlJywgYW5kICdwb2xpY3knIGFsbCBhcyB0aGluZ3MgdGhhdCBt
dWRkeSB0aGUgaXNzdWUuKSB3aGF0IGRvIHdlIHRoaW5rIG9mIHRoaXMgaXRlcmF0aW9uPw0KDQpP
cGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucw0KDQpEaWZmZXJlbnQgRE5TIHNlcnZlcnMgbWF5IHBy
b3ZpZGUgZGlmZmVyZW50IHJlc3VsdHMgdG8gdGhlIHNhbWUgcXVlcnkuIEl0IGxvZ2ljYWxseSBm
b2xsb3dzIHRoYXQgd2hpY2ggc2VydmVyIGlzIGNvbnN1bHRlZCBpbmZsdWVuY2VzIHRoZSBlbmQg
cmVzdWx0LiBTcGxpdC1ob3Jpem9uIEROUyBbUkZDNjk1MF0gaXMgYSBzcGVjaWZpYyBleGFtcGxl
IG9mIHRoaXMgYXBwcm9hY2ggd2hlcmUgdGhlIGFuc3dlcnMgYXJlIGRlcml2ZWQgZnJvbSB0aGUg
c291cmNlIG9mIHRoZSBxdWVyeS4gQSBjbGllbnQgdGhhdCBxdWVyaWVzIGEgcmVzb2x2ZXIgd2hp
Y2ggdXNlcyB0aGlzIHN0eWxlIG9mIGFsZ29yaXRobSBjYW4gZXhwZWN0IHRvIHNvbWV0aW1lcyBi
ZSByZXR1cm5lZCBkaWZmZXJlbnQgYW5zd2VycyBmcm9tIHRoZSByZXNwb25zZXMgZ2l2ZW4gYnkg
cmVzb2x2ZXJzIHdoaWNoIGRvIG5vdCB1c2UgdGhlbQ0KDQpUaGUgSFRUUFMgY2hhbm5lbCB1c2Vk
IGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyBzZWN1cmUgdHdvIHBhcnR5IGNvbW11
bmljYXRpb24gYmV0d2VlbiB0aGUgRE5TIEFQSSBDbGllbnQgYW5kIHRoZSBETlMgQVBJIFNlcnZl
ci4gRmlsdGVyaW5nIG9yIGluc3BlY3Rpb24gc3lzdGVtcyB0aGF0IHJlbHkgb24gdW5zZWN1cmVk
IHRyYW5zcG9ydCBvZiBETlMgd2lsbCBub3QgZnVuY3Rpb24gaW4gYSBETlMgb3ZlciBIVFRQUyBl
bnZpcm9ubWVudC4NCg0KT24gTW9uLCBOb3YgMjAsIDIwMTcgYXQgMTowNSBBTSwgRWxpb3QgTGVh
ciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBQYXRy
aWNrLA0KDQpUaGlzIGlzIGdvb2QgdGV4dC4gIEkgdGhpbmsgSmltIGhhcyBhIHBvaW50IGFib3V0
ICJkZWZhdWx0IHJlc29sdmVyIi4NCkFsc28sIGZ1cnRoZXIgcmVkdWN0aW9uIGlzIHBvc3NpYmxl
LiAgU2VlIGJlbG93Og0KDQoNCk9uIDExLzE5LzE3IDI6NDggQU0sIFBhdHJpY2sgTWNNYW51cyB3
cm90ZToNCj4gSGkgRWxpb3QgLSBpbmRlZWQgdGhpcyBpcyBmYWlybHkgYnJpZWYuLiB0aGFuayB5
b3UuIGlmIHdlIGNhbiBrZWVwIGl0DQo+IHRvIHRoaXMgc2NvcGUgSSdtIG9rIC0gYnV0IGlmIHRo
ZSBzZWN0aW9uIGJlZ2lucyB0byBncm93IG9yZ2FuaWNhbGx5DQo+IHdlIHNob3VsZCByZWFsbHkg
ZGlzY3VzcyBtb3ZpbmcgdG8gYSBkaWZmZXJlbnQgZG9jLiBJIGhhdmUgYSBwcm9wb3NlZA0KPiBt
aW5vciByZXdvcmsgb2YgeW91ciB0ZXh0IGJlbG93IHdoaWNoIEkgYmVsaWV2ZSB0byBiZSBtb3Jl
IGNvbmNpc2UgYW5kDQo+IGEgYml0IG1vcmUgaWxsdW1pbmF0aW5nIG9uIHRoZSByb290IGlzc3Vl
cy4gTGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuDQo+DQo+IE9wZXJhdGlvbmFsIENvbnNpZGVy
YXRpb25zDQo+DQo+IERpZmZlcmVudCBETlMgc2VydmVycyBtYXkgcHJvdmlkZSBkaWZmZXJlbnQg
cmVzdWx0cyB0byB0aGUgc2FtZSBxdWVyeS4NCj4gSXQgbG9naWNhbGx5IGZvbGxvd3MgdGhhdCB3
aGljaCBzZXJ2ZXIgaXMgY29uc3VsdGVkIGluZmx1ZW5jZXMgdGhlIGVuZA0KPiByZXN1bHQuIFNw
bGl0LWhvcml6b24gRE5TIFtSRkM2OTUwXSBpcyBhIHNwZWNpZmljIGV4YW1wbGUgb2YgdGhpcw0K
PiBhcHByb2FjaCB3aGVyZSB0aGUgYW5zd2VycyBhcmUgZGVyaXZlZCBmcm9tIHRoZSAocG90ZW50
aWFsbHkgbmF0dGVkKQ0KPiBzb3VyY2Ugb2YgdGhlIHF1ZXJ5LiBBIGNsaWVudCB0aGF0IGNob29z
ZXMgdG8gcXVlcnkgYSBub24tZGVmYXVsdA0KPiByZXNvbHZlciBmb3IgYSBuYW1lIHRoYXQgaXMg
dXNpbmcgdGhpcyBzdHlsZSBvZiBhbGdvcml0aG0gbWF5IG5vdA0KPiBvYnRhaW4gY29ycmVjdCBy
ZXN1bHRzLg0KDQpzL2Nob29zZXMgdG8gcXVlcnkvcXVlcmllcy8NCg0Kcy9ub24tZGVmYXVsdCBy
ZXNvbHZlci9yZXNvbHZlciB0aGF0IGlzIG5vdCBwcm94aW1hdGUvDQoNCkhvdydzIHRoYXQ/DQo+
DQo+IFRoZSBIVFRQUyBjaGFubmVsIHVzZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlz
aGVzIHNlY3VyZSB0d28NCj4gcGFydHkgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBETlMgQVBJ
IENsaWVudCBhbmQgdGhlIEROUyBBUEkgU2VydmVyLg0KPiBGaWx0ZXJpbmcgb3IgaW5zcGVjdGlv
biBzeXN0ZW1zIHRoYXQgcmVseSBvbiB1bnNlY3VyZWQgdHJhbnNwb3J0IG9mDQo+IEROUyB3aWxs
IG5vdCBmdW5jdGlvbiBpbiBhIEROUyBvdmVyIEhUVFBTIGVudmlyb25tZW50Lg0KRWxpb3QNCg0K

--_000_2c94f0d7e86248ffa870b4852218bbe6usma1exdag1mb3msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg
NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg
bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz
aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3Jt
YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u
b3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl
OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmhvZW56
Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLHNhbnMtc2Vy
aWY7DQoJY29sb3I6IzFGMzg2NDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu
b3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNvdXBsZSBvZiBhZGRpdGlvbmFs
IHR3ZWFrcyAod2hpY2ggeW91IGNhbiwgb2YgY291cnNlLCBpZ25vcmU6PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkRpZmZlcmVudCBETlMgc2VydmVycyBtYXkgcHJvdmlkZSBkaWZmZXJlbnQgcmVz
dWx0cyB0byB0aGUgc2FtZSBxdWVyeS4gSXQgbG9naWNhbGx5IGZvbGxvd3MgdGhhdA0KPHM+d2hp
Y2ggc2VydmVyPC9zPiA8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj50aGUgc2VydmVyIHdoaWNoPC9z
cGFuPiBpcyBjb25zdWx0ZWQgaW5mbHVlbmNlcyB0aGUgZW5kIHJlc3VsdC4gU3BsaXQtaG9yaXpv
biBETlMgW1JGQzY5NTBdIGlzIGEgc3BlY2lmaWMgZXhhbXBsZSBvZiB0aGlzIGFwcHJvYWNoIHdo
ZXJlIHRoZSBhbnN3ZXJzIGFyZSBkZXJpdmVkIGZyb20gdGhlIHNvdXJjZSBvZiB0aGUgcXVlcnku
IEEgY2xpZW50IHRoYXQgcXVlcmllcw0KIGEgcmVzb2x2ZXIgd2hpY2ggdXNlcyB0aGlzIHN0eWxl
IG9mIGFsZ29yaXRobSBjYW4gZXhwZWN0IHRvIHNvbWV0aW1lcyBiZSByZXR1cm5lZCBkaWZmZXJl
bnQNCjxzPmFuc3dlcnMgZnJvbSB0aGU8L3M+IDxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPnJlc3Bv
bnNlcyBjb21wYXJlZCB3aXRoPC9zcGFuPiByZXNwb25zZXMgZ2l2ZW4gYnkgcmVzb2x2ZXJzIHdo
aWNoIGRvIG5vdCB1c2UgdGhlbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGMzg2NCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGMzg2NCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGMzg2NCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjM4NjQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjM4NjQiPlJvcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh
bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUYzODY0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTk1
OTU5Ij5Sb3J5IEhld2l0dDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl
cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTk1OTU5Ij5TZW5pb3IgU29sdXRpb25zIEFy
Y2hpdGVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkdsb2JhbCBTZXJ2aWNlcyAmYW1wOyBTdXBwb3J0PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1OTU5NTkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1OTU5NTkiPkFrYW1h
aSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo4LjBwdDtsaW5lLWhlaWdodDoxMi42cHQiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiM1OTU5NTkiPlRlbDogKDQwOCkgNjUwLTAwMzU8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUYzODY0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G
cm9tOjwvYj4gUGF0cmljayBNY01hbnVzIFttYWlsdG86cG1jbWFudXNAbW96aWxsYS5jb21dIDxi
cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDEyOjM5IFBNPGJyPg0K
PGI+VG86PC9iPiBFbGlvdCBMZWFyICZsdDtsZWFyQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8
L2I+IGRvaEBpZXRmLm9yZzsgUGF0cmljayBNY01hbnVzICZsdDtwbWNtYW51c0Btb3ppbGxhLmNv
bSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb2hdIG9wZXJhdGlvbmFsIGNvbnNpZGVy
YXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSB0YWtlbiB0
aGUgKGltbykgYmVzdCBiaXRzIGZyb20gRWxpb3QsIEppbSwgYW5kIG15c2VsZi4uIChJJ3ZlIHRy
aWVkIHRvIHJlamVjdCAnbm9uLWRlZmF1bHQnLCAncHJveGltYXRlJywgYW5kICdwb2xpY3knIGFs
bCBhcyB0aGluZ3MgdGhhdCBtdWRkeSB0aGUgaXNzdWUuKSB3aGF0IGRvIHdlIHRoaW5rIG9mIHRo
aXMgaXRlcmF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PcGVyYXRpb25hbCBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaWZmZXJlbnQgRE5TIHNlcnZlcnMg
bWF5IHByb3ZpZGUgZGlmZmVyZW50IHJlc3VsdHMgdG8gdGhlIHNhbWUgcXVlcnkuIEl0IGxvZ2lj
YWxseSBmb2xsb3dzIHRoYXQgd2hpY2ggc2VydmVyIGlzIGNvbnN1bHRlZCBpbmZsdWVuY2VzIHRo
ZSBlbmQgcmVzdWx0LiBTcGxpdC1ob3Jpem9uIEROUyBbUkZDNjk1MF0gaXMgYSBzcGVjaWZpYyBl
eGFtcGxlIG9mIHRoaXMgYXBwcm9hY2ggd2hlcmUgdGhlIGFuc3dlcnMgYXJlDQogZGVyaXZlZCBm
cm9tIHRoZSBzb3VyY2Ugb2YgdGhlIHF1ZXJ5LiBBIGNsaWVudCB0aGF0IHF1ZXJpZXMgYSByZXNv
bHZlciB3aGljaCB1c2VzIHRoaXMgc3R5bGUgb2YgYWxnb3JpdGhtIGNhbiBleHBlY3QgdG8gc29t
ZXRpbWVzIGJlIHJldHVybmVkIGRpZmZlcmVudCBhbnN3ZXJzIGZyb20gdGhlIHJlc3BvbnNlcyBn
aXZlbiBieSByZXNvbHZlcnMgd2hpY2ggZG8gbm90IHVzZSB0aGVtPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBIVFRQUyBjaGFubmVsIHVz
ZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHNlY3VyZSB0d28gcGFydHkgY29t
bXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBETlMgQVBJIENsaWVudCBhbmQgdGhlIEROUyBBUEkgU2Vy
dmVyLiBGaWx0ZXJpbmcgb3IgaW5zcGVjdGlvbiBzeXN0ZW1zIHRoYXQgcmVseSBvbiB1bnNlY3Vy
ZWQgdHJhbnNwb3J0IG9mIEROUyB3aWxsIG5vdCBmdW5jdGlvbiBpbiBhIEROUw0KIG92ZXIgSFRU
UFMgZW52aXJvbm1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDIwLCAyMDE3IGF0IDE6MDUgQU0sIEVsaW90IExlYXIg
Jmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlYXJA
Y2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SGkgUGF0cmljayw8YnI+DQo8YnI+DQpUaGlzIGlzIGdvb2QgdGV4
dC4mbmJzcDsgSSB0aGluayBKaW0gaGFzIGEgcG9pbnQgYWJvdXQgJnF1b3Q7ZGVmYXVsdCByZXNv
bHZlciZxdW90Oy4mbmJzcDs8YnI+DQpBbHNvLCBmdXJ0aGVyIHJlZHVjdGlvbiBpcyBwb3NzaWJs
ZS4mbmJzcDsgU2VlIGJlbG93Ojxicj4NCjxicj4NCjxicj4NCk9uIDExLzE5LzE3IDI6NDggQU0s
IFBhdHJpY2sgTWNNYW51cyB3cm90ZTo8YnI+DQomZ3Q7IEhpIEVsaW90IC0gaW5kZWVkIHRoaXMg
aXMgZmFpcmx5IGJyaWVmLi4gdGhhbmsgeW91LiBpZiB3ZSBjYW4ga2VlcCBpdDxicj4NCiZndDsg
dG8gdGhpcyBzY29wZSBJJ20gb2sgLSBidXQgaWYgdGhlIHNlY3Rpb24gYmVnaW5zIHRvIGdyb3cg
b3JnYW5pY2FsbHk8YnI+DQomZ3Q7IHdlIHNob3VsZCByZWFsbHkgZGlzY3VzcyBtb3ZpbmcgdG8g
YSBkaWZmZXJlbnQgZG9jLiBJIGhhdmUgYSBwcm9wb3NlZCZuYnNwOzxicj4NCiZndDsgbWlub3Ig
cmV3b3JrIG9mIHlvdXIgdGV4dCBiZWxvdyB3aGljaCBJIGJlbGlldmUgdG8gYmUgbW9yZSBjb25j
aXNlIGFuZDxicj4NCiZndDsgYSBiaXQgbW9yZSBpbGx1bWluYXRpbmcgb24gdGhlIHJvb3QgaXNz
dWVzLiBMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay48YnI+DQomZ3Q7PGJyPg0KJmd0OyBPcGVy
YXRpb25hbCBDb25zaWRlcmF0aW9uczxicj4NCiZndDs8YnI+DQomZ3Q7IERpZmZlcmVudCBETlMg
c2VydmVycyBtYXkgcHJvdmlkZSBkaWZmZXJlbnQgcmVzdWx0cyB0byB0aGUgc2FtZSBxdWVyeS48
YnI+DQomZ3Q7IEl0IGxvZ2ljYWxseSBmb2xsb3dzIHRoYXQgd2hpY2ggc2VydmVyIGlzIGNvbnN1
bHRlZCBpbmZsdWVuY2VzIHRoZSBlbmQ8YnI+DQomZ3Q7IHJlc3VsdC4gU3BsaXQtaG9yaXpvbiBE
TlMgW1JGQzY5NTBdIGlzIGEgc3BlY2lmaWMgZXhhbXBsZSBvZiB0aGlzPGJyPg0KJmd0OyBhcHBy
b2FjaCB3aGVyZSB0aGUgYW5zd2VycyBhcmUgZGVyaXZlZCBmcm9tIHRoZSAocG90ZW50aWFsbHkg
bmF0dGVkKTxicj4NCiZndDsgc291cmNlIG9mIHRoZSBxdWVyeS4gQSBjbGllbnQgdGhhdCBjaG9v
c2VzIHRvIHF1ZXJ5IGEgbm9uLWRlZmF1bHQ8YnI+DQomZ3Q7IHJlc29sdmVyIGZvciBhIG5hbWUg
dGhhdCBpcyB1c2luZyB0aGlzIHN0eWxlIG9mIGFsZ29yaXRobSBtYXkgbm90PGJyPg0KJmd0OyBv
YnRhaW4gY29ycmVjdCByZXN1bHRzLjxicj4NCjxicj4NCnMvY2hvb3NlcyB0byBxdWVyeS9xdWVy
aWVzLzxicj4NCjxicj4NCnMvbm9uLWRlZmF1bHQgcmVzb2x2ZXIvcmVzb2x2ZXIgdGhhdCBpcyBu
b3QgcHJveGltYXRlLzxicj4NCjxicj4NCkhvdydzIHRoYXQ/PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+Jmd0Ozxicj4NCiZndDsgVGhlIEhUVFBTIGNoYW5uZWwgdXNlZCBieSB0aGlzIHNwZWNpZmlj
YXRpb24gZXN0YWJsaXNoZXMgc2VjdXJlIHR3bzxicj4NCiZndDsgcGFydHkgY29tbXVuaWNhdGlv
biBiZXR3ZWVuIHRoZSBETlMgQVBJIENsaWVudCBhbmQgdGhlIEROUyBBUEkgU2VydmVyLjxicj4N
CiZndDsgRmlsdGVyaW5nIG9yIGluc3BlY3Rpb24gc3lzdGVtcyB0aGF0IHJlbHkgb24gdW5zZWN1
cmVkIHRyYW5zcG9ydCBvZjxicj4NCiZndDsgRE5TIHdpbGwgbm90IGZ1bmN0aW9uIGluIGEgRE5T
IG92ZXIgSFRUUFMgZW52aXJvbm1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBj
bGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+RWxpb3Q8L3NwYW4+PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_2c94f0d7e86248ffa870b4852218bbe6usma1exdag1mb3msgcorpak_--


From nobody Mon Nov 20 13:30:24 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112DB12711D for ; Mon, 20 Nov 2017 13:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VX57N7d2c70G for ; Mon, 20 Nov 2017 13:30:21 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF18126FDC for ; Mon, 20 Nov 2017 13:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10576; q=dns/txt; s=iport; t=1511213421; x=1512423021; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jdpscWJWPyXQPO+Ho0m1GUAkmrdc8FH/mGQriSEIhro=; b=UUBnUSEK8JmNYzijCqhJbdSm6nVqpMT1x9OfeLDd4l2sA3V2QEzRlS89 ruIHYEl6P6svR1LouE7Gr3ug4vYyE6hgiOtW8T4vDlG95dqvlX81tf5OJ fEU1LnFylQUMWOrTdyBMpll4bNh0REnmlAVOO+8rg5yTEtMCaG5liiOho A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAQA/SBNa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRRuJ4N/ixOQCyaRGYVZggEHA4U7AoVAFAEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAgEjVhALGCcDAgJGEQYNBgIBAYoZCKhVgicmilABAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEOD4M0hW4LgneEXyaDK4JjBZF0kEqESYIojhuMBIdIljKBOjY?= =?us-ascii?q?igXQ0IQgdFYMthGBANotSAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,429,1505779200";  d="asc'?scan'208,217";a="331636"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 21:30:19 +0000
Received: from [10.61.98.150] (dhcp-10-61-98-150.cisco.com [10.61.98.150]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAKLUIT0017365; Mon, 20 Nov 2017 21:30:18 GMT
To: Patrick McManus 
Cc: "doh@ietf.org" 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>   
From: Eliot Lear 
Message-ID: <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
Date: Mon, 20 Nov 2017 22:28:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FTj8C5IFxsgtoo5ITTmIwUvvp7w9F1LwE"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:30:23 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FTj8C5IFxsgtoo5ITTmIwUvvp7w9F1LwE
Content-Type: multipart/mixed; boundary="wKvQvPhXp5JHMcHO9iIU6kUEnhrTr2MI2";
 protected-headers="v1"
From: Eliot Lear 
To: Patrick McManus 
Cc: "doh@ietf.org" 
Message-ID: <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
Subject: Re: [Doh] operational considerations
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
 
 
 
In-Reply-To: 

--wKvQvPhXp5JHMcHO9iIU6kUEnhrTr2MI2
Content-Type: multipart/alternative;
 boundary="------------AA61776977BDB5A57AC2F9CB"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------AA61776977BDB5A57AC2F9CB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Patrick,

The answer is not just different, but inappropriate.=C2=A0 We need to cap=
ture
that point because that is why remediation would be required, and why
this is at all worth mentioning.=C2=A0 I propose that we take another swi=
ng
at this text over the next few days.

Eliot




On 11/20/17 9:39 PM, Patrick McManus wrote:
> I've taken the (imo) best bits from Eliot, Jim, and myself.. (I've
> tried to reject 'non-default', 'proximate', and 'policy' all as things
> that muddy the issue.) what do we think of this iteration?
>
> Operational Considerations
>
> Different DNS servers may provide different results to the same query.
> It logically follows that which server is consulted influences the end
> result. Split-horizon DNS [RFC6950] is a specific example of this
> approach where the answers are derived from the source of the query. A
> client that queries a resolver which uses this style of algorithm can
> expect to sometimes be returned different answers from the responses
> given by resolvers which do not use them
>
> The HTTPS channel used by this specification establishes secure two
> party communication between the DNS API Client and the DNS API Server.
> Filtering or inspection systems that rely on unsecured transport of
> DNS will not function in a DNS over HTTPS environment.
>
> On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear  > wrote:
>
>     Hi Patrick,
>
>     This is good text.=C2=A0 I think Jim has a point about "default res=
olver".=C2=A0
>     Also, further reduction is possible.=C2=A0 See below:
>
>
>     On 11/19/17 2:48 AM, Patrick McManus wrote:
>     > Hi Eliot - indeed this is fairly brief.. thank you. if we can
>     keep it
>     > to this scope I'm ok - but if the section begins to grow organica=
lly
>     > we should really discuss moving to a different doc. I have a
>     proposed=C2=A0
>     > minor rework of your text below which I believe to be more
>     concise and
>     > a bit more illuminating on the root issues. Let me know what you
>     think.
>     >
>     > Operational Considerations
>     >
>     > Different DNS servers may provide different results to the same
>     query.
>     > It logically follows that which server is consulted influences
>     the end
>     > result. Split-horizon DNS [RFC6950] is a specific example of this=

>     > approach where the answers are derived from the (potentially natt=
ed)
>     > source of the query. A client that chooses to query a non-default=

>     > resolver for a name that is using this style of algorithm may not=

>     > obtain correct results.
>
>     s/chooses to query/queries/
>
>     s/non-default resolver/resolver that is not proximate/
>
>     How's that?
>     >
>     > The HTTPS channel used by this specification establishes secure t=
wo
>     > party communication between the DNS API Client and the DNS API
>     Server.
>     > Filtering or inspection systems that rely on unsecured transport =
of
>     > DNS will not function in a DNS over HTTPS environment.
>
>     Eliot
>
>


--------------AA61776977BDB5A57AC2F9CB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Patrick,

    
The answer is not just different, but inappropriate.=C2=A0 We need=
 to
      capture that point because that is why remediation would be
      required, and why this is at all worth mentioning.=C2=A0 I propose =
that
      we take another swing at this text over the next few days.

    

    
Eliot

    

    


    

    


    

    

    
On 11/20/17 9:39 PM, Patrick McManus
      wrote:

    

    

      
      

        
I've taken the (imo) best bits from Eliot, Jim, and
          myself.. (I've tried to reject 'non-default', 'proximate', and
          'policy' all as things that muddy the issue.) what do we think
          of this iteration?

        

        


        

        
Operational Considerations

        


        

        
Different DNS servers may provide different results to the
          same query. It logically follows that which server is
          consulted influences the end result. Split-horizon DNS
          [RFC6950] is a specific example of this approach where the
          answers are derived from the source of the query. A client
          that queries a resolver which uses this style of algorithm can
          expect to sometimes be returned different answers from the
          responses given by resolvers which do not use them

        

        


        

        
The HTTPS channel used by this specification establishes
          secure two party communication between the DNS API Client and
          the DNS API Server. Filtering or inspection systems that rely
          on unsecured transport of DNS will not function in a DNS over
          HTTPS environment.

      

      


        
On Mon, Nov 20, 2017 at 1:05 AM, Eliot=

          Lear <lear@cisco.com>
          wrote:

          
Hi
            Patrick,

            

            This is good text.=C2=A0 I think Jim has a point about "defau=
lt
            resolver".=C2=A0

            Also, further reduction is possible.=C2=A0 See below:

            

              

              On 11/19/17 2:48 AM, Patrick McManus wrote:

              > Hi Eliot - indeed this is fairly brief.. thank you.
              if we can keep it

              > to this scope I'm ok - but if the section begins to
              grow organically

              > we should really discuss moving to a different doc. I
              have a proposed=C2=A0

              > minor rework of your text below which I believe to be
              more concise and

              > a bit more illuminating on the root issues. Let me
              know what you think.

              >

              > Operational Considerations

              >

              > Different DNS servers may provide different results
              to the same query.

              > It logically follows that which server is consulted
              influences the end

              > result. Split-horizon DNS [RFC6950] is a specific
              example of this

              > approach where the answers are derived from the
              (potentially natted)

              > source of the query. A client that chooses to query a
              non-default

              > resolver for a name that is using this style of
              algorithm may not

              > obtain correct results.

              

            s/chooses to query/queries/

            

            s/non-default resolver/resolver that is not proximate/

            

            How's that?

            

              
>

                > The HTTPS channel used by this specification
                establishes secure two

                > party communication between the DNS API Client and
                the DNS API Server.

                > Filtering or inspection systems that rely on
                unsecured transport of

                > DNS will not function in a DNS over HTTPS
                environment.

                

              

            

            Eliot

                

              

        

        

      

    

    

  


--------------AA61776977BDB5A57AC2F9CB--

--wKvQvPhXp5JHMcHO9iIU6kUEnhrTr2MI2--

--FTj8C5IFxsgtoo5ITTmIwUvvp7w9F1LwE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaE0kVAAoJEIe2a0bZ0noz0PkH/R2ILdotQAgdlkmxKlAnZogZ
mVPHZJEP4NYtDPZGV2iSYQyjgnvPFVI6dddD7RSNS4WS3T57s7BfANGdyJntGyL8
TNhE01UwxRScafhlReiwqxylLl+DJy9Vr0zc0LnilIF2N1gMYAXfdmd73HXOzEHc
uyRORE7rgsJ/n7LJX702xHrP+WAFNixhjmuaLxmK194Eovj73HaFM5jsCq3If1sO
T82KU2ufzlE9/kqA8U/1eWK15mzQg+ae0EuMhenfNLcMPcEmZIVJGn/vAUIyc2oh
JPeY5HsuzhlVxugbdKl0ACP21MBpG/jurUMHvt8IMc8mgDDUIoQGoShOMh1yXY0=
=srZS
-----END PGP SIGNATURE-----

--FTj8C5IFxsgtoo5ITTmIwUvvp7w9F1LwE--


From nobody Mon Nov 20 13:44:16 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5815012EAB3 for ; Mon, 20 Nov 2017 13:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level: 
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 C7m5auTUcgHm for ; Mon, 20 Nov 2017 13:44:13 -0800 (PST)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35B126FDC for ; Mon, 20 Nov 2017 13:44:13 -0800 (PST)
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id A5D4E3A0BC for ; Mon, 20 Nov 2017 16:44:12 -0500 (EST)
Received: by mail-lf0-f48.google.com with SMTP id m1so11751186lfj.9 for ; Mon, 20 Nov 2017 13:44:12 -0800 (PST)
X-Gm-Message-State: AJaThX6fsSCPsToUmPPyqns8xjwq7zs+0s1KLLq0OL3Fy5kGpFsZU6I6 l1e/f27lBXtPjmHOcHNgyuNaEzke77uyzz513t4=
X-Google-Smtp-Source: AGs4zMZp0kvdBXUHEFrZX0htjU+wViFSRSPoZ6IA5SA5CJuAt4nz8RPNaGwDfPFZaJamCP+DKgdKYny1Ws2/Hgap4/4=
X-Received: by 10.25.208.20 with SMTP id h20mr3494549lfg.26.1511214251289; Mon, 20 Nov 2017 13:44:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.151.9 with HTTP; Mon, 20 Nov 2017 13:44:10 -0800 (PST)
In-Reply-To: <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>    <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
From: Patrick McManus 
Date: Mon, 20 Nov 2017 16:44:10 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Eliot Lear 
Cc: Patrick McManus , "doh@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114125c8a0b470055e70fc36"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:44:15 -0000

--001a114125c8a0b470055e70fc36
Content-Type: text/plain; charset="UTF-8"

I agree a bit. I had originally gone with incorrect (or not correct or
something like that) and Jim pushed back a tad. Its incorrect wrt the
algorithm and I think its fine to capture that if the scope is tight..

Here's another swing (with Rory's editorial changes.) that I like.

"Different DNS servers may provide different results to the same query. It
logically follows that the server which is consulted influences the end
result. Split-horizon DNS [RFC6950] is a specific example of this approach
where the answers are derived from the source of the query. If a client
selects a server that is unanticipated by this style of algorithm the
response may be not be correct."




On Mon, Nov 20, 2017 at 4:28 PM, Eliot Lear  wrote:

> Hi Patrick,
>
> The answer is not just different, but inappropriate.  We need to capture
> that point because that is why remediation would be required, and why this
> is at all worth mentioning.  I propose that we take another swing at this
> text over the next few days.
>
> Eliot
>
>
>
>
> On 11/20/17 9:39 PM, Patrick McManus wrote:
>
> I've taken the (imo) best bits from Eliot, Jim, and myself.. (I've tried
> to reject 'non-default', 'proximate', and 'policy' all as things that muddy
> the issue.) what do we think of this iteration?
>
> Operational Considerations
>
> Different DNS servers may provide different results to the same query. It
> logically follows that which server is consulted influences the end result.
> Split-horizon DNS [RFC6950] is a specific example of this approach where
> the answers are derived from the source of the query. A client that queries
> a resolver which uses this style of algorithm can expect to sometimes be
> returned different answers from the responses given by resolvers which do
> not use them
>
> The HTTPS channel used by this specification establishes secure two party
> communication between the DNS API Client and the DNS API Server. Filtering
> or inspection systems that rely on unsecured transport of DNS will not
> function in a DNS over HTTPS environment.
>
> On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear  wrote:
>
>> Hi Patrick,
>>
>> This is good text.  I think Jim has a point about "default resolver".
>> Also, further reduction is possible.  See below:
>>
>>
>> On 11/19/17 2:48 AM, Patrick McManus wrote:
>> > Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it
>> > to this scope I'm ok - but if the section begins to grow organically
>> > we should really discuss moving to a different doc. I have a proposed
>> > minor rework of your text below which I believe to be more concise and
>> > a bit more illuminating on the root issues. Let me know what you think.
>> >
>> > Operational Considerations
>> >
>> > Different DNS servers may provide different results to the same query.
>> > It logically follows that which server is consulted influences the end
>> > result. Split-horizon DNS [RFC6950] is a specific example of this
>> > approach where the answers are derived from the (potentially natted)
>> > source of the query. A client that chooses to query a non-default
>> > resolver for a name that is using this style of algorithm may not
>> > obtain correct results.
>>
>> s/chooses to query/queries/
>>
>> s/non-default resolver/resolver that is not proximate/
>>
>> How's that?
>> >
>> > The HTTPS channel used by this specification establishes secure two
>> > party communication between the DNS API Client and the DNS API Server.
>> > Filtering or inspection systems that rely on unsecured transport of
>> > DNS will not function in a DNS over HTTPS environment.
>>
>> Eliot
>>
>>
>
>

--001a114125c8a0b470055e70fc36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree a bit. I had originally gone with incorrect (=
or not correct or something like that) and Jim pushed back a tad. Its incor=
rect wrt the algorithm and I think its fine to capture that if the scope is=
 tight..

Here's another swing (with Rory&#=
39;s editorial changes.) that I like.

"Di=
fferent DNS servers may=20
provide different results to the same query. It logically follows that the =
server which is consulted influences the end result. Split-horizon DNS=20
[RFC6950] is a specific example of this approach where the answers are=20
derived from the source of the query. If a client selects a server that is =
unanticipated by this style of algorithm the response may be not be correct=
."




On Mon, Nov 20, 2017 at 4:28 PM, Eliot =
Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Patrick,

    
The answer is not just different, but inappropriate.=C2=A0 We need t=
o
      capture that point because that is why remediation would be
      required, and why this is at all worth mentioning.=C2=A0 I propose th=
at
      we take another swing at this text over the next few days.

    

    
Eliot

    

    


    

    


    

    

    
On 11/20/17 9:39 PM, =
Patrick McManus
      wrote:

    

    

     =20
      

        
I've taken the (imo) best bits from Eliot, Jim, and
          myself.. (I've tried to reject 'non-default', 'pr=
oximate', and
          'policy' all as things that muddy the issue.) what do we =
think
          of this iteration?

        

        


        

        
Operational Considerations

        


        

        
Different DNS servers may provide different results to the
          same query. It logically follows that which server is
          consulted influences the end result. Split-horizon DNS
          [RFC6950] is a specific example of this approach where the
          answers are derived from the source of the query. A client
          that queries a resolver which uses this style of algorithm can
          expect to sometimes be returned different answers from the
          responses given by resolvers which do not use them

        

        


        

        
The HTTPS channel used by this specification establishes
          secure two party communication between the DNS API Client and
          the DNS API Server. Filtering or inspection systems that rely
          on unsecured transport of DNS will not function in a DNS over
          HTTPS environment.

      

      


        
On Mon, Nov 20, 2017 at 1:05 AM, Eliot
          Lear <lear@cisco.com>
          wrote:

          
Hi
            Patrick,

            

            This is good text.=C2=A0 I think Jim has a point about "de=
fault
            resolver".=C2=A0

            Also, further reduction is possible.=C2=A0 See below:

            

              

              On 11/19/17 2:48 AM, Patrick McManus wrote:

              > Hi Eliot - indeed this is fairly brief.. thank you.
              if we can keep it

              > to this scope I'm ok - but if the section begins to
              grow organically

              > we should really discuss moving to a different doc. I
              have a proposed=C2=A0

              > minor rework of your text below which I believe to be
              more concise and

              > a bit more illuminating on the root issues. Let me
              know what you think.

              >

              > Operational Considerations

              >

              > Different DNS servers may provide different results
              to the same query.

              > It logically follows that which server is consulted
              influences the end

              > result. Split-horizon DNS [RFC6950] is a specific
              example of this

              > approach where the answers are derived from the
              (potentially natted)

              > source of the query. A client that chooses to query a
              non-default

              > resolver for a name that is using this style of
              algorithm may not

              > obtain correct results.

              

            s/chooses to query/queries/

            

            s/non-default resolver/resolver that is not proximate/

            

            How's that?

            

              
>

                > The HTTPS channel used by this specification
                establishes secure two

                > party communication between the DNS API Client and
                the DNS API Server.

                > Filtering or inspection systems that rely on
                unsecured transport of

                > DNS will not function in a DNS over HTTPS
                environment.

                

              

            

            Eliot

                

              

        

        

      

    

    

  






--001a114125c8a0b470055e70fc36--


From nobody Mon Nov 20 13:50:30 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC7C126FDC for ; Mon, 20 Nov 2017 13:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 omlI4bAckIiP for ; Mon, 20 Nov 2017 13:50:22 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21524126B6E for ; Mon, 20 Nov 2017 13:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16089; q=dns/txt; s=iport; t=1511214622; x=1512424222; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WGBY2JQz/MXdD0N/l7lTunheJwudkcP4M46UMptMiDY=; b=mRD6LfFLmZG1xe7kFGdzURTfzQ2dc/IO/GxaO1gITfm9C1COPP9R3XqW 86UqS+tOntEyatuwnadSsErZ+eGOm3Gp8knjfJt7YdR6KzzZMH+iJnLUB GoSDv1NrGaT83uzXC8THLorboN59vDly4YlgSrfZxJ6uApK3V/4lbhS6R g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQB1TRNa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRRuJ4N/ixOQMZEZhVmCAQcDhTsChT8VAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQECASNWEAsYJwMCAkYRBg0GAgEBihkIqE6CJyaKUAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQ4PgzSFboMChF8mgyuCYwWRdJBKhEmCKI4bjASHSJYygTo1I4F?= =?us-ascii?q?0NCEIHRWDLYRgQDaLUgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,430,1505779200";  d="asc'?scan'208,217";a="384717"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 21:50:20 +0000
Received: from [10.61.98.150] (dhcp-10-61-98-150.cisco.com [10.61.98.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAKLoJrI030209; Mon, 20 Nov 2017 21:50:19 GMT
To: Patrick McManus 
Cc: "doh@ietf.org" 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>    <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com> 
From: Eliot Lear 
Message-ID: <28b3ed9f-5f0a-ca07-9a50-68111d5c7fb7@cisco.com>
Date: Mon, 20 Nov 2017 22:48:53 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HV1TAl1cdbL9OIinUSgQcI8lgQkOEcSlh"
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:50:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HV1TAl1cdbL9OIinUSgQcI8lgQkOEcSlh
Content-Type: multipart/mixed; boundary="NA7Nx1VvTKxNJmPix1Pk9tDGwcuSlWhCn";
 protected-headers="v1"
From: Eliot Lear 
To: Patrick McManus 
Cc: "doh@ietf.org" 
Message-ID: <28b3ed9f-5f0a-ca07-9a50-68111d5c7fb7@cisco.com>
Subject: Re: [Doh] operational considerations
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
 
 
 
 <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
 
In-Reply-To: 

--NA7Nx1VvTKxNJmPix1Pk9tDGwcuSlWhCn
Content-Type: multipart/alternative;
 boundary="------------7AD179B6E724A4F5FAC90554"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7AD179B6E724A4F5FAC90554
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

WFM.

Thanks,

Eliot


On 11/20/17 10:44 PM, Patrick McManus wrote:
> I agree a bit. I had originally gone with incorrect (or not correct or
> something like that) and Jim pushed back a tad. Its incorrect wrt the
> algorithm and I think its fine to capture that if the scope is tight..
>
> Here's another swing (with Rory's editorial changes.) that I like.
>
> "Different DNS servers may provide different results to the same
> query. It logically follows that the server which is consulted
> influences the end result. Split-horizon DNS [RFC6950] is a specific
> example of this approach where the answers are derived from the source
> of the query. If a client selects a server that is unanticipated by
> this style of algorithm the response may be not be correct."
>
>
>
>
> On Mon, Nov 20, 2017 at 4:28 PM, Eliot Lear  > wrote:
>
>     Hi Patrick,
>
>     The answer is not just different, but inappropriate.=C2=A0 We need =
to
>     capture that point because that is why remediation would be
>     required, and why this is at all worth mentioning.=C2=A0 I propose =
that
>     we take another swing at this text over the next few days.
>
>     Eliot
>
>
>
>
>     On 11/20/17 9:39 PM, Patrick McManus wrote:
>>     I've taken the (imo) best bits from Eliot, Jim, and myself..
>>     (I've tried to reject 'non-default', 'proximate', and 'policy'
>>     all as things that muddy the issue.) what do we think of this
>>     iteration?
>>
>>     Operational Considerations
>>
>>     Different DNS servers may provide different results to the same
>>     query. It logically follows that which server is consulted
>>     influences the end result. Split-horizon DNS [RFC6950] is a
>>     specific example of this approach where the answers are derived
>>     from the source of the query. A client that queries a resolver
>>     which uses this style of algorithm can expect to sometimes be
>>     returned different answers from the responses given by resolvers
>>     which do not use them
>>
>>     The HTTPS channel used by this specification establishes secure
>>     two party communication between the DNS API Client and the DNS
>>     API Server. Filtering or inspection systems that rely on
>>     unsecured transport of DNS will not function in a DNS over HTTPS
>>     environment.
>>
>>     On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear >     > wrote:
>>
>>         Hi Patrick,
>>
>>         This is good text.=C2=A0 I think Jim has a point about "defaul=
t
>>         resolver".=C2=A0
>>         Also, further reduction is possible.=C2=A0 See below:
>>
>>
>>         On 11/19/17 2:48 AM, Patrick McManus wrote:
>>         > Hi Eliot - indeed this is fairly brief.. thank you. if we
>>         can keep it
>>         > to this scope I'm ok - but if the section begins to grow
>>         organically
>>         > we should really discuss moving to a different doc. I have
>>         a proposed=C2=A0
>>         > minor rework of your text below which I believe to be more
>>         concise and
>>         > a bit more illuminating on the root issues. Let me know
>>         what you think.
>>         >
>>         > Operational Considerations
>>         >
>>         > Different DNS servers may provide different results to the
>>         same query.
>>         > It logically follows that which server is consulted
>>         influences the end
>>         > result. Split-horizon DNS [RFC6950] is a specific example
>>         of this
>>         > approach where the answers are derived from the
>>         (potentially natted)
>>         > source of the query. A client that chooses to query a
>>         non-default
>>         > resolver for a name that is using this style of algorithm
>>         may not
>>         > obtain correct results.
>>
>>         s/chooses to query/queries/
>>
>>         s/non-default resolver/resolver that is not proximate/
>>
>>         How's that?
>>         >
>>         > The HTTPS channel used by this specification establishes
>>         secure two
>>         > party communication between the DNS API Client and the DNS
>>         API Server.
>>         > Filtering or inspection systems that rely on unsecured
>>         transport of
>>         > DNS will not function in a DNS over HTTPS environment.
>>
>>         Eliot
>>
>>
>
>


--------------7AD179B6E724A4F5FAC90554
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
WFM.

    
Thanks,

    
Eliot

    

    

    
On 11/20/17 10:44 PM, Patrick McManus
      wrote:

    

    

      
      

        
I agree a bit. I had originally gone with incorrect (or not
          correct or something like that) and Jim pushed back a tad. Its
          incorrect wrt the algorithm and I think its fine to capture
          that if the scope is tight..

        

        


        

        
Here's another swing (with Rory's editorial changes.) that
          I like.

        

        


        

        
"Different DNS servers may provide different results to the
          same query. It logically follows that the server which is
          consulted influences the end result. Split-horizon DNS
          [RFC6950] is a specific example of this approach where the
          answers are derived from the source of the query. If a client
          selects a server that is unanticipated by this style of
          algorithm the response may be not be correct."

        


        

        


        

        

      

      


        
On Mon, Nov 20, 2017 at 4:28 PM, Eliot=

          Lear <lear@cisco.com>
          wrote:

          

            

              
Hi Patrick,

              
The answer is not just different, but inappropriate.=C2=A0=

                We need to capture that point because that is why
                remediation would be required, and why this is at all
                worth mentioning.=C2=A0 I propose that we take another sw=
ing
                at this text over the next few days.

                  

              
                  
Eliot

                  

                
              

                

                  


                  

                  


                  

                  

                  
On
                    11/20/17 9:39 PM, Patrick McManus wrote:

                  

                  

                    

                      
I've taken the (imo) best bits from Eliot,
                        Jim, and myself.. (I've tried to reject
                        'non-default', 'proximate', and 'policy' all as
                        things that muddy the issue.) what do we think
                        of this iteration?

                      

                      


                      

                      
Operational Considerations

                      


                      

                      
Different DNS servers may provide different
                        results to the same query. It logically follows
                        that which server is consulted influences the
                        end result. Split-horizon DNS [RFC6950] is a
                        specific example of this approach where the
                        answers are derived from the source of the
                        query. A client that queries a resolver which
                        uses this style of algorithm can expect to
                        sometimes be returned different answers from the
                        responses given by resolvers which do not use
                        them

                      

                      


                      

                      
The HTTPS channel used by this specification
                        establishes secure two party communication
                        between the DNS API Client and the DNS API
                        Server. Filtering or inspection systems that
                        rely on unsecured transport of DNS will not
                        function in a DNS over HTTPS environment.

                    

                    


                      
On Mon, Nov 20, 2017 at
                        1:05 AM, Eliot Lear <lear@cisco.com&g=
t;
                        wrote:

                        
Hi Patrick,

                          

                          This is good text.=C2=A0 I think Jim has a poin=
t
                          about "default resolver".=C2=A0

                          Also, further reduction is possible.=C2=A0 See
                          below:

                          

                            

                            On 11/19/17 2:48 AM, Patrick McManus wrote:
                            > Hi Eliot - indeed this is fairly
                            brief.. thank you. if we can keep it

                            > to this scope I'm ok - but if the
                            section begins to grow organically

                            > we should really discuss moving to a
                            different doc. I have a proposed=C2=A0

                            > minor rework of your text below which I
                            believe to be more concise and

                            > a bit more illuminating on the root
                            issues. Let me know what you think.

                            >

                            > Operational Considerations

                            >

                            > Different DNS servers may provide
                            different results to the same query.

                            > It logically follows that which server
                            is consulted influences the end

                            > result. Split-horizon DNS [RFC6950] is
                            a specific example of this

                            > approach where the answers are derived
                            from the (potentially natted)

                            > source of the query. A client that
                            chooses to query a non-default

                            > resolver for a name that is using this
                            style of algorithm may not

                            > obtain correct results.

                            

                          s/chooses to query/queries/

                          

                          s/non-default resolver/resolver that is not
                          proximate/

                          

                          How's that?

                          

                            
>
=

                              > The HTTPS channel used by this
                              specification establishes secure two

                              > party communication between the DNS
                              API Client and the DNS API Server.

                              > Filtering or inspection systems that
                              rely on unsecured transport of

                              > DNS will not function in a DNS over
                              HTTPS environment.

                              

                            

                          

                          Eliot

                              

                            

                      

                      

                    

                  

                  

                

              

            

          

        

        

      

    

    

  


--------------7AD179B6E724A4F5FAC90554--

--NA7Nx1VvTKxNJmPix1Pk9tDGwcuSlWhCn--

--HV1TAl1cdbL9OIinUSgQcI8lgQkOEcSlh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJaE03GAAoJEIe2a0bZ0nozrWwH/i3WrdA0gOSYJ9yfTS06SDlh
ymXLFccC3euSE9Xz2riSKhIDSMefiEvoYyI/hzmstfO5M9DNEwHrXYWrXwzzS1AI
FR9TU+vN0NyVwSgMQwwnfiW6WK8as2mGh7KA56+LmUBan/q5SIO2T+bQWEaSfAD5
MM8nZP5ArJQfK2BbnIOwnNIcY/4TZK/HjF1FM/kShuT40pmtowod7Zz1F62XiZuT
OA7ftbcTZ1JFFQy+JsOPe79xhi6vt9sMgTdhBX/SzLqo/q/cKLG99erzCnobEFKe
vK7y7ovxB6I43ZTlu1JZ3YOT6oeZH+K+yF13APom1lLQrnFt3B1fcwc4XtOopfE=
=2Wbw
-----END PGP SIGNATURE-----

--HV1TAl1cdbL9OIinUSgQcI8lgQkOEcSlh--


From nobody Mon Nov 20 14:01:15 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D5612EAC6 for ; Mon, 20 Nov 2017 14:01:14 -0800 (PST)
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] 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 0ERpLvyAkE5C for ; Mon, 20 Nov 2017 14:01:12 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89F71241F5 for ; Mon, 20 Nov 2017 14:01:12 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id A8DB32420D43; Mon, 20 Nov 2017 22:01:10 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid 
In-Reply-To: 
Date: Mon, 20 Nov 2017 22:01:10 +0000
Cc: Eliot Lear , DoH Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>    <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com> 
To: Patrick McManus 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:01:14 -0000

> On 20 Nov 2017, at 21:44, Patrick McManus  =
wrote:
>=20
> "Different DNS servers may provide different results to the same =
query. It logically follows that the server which is consulted =
influences the end result. Split-horizon DNS [RFC6950] is a specific =
example of this approach where the answers are derived from the source =
of the query. If a client selects a server that is unanticipated by this =
style of algorithm the response may be not be correct."

I don=E2=80=99t like this. Sorry. =E2=80=9CCorrect=E2=80=9D is not the =
correct word to use here. I might query a split DNS server (or whatever) =
and get what would be the correct response for me. But if you queried =
that server, the answer could be wrong for you. But only you. =
=E2=80=9CAlgorithm=E2=80=9D doesn=E2=80=99t seem right either since =
algorithms are not necessarily involved in determining what response a =
server returns. Algorithm kind of implies some sort of response =
rewriting and while that does happen, it=E2=80=99s not the only way that =
a server might return different answers.

Let=E2=80=99s simplify further. How about:

Local policy considerations and similar factors mean different DNS =
servers may provide different results to the same query: for instance in =
split DNS configurations [RFC6950]. It logically follows that the server =
which is queried can influence the end result. Therefore a client=E2=80=99=
s choice of resolving server may affect the responses it gets to its =
queries.


From nobody Mon Nov 20 14:07:17 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1812EAB5 for ; Mon, 20 Nov 2017 14:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qk-QandRg-MN for ; Mon, 20 Nov 2017 14:07:15 -0800 (PST)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E78129B46 for ; Mon, 20 Nov 2017 14:07:14 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id BB91E2420D43; Mon, 20 Nov 2017 22:07:13 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid 
In-Reply-To: 
Date: Mon, 20 Nov 2017 22:07:13 +0000
Cc: Eliot Lear , DoH Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C5054E6-DA90-43DE-BD7B-02136F74A09C@rfc1035.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>    <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>  
To: Patrick McManus 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Doh] operational considerations
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:07:16 -0000

> On 20 Nov 2017, at 22:01, Jim Reid  wrote:
>=20
> Local policy considerations and similar factors mean different DNS =
servers may provide different results to the same query: for instance in =
split DNS configurations [RFC6950]. It logically follows that the server =
which is queried can influence the end result. Therefore a client=E2=80=99=
s choice of resolving server may affect the responses it gets to its =
queries.

Replying to myself, eh? The above is a bit clunky. Try this instead:

Local policy considerations and similar factors mean a DNS server can =
sometimes provide different results to the same query: for instance in =
split DNS configurations [RFC6950]. It logically follows that the server =
which is queried can influence the end result. Therefore a client=E2=80=99=
s choice of DNS server may affect the responses it gets to its queries.


From nobody Tue Nov 28 14:54:22 2017
Return-Path: 
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCFE1286B1; Tue, 28 Nov 2017 14:54:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: doh@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151190966085.7996.3478258410803970939@ietfa.amsl.com>
Date: Tue, 28 Nov 2017 14:54:20 -0800
Archived-At: 
Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-02.txt
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 22:54:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Over HTTPS WG of the IETF.

        Title           : DNS Queries over HTTPS
        Authors         : Paul Hoffman
                          Patrick McManus
	Filename        : draft-ietf-doh-dns-over-https-02.txt
	Pages           : 15
	Date            : 2017-11-28

Abstract:
   DNS queries sometimes experience problems with end to end
   connectivity at times and places where HTTPS flows freely.

   HTTPS provides the most practical mechanism for reliable end to end
   communication.  Its use of TLS provides integrity and confidentiality
   guarantees and its use of HTTP allows it to interoperate with
   proxies, firewalls, and authentication systems where required for
   transit.

   This document describes how to run DNS service over HTTP using
   https:// URIs.

   [[ There is a repository for this draft at https://github.com/dohwg/
   draft-ietf-doh-dns-over-https ]].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02
https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Nov 28 15:02:56 2017
Return-Path: 
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7D128AB0 for ; Tue, 28 Nov 2017 15:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kuoHKvJGkRrz for ; Tue, 28 Nov 2017 15:02:54 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43399126DC2 for ; Tue, 28 Nov 2017 15:02:54 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Nov 2017 15:02:52 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 28 Nov 2017 15:02:52 -0800
From: Paul Hoffman 
To: "doh@ietf.org" 
Thread-Topic: -02 posted
Thread-Index: AQHTaJ0EPOqyCB/F+ECzRmRUuqng3A==
Date: Tue, 28 Nov 2017 23:02:52 +0000
Message-ID: <955D7F64-E471-4172-8D71-03AC8742CA84@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <396468DBAC29C741911397B0316DEF22@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Doh] -02 posted
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 23:02:55 -0000

Greetings. As you can see from the previous message, we have done a big upd=
ate to the -01. Please review the diffs and let us know if we got some wron=
g or undershot what was requested. Heck, please review the whole draft: it'=
s still pretty short.

As a reminder, we are tracking issues brought up here on the GitHub repo at
   https://github.com/dohwg/draft-ietf-doh-dns-over-https
You can see that we still have five known issues open, and there are a few =
placeholders in the draft itself. Let's keep the level of discussion up so =
we can surprise everyone and make our WG deadline. :-)

--Paul Hoffman

Title : DNS Queries over HTTPS=20
Authors : Paul Hoffman=20
Patrick McManus=20
Filename : draft-ietf-doh-dns-over-https-02.txt=20
Pages : 15=20
Date : 2017-11-28=20

https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/

There are also htmlized versions available at:=20
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02
https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-02

A diff from the previous version is available at:=20
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-doh-dns-over-https-02