From nobody Thu Mar 1 09:50:36 2018 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 293FC12EBF1; Thu, 1 Mar 2018 09:50:34 -0800 (PST) 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=unavailable 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 K99RMu8WXWr2; Thu, 1 Mar 2018 09:50:32 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2DD12EBF5; Thu, 1 Mar 2018 09:50:28 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id 108so6342313otv.3; Thu, 01 Mar 2018 09:50:28 -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=scnlEauMGmaADg9bUgBzAQx1aw6urwv8RKQ4iFi+CqI=; b=u4cCQp30gk28XXwvGD3A4PKUaZsI90YNtSag6EDuy+Exau6bntrV+tgfCks/3q1CO7 O63vxQ9mOxQhx9SsorPygzB/yHznpCvggn60ZzVfzO70gIv2+tYSiTWz/vuZREK6zelM RDMbQAZIXjc1/hBTQZiK7LwQr+lRmGiiaeUXpVdhHcY8XU+5oS0e5HQgQPp3aWx6QQJF BfFEn0jgMwkHfLWe9mKE7WVkY+NY+qEsXIbge/Us2uUQQWul9fsLjHyj5WOdeoSDG5Ns RKNwPDcaAV1X9FfcYAHuJ1S/gIvGTzioMK88dWFyso7lQXTVdBpD5Fnuw5TdphnK8P2s BYHg== 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=scnlEauMGmaADg9bUgBzAQx1aw6urwv8RKQ4iFi+CqI=; b=cBjEoh1fKYQ5BIYGQ3dtyB+8XJ5ueOKLxEB2WhgZsk5c92CVc2gx6Kl3pilV21j07g npZsg8m2Wtl/iUUOuBO3Eh16ua4SGcX5jFOQpeiQjUNxDDYgqbANmRoLdTEr9JOfNcUS E2CzovfKI3gUU1uPr9mCDj2Bs1mP2ouqsm0uq1eGFMFxRvtRTk9T6EeP+OwEN+k1L9uF FJMhWnJwyuEELqc3pOLmNM1x3Vd3ddTffyXNuWMcN4P3be5FaSO+Owg2WBbEbfM5xu1v r3NRLs2b6YMxDqSWZdGh8sFeg4xDcoGHETyIFIzWhHel2oD7EljbAsKeXuj5tdzeOSQc xegQ== X-Gm-Message-State: APf1xPDf/64puZLaFPX9K2itw0H9IYoIHpYGBXbIvjYR6sLOmeE5Tpow qihijpXcus0e7VKyrgQS32um5iduuHnEHfCVt6lErw== X-Google-Smtp-Source: AG47ELt9DcTcA+SzRKduWAc0e5WTHv4Of7n7CClKi0MCV6xxo/wYKss99t8rLHpxN2GKkHnIAfm/JT3rcaH0rzUno7M= X-Received: by 10.157.24.48 with SMTP id b45mr2110051ote.195.1519926627736; Thu, 01 Mar 2018 09:50:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Thu, 1 Mar 2018 09:49:57 -0800 (PST) From: Ted Hardie Date: Thu, 1 Mar 2018 09:49:57 -0800 Message-ID: To: doh@ietf.org, dnsop@ietf.org, precis@ietf.org, dprive@ietf.org, idnabis@ietf.org, Internet Architecture Board Content-Type: multipart/alternative; boundary="001a113d6d86bb218c05665d7e22" Archived-At: Subject: [Doh] IAB seeks volunteer to serve on ICANN study group for root zone label generation 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, 01 Mar 2018 17:50:34 -0000 --001a113d6d86bb218c05665d7e22 Content-Type: text/plain; charset="UTF-8" Greetings, As part of their work on the deployment of IDNs in the root zone, ICANN plans to convene a technical study group on the application of root zone label generation rules . They have the asked the IAB to assist in the nomination of experts to this panel, and the IAB has agreed. We are therefore seeking community volunteers to assist with this work. The technical experts are expected to be familiar with the technical standards and the issues relevant to these ICANN activities, primarily DNS and IDNA2008 standards and DNS registry operational practices. See the link above for additional background and applicable areas of expertise. If you are interested, please send a short email message to iab-chair@iab.org with a copy to execd@iab.org with your motivation and information concerning your familiarity with the IETF and ICANN. The deadline for volunteering is March 16, 2018. Thanks, Ted Hardie for the IAB --001a113d6d86bb218c05665d7e22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>

Greetings,

As part of their work on the deployment o= f IDNs in the root zone, ICANN plans to con= vene a technical study group on the application of root zone label= generation rules .=C2=A0 They have the asked the IAB to assist in the nomination of experts= =20 to this panel, and the IAB has agreed.=C2=A0 We are therefore seeking=20 community volunteers to assist with this work. =C2=A0

The tech= nical experts are expected=20 to be familiar with the technical standards and the issues relevant to these ICANN activities, primarily DNS and= =20 IDNA2008 standards and DNS registry operational practices. See the link=20 above for additional background and applicable areas of expertise.

If you = are interested, please send a short email=20 message to iab-chair= @iab.org with a copy to execd@iab.org with your=20 motivation and information concerning your familiarity with the IETF and ICANN.=C2=A0 The deadline for volunteering= is March 16, 2018.

Thanks,

Ted Hardie
for the IAB

--001a113d6d86bb218c05665d7e22-- From nobody Tue Mar 6 07:33:29 2018 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 D66D4120454 for ; Tue, 6 Mar 2018 07:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 OvU35rd7p6FF for ; Tue, 6 Mar 2018 07:33:25 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768DE124E15 for ; Tue, 6 Mar 2018 07:33:25 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id b34so22459041ioj.6 for ; Tue, 06 Mar 2018 07:33:25 -0800 (PST) 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=w50h0AQKd7OJ8u2MwvPJf1hCfQmRRbxW1rccO+OBDyY=; b=O0iE6r2ZvBMJb56TzbkhLXLv8lbpZqIQcAOP70qkb5sh8yR2vTq+hdi2o5fL8lCxh3 zF/0N3Wl/JS7h230wMaulj0UYeDdhgZKpiu2tnaqyNhrGVw/1dL2M0B0ychwpw4jbspI uyVfaHaaQacd+6+6hX6SkUBQZMaktxrI65XqhGUmQ1pSRQ6C3J8P5RWTcADmVXvcUq+Y DDEQ68SbWTA2NSWYRamMhGAv82uNLwq3Vn02po4s+iKBv9ZzlBiqA0pMJAX21B+jCax0 IViMUQ+PZKV/jsnwEKVTiTnMRXmNTlf+3U//Nncf6Btr7mBwUr23PPQe37pO+fTx9JyW 0lNw== 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=w50h0AQKd7OJ8u2MwvPJf1hCfQmRRbxW1rccO+OBDyY=; b=hgEaZOS0/ElMLO2Z5nBlATFtFyDBFp+XteB9Y38I+JydLQuIKR2LRFWLpeQlpx9T3F 0ThRNAcWFhuREtzp8J8cIeqHhp5M5KZeeSOeuS3UOETeQHQymTbUuNHyb1FTA8r9FgHU jhWE2LfK58NqqFxiBt5myYitRVPHm75DjuRagzME+7laqQJMGyMP/DVhF+RanownHpS2 tqEbIm8Ym21SQPYVwlRI6HYey6O3JfwwbMdyG0yELWXEJsqRWeWGJpUEp9jDsB7LKZkk VRV7oo4UOyoM9ffDH4i4ODYR/i4z6oHBHSPP5LAUxa3zSCol3bHLkfVYUHlG/EmibqmX JmQQ== X-Gm-Message-State: AElRT7GmRK+nxSYWyDtXh66ToQ/D2m1m4h1LfTnpw0EBfP32fl8C3XUe Qe6UN4hOBU/AJNWLDNel2r42juhKfVd0c9b8/Bfq7mjl X-Google-Smtp-Source: AG47ELsNya0+7tsoO9eW59iXnSDuZ1WWYPwMQjgM4kEfce4aQjgdWplRm8DMsGy+AHy9RrLxNY6RK4xJawQ9ZHpb45o= X-Received: by 10.107.48.209 with SMTP id w200mr21483290iow.128.1520350404040; Tue, 06 Mar 2018 07:33:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.174.133 with HTTP; Tue, 6 Mar 2018 07:33:23 -0800 (PST) From: Ben Schwartz Date: Tue, 6 Mar 2018 10:33:23 -0500 Message-ID: To: doh@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1146325ed1358a0566c029f8" Archived-At: Subject: [Doh] Reminder: DOH IETF 101 agenda time 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, 06 Mar 2018 15:33:27 -0000 --001a1146325ed1358a0566c029f8 Content-Type: multipart/alternative; boundary="001a1146325ec5a4e00566c02905" --001a1146325ec5a4e00566c02905 Content-Type: text/plain; charset="UTF-8" To anyone who needs agenda time in DOH at IETF 101, please notify the chairs this week. Thanks, Ben --001a1146325ec5a4e00566c02905 Content-Type: text/html; charset="UTF-8"
To anyone who needs agenda time in DOH at IETF 101, please notify the chairs this week.

Thanks,
Ben
--001a1146325ec5a4e00566c02905-- --001a1146325ed1358a0566c029f8 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAte+U71moeM1MMfh1ihxZv gowaLkp2vgvFTJt8RM+7yTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMDYxNTMzMjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAXf9ioKu4KqJa6a5rrE/o2qdWvbZ9BovzaiGLpJa7 EtXgx52P68M7oXSIZgYqiuiR0oYswSEzRf3LYX3i1nLR76Kn23P+CzCp8ZxKW1vc+dxpT2ijKqle Wxjbz9NCGd0MwOBbBchQYMQkhjfN3u5ETE9kqgUrzgLMNIzaL+z+cef5AymN/KryEPjl0KCy8JMs vWSbLPYITbV7QtrkfcSZR4yTbJtWHaXyK+fwJD0MQloYwh4HmHs0/w65fytEqMGIBLO/I48UjRit ZFbzmh6gKEsgHBa4YDwFZV+ir2uvldyBU4bsBXKg7djr/+6vK/NyuQrEYAaWUupPU4rAiMWylg== --001a1146325ed1358a0566c029f8-- From nobody Tue Mar 6 19:49:31 2018 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 1AC4C126CC7 for ; Tue, 6 Mar 2018 19:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 r1d-l4Ofg5Fz for ; Tue, 6 Mar 2018 19:49:28 -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 8FFF1124BE8 for ; Tue, 6 Mar 2018 19:49:28 -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, 6 Mar 2018 19:49:26 -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, 6 Mar 2018 19:49:26 -0800 From: Paul Hoffman To: "doh@ietf.org" Thread-Topic: Use cases and URLs Thread-Index: AQHTtcdJ6G4jKxcbnU6n6Up2z3ylaw== Date: Wed, 7 Mar 2018 03:49:26 +0000 Message-ID: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@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: <25ED1C188F34724EBF7C31B163980C15@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Use cases and URLs 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, 07 Mar 2018 03:49:30 -0000 Greetings again. In the discussions in the last month since draft-ietf-doh-= dns-over-https-03 came out, particularly at the DNS Privacy Workshop at NDS= S, it has become clear that there are a lot of use cases that are related t= o the two given in Section 3 of the draft, but are not called out explicitl= y. They fall under the sentence "They might use the DOH server for all quer= ies, or only for a subset of them." Some that I have heard are (approximately): - Use the preferred DNS API server for all DNS lookups in the browser whene= ver the browser is running (start the TLS session with the DNS API when the= browser starts). - If a tab/window for the origin of a configured DNS API server is open, us= e the configured API server for all DNS lookups. - If a tab/window for the origin of a configured DNS API server is open, us= e the configured API server for DNS lookups that are in that origin only. - If a tab/window for the origin of a configured DNS API server is open, an= d the configured API server pushes DNS information, accept it. (Note that you might like or dislike some of these; that's fine.) In addition, there has been the assumption by many people that they could a= dd new DNS API servers to the list of configured servers in the browser bas= ed on various out-of-band information (articles, word-of-mouth, ...). That = is, people want the additional DNS privacy through a somewhat-trusted web s= ite rather than no privacy from the who-knows-where they are getting now. (= Don't forget that the vast, vast majority of users are doing DNS lookups us= ing resolvers they have no idea about.) The ability to add new DNS APIs servers leads to the question of the URL be= ing used for a particular DNS API server. In early drafts, we used "https:/= //.well-known/dns-query?..." as the standard URL, but it was pointe= d out that such a standard is prohibited by RFC 5785. The current draft say= s that there is no standard, and every origin will have its own URL for the= API. This makes it much harder for a user to add new configured DNS API se= rvers and thus reduces the chance that some of their DNS queries will be pr= ivate, based on which of the use cases get implemented. A protocol point between "here is the fixed URL" and "every origin has its = own URL" is "discover the policy for an origin to serve as a DNS API server= ". That is, use the RFC 5785 ".well-known" scheme as a way to find out what= the origin's policy is. That way, a user can configure new servers in thei= r browser only knowing the origin name (which is all they really understand= anyway...). A first guess of a proposal would be that "https:///.well-known/dns= -query/" returns a JSON object that looks like: { "has-DNS-API": true, "DNS-API-URLs": [ "https:///admin-dns/?", "https:///backup-dns/?" ] } This uses the .well-known for what it is supposed to be used for, and gives= each origin a chance to pick their own URL scheme. Getting no response or = "{ "has-DNS-API": false }" both tell the user that origin's policy as well,= of course. Thoughts? --Paul Hoffman= From nobody Tue Mar 6 20:04:37 2018 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 05AB5124BE8 for ; Tue, 6 Mar 2018 20:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 Tk8fu2F8Sl3g for ; Tue, 6 Mar 2018 20:04:35 -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 03F751242EA for ; Tue, 6 Mar 2018 20:04:34 -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 w2744AHV037528 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 6 Mar 2018 22:04:11 -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 , "doh@ietf.org" References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> From: Adam Roach Message-ID: <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> Date: Tue, 6 Mar 2018 22:04:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Use cases and URLs 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, 07 Mar 2018 04:04:36 -0000 On 3/6/18 9:49 PM, Paul Hoffman wrote: > The current draft says that there is no standard, and every origin will have its own URL for the API. This makes it much harder for a user to add new configured DNS API servers Can you elaborate on this a bit? I fully expect that the typical user-self-provisioning case will involve copy/pasting server information, in which case the difference between a server and a URL is pretty minimal. Do you expect users to type server names in rather than copying them? /a From nobody Tue Mar 6 21:28:26 2018 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 1326F126D73 for ; Tue, 6 Mar 2018 21:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 BVS2-GgxYo4N for ; Tue, 6 Mar 2018 21:28:23 -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 397F2124D6C for ; Tue, 6 Mar 2018 21:28:23 -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; Tue, 6 Mar 2018 21:28:21 -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, 6 Mar 2018 21:28:20 -0800 From: Paul Hoffman To: Adam Roach CC: "doh@ietf.org" Thread-Topic: [Ext] Re: [Doh] Use cases and URLs Thread-Index: AQHTtcdJ40hpyDl8sESf8pnHtAiHH6PErTiA//+Rbrc= Date: Wed, 7 Mar 2018 05:28:19 +0000 Message-ID: <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org>, <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> In-Reply-To: <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 05:28:25 -0000 On Mar 6, 2018, at 20:04, Adam Roach wrote: >=20 >> On 3/6/18 9:49 PM, Paul Hoffman wrote: >> The current draft says that there is no standard, and every origin will = have its own URL for the API. This makes it much harder for a user to add n= ew configured DNS API servers >=20 >=20 > Can you elaborate on this a bit? I fully expect that the typical user-sel= f-provisioning case will involve copy/pasting server information, in which = case the difference between a server and a URL is pretty minimal. Do you ex= pect users to type server names in rather than copying them? Yes, exactly. If someone tells you that your bank runs this secure DNS serv= er, that=92s verbal, not copy and paste. = From nobody Tue Mar 6 21:41:26 2018 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 667C91241F3 for ; Tue, 6 Mar 2018 21:41:25 -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=iPl5h3/z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QZHcPczJ 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 vCj_c3sPJ64Q for ; Tue, 6 Mar 2018 21:41:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D2B124BE8 for ; Tue, 6 Mar 2018 21:41:23 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 277F420DD3; Wed, 7 Mar 2018 00:41:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 07 Mar 2018 00:41:22 -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=fm2; bh=9NJFveKI/DZIJJRpJHFzXfpWwA9Vh az4kg/1tELwDgA=; b=iPl5h3/z19dbJUDpAMJErN2q1/aFW/AXlFiSgNqT43uze PuSi+2KcPrecO777taYjAZUvYAiqk+EDx83uUXqUgJS3ZafxTqUidGNPtuxyDIs7 yhbSt/HG5/BTW3IzciVSKrG3KNjhQZuo8ml0CXr/Nvsc0Ghu9Zk0ehGUF+zz7oiS JrogfIACMis1/w6xHxR3Nll7MKep1X1XMlWzqS8hKPbrgEQIyVQR7R4Z0BXITGoh ZA/YX2e2lje8jUCi4aHKc81KEn9NPXpc6SPlaG5Kus8zAtj6slvrdwXgSFzs15Zp yipzGFdw0VAS695ijv/v84N/mLLOFgZl8HtD49wpQ== 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=fm2; bh=9NJFve KI/DZIJJRpJHFzXfpWwA9Vhaz4kg/1tELwDgA=; b=QZHcPczJFkynrde+KqbDqF KPnTzuY8snlgBXQUi4xhqbLJSM8I1iOdm5Uh+SKMpg9+IlEcZuuu1pFoGubdf2fO Kx+yNEqHmcy+2Ccag1WnJjZRGd4hhGuP6BCLDb7eGAGE6hkHHcrfK31p9Eegyf1l 47Kt3qf2szcySnWTGFkStS/X7EykOqRp3iVfXx0jLq5o2tnOQanZwtOOyz5cNOEM aLCYsiSHAkoKTv0d59YF+AuyElm7zIEBe4NkrWHm9Z3Enk6sRIHvrRXBIOlWHBav wFrAb+TWyVev6N64e4ue35R1kYEoszHS9F2sf2mWzM7TksToVH32VtSKYUmTCfpA == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B3D847E498; Wed, 7 Mar 2018 00:41:20 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> Date: Wed, 7 Mar 2018 16:41:17 +1100 Cc: Adam Roach , "doh@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 05:41:25 -0000 Is making it super-easy for non-technical end users to configure a new = DNS server a feature or a bug? > On 7 Mar 2018, at 4:28 pm, Paul Hoffman = wrote: >=20 > On Mar 6, 2018, at 20:04, Adam Roach wrote: >>=20 >>> On 3/6/18 9:49 PM, Paul Hoffman wrote: >>> The current draft says that there is no standard, and every origin = will have its own URL for the API. This makes it much harder for a user = to add new configured DNS API servers >>=20 >>=20 >> Can you elaborate on this a bit? I fully expect that the typical = user-self-provisioning case will involve copy/pasting server = information, in which case the difference between a server and a URL is = pretty minimal. Do you expect users to type server names in rather than = copying them? >=20 > Yes, exactly. If someone tells you that your bank runs this secure DNS = server, that=E2=80=99s verbal, not copy and paste.=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 7 07:35:21 2018 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 3A3E2128961 for ; Wed, 7 Mar 2018 07:35:19 -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 AOYyGZwXJ8bY for ; Wed, 7 Mar 2018 07:35:11 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 2F0E812778D for ; Wed, 7 Mar 2018 07:35:11 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s198so3124695qke.5 for ; Wed, 07 Mar 2018 07:35:11 -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=nurtxQDfpXiBfEfyVIXtlbWwcKcXwjO1ibq5Ouo4yno=; b=YEDDpo33CdsTnsVLpgUmF3mZLYpBpnhekJh7vZlIlf1GWWcqdOqTTm7ya96eDclA0x QrqOmwZfvEGAq6wfPjS5MJbeM5PLZpyPSv5lmGc0UaOaCXBoRiAaiTbNTRHSlrC1StIK 1Cj/PB8yRHTJh96bpbfRvpdBjuJbv1M/e8MMYOdIuxRYHvahJIxMqho5OcxGUenfYykR f0IbUqmxHViHmWYTU+Tz+b/LMJhiABiPbyMGKCYtQ3rN2W4FnTDh+M9GDVWqrzZocTWH wZHiOq4Jqqd3JKoA4l6Au7anOywc1gzQQ9vLlsU8VstxqqBZukDviDs7eQBsUHgjtTB5 WtBg== 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=nurtxQDfpXiBfEfyVIXtlbWwcKcXwjO1ibq5Ouo4yno=; b=JYZ9U8SU76kbbCd8KgIDleiEVet3UFmo3z7EAuUKXH72RdMhmuUOLAZVAQUn68O7r1 t9OYPvRyUUpeC5j6EQR8bP4lg92tCa+3YQ7FnyixdJjZ4e65ZFTMkkL6ykwHaks6o+cq PAwuBo8lnsu0XepnOnPYtNe+UPUdGUi+ig8ONLDrNYClAJ9L/+XlEdic8j2D6ev25xeB HOFIRwdQ8wpkfA6fhxM3NJdNUqiYbV1UylcMqTcXCzvfa35Qvo7iDu5MFoku1fDN9i26 Rxz3WPCrXswk/i0bIFcWmp/J5S2vyKc2Z2R1W++LehbXZ10LzrP9A27IRMTeWxi24K6c oE9g== X-Gm-Message-State: AElRT7H8QmZdb8busHKiUJbjN5kk94yWnFwxWT6vHNfDj/QWVSP3O7fB G6eBuhCaudwDe2klCc1WBz48kpa8ByIXVNslJ9e/HQ== X-Google-Smtp-Source: AG47ELvHdl9u9Tqvu1GghgCrlsibvNVByM7VUI3GXGA+/e0MqSYHhmb8rKnB2eSty9F+H6oJwjZ03bAhILxKghv43mw= X-Received: by 10.55.171.6 with SMTP id u6mr33770455qke.175.1520436909602; Wed, 07 Mar 2018 07:35:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.46.72 with HTTP; Wed, 7 Mar 2018 07:35:08 -0800 (PST) From: Massimiliano Fantuzzi Date: Wed, 7 Mar 2018 16:35:08 +0100 Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="089e08e589a5e67a8a0566d44dc6" Archived-At: Subject: Re: [Doh] Running code 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, 07 Mar 2018 15:35:19 -0000 --089e08e589a5e67a8a0566d44dc6 Content-Type: text/plain; charset="UTF-8" Hi to the Doh mailing list and group, Bringing your attention to an interesting project (born around 2009). DNSP is written in C (local client server) and PHP (remote resolver): https://github.com/fantuz/DNSProxy it WAS NOT built on "H2 compliancy" by the time, quite obviuously. Now thanks to more recent CURL libs, the H2 part has been added and passing tests; by this weekend I can commit to have it completely DOH-aware. Some functions/plugins for DNSP are being staged and to be released soon. more features are to be supported with minimum effort. Redis cache for example is trivial, adding QUIC might be not. Please let me know your feedback ! The tree of the project might look ugly to you; I am not a software engineer, just a passionate technician (sysadmin/networking/webservers/db) with sufficient debug skills. The initial credit goes to Andrea Fabrizi who created alpha DNSP back in 2009. Since 2010 I have been thinking of how to expand further this idea, got lucky enough to test its functionality within a small satellite-provider in some time later (2013) [1] Andrea has fully authorized me to take on his project as he would not have interest or time to carry on. Code changed quite a bit, but the core hasn't (principle was good). I even created an Arduino version, as POC and for fun :) As I could not find any draft on a DOH topic back then (DNSSEC was rolling out) I cannot even name that many experiments on embrionic-Doh ancestors, per my knowledge, The only 3 examples deserving a credit for being innovative in vehiculating DNS over differernt channels are to me "dnspod"[2] and Pcap_DNSProxy[3] and more recently, ChinaDNS[4]. Might there be other, I let you complete. Summarising: - DNSP did its modest job, against DNS censorship, blocking/locating/redirecting and leaks, offering a *mitigation* to TOR-leaks and helping people bypass Chinese walls or anycast/proximity DNS... outside of Torsocks (i was on that for short time). - It also proved being "practical" on highly-delayed network paths with possibly high packet loss (airplane use squid to cache traffic as much as possible). - since geolocation, anycast and CDNs step into the game, such a tool showed being helpful as valuable workaround in *some* situation (an user reported watchning Netflix via DNSP, not sure if still holds true, is not my scope). Hopefully just less than a month ago I discovered the D-o-H draft version 3 and this working group.... *Such a reliev !! I have been wating on DoH even prior it's "officiial" birth :)* After I got to know about the upcoming London IETF Hackathon, I am implementing DOH-set-of-features including ease of use and ease of deploy (for the moment is more a local DNS than a distributed one, not impossible to scale out, is just threads and send_to). The phase of making it compliant with DOH-proposed-format(s) is almost completed (check README or run the code). In my simplicistic roadmap I am still somehow willing to support Google DNS and keep supporting my ultrabasic standard (the q-type is contained in GET/POST request, simplicistic but my initial purposes was to shorten answers, by tailoring the response packet without ADDITIONAL and AUTHORITY sections) and veichulating such via proxied HTTP (fast responses, TTL valid). Probably there was no buzz about DNS over HTTP because such transport/encapsulation direction was not foreseenable or desired few years ago.... surely there will be objections, in terms of traceability (law enforcement to mention one). The increased demand for "anonimity", for "security", along with the increasing size of DNS messaging and the advent of H2 made it convenient to *try* and serve the DNS by the same mean we serve web-pages, possibly along the same iteration (i.e. browser integration with APIs). I have again some doubts on the logging of such requests, but this is probaly an open point yet. Then just to complete the story, some times in 2016 I have seen Google HTTPS DNS service being published but I was busy so I sincerely do not remember interacting with it alot. [5] Unfortunately, I think it didn't raise alot lot of interest, neither it got fully advertised... Is it true? Am i totally wrong? Happy to address you all, apologise for long thread/simple language. Hope you will appreciate DNSP as wannabe DOH local server. See you 17/18 March at the Hilton Metropole ! Thanks for your time, Massimiliano (Max) Footnotes: [1]: satellite connectivity made me needing short responses and HTTP is more friendly to billing, UDP was getting lost and users unhappy. [2]: made in China out of similar branch of mine ( http://dnspod.github.io/dnspod-int-api-docs/ and https:// github.com/DNSPod/dplus-c/blob/master/src/http.c htt ps://github.com/DNSPod/dplus-c [3]: chinese windows proxy was just inspirational sometimes and made me curious about China internet situation, but this project had no HTTP involved. https://github.com/chengr28/Pcap_DNSProxy/blob/mas ter/Documents/ReadMe.en.txt [4]: https://github.com/shadowsocks/ChinaDNS [5]: Just my 2c: let's compare for a second the SPDY evolution into H2, and look at DOH (or alternatives of it) as the next promising tech. IMHO, this Google DNSHTTPS experimental product came bit lately than "expected". How many millions users are on 8.8.8.8 standard DNS ? Whole enterprises (not nice of them, that's why they *used to* get throttled)... The forwarder view offered by Google has been "accepted" by its users since longer time than any other "free" DNS service, i.e. OpenDNS. We believe that Google did an astounding commercial choice in using all 8s digits. This is why I say that this DNS/HTTPS Google service was launched "late", just because big G earned an enormous share on the free DNS market and oviously is always in the position to help supporting DOH adoption/advertisement with such a easy mnemonic choice !! Free-of-charge google services are attractive. I recall that Google service is not DOH compliant, but i see a common intent. Does anyone have some numbers on dns.google.com HTTPS service, in terms of active users (or system uptime/faults) ? just approximately ? BTW, IBM owns 9.9.9.9 and HP 16.16.16.16.16, mnemonic choices do "avoid re-translating something we already known by heart" (is a bit like "thinking in the same language your conversation happens to be", considered a must in foreign languages interpretation). With kind regards, Massimiliano Fantuzzi -- *Massimiliano Fantuzzi* *IT professional, expert in DB Linux and networks.* *+41 76 754 1037 <%2B41%2076%20754%201037>* --089e08e589a5e67a8a0566d44dc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi to the Doh mailing list and group,
<= br>
Bringing your attention to an interesting project (born around 2009= ).
DNSP is written in C (local client server) and PHP (remote reso= lver):=C2=A0https://github.com/f= antuz/DNSProxy=C2=A0=C2=A0it WAS NOT built on= "H2 compliancy" by the time, quite obviuously.
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal= ;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex= t-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(2= 55,255,255);text-decoration-style:initial;text-decoration-color:initial">No= w thanks to more recent CURL libs, the H2 part has been added and passing t= ests; by this weekend I can commit to have it completely DOH-aware.

Some = functions/plugins for DNSP are being staged and to be released soon. more= =C2=A0features are to be supported with minimum effort.
Redis cache for= example is trivial, adding=C2=A0QUIC might be not. Please let me kno= w your feedback !
The tree of the project might look ugly to you; I am n= ot a software engineer, just a passionate technician (sysadmin/networking/w= ebservers/db) with sufficient debug skills.

The initial credit goes to Andrea Fabrizi who created = alpha DNSP back in 2009.
Since 2010 I have been thinking of how t= o expand further this idea, got lucky enough to test its functionality with= in a small satellite-provider in some time later (2013) [1]
A= ndrea has fully authorized me to take on his project as he would not have i= nterest or time to carry on. Code changed quite a bit, but the core hasn= 9;t (principle was good).
I even created an Arduino version, as P= OC and for fun :)

As I could not find any draft on = a DOH topic back then (DNSSEC was rolling out)=C2=A0I cannot even name that= many experiments on embrionic-Doh ancestors, per my knowledge,
The= only 3 examples deserving a credit for being innovative in vehiculating DN= S over differernt channels are to me "dnspod"[2] and=C2=A0Pcap_DN= SProxy[3] and more recently, ChinaDNS[4]. Might there be other, I let you c= omplete.

Summarising:
=C2=A0- DNSP did its modes= t job, against DNS censorship,=C2=A0blocking/locating/redirecting and = leaks, offering a=C2=A0mitigation=C2=A0to TOR-leaks and helping peop= le bypass Chinese walls or anycast/proximity DNS... outside of Torsocks (i = was on that for short time).
=C2=A0- It also proved being "practica= l" on highly-delayed network paths with possibly high packet loss (air= plane use squid to cache traffic as much as possible).
=C2=A0- sin= ce geolocation, anycast and CDNs step into the game, such a tool showed bei= ng helpful as valuable workaround in *some* situation (an user reported wat= chning Netflix via DNSP, not sure if still holds true, is not my scope).

Hopefully just less than a month ago I discovered the D-o-H= draft version 3 and this working group....
Such a reliev !! I= have been wating on DoH even prior it's "officiial" birth :)=

After I got to know about the upcoming= London IETF Hackathon, I am implementing DOH-set-of-features including eas= e of use and ease of deploy (for the moment is more a local DNS than a dist= ributed one, not impossible=C2=A0to scale out, is just threads and send_to)= .
The phase of=C2=A0making it compliant with DOH-proposed-for= mat(s) is almost completed (check README or run the code).
In my simplic= istic roadmap I am still somehow willing to support Google DNS and keep sup= porting my ultrabasic standard (the q-type is contained in GET/POST request= , simplicistic but my initial purposes was to shorten answers, by tailoring= the response packet without ADDITIONAL and AUTHORITY sections) and veichul= ating such via proxied HTTP (fast responses, TTL valid).

Probably there was no buzz abou= t DNS over HTTP because such transport/encapsulation direction was not fore= seenable or desired few years ago.... surely there will be objections, in t= erms of traceability (law enforcement to mention one).
The in= creased demand for "anonimity", for "security", along w= ith the increasing size of DNS messaging and the advent of H2 made it conve= nient to *try* and serve the DNS by the same mean we serve web-pages, possi= bly along the same iteration (i.e. browser integration with APIs). I have a= gain some doubts on the logging of such requests, but this is probaly an op= en point yet.

Then just to complete the story, som= e times in 2016 I have seen Google HTTPS DNS service being published but I = was busy so I sincerely do not remember interacting with it alot. [5]
Unfortunately, I think it didn't raise alot lot of interest, n= either it got fully advertised... Is it true? Am i totally wrong?


Happy to address you all, apologise for long thread/= simple language. Hope you will appreciate DNSP as wannabe DOH local server.=


See you 17/18 March at the Hilton Metropole !
<= /div>
Thanks for your time,
Massimiliano (Max)

<= div>

Footnotes:

[1]:=C2=A0satellite = connectivity made me needing short responses and HTTP is more friendly to b= illing, UDP was getting lost and users unhappy.
[3]: chinese windows proxy was just inspirational some= times and made me curious about China internet situation, but this project = had no HTTP involved.=C2=A0https://github.com/chengr28/Pcap_DNSProxy/blob/master/Documents/ReadMe.en.txt
[5= ]: Just my 2c: let's compare for a second the SPDY=C2=A0evolution into = H2, and look at DOH (or alternatives of it) as the next promising tech. IMH= O, this Google DNSHTTPS experimental product came bit lately than "exp= ected".
How many millions users=C2=A0are on 8.8.8.8 standard DNS ?= Whole enterprises (not nice of them, that's why they *used to* get thr= ottled)... The forwarder view offered by Google has been "accepted&quo= t; by its users since longer time than any other "free" DNS servi= ce, i.e. OpenDNS. We believe that Google did an astounding commercial choic= e in using all 8s digits.=C2=A0This is why I say that this DNS/HTTPS Google= service was launched "late", just because big G earned an enormo= us=C2=A0share=C2=A0on the free DNS market and oviously is always=C2=A0in th= e position to help supporting DOH adoption/advertisement with such a easy m= nemonic choice=C2=A0!! Free-of-charge google services are attractive. I rec= all that Google service is not=C2=A0DOH compliant, but i see a common inten= t.=C2=A0Does anyone have some numbers on dns.google.com HTTPS service, in terms of active user= s (or system uptime/faults) ? just approximately ? BTW, IBM owns 9.9.9.9 an= d HP 16.16.16.16.16, mnemonic choices do "avoid re-translating somethi= ng we already known by heart" (is a bit like "thinking in the sam= e language your conversation happens to be", considered a must in fore= ign languages interpretation).



= With kind regards,
Massimiliano Fantuzzi

--

Mas= similiano Fantuzzi
IT professional, expert in DB Linux and= networks.


<= /div>
--089e08e589a5e67a8a0566d44dc6-- From nobody Wed Mar 7 13:11:10 2018 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 7732C127863 for ; Wed, 7 Mar 2018 13:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yR_dRXjv-rA0 for ; Wed, 7 Mar 2018 13:11:03 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id F07F41277BB for ; Wed, 7 Mar 2018 13:11:02 -0800 (PST) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5F9343A067 for ; Wed, 7 Mar 2018 16:11:02 -0500 (EST) Received: by mail-oi0-f41.google.com with SMTP id t185so2776985oif.6 for ; Wed, 07 Mar 2018 13:11:02 -0800 (PST) X-Gm-Message-State: APf1xPDMIQBp3Frnlp7wSkRnH4yPa6RLQN6cdGIs6IIj4J6hYHGv1UXv 53jAWNuJyN5br0zIw9iG94R9THFRPozZ32eXQno= X-Google-Smtp-Source: AG47ELvxhDzrzVoJNEtKtRWRXcbK2dWh7fl57SIbznxG8gcughd8VHO+jYdVX3MP1z0vK/BAoM9XquMX/h7/hC63s+o= X-Received: by 10.202.94.132 with SMTP id s126mr14362728oib.155.1520457062049; Wed, 07 Mar 2018 13:11:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Wed, 7 Mar 2018 13:11:01 -0800 (PST) In-Reply-To: <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> From: Patrick McManus Date: Wed, 7 Mar 2018 16:11:01 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Adam Roach , "doh@ietf.org" Content-Type: multipart/alternative; boundary="001a113d5160146f7d0566d8ff42" Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 21:11:09 -0000 --001a113d5160146f7d0566d8ff42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 7, 2018 at 12:28 AM, Paul Hoffman wrote: > On Mar 6, 2018, at 20:04, Adam Roach wrote: > > > > > > > > Can you elaborate on this a bit? I fully expect that the typical > user-self-provisioning case will involve copy/pasting server information, > in which case the difference between a server and a URL is pretty minimal= . > Do you expect users to type server names in rather than copying them? > > Yes, exactly. If someone tells you that your bank runs this secure DNS > server, that=E2=80=99s verbal, not copy and paste. > > I don't agree with this. Its logically an argument for not even using hostnames. The minimal information in your example is your bank - so just assume www.BANK.com. That's certainly easier to convey though it has some obvious shortcomings. But even if you argue hostname is the goldilocks of granularity, the DNS resolver market has already shown that its not rich enough. note that quad-9 offers both 9.9.9.9 and 9.9.9.10 and that 10 is not simply a secondary for .9 but its a different service with different policies and different results.. but because the configuration scheme of traditional DNS is so coarse they needed to burn IPv4 addresses just to convey configuration information. Your suggestion uplevels that from 1 address to 1 hostname but the fundamental problem remains. Lastly, we want this work to be consistent with the BCP56bis work which explicitly talks about Initial URLs in 4.4.1. It says arbitrary URLs should be used unless they are not practical. I would say if there were no configuration at all we could talk about whether or not they were impractical, but in the cases that are in scope we're definitely talking about configuration. -P --001a113d5160146f7d0566d8ff42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 7, 2018 at 12:28 AM, Paul Hoffman <paul.hoffman@icann= .org> wrote:
On Mar 6, 2018, at 20:04, Adam Roach <adam@nostrum.com> wrote:
>
>
>
> Can you elaborate on this a bit? I fully expect that the typical user-= self-provisioning case will involve copy/pasting server information, in whi= ch case the difference between a server and a URL is pretty minimal. Do you= expect users to type server names in rather than copying them?

Yes, exactly. If someone tells you that your bank runs this secure D= NS server, that=E2=80=99s verbal, not copy and paste.

<= div>
I don't agree with this.

Its logically an argument for not even using hostnames. The minimal infor= mation in your example is your bank - so just assume www.BANK.com. That's certainly easier to convey though it= has some obvious shortcomings.

But even if yo= u argue hostname is the goldilocks of granularity, the DNS resolver market = has already shown that its not rich enough. note that quad-9 offers both 9.= 9.9.9 and 9.9.9.10 and that 10 is not simply a secondary for .9 but its a d= ifferent service with different policies and different results.. but becaus= e the configuration scheme of traditional DNS is so coarse they needed to b= urn IPv4 addresses just to convey configuration information. Your suggestio= n uplevels that from 1 address to 1 hostname but the fundamental problem re= mains.

Lastly, we want this work to be consist= ent with the BCP56bis work which explicitly talks about Initial URLs in 4.4= .1. It says arbitrary URLs should be used unless they are not practical. I = would say if there were no configuration at all we could talk about whether= or not they were impractical, but in the cases that are in scope we're= definitely talking about configuration.

-P
<= div>
--001a113d5160146f7d0566d8ff42-- From nobody Wed Mar 7 13:30:12 2018 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 D3D7912422F for ; Wed, 7 Mar 2018 13:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 cjdTMcIrkDfL for ; Wed, 7 Mar 2018 13:30:09 -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 C5E2D1270B4 for ; Wed, 7 Mar 2018 13:30:09 -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; Wed, 7 Mar 2018 13:30:08 -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; Wed, 7 Mar 2018 13:30:07 -0800 From: Paul Hoffman To: Mark Nottingham CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] Re: Use cases and URLs Thread-Index: AQHTtdbvkCdEpx1fQUqdrwh6wglRc6PF0ViA Date: Wed, 7 Mar 2018 21:30:06 +0000 Message-ID: <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> In-Reply-To: <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> 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.47.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] Re: Use cases and URLs 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, 07 Mar 2018 21:30:11 -0000 On Mar 7, 2018, at 1:41 AM, Mark Nottingham wrote: >=20 > Is making it super-easy for non-technical end users to configure a new DN= S server a feature or a bug? It has been considered a feature for as long as there has been an Internet.= That is, every operating system allows users to do this in the operating s= ystem. Why should browsers be different? The question is parallel to "Is making it super-easy for non-technical end = users to configure a new search engine a feature or a bug?". Some parties f= eel that it is a bug because users will pick a new, crappy search engine ba= sed on bad advice. Some parties feel that it is a feature because some sear= ch engines have better privacy policies than others, or have better ways of= providing results, and so on. --Paul Hoffman= From nobody Wed Mar 7 13:49:39 2018 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 177C412D952 for ; Wed, 7 Mar 2018 13:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7RNVN1OT4Rn0 for ; Wed, 7 Mar 2018 13:49:35 -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 C14721205D3 for ; Wed, 7 Mar 2018 13:49:35 -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; Wed, 7 Mar 2018 13:49:33 -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; Wed, 7 Mar 2018 13:49:33 -0800 From: Paul Hoffman To: Patrick McManus CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] Re: Use cases and URLs Thread-Index: AQHTtljUtP64RWPRoUee2jEgNitI3KPF1cQA Date: Wed, 7 Mar 2018 21:49:33 +0000 Message-ID: <53FF5085-D22D-4EEB-83DA-F5DB2CB2347C@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.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.47.234] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 21:49:37 -0000 T24gTWFyIDcsIDIwMTgsIGF0IDU6MTEgUE0sIFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96 aWxsYS5jb20+IHdyb3RlOg0KPj4gWWVzLCBleGFjdGx5LiBJZiBzb21lb25lIHRlbGxzIHlvdSB0 aGF0IHlvdXIgYmFuayBydW5zIHRoaXMgc2VjdXJlIEROUyBzZXJ2ZXIsIHRoYXTigJlzIHZlcmJh bCwgbm90IGNvcHkgYW5kIHBhc3RlLg0KPiANCj4gSSBkb24ndCBhZ3JlZSB3aXRoIHRoaXMuDQo+ IA0KPiBJdHMgbG9naWNhbGx5IGFuIGFyZ3VtZW50IGZvciBub3QgZXZlbiB1c2luZyBob3N0bmFt ZXMuDQoNClRoYXQgaXMgYW4gYWJzdXJkIHJlYWNoLiBJZiBJIGFscmVhZHkgaW50ZXJhY3Qgd2l0 aCBteSBiYW5rIHRocm91Z2ggbXkgYnJvd3NlciwgSSBrbm93IGl0cyBob3N0bmFtZS4gSSBjYWxs IG15IGJhbmsgIkJhbmsgb2YgQW1lcmljYSIsIG5vdCAiYm9mYS5jb20iLCBidXQgSSBrbm93IHRo ZSBsYXR0ZXIgaXMgaXRzIGhvc3RuYW1lLg0KDQo+IFRoZSBtaW5pbWFsIGluZm9ybWF0aW9uIGlu IHlvdXIgZXhhbXBsZSBpcyB5b3VyIGJhbmsgLSBzbyBqdXN0IGFzc3VtZSB3d3cuQkFOSy5jb20u DQoNClNlZSBhYm92ZS4gSW4gdGhlIGVkZ2UgY2FzZSB0aGF0IEkgaGVhciB0aGF0IG15IGJhbmsg cnVucyB0aGlzIHNlY3VyZSBETlMgc2VydmVyIGJ1dCBJIGRvbid0IGtub3cgbXkgYmFuaydzIGhv c3RuYW1lLCBJIGFtIG91dCBvZiBsdWNrIHdpdGggRE9ILiBUaGF0J3MgZmluZS4NCg0KPiBCdXQg ZXZlbiBpZiB5b3UgYXJndWUgaG9zdG5hbWUgaXMgdGhlIGdvbGRpbG9ja3Mgb2YgZ3JhbnVsYXJp dHksIHRoZSBETlMgcmVzb2x2ZXIgbWFya2V0IGhhcyBhbHJlYWR5IHNob3duIHRoYXQgaXRzIG5v dCByaWNoIGVub3VnaC4gbm90ZSB0aGF0IHF1YWQtOSBvZmZlcnMgYm90aCA5LjkuOS45IGFuZCA5 LjkuOS4xMCBhbmQgdGhhdCAxMCBpcyBub3Qgc2ltcGx5IGEgc2Vjb25kYXJ5IGZvciAuOSBidXQg aXRzIGEgZGlmZmVyZW50IHNlcnZpY2Ugd2l0aCBkaWZmZXJlbnQgcG9saWNpZXMgYW5kIGRpZmZl cmVudCByZXN1bHRzLi4gYnV0IGJlY2F1c2UgdGhlIGNvbmZpZ3VyYXRpb24gc2NoZW1lIG9mIHRy YWRpdGlvbmFsIEROUyBpcyBzbyBjb2Fyc2UgdGhleSBuZWVkZWQgdG8gYnVybiBJUHY0IGFkZHJl c3NlcyBqdXN0IHRvIGNvbnZleSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLg0KDQpPUyBjb25m aWd1cmF0aW9uIGZvciBETlMgc2VydmljZSBoYXMgYWx3YXlzIGJlZW4gYmFzZWQgb24gSVAgYWRk cmVzc2VzIGJlY2F1c2UgdXNpbmcgYSBkb21haW4gbmFtZSB0byBpZGVudGlmeSBhIHNlcnZlciBj YXVzZXMgYSBwcmV0dHkgb2J2aW91cyBjaGlja2VuLWFuZC1lZ2cgcHJvYmxlbS4gSG93IGlzIHRo YXQgcmVsZXZhbnQgZm9yIERPSCwgd2hpY2ggaXMgYmFzZWQgb24gVVJMcyB0aGF0IGFscmVhZHkg aGF2ZSBhIGhvc3RuYW1lIGluIHRoZW0/DQoNCj4gWW91ciBzdWdnZXN0aW9uIHVwbGV2ZWxzIHRo YXQgZnJvbSAxIGFkZHJlc3MgdG8gMSBob3N0bmFtZSBidXQgdGhlIGZ1bmRhbWVudGFsIHByb2Js ZW0gcmVtYWlucy4NCg0KV2hpY2ggZnVuZGFtZW50YWwgcHJvYmxlbT8gTXkgcHJvcG9zYWwgYWxs b3dzIGZvciBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlIGluIHRoZSBKU09OIHJlc3BvbnNlLg0KDQo+ IExhc3RseSwgd2Ugd2FudCB0aGlzIHdvcmsgdG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSBCQ1A1 NmJpcyB3b3JrIHdoaWNoIGV4cGxpY2l0bHkgdGFsa3MgYWJvdXQgSW5pdGlhbCBVUkxzIGluIDQu NC4xLiBJdCBzYXlzIGFyYml0cmFyeSBVUkxzIHNob3VsZCBiZSB1c2VkIHVubGVzcyB0aGV5IGFy ZSBub3QgcHJhY3RpY2FsLg0KDQpBbmQgdGhpcyBwcm9wb3NhbCBmdWxseSBzdXBwb3J0cyB0aGF0 IG5vdGlvbi4gTm8gb25lIGhhcyB0byBnbyB0aHJvdWdoIGRpc2NvdmVyeSB0byB1c2UgdGhlIERO UyBBUEkgc2VydmVyLg0KDQo+IEkgd291bGQgc2F5IGlmIHRoZXJlIHdlcmUgbm8gY29uZmlndXJh dGlvbiBhdCBhbGwgd2UgY291bGQgdGFsayBhYm91dCB3aGV0aGVyIG9yIG5vdCB0aGV5IHdlcmUg aW1wcmFjdGljYWwsIGJ1dCBpbiB0aGUgY2FzZXMgdGhhdCBhcmUgaW4gc2NvcGUgd2UncmUgZGVm aW5pdGVseSB0YWxraW5nIGFib3V0IGNvbmZpZ3VyYXRpb24uDQoNCkNvcnJlY3QuIFRoaXMgcHJv cG9zYWwgaXMgdG8gbWFrZSBjb25maWd1cmF0aW9uIGVhc2llci4gQXJlIHlvdSBvYmplY3Rpbmcg dG8gbWFraW5nIGNvbmZpZ3VyYXRpb24gZWFzaWVyLCBvciB0byB0aGUgbm90aW9uIHRoYXQgdGhl IEROUyBBUEkgc2VydmVyIFVSTCBzaG91bGQgYmUgZGlzY292ZXJhYmxlLCBvciAuLi4/DQoNCi0t UGF1bCBIb2ZmbWFu From nobody Wed Mar 7 14:03:35 2018 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 70E2912D95A for ; Wed, 7 Mar 2018 14:03:29 -0800 (PST) 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, FREEMAIL_FROM=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 W1VlhqYaGnho for ; Wed, 7 Mar 2018 14:03:25 -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 2C47212E036 for ; Wed, 7 Mar 2018 14:03:25 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id c83so2902152oib.1 for ; Wed, 07 Mar 2018 14:03:25 -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:content-transfer-encoding; bh=VOrhiKW++3YGIe5Bb8WA3N0B7lLkNIUIu2zYrVpR3g0=; b=XIQQ1qS4aw7cI4j0X3il+jkuflX3s+uJHL0vA+V6JmKjEiQSaQKtP1Lw654BYwQEZz UV4q0yPLufcpiYXdU06QVSYQ4QdxSxsfBZKrTmdExI538BzFpXCe9uDrIFrh9HAiQXTR XDf6wGrUcW1LV05A3AZHCVkRTimDc1qOHRNUM2svMQhaeWwln288XvgwjzsRUx7W8rKY tdo3GEVDarq4eXlyjFZQ/KJUkoXjRfreJKsLfB2RYIQIAaqD81RB0GDorDAKnTWMtI7J MYiQ5GpnYLj4eWuksTR9fr1f3ANR3lZYhSuuCKdMsIbQXtOua1Ej5XZfdLEQgH+bfQ2Z Pimw== 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:content-transfer-encoding; bh=VOrhiKW++3YGIe5Bb8WA3N0B7lLkNIUIu2zYrVpR3g0=; b=DjtPAXBohgwY9CBvOcHPqz3xF6FoanqQYa+C4aabAjyWOcTBSNTd0WnOeh5S3hwJgl ksYYJErfGqIa8sqQlzoNosIYZ47YUfkd2aMeFlkEo2ftecjApf/QnCWOFxMGZEK9J+k2 Ux+NL94uOOsmy8l+MxAwyqvR7itYvJb6gllNw8luBbRlg84VCMk4i5OxHaTeqU8fY2TJ lwpFL0RR9haI2OcBbdSP1DiYC1zBOKweUbWVIOnSlOeCOa1uhvfXGzC/H4OP+XGsJizi Jl0hVN6izWEEYGESVHliJABTN8nlQq7/3fHnClwyf6hcnh8jKMVrz1yf5vGH+YuzindH P4rg== X-Gm-Message-State: AElRT7F1xm2UnVRxfQr3iEQ7JxvkQek6E6lTYO0KcYYYbD75SCG3O/cV PEj4m6xtYaI9rNEiqHtc7WsHAlOLv6mt0bjeH+huNg== X-Google-Smtp-Source: AG47ELuxQojZvf1K7AS5y8axxawbiuYfJ8cRnuLNYW8fo3a+gEPoe2yLGOrzqKDkTe2CqNG/co+z0Qi4KFVDsnjO7JM= X-Received: by 10.202.13.8 with SMTP id 8mr15581454oin.272.1520460204437; Wed, 07 Mar 2018 14:03:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Wed, 7 Mar 2018 14:03:24 -0800 (PST) In-Reply-To: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> From: Martin Thomson Date: Thu, 8 Mar 2018 09:03:24 +1100 Message-ID: To: Paul Hoffman Cc: "doh@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] Use cases and URLs 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, 07 Mar 2018 22:03:29 -0000 Still having trouble with this. Think about how you interact with a browser. You might type "icann.org" knowing that this gets you ICANN, and that is magically turned into "http://icann.org/" (yeah, the missing 's' remains an embarrassing omission, but that's harder to fix than it seems). Fewer people do that than you think, because that's the role that search engines fill now. You might also type "icann.org/dns", but even fewer do that. Why do you believe that servicing this market in this way is such an imperative? Search the web, find the string you want, copy and paste. In fact, it serves the point of separation very effectively. If your configuration lists "9.9.9.9" or "dns.provider.example", then the string "https://dns.provider.example/" might signify an important difference in how the software uses that string. Note the huge difference in those last two examples does not - in my opinion - motivate the architectural violence you advocate for. On Wed, Mar 7, 2018 at 2:49 PM, Paul Hoffman wrote= : > Greetings again. In the discussions in the last month since draft-ietf-do= h-dns-over-https-03 came out, particularly at the DNS Privacy Workshop at N= DSS, it has become clear that there are a lot of use cases that are related= to the two given in Section 3 of the draft, but are not called out explici= tly. They fall under the sentence "They might use the DOH server for all qu= eries, or only for a subset of them." > > Some that I have heard are (approximately): > > - Use the preferred DNS API server for all DNS lookups in the browser whe= never the browser is running (start the TLS session with the DNS API when t= he browser starts). > > - If a tab/window for the origin of a configured DNS API server is open, = use the configured API server for all DNS lookups. > > - If a tab/window for the origin of a configured DNS API server is open, = use the configured API server for DNS lookups that are in that origin only. > > - If a tab/window for the origin of a configured DNS API server is open, = and the configured API server pushes DNS information, accept it. > > (Note that you might like or dislike some of these; that's fine.) > > In addition, there has been the assumption by many people that they could= add new DNS API servers to the list of configured servers in the browser b= ased on various out-of-band information (articles, word-of-mouth, ...). Tha= t is, people want the additional DNS privacy through a somewhat-trusted web= site rather than no privacy from the who-knows-where they are getting now.= (Don't forget that the vast, vast majority of users are doing DNS lookups = using resolvers they have no idea about.) > > The ability to add new DNS APIs servers leads to the question of the URL = being used for a particular DNS API server. In early drafts, we used "https= :///.well-known/dns-query?..." as the standard URL, but it was poin= ted out that such a standard is prohibited by RFC 5785. The current draft s= ays that there is no standard, and every origin will have its own URL for t= he API. This makes it much harder for a user to add new configured DNS API = servers and thus reduces the chance that some of their DNS queries will be = private, based on which of the use cases get implemented. > > A protocol point between "here is the fixed URL" and "every origin has it= s own URL" is "discover the policy for an origin to serve as a DNS API serv= er". That is, use the RFC 5785 ".well-known" scheme as a way to find out wh= at the origin's policy is. That way, a user can configure new servers in th= eir browser only knowing the origin name (which is all they really understa= nd anyway...). > > A first guess of a proposal would be that "https:///.well-known/d= ns-query/" returns a JSON object that looks like: > { "has-DNS-API": true, "DNS-API-URLs": > [ "https:///admin-dns/?", "https:///backup-dns/?" ]= } > > This uses the .well-known for what it is supposed to be used for, and giv= es each origin a chance to pick their own URL scheme. Getting no response o= r "{ "has-DNS-API": false }" both tell the user that origin's policy as wel= l, of course. > > Thoughts? > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Wed Mar 7 14:20:43 2018 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 AE39612D95A for ; Wed, 7 Mar 2018 14:20: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=KnKdixtQ; dkim=pass (1024-bit key) header.d=yitter.info header.b=fqoEmVeh 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 ku8iWJV1CWML for ; Wed, 7 Mar 2018 14:20:41 -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 375E412D959 for ; Wed, 7 Mar 2018 14:20:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9A2F0BE780 for ; Wed, 7 Mar 2018 22:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520461239; bh=/pzd0u6EmxPiC2I+x4cBoY7FQgCuXDtsPektHyV80KA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KnKdixtQre5EMe7EOQaEtqM0PqIFSrcOgS9uxaeNvgRYlIk4QdeyxopMEwxRAmgiG qZiiMgGCkyUkWiXbVsafO9wcxhv/kwr3Ks7XqhB2YEsyAN6FLu/MvBAEmOniMto/v9 TaAbrWhIY0v8dWc0T1i49IH7aWu+UA/WybKwPots= 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 XlgOhTuBR-iC for ; Wed, 7 Mar 2018 22:20:38 +0000 (UTC) Date: Wed, 7 Mar 2018 17:20:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520461238; bh=/pzd0u6EmxPiC2I+x4cBoY7FQgCuXDtsPektHyV80KA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fqoEmVehSm9+xLr8YRAKM0gy8xbk9PHma7dnmsKu93zCHxgJjg/qNMjRE9H0vgAeU pkMsGPu6xPH0LfxKnmVgFzaOkoVbE5qGYGBDD/8FNeqkJ0/TBzXpRvnU1uJ7h1PSdy 4opjotP7x4liMb0G5STNdw/klwSnnfYrCsELMwwM= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180307222035.tztpmcyoiraiwnrt@mx4.yitter.info> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 22:20:43 -0000 Hi, On Wed, Mar 07, 2018 at 09:30:06PM +0000, Paul Hoffman wrote: > On Mar 7, 2018, at 1:41 AM, Mark Nottingham wrote: > > > > Is making it super-easy for non-technical end users to configure a new DNS server a feature or a bug? > > It has been considered a feature for as long as there has been an Internet. That is, every operating system allows users to do this in the operating system. Why should browsers be different? > I think I agree with Paul's sentiment there, but I am pretty sure I disagree with his glib description of the history. As a percentage of Internet users, the group of people who understood what it meant to reconfigure one's DNS resolution path has been in decline for rather a long time, and it is often quite clear to me that even developers working on things that might touch on the DNS have only the dimmest grasp of how it works or what the consequences will be in fooling with it. Nobody has any reason to imagine that changes to their search engine will have wide effects throughout the automatic portions of their Internet experience, but changing your resolver certainly will have that sort of effect in at least some cases. I think this is an area that needs some care, even if I agree that users need to be able to do it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Mar 7 14:46:29 2018 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 7772B12D886 for ; Wed, 7 Mar 2018 14:46: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=eHmZtov/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N3DGCQyW 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 wKhOJh9OkFvs for ; Wed, 7 Mar 2018 14:46:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF1A127419 for ; Wed, 7 Mar 2018 14:46:25 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C9A0521023; Wed, 7 Mar 2018 17:46:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 07 Mar 2018 17:46:24 -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=fm2; bh=ZVoHQ6QCqOsT9AwwX+i+IguDcVu/L YwOViMuV9YfDF0=; b=eHmZtov/lO9nAm+3rrDUer3AHpqTAmSGSFj6LjfujPshE 3+b5Ci4bf298dFj32pdpUBADQETBPXU+BQfOf+9l5yLOvCzMkIOya4LawY5TL15k Pm7ntSn6crXFh2oymHyo3x4hzH4jv6Xnw68qPbanFjUSlng7ukGMf87Z6Kh0pQ4Z WaAHxIgvxsU5lKVJPiGwkdPBYySJBrv4oYvXnf9Z5gMKnysxxnrPGL+sOEOJSS9o Fkd2A7YT8QARQ+tjjz/XveYgdtBZEEttttCCHmWxqDc0f4ve+3NdoBPB93JquoZF 6YWgZV7T+TuaHTDCMMeA5z+20bbONza1rSRLiKetw== 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=fm2; bh=ZVoHQ6 QCqOsT9AwwX+i+IguDcVu/LYwOViMuV9YfDF0=; b=N3DGCQyWdu5SuCj+IEp6mK JfzKUO6kHMntTGJVJylUBqMr7vTYefAulMYlT1bUnFOfZMxHlj4zH4F7ickky3Ih mg7dnXmu7Ha7XiJSrCHNUFBpF77UrMSy+CSY0EMYTzkApNumi/cUZ/i8VEArzywU UkqqBY0V0KHPYQx9pJZ++ZjaNysxq5x/THU6PoD8o5hNqagI31TM4ITkkq/8rYhh uAQjrch1tRkvbeJXP2xtQTUGAqEvfG6YjZYcIbjAlL8qgzNiPJvloL+nrbD+w8D1 dHr/N/Zg2/AHUyCCAze1jdsw7jl49W9LHn3EIWpYYr8Gdc8miIcE5l5G4wb2cx8w == X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id C5BCF7E3C6; Wed, 7 Mar 2018 17:46:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> Date: Thu, 8 Mar 2018 09:46:19 +1100 Cc: "doh@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 22:46:27 -0000 > On 8 Mar 2018, at 8:30 am, Paul Hoffman = wrote: >=20 > On Mar 7, 2018, at 1:41 AM, Mark Nottingham wrote: >>=20 >> Is making it super-easy for non-technical end users to configure a = new DNS server a feature or a bug? >=20 > It has been considered a feature for as long as there has been an = Internet. That is, every operating system allows users to do this in the = operating system. Why should browsers be different? >=20 > The question is parallel to "Is making it super-easy for non-technical = end users to configure a new search engine a feature or a bug?". Some = parties feel that it is a bug because users will pick a new, crappy = search engine based on bad advice. Some parties feel that it is a = feature because some search engines have better privacy policies than = others, or have better ways of providing results, and so on. Sure, they're both attack vectors. I note that to configure a new search = engine in most browsers, you need to type in what is effectively a URL = template. Also, we don't make decisions based upon what people feel in the IETF -- = we decide based upon rough consensus and running code. Is there *any* = implementer interest in what you're describing? -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 7 14:49:13 2018 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 84B4712D886 for ; Wed, 7 Mar 2018 14:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, 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 yrVfoMh8zsXV for ; Wed, 7 Mar 2018 14:49:09 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 4EC81127419 for ; Wed, 7 Mar 2018 14:49:09 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id u5so5519323itc.1 for ; Wed, 07 Mar 2018 14:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ELDZcutipQtmhS06cEdVtOixasKqzB260cQHtJ7MdcI=; b=cNGBMRhd6T1uqOsOMra2ZAVzpPi23Wqp6rwhH3jbEZOJz01ca4HFd/7RRbOvVfTFfh v9mPRORjqQOEve3vuFS0wwJOfRaA1d1HqR4O7cSPfMe5r9CENvkongcU7BnaME8wP/Uv VRc31pWRAZR37xAO2HoIUzutPFXhcGRALRBL7+GkIDVC7Py5AcVfyUNlFAFx+Uwkczh5 YdzI2ySw3fMC2oE/DQxyktapD/VdkO6vWQ2uEYZD/IbaLV0RpU5E8TGxWj40Ub0LElaS oZ4LDj0XWPPXheJYSTXq6w8EXIkiTcgESskvUDZbKPMSi/uhAZcolMqq0kqxlrwUiodi JsKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ELDZcutipQtmhS06cEdVtOixasKqzB260cQHtJ7MdcI=; b=baUD1QeZ/FyYSf/evnFcZnn3yzdAtjLnbSkj3kJ9lipAh3EOU1HdW9KjKTt8peyVBk ryPRxytvwJM5NsscCDqTbRFchIGkLlYYiDwnckLPZEwQ8YXbWHbfLlKXqGs/sYtKcPy1 zEO493N7xAhJsQCzT83aBbb9N+HrGQ3v6BopmUPSdd5l4t+vxTc8IKeweMw5T0qUJcdC WsQzj5XyoVxltD+V6Ujgq5plJ189ceZzvh8EJo1GlqOfYDxYooBiEVvj2toAA+gmRAmE b7BGoDW3rq9UQ5DK7iSmgzgnWiz3rcNwA3YTH1JBPHAipUodtgoD/YZVxq4zPwVpALJW rEvA== X-Gm-Message-State: AElRT7FBhF4STQ29fDXeGwOlQjCD96DbfK2oAE6zynApd2l/6Dfjo39E h+G91UW3vOu9DT6EajFWmdPye+BbOM6Ml+VDBuIueott+GI= X-Google-Smtp-Source: AG47ELt6fpwfniFd5JfNDfnMjVLsESX4tNLOedTiZJ0A9lfcMmujVQaT7IB1cv6yHJF3GAKXrXqbx94oCznXdQbKP10= X-Received: by 10.36.113.67 with SMTP id n64mr24829478itc.4.1520462948206; Wed, 07 Mar 2018 14:49:08 -0800 (PST) MIME-Version: 1.0 References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> In-Reply-To: From: Justin Henck Date: Wed, 07 Mar 2018 22:48:57 +0000 Message-ID: To: mnot@mnot.net Cc: paul.hoffman@icann.org, doh@ietf.org Content-Type: multipart/alternative; boundary="001a114061d8ecb5380566da5db2" Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 22:49:11 -0000 --001a114061d8ecb5380566da5db2 Content-Type: text/plain; charset="UTF-8" > > Your suggestion uplevels that from 1 address to 1 hostname but the > fundamental problem remains. As I understand the proposal, the metadata in .well-known would be optional? If that's the case, is this any more objectionable than www.BANK.com being interpreted as http://www.BANK.com/ , which is in turn redirected to https://www.BANK.com/index.html ? It seems to me we only gain potential use cases by having an optional discovery endpoint, and lose nothing. An additional use case might be DNS-over-TLS auto-upgrade if a potentially hostile network blocks port 853. Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B On Wed, Mar 7, 2018 at 5:46 PM Mark Nottingham wrote: > > > > On 8 Mar 2018, at 8:30 am, Paul Hoffman wrote: > > > > On Mar 7, 2018, at 1:41 AM, Mark Nottingham wrote: > >> > >> Is making it super-easy for non-technical end users to configure a new > DNS server a feature or a bug? > > > > It has been considered a feature for as long as there has been an > Internet. That is, every operating system allows users to do this in the > operating system. Why should browsers be different? > > > > The question is parallel to "Is making it super-easy for non-technical > end users to configure a new search engine a feature or a bug?". Some > parties feel that it is a bug because users will pick a new, crappy search > engine based on bad advice. Some parties feel that it is a feature because > some search engines have better privacy policies than others, or have > better ways of providing results, and so on. > > Sure, they're both attack vectors. I note that to configure a new search > engine in most browsers, you need to type in what is effectively a URL > template. > > Also, we don't make decisions based upon what people feel in the IETF -- > we decide based upon rough consensus and running code. Is there *any* > implementer interest in what you're describing? > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a114061d8ecb5380566da5db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your suggestion uplevels that f= rom 1 address to 1 hostname but the fundamental problem remains.

As I understand the proposal, the metadata in .well= -known would be optional?=C2=A0 If that's the case, is this any more ob= jectionable than=C2=A0www.BANK.com=C2=A0being interpreted as=C2=A0http://www.BANK.com/, = which is in turn redirected to=C2=A0https://= www.BANK.com/index.html?=C2=A0 It seems to me we only gain potential us= e cases by having an optional discovery endpoint, and lose nothing.=C2=A0= =C2=A0

An additional use case might be DNS-over-TLS aut= o-upgrade if a potentially hostile network blocks port 853.

=

Justin Henck=C2=A0
Product Manager=C2= =A0
212-565-9811=C2=A0
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1039= 9F2D 869A 117B
<= /div>


On Wed, Mar 7, 2018 at 5:46 PM Mark Nottingham <mnot@mnot.net> wrote:


> On 8 Mar 2018, at 8:30 am, Paul Hoffman <paul.hoffman@icann.org> wrote:
>
> On Mar 7, 2018, at 1:41 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> Is making it super-easy for non-technical end users to configure a= new DNS server a feature or a bug?
>
> It has been considered a feature for as long as there has been an Inte= rnet. That is, every operating system allows users to do this in the operat= ing system. Why should browsers be different?
>
> The question is parallel to "Is making it super-easy for non-tech= nical end users to configure a new search engine a feature or a bug?".= Some parties feel that it is a bug because users will pick a new, crappy s= earch engine based on bad advice. Some parties feel that it is a feature be= cause some search engines have better privacy policies than others, or have= better ways of providing results, and so on.

Sure, they're both attack vectors. I note that to configure a new searc= h engine in most browsers, you need to type in what is effectively a URL te= mplate.

Also, we don't make decisions based upon what people feel in the IETF -= - we decide based upon rough consensus and running code. Is there *any* imp= lementer interest in what you're describing?


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--001a114061d8ecb5380566da5db2-- From nobody Wed Mar 7 14:59:54 2018 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 3C50112D88C for ; Wed, 7 Mar 2018 14:59: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=TNfOPu8S; dkim=pass (1024-bit key) header.d=yitter.info header.b=fyRWLTTd 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 xriMXjMJVANB for ; Wed, 7 Mar 2018 14:59:52 -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 1891612D86B for ; Wed, 7 Mar 2018 14:59:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 38EEBBE780 for ; Wed, 7 Mar 2018 22:59:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520463561; bh=AXYYeCSS3zByUPRZYtA7013Smqzrd4ISGTRKfo2AtZQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TNfOPu8SXVtaimO4O2raiGf6dRqODaZQWVaDSNoxyVXLIAapg+QBczdNQFI8y1k8n 05PUxu+qrsuaO/1PQguJoFc9nqyg+dcUurlSgqem1ffj0ZuvitbVaIIWh/r1Fjyuuo FTUWMSDFnSsHPbZsMlktcG23uwEbFyN1WwoKLYoY= 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 UhLNOX40F1UC for ; Wed, 7 Mar 2018 22:59:19 +0000 (UTC) Date: Wed, 7 Mar 2018 17:59:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520463559; bh=AXYYeCSS3zByUPRZYtA7013Smqzrd4ISGTRKfo2AtZQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fyRWLTTdNh7Hz8X7iLegclNgYjJoyg7z/QxqkmkoEN5X/lphOaVvUdJk4an8QzYym igOzbtATbEPWt0fAnxF80uPYfSwMIQPgBUl7GGSrKEPgfHq6mI9aHaUSF9NOfAs1I8 1en9yOebGxkZSlefFYFqumatTaL9K4nlIlSMfZN0= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180307225916.mtedvpezetnctco2@mx4.yitter.info> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 22:59:53 -0000 On Thu, Mar 08, 2018 at 09:46:19AM +1100, Mark Nottingham wrote: > > Sure, they're both attack vectors. I note that to configure a new search engine in most browsers, you need to type in what is effectively a URL template. > Well, maybe that's part of the care would be that I suggested in another message. > Also, we don't make decisions based upon what people feel in the IETF -- we decide based upon rough consensus and running code. Is there *any* implementer interest in what you're describing? > If the IETF is standardising a feature that users can't get out of or use in ways that suit them, then I would have to ask why we are willing to touch it with a 93 1/2' pole. That really would make us the IVTF, and I'm not interested in such efforts. I agree that there is a serious attack vector in allowing users to configure doh, but it's also an attack vector if only your vendor can control how it can be used. If _that's_ what we think we're building, then I at least was fooled by the charter. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Mar 7 15:03:21 2018 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 7F5291242F5 for ; Wed, 7 Mar 2018 15:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 19bN4gWhE7Qh for ; Wed, 7 Mar 2018 15:03: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 AFCF5120727 for ; Wed, 7 Mar 2018 15:03:18 -0800 (PST) Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 07B643A067 for ; Wed, 7 Mar 2018 18:03:18 -0500 (EST) Received: by mail-ot0-f182.google.com with SMTP id f11so3688314otj.12 for ; Wed, 07 Mar 2018 15:03:18 -0800 (PST) X-Gm-Message-State: APf1xPDPqz318xVPHEgJlcKYPj+9STiPPuTOpQluaFXqE1b/HAUSyLCE UHrAQ7X5k0oHFipezi0UeXoR2UikhG2sV3gGEGc= X-Google-Smtp-Source: AG47ELutmAgmrib8dO/4qCuZp2KwoGO8acbFBi4joQsSlb2ZHWTiLi2PrYq3WJ57aMcy731ObHfq+ekHUYnv7oHIv/Y= X-Received: by 10.157.18.228 with SMTP id g91mr17613108otg.2.1520463797714; Wed, 07 Mar 2018 15:03:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Wed, 7 Mar 2018 15:03:17 -0800 (PST) In-Reply-To: <53FF5085-D22D-4EEB-83DA-F5DB2CB2347C@icann.org> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <53FF5085-D22D-4EEB-83DA-F5DB2CB2347C@icann.org> From: Patrick McManus Date: Wed, 7 Mar 2018 18:03:17 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Patrick McManus , "doh@ietf.org" Content-Type: multipart/alternative; boundary="001a114c59d68e84bb0566da905f" Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 23:03:20 -0000 --001a114c59d68e84bb0566da905f Content-Type: text/plain; charset="UTF-8" I believe that the level of discovery (i.e. you need to configure it) is fine for the work the WG has adopted and the recursive resolver scope we're working on. It is the normal approach for a web service. While I don't see a lot of value in starting a separate new work item on discovery I don't have a strong opinion on whether the wg should do that beyond my suspicion that it wouldn't be widely used. On Wed, Mar 7, 2018 at 4:49 PM, Paul Hoffman wrote: > > See above. In the edge case that I hear that my bank runs this secure DNS > server but I don't know my bank's hostname, I am out of luck with DOH. > That's fine. > > I don't understand why we are talking about your bank's DNS server. I presume you mean that in context only with your interactions with the bank? I know you mentioned some use cases around the browser using it to resolve http urls instead of its global recursive resolver, but that's not something that is in scope for the DoH WG (that would imo best be a HTTPbis item - as it is how to route HTTP requests.. for which one possibility among many is to define a discovery algorithm for a DoH endpoint based on first party and define the scope of the result from that endpoint.. but that's speculative and nobody is chartered to do that work.) > > OS configuration for DNS service has always been based on IP addresses > because using a domain name to identify a server causes a pretty obvious > chicken-and-egg problem. How is that relevant for DOH, which is based on > URLs that already have a hostname in them? > it is relevant here because your proposal effectively maps a hostname to a URL. It kinda looks like it maps it to N URLs but because there is no useful way to discriminate between them other than configuration (which could just use the URL), it is effectively just one. Your example did use redundant servers, which wouldn't really need discrimination other than perf/reachability, but the web already has plenty of ways of building redundancies into unique urls and its ideal if the url descirbes the resource, not the routing, [..] > > Correct. This proposal is to make configuration easier. Are you objecting > to making configuration easier, or to the notion that the DNS API server > URL should be discoverable, or ...? > > I'm definitely saying the DoH protocol doc does not need to further define discovery. --001a114c59d68e84bb0566da905f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe that the level of discovery (i.e. you need = to configure it) is fine for the work the WG has adopted and the recursive = resolver scope we're working on. It is the normal approach for a web se= rvice.

While I don't see a lot of value in st= arting a separate new work item on discovery I don't have a strong opin= ion on whether the wg should do that beyond my suspicion that it wouldn'= ;t be widely used.

On Wed, Mar 7, 2018 at 4:49 PM, Paul Hoffman &= lt;paul.hoffman= @icann.org> wrote:

See above. In the edge case that I hear that my bank runs this secur= e DNS server but I don't know my bank's hostname, I am out of luck = with DOH. That's fine.


I don't un= derstand why we are talking about your bank's DNS server.=C2=A0 I presu= me you mean that in context only with your interactions with the bank?

I know you mentioned some use cases around the browse= r using it to resolve http urls instead of its global recursive resolver, b= ut that's not something that is in scope for the DoH WG (that would imo= best be a HTTPbis item - as it is how to route HTTP requests.. for which o= ne possibility among many is to define a discovery algorithm for a DoH endp= oint based on first party and define the scope of the result from that endp= oint.. but that's speculative and nobody is chartered to do that work.)=

OS configuration for DNS service has always been based on IP address= es because using a domain name to identify a server causes a pretty obvious= chicken-and-egg problem. How is that relevant for DOH, which is based on U= RLs that already have a hostname in them?

it is relevant here because your proposal effectively maps a hostname to= a URL. It kinda looks like it maps it to N URLs but because there is no us= eful way to discriminate between them other than configuration (which could= just use the URL), it is effectively just one. Your example did use redund= ant servers, which wouldn't really need discrimination other than perf/= reachability, but the web already has plenty of ways of building redundanci= es into unique urls and its ideal if the url descirbes the resource, not th= e routing,
[..]

Correct. This proposal is to make configuration easier. Are you obje= cting to making configuration easier, or to the notion that the DNS API ser= ver URL should be discoverable, or ...?


I'm definitely saying the DoH protocol doc does = not need to further define discovery.

--001a114c59d68e84bb0566da905f-- From nobody Wed Mar 7 15:10:51 2018 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 C5A881242F7 for ; Wed, 7 Mar 2018 15:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 s54KV8-sGS7G for ; Wed, 7 Mar 2018 15:10:47 -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 C55FA120727 for ; Wed, 7 Mar 2018 15:10:47 -0800 (PST) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id 763263A063 for ; Wed, 7 Mar 2018 18:10:47 -0500 (EST) Received: by mail-ot0-f171.google.com with SMTP id m22so3706914otf.10 for ; Wed, 07 Mar 2018 15:10:47 -0800 (PST) X-Gm-Message-State: AElRT7FzBL0QDLg765tDfrdYUtRW2rGzWJXJnxu1gvqigIY5DNvsS6lZ eU+YcLoS2O5l64L+Uc26nkuL0g6HDxDZrWcHC/w= X-Google-Smtp-Source: AG47ELt5oCUHeJ1YDHx6jgZI6vh9EFJas/kwKIiO33r5GJtM9jX5lLCndM3sldxRtpd4POqkmcHizoMY9eq4/INyehM= X-Received: by 10.157.46.143 with SMTP id w15mr16209657ota.205.1520464247164; Wed, 07 Mar 2018 15:10:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Wed, 7 Mar 2018 15:10:46 -0800 (PST) In-Reply-To: <20180307225916.mtedvpezetnctco2@mx4.yitter.info> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> <20180307225916.mtedvpezetnctco2@mx4.yitter.info> From: Patrick McManus Date: Wed, 7 Mar 2018 18:10:46 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a113540045897170566daabe1" Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 23:10:50 -0000 --001a113540045897170566daabe1 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 7, 2018 at 5:59 PM, Andrew Sullivan wrote: > > it's also an attack vector if only your vendor can control how it can > be used. If _that's_ what we think we're building, then I at least > was fooled by the charter. > I think we all support configuration by URL. Paul is simply advocating for an optional layer of indirection in discovering that URL (and please correct me if I'm wrong on that). I don't think that would have a material impact on what products would allow configuration and which wouldn't (though it obviously could impact how)... --001a113540045897170566daabe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 7, 2018 at 5:59 PM, Andrew Sullivan <ajs@anvilwalrusden.com= > wrote:

it's also an attack vector if only your vendor can control how it can be used.=C2=A0 If _that's_ what we think we're building, then I at = least
was fooled by the charter.

I think w= e all support configuration by URL. Paul is simply advocating for an option= al layer of indirection in discovering that URL (and please correct me if I= 'm wrong on that). I don't think that would have a material impact = on what products would allow configuration and which wouldn't (though i= t obviously could impact how)...

--001a113540045897170566daabe1-- From nobody Wed Mar 7 15:41:55 2018 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 B1F74126BF6 for ; Wed, 7 Mar 2018 15:41:54 -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=zMOm0UaQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cxjZP4oO 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 8svs_WWT5dBb for ; Wed, 7 Mar 2018 15:41:53 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD40124B18 for ; Wed, 7 Mar 2018 15:41:52 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 39E8C216A8; Wed, 7 Mar 2018 18:41:52 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 07 Mar 2018 18:41:52 -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=fm2; bh=7GVvD0Sx0kc/UJB+CuzbwUDTa3Drb a4ondHr5ONsNFI=; b=zMOm0UaQTLNLuD+mtEhnc5MACkowzdDgXyXsXIhorqNkH E7WWfSz7cBGsf/eMVwJGZkKcdZxLA+Fp96dTqCFjzeADImaqJ40cBiUMivEFyBSp jHpd7ItkaIPGJzfMHFqo1uzccCL15OeW9MHzfmUm9vITfUtdSYjwASWPPXpc9GS5 N2/vbpyN06FN3Yyda+LaQI2V1HtxGG6b7Q8Px2KF6/pDXZwo1X91KM2yRUL0DHiy smocklTkcXGNW4ySoV3Tz7wP7Rkz9C7RZB380Kdyi5nR2XcOvqYtHQWJlDfNejqt XcOpKyE+SlMwM9I2qifVozEKW7EcUrZZRZ3iEAPdQ== 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=fm2; bh=7GVvD0 Sx0kc/UJB+CuzbwUDTa3Drba4ondHr5ONsNFI=; b=cxjZP4oOMvb9+wmVTqc9ra DWJXdDFnh9zbkqBb2nR4/F6cfDLtsN+L14xVPM1FXex25I57S0b+3R1+qLqgHruW 71K6nDwOKtO9PBiA+4PWgc9dWL4lV6kxJz8RAXJCQ4OWEz/TQSwupEiMJj4MdoTL 1v2uiSwUClJ0vx3oe8Ek2N8JUdGE+5PzhSklZebBiewLjv7S0XGq/Bl+S1jbpBUt HnaIGtX333XUXowhW3pkpeStrlSB65jOyq/3VHkOLNJhoToYXrVfiG3CyImbuQF3 IBikli6LVZtF3MJjZqcDcS0KT2bxnd1ehk0AsOibCCZQ4E6BlcZmuWMoUZnq5i0Q == X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 337157E27B; Wed, 7 Mar 2018 18:41:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: <20180307225916.mtedvpezetnctco2@mx4.yitter.info> Date: Thu, 8 Mar 2018 10:41:47 +1100 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> <20180307225916.mtedvpezetnctco2@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 07 Mar 2018 23:41:55 -0000 > On 8 Mar 2018, at 9:59 am, Andrew Sullivan = wrote: >=20 >> Also, we don't make decisions based upon what people feel in the IETF = -- we decide based upon rough consensus and running code. Is there *any* = implementer interest in what you're describing? >=20 > If the IETF is standardising a feature that users can't get out of or > use in ways that suit them, then I would have to ask why we are > willing to touch it with a 93 1/2' pole. That really would make us > the IVTF, and I'm not interested in such efforts. I agree that there > is a serious attack vector in allowing users to configure doh, but > it's also an attack vector if only your vendor can control how it can > be used. If _that's_ what we think we're building, then I at least > was fooled by the charter. I meant something more specific -- are any implementations (practically, = browsers) keen to expose a UX that allows you to type an arbitrary = hostname into it and wind up resolving DNS through that host, and can = explain their reasons for doing so with a hostname rather than a URL = (which again is how search engines are configured currently)? We generally don't discuss UX in the IETF, but it seems like if we're = going to have a UX-driven argument determining the protocol, we should = at least have someone who's interested in following that path and can = explain why this so important. Otherwise it feels too much like = engineers who have no business making UX decisions taking a punt. And that still doesn't address the mismatch with the intended use of = .well-known. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Mar 8 07:58:58 2018 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 2D3A4127078 for ; Thu, 8 Mar 2018 07:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 T76sn4BZqvK7 for ; Thu, 8 Mar 2018 07:58:55 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 F1DB8124207 for ; Thu, 8 Mar 2018 07:58:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 64FBF28033B; Thu, 8 Mar 2018 16:58:53 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 5E99D28042D; Thu, 8 Mar 2018 16:58:53 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 5797728033B; Thu, 8 Mar 2018 16:58:53 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 548C76423521; Thu, 8 Mar 2018 16:58:53 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 4B64240282; Thu, 8 Mar 2018 16:58:53 +0100 (CET) Date: Thu, 8 Mar 2018 16:58:53 +0100 From: Stephane Bortzmeyer To: Mark Nottingham Cc: Paul Hoffman , "doh@ietf.org" Message-ID: <20180308155853.jyl6fa22svoyxdqr@nic.fr> References: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org> <5bca3f4f-e40a-4afc-c71a-25ede395a065@nostrum.com> <497ECCA2-5453-40CC-8385-7FEBE1A3FB0D@icann.org> <08C4E0C7-4C4E-4F65-82A5-9266A029A61C@mnot.net> <79E77AB7-5A2E-4DC1-A2B6-F5B8AC066513@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.004848, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.8.155415 Archived-At: Subject: Re: [Doh] [Ext] Re: Use cases and URLs 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, 08 Mar 2018 15:58:57 -0000 On Thu, Mar 08, 2018 at 09:46:19AM +1100, Mark Nottingham wrote a message of 24 lines which said: > I note that to configure a new search engine in most browsers, you > need to type in what is effectively a URL template. I would thought that almost all "M. Smith" users use (without knowing it) OpenSearch, thus have no URL to type? This reminds me I should harass webmaster@ietf.org for an OpenSearch description. From nobody Fri Mar 9 13:01:14 2018 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 2947B1270FC for ; Fri, 9 Mar 2018 13:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2eeoNe4PaCnI for ; Fri, 9 Mar 2018 13:01:12 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1B4120047 for ; Fri, 9 Mar 2018 13:01:11 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 9BB182F9C1; Fri, 9 Mar 2018 16:01:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23202.62997.612116.883242@gro.dd.org> Date: Fri, 9 Mar 2018 16:01:09 -0500 From: Dave Lawrence To: doh@ietf.org Archived-At: Subject: [Doh] Proposed Agenda, doh @ IETF 101 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, 09 Mar 2018 21:01:13 -0000 We have relative little business to conduct at the upcoming London meeting. Here is the proposed agenda, which we're expected to make final on Monday. * DNSProxy implementation experience (M. Fantuzzi; 10 min) https://github.com/fantuz/DNSProxy * draft-ietf-doh-dns-over-https (P. Hoffman, P. McManus; 30 min) https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ Update on changes and possible move to last call * Charter discussion Close the WG following RFC publication, or recharter for more work? Please send feedback for the proposed agenda by Monday. Thank you. From nobody Sat Mar 10 03:21:00 2018 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 B7F49124217 for ; Sat, 10 Mar 2018 03:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] 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 JG8kq9wzd0rK for ; Sat, 10 Mar 2018 03:20:49 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 770511271FD for ; Sat, 10 Mar 2018 03:20:49 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id e2so578972ywh.9 for ; Sat, 10 Mar 2018 03:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Z7fIcoaKW3uV6jaMwcKOD9Ei8e+uyTHrA3J3cDXZTSA=; b=IxCOA4W+qbMa17GSfWrb4N3Xxo8DzcmYppl8NwNuKUO5wQyHo794lhZ8yUdkbUUe66 bGgs+/tcHqasVRSyMeYrthCZ+JMfkQc0WzE/4BsembkJyH6LYwaZsaJUCdOAKk5UlXtm QzDIdF1CgcT7u84VM9eVqucKajwYtM+cyzsjBNazXcw6tqTd04cANB5r1RIspk8iMLQf q1ofXImgj3mYHAnl4U57/J8tU8hZNuYCva8tBvV749nDYLsdjARFHXObITu0RPyzVeEh fULlwWubaTZl3KcIKfpLrnnI7ZjpcE/MQaLdFkaUHVrlK3Rs2pbunn/dughjp+h0vmgZ 2WkQ== 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:cc; bh=Z7fIcoaKW3uV6jaMwcKOD9Ei8e+uyTHrA3J3cDXZTSA=; b=WAylbTfuvAxEB3OiXPqjuSrT95gjf5/6RtCA744OBscn+mmduSB3X8qyf5+dI/4H7F REi+iIHkkVxPX9ER5hMVrlBk9DFBFSjPkgYkbp/DuBB6pRP0D+4pq6D77vKKHN/9PQgo vDvDDWMsRpCGW7Y+Xdv+A+rvquVqg19mMY0EckyDAKPXfxsznUN8t2bhoc/eYSyYobUZ vYCoEctgOeXyiy3tpooyvtJ/u//IW2iopfgf2MMjVcbHQK/jknqcYcVGJFdVC32HxHp8 VDt91sF4rh2hlrpHmGnPkNa3GUTGt81sYwlYoIBOP1TRD0afHMwkaBpMsz+vasLaZIix yw1Q== X-Gm-Message-State: AElRT7H4GHqWm/L7+PmL1XVeFUTEKXDikw0/gZUNHylSFhy4sbg74aoe 3w6Pj3FkOEkaTmEdKOqS8cdd3yg1G+npg0sx9myJeezZ//c= X-Google-Smtp-Source: AG47ELs/H7FUfhCmZezwcqp+lY6CqsHfuKJdfRTmQha8duVadw/Cyvy/YT6l4BuhYWybxp/MOHL3TBAV//osglIwm6g= X-Received: by 10.129.42.193 with SMTP id q184mr829400ywq.266.1520680848180; Sat, 10 Mar 2018 03:20:48 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:ab51:0:0:0:0:0 with HTTP; Sat, 10 Mar 2018 03:20:27 -0800 (PST) From: Erik Kline Date: Sat, 10 Mar 2018 20:20:27 +0900 Message-ID: To: doh@ietf.org, dns-privacy@ietf.org Cc: Lorenzo Colitti , Warren Kumari Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11429238cede5205670d190f" Archived-At: Subject: [Doh] representation of DNS transport in use? 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: Sat, 10 Mar 2018 11:20:52 -0000 --001a11429238cede5205670d190f Content-Type: text/plain; charset="UTF-8" I'm expecting to die a thousand deaths for this question, but... TL;DR: Should we have some kind of URI schemes for encrypted DNS protocols (i.e. identifying the transport)? -- The motivation for this comes from working on adding DNS-over-TLS support into Android. Background: an app can always do its own DNS resolution regardless of what the system would do on its behalf were it asked. An app can send to some random server at port 53 without going through the system resolver, or it can wrap DNS queries in a Carrier Pigeon VPN. We have an API to communicate to apps whenever an encrypted DNS protocol is in use by the system: in order to express the intent of the user and indicate when at least one nameserver was successfully found in opportunistic mode (the system is consequently sending all queries to that/those server(s) inside TLS, and apps should therefore do likewise). When thinking about what information might be expressed by this API, rather than defining something bespoke I figured I'd ask about whether a standard identification scheme for transports is worth having. Currently we only support DNS-over-TLS. If we someday gained dns-over-https capability we might try to auto-detect the servers' capabilities and could conceivably convey that status to apps. RFC 4501 is obviously a thing, but seems to me to be more aimed at identifying resource records than server access methodology. To wit, from section 3: Intended usage: Whenever it is useful for DNS resources to be referenced by *protocol-independent* identifiers. Often, this occurs when the data is more important than the *access method*. Since software in general has coped without this so far, ... (emphasis mine) Add to this discussion the observation that some DNS-over-TLS servers are also reachable on 443, I think just representing the protocol in use might not be sufficient. RFC 7858 didn't seem to request any URI registration. For a server reachable via dns-over-https, the -03 doc would seem indicate we could just use https://thing:port. So maybe this is a matter only for DNS-over-TLS (dns-tls://thing:port?). End of rambling. -ek --001a11429238cede5205670d190f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8 LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2 9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgMWLjlLU8o0Ua1Y66G6fMM8pdYeH5BfEu 54312w0tMg4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMzEw MTEyMDQ4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBANNY0w55pBPGxRGL0ESMnU+VFZHtoGwfb9zc/QV/ARtdNKZKkrvh Ev67n46Umik9NRMI49BS991gZwpO+VBWzEVqXXL2J27qY3vuW+cO94P6IuhttRnC3fZ9aOrRm8cR 3wom1ItsZbTr12sEyylOD40/dyyt7TwGuwBc7/1dgzuS6NMeUB+FhKeow4zLWF8qp7LYFlMmeWjF qYC58B87KX001RM+s3obIP1e804XkCLTbgjMlaAdQDUpDViVidlYUfoXaRKmKT5L3xvoe0LvzDC0 wuNQMKThBGmHrUz7Thihjts601x/HovuhxjIFAkFN4dylYz5awiat695ewt631U= --001a11429238cede5205670d190f-- From nobody Mon Mar 12 03:40:41 2018 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 B14A21270AC; Mon, 12 Mar 2018 03:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 3Dk4EI7boPsL; Mon, 12 Mar 2018 03:40:34 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 9A0EC1241F5; Mon, 12 Mar 2018 03:40:34 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2BCEB280231; Mon, 12 Mar 2018 11:40:33 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 24877280287; Mon, 12 Mar 2018 11:40:33 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 1DB4B280231; Mon, 12 Mar 2018 11:40:33 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 1A2A8663E721; Mon, 12 Mar 2018 11:40:33 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 12C12400CB; Mon, 12 Mar 2018 11:40:33 +0100 (CET) Date: Mon, 12 Mar 2018 11:40:33 +0100 From: Stephane Bortzmeyer To: Erik Kline Cc: doh@ietf.org, dns-privacy@ietf.org, Warren Kumari , Lorenzo Colitti Message-ID: <20180312104033.oqdijbcvwp6j5is2@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000595, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.12.103316 Archived-At: Subject: Re: [Doh] [dns-privacy] representation of DNS transport in use? 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, 12 Mar 2018 10:40:36 -0000 On Sat, Mar 10, 2018 at 08:20:27PM +0900, Erik Kline wrote a message of 165 lines which said: > TL;DR: Should we have some kind of URI schemes for encrypted DNS > protocols (i.e. identifying the transport)? dns+tls: ? (To follow the COAP example of RFC 8323, section 8.) May be this is a question for uri-review@ietf.org? From nobody Mon Mar 12 03:41:46 2018 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 213D4126C25 for ; Mon, 12 Mar 2018 03:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 qf5yjC4J_97Y for ; Mon, 12 Mar 2018 03:41:44 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 49A3E1241F5 for ; Mon, 12 Mar 2018 03:41:44 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D19312801BE; Mon, 12 Mar 2018 11:41:42 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id CBC18280266; Mon, 12 Mar 2018 11:41:42 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id C51122801BE; Mon, 12 Mar 2018 11:41:42 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C1FCE663E720; Mon, 12 Mar 2018 11:41:42 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B992A400CB; Mon, 12 Mar 2018 11:41:42 +0100 (CET) Date: Mon, 12 Mar 2018 11:41:42 +0100 From: Stephane Bortzmeyer To: Dave Lawrence Cc: doh@ietf.org Message-ID: <20180312104142.4s6brnghe7nsdopd@nic.fr> References: <23202.62997.612116.883242@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23202.62997.612116.883242@gro.dd.org> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.022143, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.12.103316 Archived-At: Subject: Re: [Doh] Proposed Agenda, doh @ IETF 101 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, 12 Mar 2018 10:41:45 -0000 On Fri, Mar 09, 2018 at 04:01:09PM -0500, Dave Lawrence wrote a message of 20 lines which said: > We have relative little business to conduct at the upcoming London > meeting. Here is the proposed agenda, which we're expected to make > final on Monday. Several people expressed interest in working on DoH at the hackathon, so may be a slot "Hackathon experience"? From nobody Mon Mar 12 13:41:04 2018 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 697F0126CF9 for ; Mon, 12 Mar 2018 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 p4EFct2C1kDb for ; Mon, 12 Mar 2018 13:41:02 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72925120454 for ; Mon, 12 Mar 2018 13:41:02 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id B120632008; Mon, 12 Mar 2018 16:41:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23206.58845.708616.485909@gro.dd.org> Date: Mon, 12 Mar 2018 16:41:01 -0400 From: Dave Lawrence To: Stephane Bortzmeyer Cc: doh@ietf.org In-Reply-To: <20180312104142.4s6brnghe7nsdopd@nic.fr> References: <23202.62997.612116.883242@gro.dd.org> <20180312104142.4s6brnghe7nsdopd@nic.fr> Archived-At: Subject: Re: [Doh] Proposed Agenda, doh @ IETF 101 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, 12 Mar 2018 20:41:03 -0000 Stephane Bortzmeyer writes: > Several people expressed interest in working on DoH at the hackathon, > so may be a slot "Hackathon experience"? Are you going to be working on it? Willing to do the summary to the wg? From nobody Mon Mar 12 13:50:54 2018 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 F24A3126CF9 for ; Mon, 12 Mar 2018 13:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 95xyuYSkKp3M for ; Mon, 12 Mar 2018 13:50:51 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 0482A120454 for ; Mon, 12 Mar 2018 13:50:51 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DCC122801D8; Mon, 12 Mar 2018 21:50:48 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id D6C012802A0; Mon, 12 Mar 2018 21:50:48 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id CFECE2801D8; Mon, 12 Mar 2018 21:50:48 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C8C00663EBE0; Mon, 12 Mar 2018 21:50:48 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id C5FF94071A; Mon, 12 Mar 2018 21:50:48 +0100 (CET) Date: Mon, 12 Mar 2018 21:50:48 +0100 From: Stephane Bortzmeyer To: Dave Lawrence Cc: Stephane Bortzmeyer , doh@ietf.org Message-ID: <20180312205048.lggivmtg5irlgh3f@nic.fr> References: <23202.62997.612116.883242@gro.dd.org> <20180312104142.4s6brnghe7nsdopd@nic.fr> <23206.58845.708616.485909@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23206.58845.708616.485909@gro.dd.org> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.094618, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.12.203916 Archived-At: Subject: Re: [Doh] Proposed Agenda, doh @ IETF 101 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, 12 Mar 2018 20:50:53 -0000 On Mon, Mar 12, 2018 at 04:41:01PM -0400, Dave Lawrence wrote a message of 5 lines which said: > > Several people expressed interest in working on DoH at the hackathon, > > so may be a slot "Hackathon experience"? > > Are you going to be working on it? Willing to do the summary to the wg? Yes. Why not? From nobody Tue Mar 13 09:40:49 2018 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 3BC71124D37 for ; Tue, 13 Mar 2018 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Eg35CNHxbFqb for ; Tue, 13 Mar 2018 09:40:45 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6F3126DEE for ; Tue, 13 Mar 2018 09:40:45 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id B5A49328F5; Tue, 13 Mar 2018 12:40:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23207.65291.727182.885881@gro.dd.org> Date: Tue, 13 Mar 2018 12:40:43 -0400 From: Dave Lawrence To: doh@ietf.org Archived-At: Subject: [Doh] IETF 101 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: Tue, 13 Mar 2018 16:40:47 -0000 Here's the agenda for our meeting next week: * DNSProxy implementation experience (M. Fantuzzi; 10 min) https://github.com/fantuz/DNSProxy * Hackathon Experiences (S. Bortzmeyer; 10 min) * draft-ietf-doh-dns-over-https (P. Hoffman, P. McManus; 30 min) https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ Update on changes and possible move to last call * Charter discussion Close the WG following RFC publication, or recharter for more work? - Brief presentation of possible work (Daniel Kahn Gillmor; 10 min) - Open Discussion From nobody Sat Mar 17 05:27:15 2018 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 B10EF1277BB for ; Sat, 17 Mar 2018 05:27:13 -0700 (PDT) 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, HTML_MESSAGE=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 (1024-bit key) header.d=cloudflare.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 lxr05w3gwXhZ for ; Sat, 17 Mar 2018 05:27:12 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 3AC4812778E for ; Sat, 17 Mar 2018 05:27:12 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a20so6220122wmd.1 for ; Sat, 17 Mar 2018 05:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=4l/cO33kNUTZdgDLghDYx3jxc290lkgfgf/nzdRO0zE=; b=YURLUi/wuANmougYyMYVYoW6JkYFIvBqd3lLYnp1fvSQa90tZVPBGwx5jOIHAP1mGF Jg2XTWzGFgPVZiG7HbpgN6icUgKMYXqfSaSuMeX2Mmj6/XU9XcIgxVQogKSRuQwPcvQq +ThsNzo9l4M7MaoBvgbRkE9pXMtDk5/5gc2A8= 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=4l/cO33kNUTZdgDLghDYx3jxc290lkgfgf/nzdRO0zE=; b=Dv4htotOYvqFaoW/osG5bG83O7JWnapc8AeEmrLuS3k2N5q0fW7cMC7I95TqNsTZw0 ChHXZUKNencxjP+5N5AbztJeaikiuS8pT64OJtOTJCRljbh7laGkIFoLrn0ihFNADrFy BRlTsqMQa3GbE5mj4cRrZMVWijQyCnLcLdAmK/IGh4kgYOSfLJH13MN+AWvAw2KNCDwG yJW61cvv/ZVyPjExo1RpM61AGIoSW0qoNPXtgqHp/9UwOv7N0u0UwDfhXn5VQcvxCzwT KCYK4wMCcs0EhaCwSke2KlxWxdzkj81ynNQLPkf8OwaWdJL27pVOgMxr0CDzCe5cx3fK Rhlw== X-Gm-Message-State: AElRT7HRe9ypTuk5fEwC8932QX5BO69ajoBu1wa5h4z/hs6ylYUjhDbo GzeZVQ8ze2zqmM8F22DHlEpKiEfl6Kr94kvyGuXKhJYq X-Google-Smtp-Source: AG47ELtBq6ojL8ugUAlGdB/lhMs43OCzEsgbgesMFSkdQBsBokzKLRTdRYXFXD/xTeAxeYinttYRJhENspfA4LjbygA= X-Received: by 10.28.5.145 with SMTP id 139mr3974137wmf.31.1521289630333; Sat, 17 Mar 2018 05:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.41 with HTTP; Sat, 17 Mar 2018 05:27:09 -0700 (PDT) From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Sat, 17 Mar 2018 12:27:09 +0000 Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="001a114442f8046fe705679ad877" Archived-At: Subject: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 12:27:14 -0000 --001a114442f8046fe705679ad877 Content-Type: text/plain; charset="UTF-8" Based on experience at the IETF101 Hackathon this issue came up. dns-over-https-03 draft is silent on the topic if Get and Post are both required or implementations can only support one of them. I would like to see a section like this added to the document: Implementation requirements Post MUST be supported Get MAY be supported, when GET is not supported the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). Reasoning: In many web servers POST is not logged but GET is. Thus from a privacy point of view clients that do not want to have their queries logged by servers stand a better chance by using POST. Olafur --001a114442f8046fe705679ad877 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Based on experience at the IETF101 Hackatho= n this issue came up.

dns-over-https-03 draft is si= lent on the topic if Get and Post are both required or implementations can = only support one of them.=C2=A0

I would like to se= e a section like this added to the document:=C2=A0

Implementation requirements

Post MUST be supported Get MAY b= e supported, when GET is not supported the error code retuned should be 405= (HTTP RFC 7321, section 6.5.5).

Reasoning: In man= y web servers POST is not logged but GET is. Thus from a privacy point of v= iew clients that do not want to have their queries logged by servers stand = a better chance by using POST.=C2=A0

Olafur
<= div>

--001a114442f8046fe705679ad877-- From nobody Sat Mar 17 05:40:43 2018 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 44A1F12778E for ; Sat, 17 Mar 2018 05:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 pgqgOcEg3EVB for ; Sat, 17 Mar 2018 05:40:40 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C406127077 for ; Sat, 17 Mar 2018 05:40:40 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w2HCebHe024974 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Mar 2018 13:40:37 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w2HCebII024970; Sat, 17 Mar 2018 13:40:37 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 17 Mar 2018 13:40:37 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= cc: doh@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1129329158-101822746-1521290437=:1331" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 12:40:42 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-101822746-1521290437=:1331 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 17 Mar 2018, Ólafur Guðmundsson wrote: > Post MUST be supported Get MAY be supported, when GET is not supported the > error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). You didn't say this, and it is a side-note about methods, but I still wanted to just mention that when imlementing support for HTTP/2 server push for DOH, you want the server to send that as a GET so that the query string tells the client about the request it also sends the response to... -- / daniel.haxx.se --1129329158-101822746-1521290437=:1331-- From nobody Sat Mar 17 06:16:47 2018 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 76857127863 for ; Sat, 17 Mar 2018 06:16:46 -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 (1024-bit key) header.d=cloudflare.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 3zBMlCGaNGbC for ; Sat, 17 Mar 2018 06:16:45 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 CBAED12708C for ; Sat, 17 Mar 2018 06:16:44 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id h21so7780688wmd.1 for ; Sat, 17 Mar 2018 06:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oCRem5ljno3EV0J/xdEvf5shkMf32GTuiQD0q7LGNgs=; b=wAO9iAUugd0wpN6J0LEaT15RZSimoAoEB3BoULvh/5bk7Yu5ZbJU+Sqn8SYgkigJKE JgDP2iBxftyuFEBTZnpKHnxxnn8b8/tky+ROaWYzyx2cSzLKnYvPDBqjphFSbnUrn6gA 5u/KDF6ypXbU3NEXvntyuMZCvwPqpfxp2ke+Q= 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=oCRem5ljno3EV0J/xdEvf5shkMf32GTuiQD0q7LGNgs=; b=Ly4smsyFxLlAXZoGw1Y2rGC1UdTEEb8AUimeTTN/xnz9bhoYIX5MOmxEUkoyKEWo7D /Z/A3O5GMi0ctIiXzsz+80YJPotdKvToWNjOWUZegCJRXzLmAYff3VkDGNBJWyYwhf8r GuoB+fbkN85YI8Bonvn9aBLNXVFQFidot//QLWwA3RVnG32Rac/k+RoquY5GqI1Xdhe3 Jc/AAu7akXdnEVi12VWwzgAHcxQCsEYubJ+PIDysdA9jr1j+1hnD8U2iB5kW4SjhJ0hp JIXos2/oqN9UxfcWH0U8iY4UYl6htKatS/bq3N00R1m1OOygBmVB9Nj92aXd8f2knXK7 izLw== X-Gm-Message-State: AElRT7EQqcMNozFdqK8jKFgd5irdEZKh9qkw4T7dEt0XYJXjhPoAQqhx URe7rrd3jDzEkkqGyN2ZtDm5bqwvDhn8hUpFENNCnteu X-Google-Smtp-Source: AG47ELv5HifhAQqGRC0/PnZu565Myy7IKdS6W3unFll0TBgrbBlUGbRl2gUg8nAPn697hCo59EUq5x4aXXDskO5iNh0= X-Received: by 10.28.5.145 with SMTP id 139mr4050736wmf.31.1521292603262; Sat, 17 Mar 2018 06:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.41 with HTTP; Sat, 17 Mar 2018 06:16:42 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Sat, 17 Mar 2018 13:16:42 +0000 Message-ID: To: Daniel Stenberg Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a114442f837a09f05679b8995" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:16:46 -0000 --001a114442f837a09f05679b8995 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is the usage case to Server push of DNS answers ? Olafur On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg wrote: > On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: > > Post MUST be supported Get MAY be supported, when GET is not supported th= e >> error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). >> > > You didn't say this, and it is a side-note about methods, but I still > wanted to just mention that when imlementing support for HTTP/2 server pu= sh > for DOH, you want the server to send that as a GET so that the query stri= ng > tells the client about the request it also sends the response to... > > -- > > / daniel.haxx.se --001a114442f837a09f05679b8995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What is the usage case to Server push of DNS answers ?=C2= =A0

Olafur


On Sat, Mar 17, 2018 at 12:40 PM, Da= niel Stenberg <daniel@haxx.se> wrote:
On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson= wrote:

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...

--

=C2=A0/ daniel.haxx.se

--001a114442f837a09f05679b8995-- From nobody Sat Mar 17 06:21:31 2018 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 AB87F12708C for ; Sat, 17 Mar 2018 06:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmqXe_OD6Gy1 for ; Sat, 17 Mar 2018 06:21:25 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 4D41712762F for ; Sat, 17 Mar 2018 06:21:25 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t3so7786730wmc.2 for ; Sat, 17 Mar 2018 06:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5kWfgVb/346QCoDOjQBwJR1ueraarPcUazsZkw6CIG4=; b=WG75FKiZ509IvNVk8FgalydpE6s/VTScbCY2KKGY69gwR+bbDKJHb1IvteejnanAks d/kSSqDOHgLt9uKqVRU4zFC0ruHl38Sac/pJU0ecSS+n1NduwqpgwHTDJRcteJ+UyRy6 t+o8M6mv33BQPYKPr7Tcd2VbdbHMTJ2De0YI+wd8Mf30UiSaxUEPvaXr2gPmbOuq8YyC UBFFGU1NQ09/KEj31SG+Xgh4Tt5vRmQyTThBJZu9pIfkbXjYCo4ZTIHGlFIwgkGAOZtl u3j1P37712Y8ri6Kgo2Qq2FGzxgaYQLtc4klHThlqY9sxn5pOgSkus/exunyhex3Youp OhEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=5kWfgVb/346QCoDOjQBwJR1ueraarPcUazsZkw6CIG4=; b=aZ6IrwC0QOVWwIbRTuV/okFI7htQjD2Npe/RB0qItejNC+Tv0+K39NRqCaz4pV/Tmz HtWg3xq5aIlaYoS59yRZsdfd4OXx1CUfN78n7lHwnyuAqyw97ifjEaQIj6e0DyHxqNnu GJ59SDRBxQl7X2ve4QqFNHsqQWYcNePx+r4SW3/+y1OQwrDXligc7VpD5VYtGr5pKwob zsR2CRpDV2zByMlULsWyGwM5/sAXgrWtK4O95JtCRtHVzfPflrLO5VHN6I+WxR/fRX7D vU+dAsSkCcRSO70Uw6XLjIZSJFyWoZneIk68suLaXxDIJrxd9xqDdYCquPbvhv8C2qI3 2tUA== X-Gm-Message-State: AElRT7Gmr4pslgIBs/HzRQTWPIqddSn2G14OWrfkLWrpEZmEL//oMOsq yCwsBSBF0ozl51TnUL+3KdstNQ== X-Google-Smtp-Source: AG47ELsG7DtuWv4+IyQO7cst+U3SAzalmA285+Kzl1Ddb1zHdjv+7Sf/Ox+9jCgsbHoVCtA+7OlRJQ== X-Received: by 10.28.94.11 with SMTP id s11mr4125470wmb.159.1521292883786; Sat, 17 Mar 2018 06:21:23 -0700 (PDT) Received: from miek.nl ([2001:67c:1232:144:b320:5945:16d2:52c4]) by smtp.gmail.com with ESMTPSA id k44sm154899wrk.6.2018.03.17.06.21.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 17 Mar 2018 06:21:23 -0700 (PDT) Date: Sat, 17 Mar 2018 13:21:22 +0000 From: Miek Gieben To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: doh@ietf.org Message-ID: <20180317132122.wchzgiuayhvpmpm4@miek.nl> Mail-Followup-To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , doh@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:21:30 -0000 [ Quoting in "[Doh] Support requirements for Get ..." ] >Implementation requirements > >Post MUST be supported Get MAY be supported, when GET is not supported the >error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). > >Reasoning: In many web servers POST is not logged but GET is. Thus from a >privacy point of view clients that do not want to have their queries logged >by servers stand a better chance by using POST. I agree with this. On a side note: as an DNS library implementer I would like to expose as little knobs as possible and just default to one way of using DoH. /Miek -- Miek Gieben From nobody Sat Mar 17 06:25:43 2018 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 2D71A127867 for ; Sat, 17 Mar 2018 06:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 VETQQD228Q65 for ; Sat, 17 Mar 2018 06:25:40 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84224127863 for ; Sat, 17 Mar 2018 06:25:40 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 49A2833103; Sat, 17 Mar 2018 09:25:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23213.5971.275554.796771@gro.dd.org> Date: Sat, 17 Mar 2018 09:25:39 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:25:42 -0000 =D3lafur Gu=F0mundsson writes: > What is the usage case to Server push of DNS answers =3F=20 Minimizing the amount of time spent on DNS lookups for other assets and links in a page. From nobody Sat Mar 17 06:27:59 2018 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 EF019127909 for ; Sat, 17 Mar 2018 06:27:57 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=mnot.net header.b=nN66DBxZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RVayEHdB 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 10Joa8vM6I6k for ; Sat, 17 Mar 2018 06:27:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B54127863 for ; Sat, 17 Mar 2018 06:27:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 948C620E1C; Sat, 17 Mar 2018 09:27:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 17 Mar 2018 09:27:55 -0400 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=fm2; bh=6cJ1jbTSrFe+/q6ovvKQD8Bi9ODU3 S6LdOh+puqwfXI=; b=nN66DBxZ/AzkZy0Vi1VJJvVDkLjTu1D+T34/FOe5OfE+2 VNd65bxZfgT51Dp0u++DKHuG9uIOrxE3cnK80ZTm+UBE6wEJYzZsjMDSx3wEy5Ht E1wpTa8+Rv0pY8XY+aJg7ieYrn7+Ez2MW1vZn7I8bbTT4Z+yb6u0A0cssWN3hiVz f6kZfAiMdq8A1m1MTBdcHLWQhmEb83ZpToV/v9NJXi6iI3RnKK51d28gFBNs39C+ pyn2PtApkTf2kRssoIyTMyZ1c6D5C8R5fWarpxCJRXNIL0BP71U99XPkZPxVPbjR hXBJV27Wn6xoowRrK12dAsrkJhdOvmZRSks6V46Gg== 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=fm2; bh=6cJ1jb TSrFe+/q6ovvKQD8Bi9ODU3S6LdOh+puqwfXI=; b=RVayEHdBc8g8BLU0TyIxk5 pEgzOU01VcpU49mr8YY0PixJ/48pLxqagONc/m3RUY5kLybSsP/ACmsXp8UjclFd mnKz+1vXIy0hKz56qbjZwmZEl3RHb1PxGwAD9AOR73BUNGVm4Gc3Lb9LjK4S+6x1 v09NqXd2Zi+JXRb5F7/DKMg+gQaAm9mw1iCMbH7Vi0E5M0706SiS0WU3llpdurJ+ oZKKZxGDnuifefQJz9TPqAnPByg8506udaW6NhR0H3g8v6X+/n1IN5lqXcApm/9T F4Y9oddJkkENi9A3GsXh0v2IW0L/Bm8T0b+4dZb2U5YiVuizuYzgxQ3yMFGRV8fg == X-ME-Sender: Received: from dhcp-9233.meeting.ietf.org (dhcp-9233.meeting.ietf.org [31.133.146.51]) by mail.messagingengine.com (Postfix) with ESMTPA id 2289A241D4; Sat, 17 Mar 2018 09:27:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: Date: Sat, 17 Mar 2018 13:27:53 +0000 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <97079A96-FCAC-4D4C-A3F8-49AE29B8CC29@mnot.net> References: To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:27:58 -0000 > On 17 Mar 2018, at 12:27 pm, =C3=93lafur Gu=C3=B0mundsson = wrote: >=20 > Thus from a privacy point of view clients that do not want to have = their queries logged by servers stand a better chance by using POST.=20 That seems like a really weak guarantee of privacy. -- Mark Nottingham https://www.mnot.net/ From nobody Sat Mar 17 06:31:14 2018 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 AEB30127909 for ; Sat, 17 Mar 2018 06:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 a_oFh_v14x5X for ; Sat, 17 Mar 2018 06:31:11 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BDD127867 for ; Sat, 17 Mar 2018 06:31:11 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id CF69A3310D; Sat, 17 Mar 2018 09:31:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23213.6302.825157.726163@gro.dd.org> Date: Sat, 17 Mar 2018 09:31:10 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <97079A96-FCAC-4D4C-A3F8-49AE29B8CC29@mnot.net> References: <97079A96-FCAC-4D4C-A3F8-49AE29B8CC29@mnot.net> Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:31:13 -0000 olafur@cloudflare.com wrote: >> Thus from a privacy point of view clients that do not want to have >> their queries logged by servers stand a better chance by using POST. Mark Nottingham writes: > That seems like a really weak guarantee of privacy. Delightfully understated, in a "sure you're using that word 'guarantee' sarcastically" kind of way. From nobody Sat Mar 17 06:41:47 2018 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 656E5127909 for ; Sat, 17 Mar 2018 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 31y4v3oy4lvN for ; Sat, 17 Mar 2018 06:41:43 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 BE62012708C for ; Sat, 17 Mar 2018 06:41:43 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id e79so7511295ioi.7 for ; Sat, 17 Mar 2018 06:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j385MQQvOJZW39Ab5koJzADWfoiPp0TZDBlbsWWqKCg=; b=pib2X5/du5YLNKbeV6i+mvZeZslA5cfvEQPwez/L5v91FNiX3/CaSmal2a6oqWp40c qtwaQwnE2VgWtUcE5rdgaIfsqPYjRf9qZiwq7JativffbmfRrBpH8mgySQf0yVxD2sCb wLLJ/Z8QDTmTtPs/TWSth7xjdQNydFz6ImmvpMiEgdYhZNzpToaIby/NgOzHbDVT/USP uO2VCEgQXKxgemXQiiaaJXmhkyUyvX1Wjc5xJksctI96NKXmBI33RN3LDTIJ7DnRIcik O9krnltpQ5RqNVHlRSQqgwQ68QD/jdkE/hjT3QkMituSqaKq5Hl/VRrSj5J4cHcyziF9 q2bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j385MQQvOJZW39Ab5koJzADWfoiPp0TZDBlbsWWqKCg=; b=bUrb9plp/8GAxenrOJcajKp3fL5oucIXrVgN0kpHqdlntii1C9tbLY7OS7jbCInG+7 EHK/dKRWi0SCxk2ehO3/rsOeGSwe6U59evpS0iVn/459LN8BoRZPxXoq6EQitWuG1aER D83FVIgaAii0z06bTF6E1kUAlHofSTLsiwLoB1BqYJp6lpUbXHZ1C71kzwo1cFQPmMLY 6YLpcERpuBVZ4nuXe8aJTCYpo9BkPzBracKIz1nmIXIne320I7zhWJ3jj5IDKpLTipNq 96lIr14Tpn7v4RcpCNnksjBtsja5sbNennrwaevDXjI22IBGkJVzYrrnEEL3cDEk/Yum zqlA== X-Gm-Message-State: AElRT7HOQYK6SAqeG2CFEw+1Q0+1s6SxQE/YqZm80FXMx3JfRyKK/hZf YDVxr7/vjb80AluugV+a+4yehEdTU5sGrh2o9e0fMQ== X-Google-Smtp-Source: AG47ELum+uZ6gWely4YUw9904hoXsERgxzpkX/qsyAGrfyrY8PbRVANecT12FP7W5qUHgMWrMcm4AQQL02kzKWwy+14= X-Received: by 10.107.13.142 with SMTP id 136mr5409708ion.265.1521294102826; Sat, 17 Mar 2018 06:41:42 -0700 (PDT) MIME-Version: 1.0 References: <97079A96-FCAC-4D4C-A3F8-49AE29B8CC29@mnot.net> <23213.6302.825157.726163@gro.dd.org> In-Reply-To: <23213.6302.825157.726163@gro.dd.org> From: Ian Swett Date: Sat, 17 Mar 2018 13:41:31 +0000 Message-ID: To: tale@dd.org Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a113fe37099aef805679be21e" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:41:45 -0000 --001a113fe37099aef805679be21e Content-Type: text/plain; charset="UTF-8" FWIW, unless there is a specific exception for Doh POSTs I'm not aware of, using POST prevents clients from sending 0RTT Doh requests. On Sat, Mar 17, 2018 at 9:31 AM Dave Lawrence wrote: > olafur@cloudflare.com wrote: > >> Thus from a privacy point of view clients that do not want to have > >> their queries logged by servers stand a better chance by using POST. > > Mark Nottingham writes: > > That seems like a really weak guarantee of privacy. > > Delightfully understated, in a "sure you're using that word > 'guarantee' sarcastically" kind of way. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113fe37099aef805679be21e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, unless there is a specific exception for Doh POSTs I= 'm not aware of, using POST prevents clients from sending 0RTT Doh requ= ests.


On Sat, Mar = 17, 2018 at 9:31 AM Dave Lawrence <tale@d= d.org> wrote:
olafur@cloudflare.com wrot= e:
>> Thus from a privacy point of view clients that do not want to have=
>> their queries logged by servers stand a better chance by using POS= T.

Mark Nottingham writes:
> That seems like a really weak guarantee of privacy.

Delightfully understated, in a "sure you're using that word
'guarantee' sarcastically" kind of way.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--001a113fe37099aef805679be21e-- From nobody Sat Mar 17 06:43:22 2018 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 D3A6A12708C for ; Sat, 17 Mar 2018 06:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Je3B0f1MIStj for ; Sat, 17 Mar 2018 06:43:18 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF7127909 for ; Sat, 17 Mar 2018 06:43:18 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id D037A3A0EB for ; Sat, 17 Mar 2018 09:43:17 -0400 (EDT) Received: by mail-oi0-f49.google.com with SMTP id u73so10889338oie.3 for ; Sat, 17 Mar 2018 06:43:17 -0700 (PDT) X-Gm-Message-State: AElRT7GHJoxK2SmmFpYaAkOw2gJtUr144XFdHuXMdSPhXdieelMF7Pwg F4akflHHougTwI0RVe+WqfTc9WRwIdzLSVEsI0I= X-Google-Smtp-Source: AG47ELsEE+/3NlhhMd1ADZsIpZZU6Vlft1pWNZrA9s5w1WNfAVkD8evxp4GYWZ4ftMVAs4ThNwjt3xaPjBxnMbUOEOU= X-Received: by 10.202.75.4 with SMTP id y4mr3213563oia.17.1521294197532; Sat, 17 Mar 2018 06:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sat, 17 Mar 2018 06:43:17 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sat, 17 Mar 2018 13:43:17 +0000 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: Daniel Stenberg , doh@ietf.org Content-Type: multipart/alternative; boundary="001a113de11a3e319605679be8a8" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:43:21 -0000 --001a113de11a3e319605679be8a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable push #1: anticipate other needs of the client (as mentioned) push #2: its a different way to express additional records if that's a desirable thing (e.g. ttl granularity) On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson wrote: > What is the usage case to Server push of DNS answers ? > > Olafur > > > On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg wrote: > >> On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: >> >> Post MUST be supported Get MAY be supported, when GET is not supported >>> the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). >>> >> >> You didn't say this, and it is a side-note about methods, but I still >> wanted to just mention that when imlementing support for HTTP/2 server p= ush >> for DOH, you want the server to send that as a GET so that the query str= ing >> tells the client about the request it also sends the response to... >> >> -- >> >> / daniel.haxx.se > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --001a113de11a3e319605679be8a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
push #1: anticipate other needs of the client (as men= tioned)

push #2: its a different way to express ad= ditional records if that's a desirable thing (e.g. ttl granularity)



On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0m= undsson <olafur@cloudflare.com> wrote:
What is the usage case to Server push of = DNS answers ?=C2=A0

Olafur


On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <daniel= @haxx.se> wrote:
On= Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote:

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...

--

=C2=A0/ daniel.haxx.se


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


--001a113de11a3e319605679be8a8-- From nobody Sat Mar 17 06:47:22 2018 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 D3AE6126DCA for ; Sat, 17 Mar 2018 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NYmkyvkbNp6O for ; Sat, 17 Mar 2018 06:47:18 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id CAE5E12708C for ; Sat, 17 Mar 2018 06:47:18 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 790CC3A021 for ; Sat, 17 Mar 2018 09:47:18 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id e79so6941592oih.1 for ; Sat, 17 Mar 2018 06:47:18 -0700 (PDT) X-Gm-Message-State: AElRT7GtZmY6uY49pDL5D2dCXbCxKGu8zAIeylQ12TmRHGdgF6j4u+Hy sM49eCjWXrZseREIKg9eMd469RsIXaHh4+7eB8g= X-Google-Smtp-Source: AG47ELteiIxSW66xPXWnTXSYvTfD96+YAdIdLMpQllVj1iia3L6kl3UTL5TMML+ES5SF/prtC1rW8Wp0rZjZpooJAPk= X-Received: by 10.202.6.195 with SMTP id 186mr3152805oig.347.1521294438234; Sat, 17 Mar 2018 06:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sat, 17 Mar 2018 06:47:17 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sat, 17 Mar 2018 13:47:17 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Daniel Stenberg , doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c13f9a097027005679bf66e" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 13:47:21 -0000 --94eb2c13f9a097027005679bf66e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Overall I think the draft does an OK job of describing the merits of get/post (post is more efficient but is not http cache friendly, get is needed for cases like push and is more http cache friendly). If folks think its imperative to have that summary in one place in the document I'm happy to make that change. I would think most clients relying on http caches for performance would use get, but if they have a DNS cache they are populating they would use post. A server can choose not to implement one of these (and "method not allowed" is the right response for that imo), but its limiting what clients can achieve with it. -P On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus wrote: > push #1: anticipate other needs of the client (as mentioned) > > push #2: its a different way to express additional records if that's a > desirable thing (e.g. ttl granularity) > > > > On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson > wrote: > >> What is the usage case to Server push of DNS answers ? >> >> Olafur >> >> >> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg wrote= : >> >>> On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: >>> >>> Post MUST be supported Get MAY be supported, when GET is not supported >>>> the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). >>>> >>> >>> You didn't say this, and it is a side-note about methods, but I still >>> wanted to just mention that when imlementing support for HTTP/2 server = push >>> for DOH, you want the server to send that as a GET so that the query st= ring >>> tells the client about the request it also sends the response to... >>> >>> -- >>> >>> / daniel.haxx.se >> >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> > --94eb2c13f9a097027005679bf66e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Overall I think the draft does an OK job of describin= g the merits of get/post (post is more efficient but is not http cache frie= ndly, get is needed for cases like push and is more http cache friendly). I= f folks think its imperative to have that summary in one place in the docum= ent I'm happy to make that change.

I would= think most clients relying on http caches for performance would use get, b= ut if they have a DNS cache they are populating they would use post. A serv= er can choose not to implement one of these (and "method not allowed&q= uot; is the right response for that imo), but its limiting what clients can= achieve with it.

-P


On Sat, Mar 17, 2018 at 1:4= 3 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
push #1: anticipate othe= r needs of the client (as mentioned)

push #2: its = a different way to express additional records if that's a desirable thi= ng (e.g. ttl granularity)



On= Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@cl= oudflare.com> wrote:
What is the usage case to Ser= ver push of DNS answers ?=C2=A0

Olafur


O= n Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <daniel@haxx.se> wrote:
On Sat, 17 Mar 2018, =C3= =93lafur Gu=C3=B0mundsson wrote:

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...

--

=C2=A0/ daniel.haxx.se


______________________________= _________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh



--94eb2c13f9a097027005679bf66e-- From nobody Sat Mar 17 10:22:34 2018 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 39AAD126C83 for ; Sat, 17 Mar 2018 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, T_RP_MATCHES_RCVD=-0.01, 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 EueoqgcWbeGg for ; Sat, 17 Mar 2018 10:22:30 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 75E2A12025C for ; Sat, 17 Mar 2018 10:22:30 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m83so16099677ioi.8 for ; Sat, 17 Mar 2018 10:22:30 -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 :cc; bh=m80jnhY+FTbGYuapSSJFzVIGGTnF+qfF4wUcN4iJfj8=; b=HzfpiFZr19Vxl9Gdu6hvXHXhI6TLUJeww9fs9IOgBA8KDSwGzs9xS6g7SxpApE/2eR CvT1xP0YJbgo0Eg24eSosvp+u7VuNW00+l17b/YO6r5NKkJ4mN8p0tWTR+gfEM5iAB8f wKqmC36goj+TuT8Ob/iDpCFHi5h0O45W+LwlGtz42m4xXY/0Sr+yewrOPIdBb69ur/oK fAPr8dy8pRp0XaBaXMyKe2pfgb6HdfUIyRL80Mjh3I2kvdhJbl/eQ3WHOG6H4bAiHxhp Xoe5IWvhjmkn6XBEBPmDg9+oxfzr4f6KawbNGK/9ipGrc8RWQKMDjA1tFwFxmA2keKPJ HOSw== 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=m80jnhY+FTbGYuapSSJFzVIGGTnF+qfF4wUcN4iJfj8=; b=jKgOo1PDTVSvLZnibViie0XuWe8kDpRpuIYFuzjOFHDpP91hhlnVPA06tgebG54CSQ cVnMQVnPFvtFrAkzNLcLhPncW+4CpExdpH9fpDVXEHFTGryL3CeabKql0kcPbPwgKzfT G9Dz6/RpknC6ylBOaLVB8ik8LwsgluzUo344z6YsH5fcGFXBHheAwFRsp6nlL0EnyZVU tx7KZPVwOzOfQPR5jSeigTUOxsMMAjBmmEe/36WqsKPpAlh2WH2HK0/K5xkhzPjmUjVF d7/WEzVGRCCafdf+bpNHpuphQBK3cf2pFObd4lAOgzcfyWjWFQbRIUKuSfSL/ceMokw+ th3w== X-Gm-Message-State: AElRT7HT+lmwJYVKB16HXU4CW069R9QLa/ufpRZUixXaUBOjZib//HRL oRxHARyDYUVEVQjmW/totz06yOPHMnDtHaCGSSW2ZA== X-Google-Smtp-Source: AG47ELs9Cunp/fPVLl0BYIA9jcVrq5u4wD8drcuALO5jvqoG6gccqHbo+wTXOejzjBuQyaXwCA8xSWZ/MCGXZ1bJAkQ= X-Received: by 10.107.29.205 with SMTP id d196mr6445806iod.18.1521307349091; Sat, 17 Mar 2018 10:22:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Sat, 17 Mar 2018 10:22:28 -0700 (PDT) In-Reply-To: References: From: Ben Schwartz Date: Sat, 17 Mar 2018 13:22:28 -0400 Message-ID: To: Patrick McManus Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , doh@ietf.org, Daniel Stenberg Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1140a7442f022e05679ef833" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 17:22:33 -0000 --001a1140a7442f022e05679ef833 Content-Type: multipart/alternative; boundary="001a1140a74423923205679ef820" --001a1140a74423923205679ef820 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus wrote: > Overall I think the draft does an OK job of describing the merits of > get/post (post is more efficient but is not http cache friendly, get is > needed for cases like push and is more http cache friendly). If folks thi= nk > its imperative to have that summary in one place in the document I'm happ= y > to make that change. > > I would think most clients relying on http caches for performance would > use get, but if they have a DNS cache they are populating they would use > post. A server can choose not to implement one of these (and "method not > allowed" is the right response for that imo), but its limiting what clien= ts > can achieve with it. > SHOULD clients handle a "method not allowed" by retrying with the other method? > > -P > > > On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus > wrote: > >> push #1: anticipate other needs of the client (as mentioned) >> >> push #2: its a different way to express additional records if that's a >> desirable thing (e.g. ttl granularity) >> >> >> >> On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson < >> olafur@cloudflare.com> wrote: >> >>> What is the usage case to Server push of DNS answers ? >>> >>> Olafur >>> >>> >>> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg >>> wrote: >>> >>>> On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: >>>> >>>> Post MUST be supported Get MAY be supported, when GET is not supported >>>>> the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). >>>>> >>>> >>>> You didn't say this, and it is a side-note about methods, but I still >>>> wanted to just mention that when imlementing support for HTTP/2 server= push >>>> for DOH, you want the server to send that as a GET so that the query s= tring >>>> tells the client about the request it also sends the response to... >>>> >>>> -- >>>> >>>> / daniel.haxx.se >>> >>> >>> >>> _______________________________________________ >>> 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 > > --001a1140a74423923205679ef820 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Mar 17, 2018 at 9:47 AM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
= Overall I think the draft does an OK job of describing the merits of get/po= st (post is more efficient but is not http cache friendly, get is needed fo= r cases like push and is more http cache friendly). If folks think its impe= rative to have that summary in one place in the document I'm happy to m= ake that change.

I would think most clients re= lying on http caches for performance would use get, but if they have a DNS = cache they are populating they would use post. A server can choose not to i= mplement one of these (and "method not allowed" is the right resp= onse for that imo), but its limiting what clients can achieve with it.

SHOULD clients handle a "metho= d not allowed" by retrying with the other method?
=C2=A0

-P


<= div class=3D"gmail_quote">On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus = <pmcmanus@mozilla.com> wrote:
push #1: anticipate other needs of the client = (as mentioned)

push #2: its a different way to exp= ress additional records if that's a desirable thing (e.g. ttl granulari= ty)


On= Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@cl= oudflare.com> wrote:
What is= the usage case to Server push of DNS answers ?=C2=A0

Ol= afur


On Sat, Ma= r 17, 2018 at 12:40 PM, Daniel Stenberg <daniel@haxx.se> wrote:=
On Sat, 17 Mar 2018, =C3=93lafur G= u=C3=B0mundsson wrote:

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...

--

=C2=A0/ daniel.haxx.se


____________________________________= ___________
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


--001a1140a74423923205679ef820-- --001a1140a7442f022e05679ef833 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAvyXZOfHPs8CrP2dNJOasM fbgrD1AhmDIh7vi5eIEkQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMTcxNzIyMjlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAhEBzt43TDrL32YTLDAq15K0PbWil55KFPYn/PbXk ItGBtjxvxBTGAdmfv40x3lq+3l6coKq5m71KslJaK4tM/Ihy00T/YDLuPUddKZtq+s1z0+kCR1y0 nLvDNB9nDXwqLwU99u6pAG5VY4YnliRACo8jXUrBJurXzC7sdpoTkBf3fCncYDqSMM3RJaYrG5x0 bf5JvknIEHVEesdHZb6t95P3RZ6vVJqXWK42Mq8ocf3QeVQTh2c+dvlQEOVBPLVU5twWJ3oo9GRD tqza+B/jexXJIwgtIIdJI2n0eRz97Mf9+MfhNDJU6zl+ejWuqlA+l9JM7kedJQ6i9moO7WpaNA== --001a1140a7442f022e05679ef833-- From nobody Sat Mar 17 10:42:43 2018 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 D35E212711E for ; Sat, 17 Mar 2018 10:42:41 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 CjgWZ8tCU7te for ; Sat, 17 Mar 2018 10:42:39 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 99F8712025C for ; Sat, 17 Mar 2018 10:42:39 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p66so1196986oia.12 for ; Sat, 17 Mar 2018 10:42:39 -0700 (PDT) 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=8SpCnJRqquV0fqVphvl3QCP+ePbn4nyS2t9GWS2kMXA=; b=pqe5axlmgWqHVOIDQVFs0w0P5UxpBXDysMa+b1sJ2lHyThWGgi3v1Ed4RkHh90vrnq D8TJ5dISkBzh4sChgd2Hx5bwgjXsWVWZlj4/sRyrObWppjkJXvPOn1CdM//mOpzAxWrO qVjgNsNBZo9Wb64ALHzCVrsJJSqBK1wGYbVQ16q9MA4Gf7BHqcp9yI+f0orH/hMSRjdO hunSEaOHcIjduuIjggJQrX5g14Da3Y/ak/YyrEQtEjJw+JocbqUdmUCAO8zN+PrdVWsv FyV0YtDAdPN88t3DzfJl/iFeE/B0UCHv8oJuTLQhtvGXTvWFYXQPsSQfUukWF7hUg0UY vKMA== 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=8SpCnJRqquV0fqVphvl3QCP+ePbn4nyS2t9GWS2kMXA=; b=tBuMBIgKDc7JO8Gu2ssm/DKYk2nm0WU3d61agkaDVjpvR1ATxUmGydpx5Guxq+gBbk DJgKpg4lKBUSTLjgL5JlbEi8zCPRD02hwMhtaDKT1v8yz8fd6Urc5fi81Pax5o3XQQn6 Zy0fJ/dGiiGW8nOpe9Yd2G+MgMI9eP/KtbayBNfILhiP0d8M2J6N+fdDeqVPr/k4l86t tnEUOZD1T8kLvkdjj2xY9sZ7LnV5B6jNa1KM1XBp81Jjk1hzKjFj5jnzK0EE+rkIuLZX RM7vthJcEUGoTpmA6oAQsehUU2Jtx3uEGkAMpgDsQRW+nwgY7EErSAyDQ2Jyhr32eaVm AJSg== X-Gm-Message-State: AElRT7EbmHTxQ6QRt3rYck7we3PRFR8uzHl4kscL2k8jpFJXqbl/ARbJ 19DcooGvJlWQDT83SmpjXjNoX0QYv9h2BAvSESjcIA== X-Google-Smtp-Source: AG47ELvT6liAyoQQ9TXdlGrW0pAePX+Xpi7VlvCfAekLd6vqBP1XapdWFWE5JZsqGOLqsZZHZSwQqDEo/OzTh+gA41Y= X-Received: by 10.202.63.132 with SMTP id m126mr3856315oia.45.1521308558433; Sat, 17 Mar 2018 10:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Sat, 17 Mar 2018 10:42:08 -0700 (PDT) From: Ted Hardie Date: Sat, 17 Mar 2018 10:42:08 -0700 Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="001a113d660a38237205679f4015" Archived-At: Subject: [Doh] A question on the mix of DNS and HTTP semantics 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: Sat, 17 Mar 2018 17:42:42 -0000 --001a113d660a38237205679f4015 Content-Type: text/plain; charset="UTF-8" Howdy, First, my apologies that this may be incoherent; I'm somewhat jet-lagged and the issue that I'm trying to raise has been slippery to discuss in the side conversations I've tried to have today. Underneath that lack clarity, though, is what I believe is a somewhat structural question. Reading the doc on the way over, I found myself tumbling down a couple of rat-holes on the interaction between the HTTP protocol mechanics and their mapping to DNS semantics. When I started talking to other folks about those, a couple more DNS semantics mapping to HTTP semantics issues came up. Trying to work those through, I found myself grappling with this: The described approach is more than a tunnel over HTTP. It establishes default media formatting types for requests and responses but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases. In addition to this media type negotiation, it aligns itself with HTTP features such as caching, proxying, and compression. The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to the DNS. What concerns me is that the appropriate methods for mapping between HTTP and DNS semantics may not be quite the same for those two use cases. In particular, the HTTP semantics for redirection (e.g. HTTP response 307 or 308) and client error (e.g. HTTP response 403 or 451) may be difficult to map back into DNS errors when the target is a traditional DNS client. To take an example from the redirection side, if a client has configured an ordered list of recursive resolvers and gets a redirect from the DOH server, it could theoretically either follow the redirect or move down its own list (treating the redirect as an offered member for the list, but sorted below the current list). The behavior for that might be influenced by the body included in the response. A 307 with a response body containing the UDP wire format DNS response for SRVFAIL, for example, might cause the DNS client to move down the ordered list, where a 307 with no response body might be handled entirely within HTTP's semantics, prior to returning a message to the DNS client code. (Note that the choice between these two may result in different privacy considerations, especially if resolvers later in the list do not use DOH or DNS over TLS). Similarly, it was not clear to me whether a response like 451 could contain a UDP wireformat body and, if so, what it would be. If it contains no body, the DNS implementation might continue attempting to query for the information. If it contains a REFUSED RCODE, in contrast, it would see a policy-based error. The document simply provides very little guidance on how to handle cases like these. There appear to be two extreme positions possible: 1) DOH servers should, as much as possible, encode all the semantics in UDP wireformat DNS messages and return appropriate messages when using HTTP's redirection, authorization, or caching semantics. Clients can then act on the DNS messages within a structure that may include other recursive resolvers. 2) DOH clients should use HTTP semantics as faithfully as possible, returning UDP wireformat DNS messages only after the full HTTP protocol mechanics have been worked out and synthesizing DNS messages (such as SRVFAIL) when these are implied by the HTTP exchange. The document leans more toward 2 than 1, but does not do so in a way that makes it mandatory; you would appear to be able to write a conformant server or client using either theory (or much in between). I suspect that leaning is due to the web application use case's presumed popularity compared to the traditional DNS client use case, but I could be wrong. Whatever the cause, I believe that additional clarity here is important and that some text specifically on the interplay in semantics would be useful. I believe that this is particularly important for the traditional DNS client use case, as there is an existing state machine there which will be also be used with DNS over TLS, DNS over TCP, and DNS over UDP. The more consistency those clients have in the treatment of underlying transports, the better life will be for them. Again, my apologies if this is not clear, but I wanted to write something before the meeting. regards, Ted --001a113d660a38237205679f4015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
H= owdy,

First, my apologies that this may be incoherent; I'm somew= hat jet-lagged and the issue that I'm trying to raise has been slippery= to discuss in the side conversations I've tried to have today.=C2=A0 U= nderneath that lack clarity, though, is what I believe is a somewhat struct= ural question.

Reading the doc on the way over, I found myself tumbl= ing down a couple of rat-holes on the interaction between the HTTP protocol= mechanics and their mapping to DNS semantics.=C2=A0 When I started talking= to other folks about those, a couple more DNS semantics mapping to HTTP se= mantics issues came up.=C2=A0 Trying to work those through, I found myself = grappling with this:

=C2=A0 =C2=A0The described approach is more than a= tunnel over HTTP.=C2=A0 It
=C2=A0 =C2=A0establishes default media forma= tting types for requests and responses
=C2=A0 =C2=A0but uses normal HTTP= content negotiation mechanisms for selecting
=C2=A0 =C2=A0alternatives = that endpoints may prefer in anticipation of serving new
=C2=A0 =C2=A0us= e cases.=C2=A0 In addition to this media type negotiation, it aligns
=C2= =A0 =C2=A0itself with HTTP features such as caching, proxying, and compress= ion.

=C2=A0 =C2=A0The integration wit= h HTTP provides a transport suitable for both
=C2=A0 =C2=A0traditional D= NS clients and native web applications seeking access to
=C2=A0 =C2=A0th= e DNS.

What concerns me is that the appropriate methods for m= apping between HTTP and DNS semantics may not be quite the same for those t= wo use cases.=C2=A0 In particular, the HTTP semantics for redirection (e.g.= HTTP response 307 or 308) and client error (e.g. HTTP response 403 or 451)= may be difficult to map back into DNS errors when the target is a traditio= nal DNS client.

To take an example fro= m the redirection side, if a client has configured an ordered list of recur= sive resolvers and gets a redirect from the DOH server, it could theoretica= lly either follow the redirect or move down its own list (treating the redi= rect as an offered member for the list, but sorted below the current list).= =C2=A0 The behavior for that might be influenced by the body included in th= e response. A 307 with a response body containing the UDP wire format DNS r= esponse for SRVFAIL, for example, might cause the DNS client to move down t= he ordered list, where a 307 with no response body might be handled entirel= y within HTTP's semantics, prior to returning a message to the DNS clie= nt code.=C2=A0 (Note that the choice between these two may result in differ= ent privacy considerations, especially if resolvers later in the list do no= t use DOH or DNS over TLS).

Similarly,= it was not clear to me whether a response like 451 could contain a UDP wir= eformat body and, if so, what it would be.=C2=A0 If it contains no body, th= e DNS implementation might continue attempting to query for the information= .=C2=A0 If it contains a REFUSED RCODE, in contrast, it would see a policy-= based error.=C2=A0 The document simply provides very little guidance on how= to handle cases like these.

There app= ear to be two extreme positions possible:=C2=A0

1) DOH servers shou= ld, as much as possible, encode all the semantics in UDP wireformat DNS mes= sages and return appropriate messages when using HTTP's redirection, au= thorization, or caching semantics.=C2=A0 Clients can then act on the DNS me= ssages within a structure that may include other recursive resolvers.
2) DOH clients should use HTTP semantics as= faithfully as possible, returning UDP wireformat DNS messages only after t= he full HTTP protocol mechanics have been worked out and synthesizing DNS m= essages (such as SRVFAIL) when these are implied by the HTTP exchange.
<= br>
The document leans more toward 2 than 1, b= ut does not do so in a way that makes it mandatory; you would appear to be = able to write a conformant server or client using either theory (or much in= between).=C2=A0 I suspect that leaning is due to the web application use c= ase's presumed popularity compared to the traditional DNS client use ca= se, but I could be wrong.

Whatever the cause, I believe that additio= nal clarity here is important and that some text specifically on the interp= lay in semantics would be useful.=C2=A0 I believe that this is particularly= important for the traditional DNS client use case, as there is an existing= state machine there which will be also be used with DNS over TLS, DNS over= TCP, and DNS over UDP.=C2=A0 The more consistency those clients have in th= e treatment of underlying transports, the better life will be for them.
=
Again, my apologies if this is not clear,= but I wanted to write something before the meeting.

regards,

Ted
=




--001a113d660a38237205679f4015-- From nobody Sat Mar 17 11:30:26 2018 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 10C9E1273E2 for ; Sat, 17 Mar 2018 11:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 Gyy_c1hpME4t for ; Sat, 17 Mar 2018 11:30:22 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id A22341271DF for ; Sat, 17 Mar 2018 11:30:22 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 9845B3A0ED for ; Sat, 17 Mar 2018 14:30:19 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id q71so978515oic.6 for ; Sat, 17 Mar 2018 11:30:19 -0700 (PDT) X-Gm-Message-State: AElRT7FB/NPrgGVs0kChv7w8dcH7LB7H5YIsltCL0xcNfuYyuJkZoWkt wrf3VJp8tbnDAphdYS/4IYC1XtD111wgDw7O1k8= X-Google-Smtp-Source: AG47ELuKSvJ5x3J3HJ2wbkocUvUEkahxS01aTXY7HPuEuKfHc9ZmdoDzQ0atAgNvf9x9vIl6GHPUJlN6S7c7AEhVn2k= X-Received: by 10.202.6.195 with SMTP id 186mr3595304oig.347.1521311419275; Sat, 17 Mar 2018 11:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sat, 17 Mar 2018 11:30:18 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sat, 17 Mar 2018 18:30:18 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ben Schwartz Cc: Patrick McManus , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , doh@ietf.org, Daniel Stenberg Content-Type: multipart/alternative; boundary="94eb2c13f9a0bd21ab05679fea9c" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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: Sat, 17 Mar 2018 18:30:25 -0000 --94eb2c13f9a0bd21ab05679fea9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable imo normative SHOULD is a tad too strong. One thing to note is that the 405 ought to include an allow response header indicating what methods it can process.. so your fallback ought to be in that set, at a minimum. But its also possible that the other method might not meet your requirements.. e.g. a GET is 405'd and you require an HTTP cache to meet performance requirements - you might not use doh, or use a different server, or whatever instead of SHOULD retry. may is really ok imo. On Sat, Mar 17, 2018 at 5:22 PM, Ben Schwartz wrote: > On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus > wrote: > >> Overall I think the draft does an OK job of describing the merits of >> get/post (post is more efficient but is not http cache friendly, get is >> needed for cases like push and is more http cache friendly). If folks th= ink >> its imperative to have that summary in one place in the document I'm hap= py >> to make that change. >> >> I would think most clients relying on http caches for performance would >> use get, but if they have a DNS cache they are populating they would use >> post. A server can choose not to implement one of these (and "method not >> allowed" is the right response for that imo), but its limiting what clie= nts >> can achieve with it. >> > > SHOULD clients handle a "method not allowed" by retrying with the other > method? > > >> >> -P >> >> >> On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus >> wrote: >> >>> push #1: anticipate other needs of the client (as mentioned) >>> >>> push #2: its a different way to express additional records if that's a >>> desirable thing (e.g. ttl granularity) >>> >>> >>> >>> On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson < >>> olafur@cloudflare.com> wrote: >>> >>>> What is the usage case to Server push of DNS answers ? >>>> >>>> Olafur >>>> >>>> >>>> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg >>>> wrote: >>>> >>>>> On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: >>>>> >>>>> Post MUST be supported Get MAY be supported, when GET is not supporte= d >>>>>> the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5). >>>>>> >>>>> >>>>> You didn't say this, and it is a side-note about methods, but I still >>>>> wanted to just mention that when imlementing support for HTTP/2 serve= r push >>>>> for DOH, you want the server to send that as a GET so that the query = string >>>>> tells the client about the request it also sends the response to... >>>>> >>>>> -- >>>>> >>>>> / daniel.haxx.se >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --94eb2c13f9a0bd21ab05679fea9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
imo normative SHOULD is a tad too strong.
<= br>
One thing to note is that the 405 ought to include an allow r= esponse header indicating what methods it can process.. so your fallback ou= ght to be in that set, at a minimum.

But its also = possible that the other method might not meet your requirements.. e.g. a GE= T is 405'd and you require an HTTP cache to meet performance requiremen= ts - you might not use doh, or use a different server, or whatever instead = of SHOULD retry.

may is really ok imo.



On Sat, Mar 17, 2018 at 5:22 PM, Ben Schwartz <bemasc@goo= gle.com> wrote:
On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus <pmcmanus@mozilla.co= m> wrote:
=
Overall I think the draft does an OK job of describing the merits of g= et/post (post is more efficient but is not http cache friendly, get is need= ed for cases like push and is more http cache friendly). If folks think its= imperative to have that summary in one place in the document I'm happy= to make that change.

I would think most clien= ts relying on http caches for performance would use get, but if they have a= DNS cache they are populating they would use post. A server can choose not= to implement one of these (and "method not allowed" is the right= response for that imo), but its limiting what clients can achieve with it.=

SHOULD clients handle a= "method not allowed" by retrying with the other method?
=C2=A0

-P


On Sat, Mar 17, 2018 at 1:43 PM,= Patrick McManus <pmcmanus@mozilla.com> wrote:
push #1: anticipate other nee= ds of the client (as mentioned)

push #2: its a dif= ferent way to express additional records if that's a desirable thing (e= .g. ttl granularity)



On Sat, Mar 17, 2018 at 1:16 PM, =C3=93= lafur Gu=C3=B0mundsson <olafur@cloudflare.com> wrote:
What is the usage case = to Server push of DNS answers ?=C2=A0

Olafur
<= br>

On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <daniel@ha= xx.se> wrote:
On Sat,= 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote:

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...

--

=C2=A0/ daniel.haxx.se


____________________________________= ___________
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



--94eb2c13f9a0bd21ab05679fea9c-- From nobody Sun Mar 18 02:22:48 2018 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 BBE46127241 for ; Sun, 18 Mar 2018 02:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 POGDxFgOr7BW for ; Sun, 18 Mar 2018 02:22:44 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 9423C1200FC for ; Sun, 18 Mar 2018 02:22:44 -0700 (PDT) Received: from mail-ot0-f179.google.com (mail-ot0-f179.google.com [74.125.82.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id 7ED003A021 for ; Sun, 18 Mar 2018 05:22:39 -0400 (EDT) Received: by mail-ot0-f179.google.com with SMTP id y11-v6so14521314otg.0 for ; Sun, 18 Mar 2018 02:22:39 -0700 (PDT) X-Gm-Message-State: AElRT7GyXOp+kc56wvu4brMGuFEZVbTNM3sPK4v/2Bkc4zfc2kH2+kaI j7yKTyVDaa2niUKh79gMe9zdWCkTuLfh0VZeTRQ= X-Google-Smtp-Source: AG47ELt//Sbc66Ht1q+nYpie/feCmdwEFPJLryGtLy5up7OTvRs6MqO1l8ZKkxKePp6Gi7Z66A4rm9NOGUWW46kSyGI= X-Received: by 2002:a9d:213c:: with SMTP id i57-v6mr3178402otb.85.1521364959194; Sun, 18 Mar 2018 02:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 02:22:38 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sun, 18 Mar 2018 09:22:38 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000f776f00567ac61f8" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 09:22:47 -0000 --000000000000f776f00567ac61f8 Content-Type: text/plain; charset="UTF-8" Hi Ted, thanks for writing this down. I think I understand it a bit better now. I think the most relevant point is that DoH is the use of HTTP as a substrate. As a user of HTTP RFC7231 is very relevant (HTTP status codes) On Sat, Mar 17, 2018 at 5:42 PM, Ted Hardie wrote: > In particular, the HTTP semantics for redirection (e.g. HTTP response > 307 or 308) and client error (e.g. HTTP response 403 or 451) may be > difficult to map back into DNS errors when the target is a traditional DNS > client. > > 7231 defines 2xx as success. If your code is not 2xx then your DoH request did not succeed and you can feel confident in saying that you do not have a dns response to the dns request that was made in the http request. Conversely, a 2xx response needs to carry a DNS reply to your DNS request. (now that can be a DNS failure - nxdomain, etc, but the 2xx at the HTTP level is saying a valid DNS response to your request is contained therein.. i.e. DoH has succeeded). non 2xx levels of response do not carry the answer to the DNS query. The message in those responses is basically just FYI. HTTP allows you to put any media type you want in there, so I'm not going to tell you you cannot put DNS information in the body of a 404 if you think that's good FYI, but I am going to say the body of a 4xx is not the dns answer to the DoH request that generated it. A client may or may not be able to go further based on the response code. e.g. a 3xx code can obviously be taken further with another request, as can 401, or maybe even 405. There is a general expectation that clients that can act on http response codes other than 2xx do so, but its their decision. So I would say all HTTP clients, including DoH clients but not in any special way, are expected to follow redirects within the scope of how the particular redirect is defined, and the message body of the [345]xx is not very interesting. As noted above, if you don't end this process with a 2xx you don't have a DNS response to the DNS query of the original request - the transport has failed. I would say you should map that into the traditional DNS in the same fashion as any other transport failure.. e.g. UDP timing out, or TCP generating RST, or TLS failing verification. An HTTP non-success isn't going to give you rich DNS information.. if the failure is at the DNS level and not the DOH level, then the DNS failure can be carried in a 2xx HTTP response. I hope all that helps. I hope that's what things like BCP56bis are aimed at - we don't want to write down all the HTTP rules for every application that uses HTTP as a substrate each time. And of course I would expect that new DoH clients would reuse old HTTP stacks where possible as they should already encapsulate these rules. > To take an example from the redirection side, if a client has configured > an ordered list of recursive resolvers and gets a redirect from the DOH > server, it could theoretically either follow the redirect or move down its > own list (treating the redirect as an offered member for the list, but > sorted below the current list). The behavior for that might be influenced > by the body included in the response. A 307 with a response body containing > the UDP wire format DNS response for SRVFAIL, for example, might cause the > DNS client to move down the ordered list, where a 307 with no response body > might be handled entirely within HTTP's semantics, prior to returning a > message to the DNS client code. (Note that the choice between these two > may result in different privacy considerations, especially if resolvers > later in the list do not use DOH or DNS over TLS). > The udp body in the 307 that you posit is not the dns response to the original dns question it is just FYI and doesn't have a programmatic interpretation in the way the 307 and the Location response header do. The expectation is that if you would like to complete that original request you should make a new request to the redirected location. Aborting or pushing a new approach on top of the stack is fine, but I feel like you feel you're getting more information from that 307 than you really are. All you know is its in progress and how to continue. > Similarly, it was not clear to me whether a response like 451 could > contain a UDP wireformat body and, if so, what it would be. If it contains > no body, the DNS implementation might continue attempting to query for the > information.. If it contains a REFUSED RCODE, in contrast, it would see a > policy-based error. The document simply provides very little guidance on > how to handle cases like these. > > Similarly to above, 451 is defined by 7225. DoH seeks to _not_ restate all the existing HTTP definitions, it just seeks to use them. If DoH was doing something inconsistent with 7225 that would imo probably be a doh bug. In the case of 451 In this case 7225 defines the response body as a human readable description of the censorship - so I don't think wireformat would be a good choice. (7225 doesn't make an exception for non human clients, of which there have always been many). It is interesting to note how the code itself is indeed actionable - the DoH client might choose to repeat the same query of a VPN or Tor knowing this information. > There appear to be two extreme positions possible: > > 1) DOH servers should, as much as possible, encode all the semantics in > UDP wireformat DNS messages and return appropriate messages when using > HTTP's redirection, authorization, or caching semantics. Clients can then > act on the DNS messages within a structure that may include other recursive > resolvers. > I hope this message has shed some light on this. wireformat in a non 2xx response, while legal, is not the response to the dns query in the http request. I would say its probably not a good idea either, but ymmv. > 2) DOH clients should use HTTP semantics as faithfully as possible, > returning UDP wireformat DNS messages only after the full HTTP protocol > mechanics have been worked out and synthesizing DNS messages (such as > SRVFAIL) when these are implied by the HTTP exchange. > > I hope the situation is a bit clearer that this - but yes this is closer. > The document leans more toward 2 than 1, but does not do so in a way that > makes it mandatory; you would appear to be able to write a conformant > server or client using either theory (or much in between). I suspect that > leaning is due to the web application use case's presumed popularity > compared to the traditional DNS client use case, but I could be wrong. > > I think I disagree here. While you can indeed stick wireformat into all kinds of non 2xx responses, I do not believe it means what you thought it meant when you wrote this :) > Whatever the cause, I believe that additional clarity here is important > and that some text specifically on the interplay in semantics would be > useful. > The text you cited in the top of your mail (which I've trimmed here prematurely) was meant to be part of that, but more important the "over HTTP" parts are meant to make it clear that HTTP semantics carry the DNS semantics. I'm certainly happy to add a sentence or two to help make that more clear (suggestions?) but I don't want to start defining/reiterating HTTP semantics in the DoH doc - we've already got lots of documents (i.e. rfc723x.. which are all included normatively by 7230 which doh includes normatively) that do that and its not in doh's charter to mess those things anyhow. > --000000000000f776f00567ac61f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted, thanks for writing this down. I think I under= stand it a bit better now.

I think the most releva= nt point is that DoH is the use of HTTP as a substrate. As a user of HTTP R= FC7231 is very relevant (HTTP status codes)


On Sat, Mar 17, 2018 at 5:4= 2 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
=C2=A0 In particular, the HTTP semantics for redirection= (e.g. HTTP response 307 or 308) and client error (e.g. HTTP response 403 o= r 451) may be difficult to map back into DNS errors when the target is a tr= aditional DNS client.


7231 defines 2xx as success= . If your code is not 2xx then your DoH request did not succeed and you can= feel confident in saying that you do not have a dns response to the dns re= quest that was made in the http request. Conversely, a 2xx response needs t= o carry a DNS reply to your DNS request. (now that can be a DNS failure - n= xdomain, etc, but the 2xx at the HTTP level is saying a valid DNS response = to your request is contained therein.. i.e. DoH has succeeded).
<= br>
non 2xx levels of response do not carry the answer to the DNS= query. The message in those responses is basically just FYI. HTTP allows y= ou to put any media type you want in there, so I'm not going to tell yo= u you cannot put DNS information in the body of a 404 if you think that'= ;s good FYI, but I am going to say the body of a 4xx is not the dns answer = to the DoH request that generated it.

A client= may or may not be able to go further based on the response code. e.g. a 3x= x code can obviously be taken further with another request, as can 401, or = maybe even 405. There is a general expectation that clients that can act on= http response codes other than 2xx do so, but its their decision. So I wou= ld say all HTTP clients, including DoH clients but not in any special way, = are expected to follow redirects within the scope of how the particular red= irect is defined, and the message body of the [345]xx is not very interesti= ng.

As noted above, if you don't end this proc= ess with a 2xx you don't have a DNS response to the DNS query of the or= iginal request - the transport has failed. I would say you should map that = into the traditional DNS in the same fashion as any other transport failure= .. e.g. UDP timing out, or TCP generating RST, or TLS failing verification.= An HTTP non-success isn't going to give you rich DNS information.. if = the failure is at the DNS level and not the DOH level, then the DNS failure= can be carried in a 2xx HTTP response.

I hope all= that helps. I hope that's what things like BCP56bis are aimed at - we = don't want to write down all the HTTP rules for every application that = uses HTTP as a substrate each time. And of course I would expect that new D= oH clients would reuse old HTTP stacks where possible as they should alread= y encapsulate these rules.
=C2=A0
To take an example from the redirecti= on side, if a client has configured an ordered list of recursive resolvers = and gets a redirect from the DOH server, it could theoretically either foll= ow the redirect or move down its own list (treating the redirect as an offe= red member for the list, but sorted below the current list).=C2=A0 The beha= vior for that might be influenced by the body included in the response. A 3= 07 with a response body containing the UDP wire format DNS response for SRV= FAIL, for example, might cause the DNS client to move down the ordered list= , where a 307 with no response body might be handled entirely within HTTP&#= 39;s semantics, prior to returning a message to the DNS client code.=C2=A0 = (Note that the choice between these two may result in different privacy con= siderations, especially if resolvers later in the list do not use DOH or DN= S over TLS).

The udp body in the 307 that you posit is not = the dns response to the original dns question it is just FYI and doesn'= t have a programmatic interpretation in the way the 307 and the Location re= sponse header do. The expectation is that if you would like to complete tha= t original request you should make a new request to the redirected location= . Aborting or pushing a new approach on top of the stack is fine, but I fee= l like you feel you're getting more information from that 307 than you = really are. All you know is its in progress and how to continue.
<= div>
=C2=A0
Similarly, it was not cl= ear to me whether a response like 451 could contain a UDP wireformat body a= nd, if so, what it would be.=C2=A0 If it contains no body, the DNS implemen= tation might continue attempting to query for the information..=C2=A0 If it= contains a REFUSED RCODE, in contrast, it would see a policy-based error.= =C2=A0 The document simply provides very little guidance on how to handle c= ases like these.


Similarly to above, 451 is defined by 7225. = DoH seeks to _not_ restate all the existing HTTP definitions, it just seeks= to use them. If DoH was doing something inconsistent with 7225 that would = imo probably be a doh bug. In the case of 451 In this case 7225 defines the= response body as a human readable description of the censorship - so I don= 't think wireformat would be a good choice. (7225 doesn't make an e= xception for non human clients, of which there have always been many). It i= s interesting to note how the code itself is indeed actionable - the DoH cl= ient might choose to repeat the same query of a VPN or Tor knowing this inf= ormation.

=C2=A0
<= /div>There appear to be two extreme positions possible:=C2= =A0

1) DOH servers should, as much as possible, encode all the sema= ntics in UDP wireformat DNS messages and return appropriate messages when u= sing HTTP's redirection, authorization, or caching semantics.=C2=A0 Cli= ents can then act on the DNS messages within a structure that may include o= ther recursive resolvers.

I hope this message has shed some light on th= is. wireformat in a non 2xx response, while legal, is not the response to t= he dns query in the http request. I would say its probably not a good idea = either, but ymmv.

<= div dir=3D"ltr">

= 2) DOH clients should use HTTP semantics as faithfully as = possible, returning UDP wireformat DNS messages only after the full HTTP pr= otocol mechanics have been worked out and synthesizing DNS messages (such a= s SRVFAIL) when these are implied by the HTTP exchange.


I hope the situat= ion is a bit clearer that this - but yes this is closer.
=C2= =A0
The document leans more to= ward 2 than 1, but does not do so in a way that makes it mandatory; you wou= ld appear to be able to write a conformant server or client using either th= eory (or much in between).=C2=A0 I suspect that leaning is due to the web a= pplication use case's presumed popularity compared to the traditional D= NS client use case, but I could be wrong.

<= /div>
I think I disagree here. While you can indeed stick = wireformat into all kinds of non 2xx responses, I do not believe it means w= hat you thought it meant when you wrote this :)

=C2=A0
Whatever the cause, I believe that additional clarity he= re is important and that some text specifically on the interplay in semanti= cs would be useful.=C2=A0
=
The text you cited in the top of your mail (which I've t= rimmed here prematurely) was meant to be part of that, but more important t= he "over HTTP" parts are meant to make it clear that HTTP semanti= cs carry the DNS semantics.

I'm certainly hap= py to add a sentence or two to help make that more clear (suggestions?) but= I don't want to start defining/reiterating HTTP semantics in the DoH d= oc - we've already got lots of documents (i.e. rfc723x.. which are all = included normatively by 7230 which doh includes normatively) that do that a= nd its not in doh's charter to mess those things anyhow.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

--000000000000f776f00567ac61f8-- From nobody Sun Mar 18 03:09:51 2018 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 54D1012741D for ; Sun, 18 Mar 2018 03:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 SgojnK-rF8TE for ; Sun, 18 Mar 2018 03:09:46 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C596A1200A0 for ; Sun, 18 Mar 2018 03:09:45 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id y20-v6so6838001itc.5 for ; Sun, 18 Mar 2018 03:09:45 -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 :cc; bh=Y5h5jiCAJ+bj7EmKviTBaH60Ld3rJTr1HmTSXFBam+k=; b=C6IgO2bnQgj8gfwulhaH3I8rMstHZhA4FWML8sMC+/2J2dhuF7iwqYwlcrnubP30ie kfrnezA+P8k2CSsAygshqoJytOJASCRccLsefjmdUsv5/u/VvE2XdnwY/XG2VL7KvxBS 3iNiC/t/K/n2gWIx3IUvEihvVK9Zj3SBmYiRAo2y0u1f5UvyFcyf8GrKXMpvcVIOYj+3 RT6y//ysBqyYpBltnAWHJvB3LnfB4IbWyh4A7vl39m+kAb0TFSQrYqhKxqFql0MM4imk uRs45zcRt9OM31b6vTFL8sGCMNJusmvKiKtue1U5HgtiBCJQUPhc5U8+mH0e3bmAdjI1 /0+Q== 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=Y5h5jiCAJ+bj7EmKviTBaH60Ld3rJTr1HmTSXFBam+k=; b=a13uSX1KxGbWab+ueWKbyjkAylLErTiAfTCtjkQWcQJPzlF6XlqHDYZLPoMduTK9U9 ChqzlSB+a0PGu6U4u4GjIPpDhnEv4PUIkAXnUY7fvT+q1RIkPoW0jCniKGjoSn1Z0krC rN+VvgYGbtZIUfJvU0HaSAqOMdNh+ChY4iViz77aLZ1i4EAcNLHJHLs0CBpX/7ctDFas VxPe1AESl/cPKrWDH1GoZqvMfLlHOa0TBciFHc1hw3LO0BVstL1cSN/z930OQdqUwN7v RMrlJqB/dl3cI2a4RtUQAGpYl9mclKucySjSLRI/jHJDsrDo6wni6cuka2q1vG5zrw6q +jow== X-Gm-Message-State: AElRT7FoBWIy31nnk1h2jDHcpYIkMfUWQnaL4YgBv4kkpA9DwGKOY0ou 22hDzVDHw9Cwk/iTQIbZUSf8ge5tFMM3BhSkpBSvPQ== X-Google-Smtp-Source: AG47ELuPF/+MIrPx/Qqtr8XGDhjrWRS7AvVodgVnlr/qWK2fH+qkTLcX8NjZzN8C+qRvrisHBMiPt0Ftr5hkE9ChwXs= X-Received: by 2002:a24:d803:: with SMTP id b3-v6mr8703158itg.7.1521367784609; Sun, 18 Mar 2018 03:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Sun, 18 Mar 2018 03:09:44 -0700 (PDT) In-Reply-To: References: From: Ben Schwartz Date: Sun, 18 Mar 2018 06:09:44 -0400 Message-ID: To: Patrick McManus Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , doh@ietf.org, Daniel Stenberg Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006aedb40567ad0a2a" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 18 Mar 2018 10:09:48 -0000 --0000000000006aedb40567ad0a2a Content-Type: multipart/alternative; boundary="0000000000006077bb0567ad0a04" --0000000000006077bb0567ad0a04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So does that mean that a DOH server and client that both comply with all SHOULD-strength requirements still may not be able to exchange any DNS data? That seems like a weaker guarantee of compatibility than is typical at the IETF. If following all the SHOULD-level recommendations is not sufficient to ensure compatibility, then as an implementor I would appreciate some clear additional guidance on what I have to do to make my client compatible with any compliant DOH server (and vice versa as a server implementor). On Sat, Mar 17, 2018 at 2:30 PM, Patrick McManus wrote: > imo normative SHOULD is a tad too strong. > > One thing to note is that the 405 ought to include an allow response > header indicating what methods it can process.. so your fallback ought to > be in that set, at a minimum. > > But its also possible that the other method might not meet your > requirements.. e.g. a GET is 405'd and you require an HTTP cache to meet > performance requirements - you might not use doh, or use a different > server, or whatever instead of SHOULD retry. > > may is really ok imo. > > > > On Sat, Mar 17, 2018 at 5:22 PM, Ben Schwartz wrote: > >> On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus >> wrote: >> >>> Overall I think the draft does an OK job of describing the merits of >>> get/post (post is more efficient but is not http cache friendly, get is >>> needed for cases like push and is more http cache friendly). If folks t= hink >>> its imperative to have that summary in one place in the document I'm ha= ppy >>> to make that change. >>> >>> I would think most clients relying on http caches for performance would >>> use get, but if they have a DNS cache they are populating they would us= e >>> post. A server can choose not to implement one of these (and "method no= t >>> allowed" is the right response for that imo), but its limiting what cli= ents >>> can achieve with it. >>> >> >> SHOULD clients handle a "method not allowed" by retrying with the other >> method? >> >> >>> >>> -P >>> >>> >>> On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus >>> wrote: >>> >>>> push #1: anticipate other needs of the client (as mentioned) >>>> >>>> push #2: its a different way to express additional records if that's a >>>> desirable thing (e.g. ttl granularity) >>>> >>>> >>>> >>>> On Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson < >>>> olafur@cloudflare.com> wrote: >>>> >>>>> What is the usage case to Server push of DNS answers ? >>>>> >>>>> Olafur >>>>> >>>>> >>>>> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg >>>>> wrote: >>>>> >>>>>> On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote: >>>>>> >>>>>> Post MUST be supported Get MAY be supported, when GET is not >>>>>>> supported the error code retuned should be 405 (HTTP RFC 7321, sect= ion >>>>>>> 6.5.5). >>>>>>> >>>>>> >>>>>> You didn't say this, and it is a side-note about methods, but I stil= l >>>>>> wanted to just mention that when imlementing support for HTTP/2 serv= er push >>>>>> for DOH, you want the server to send that as a GET so that the query= string >>>>>> tells the client about the request it also sends the response to... >>>>>> >>>>>> -- >>>>>> >>>>>> / daniel.haxx.se >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> > --0000000000006077bb0567ad0a04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So does that mean that a DOH server and client that both c= omply with all SHOULD-strength requirements still may not be able to exchan= ge any DNS data?=C2=A0 That seems like a weaker guarantee of compatibility = than is typical at the IETF.

If following all the SHOULD= -level recommendations is not sufficient to ensure compatibility, then as a= n implementor I would appreciate some clear additional guidance on what I h= ave to do to make my client compatible with any compliant DOH server (and v= ice versa as a server implementor).
<= br>
On Sat, Mar 17, 2018 at 2:30 PM, Patrick McMa= nus <pmcmanus@mozilla.com> wrote:
imo normative SHOULD is a tad too strong.<= /div>

One thing to note is that the 405 ought to include= an allow response header indicating what methods it can process.. so your = fallback ought to be in that set, at a minimum.

Bu= t its also possible that the other method might not meet your requirements.= . e.g. a GET is 405'd and you require an HTTP cache to meet performance= requirements - you might not use doh, or use a different server, or whatev= er instead of SHOULD retry.

may is really ok imo.<= br>



On Sat,= Mar 17, 2018 at 5:22 PM, Ben Schwartz <bemasc@google.com> w= rote:
On Sat, Mar 17, 2018 at 9:47 AM, = Patrick McManus <pmcmanus@mozilla.com> wrote:
Overall I think the draft does= an OK job of describing the merits of get/post (post is more efficient but= is not http cache friendly, get is needed for cases like push and is more = http cache friendly). If folks think its imperative to have that summary in= one place in the document I'm happy to make that change.

I would think most clients relying on http caches for perfo= rmance would use get, but if they have a DNS cache they are populating they= would use post. A server can choose not to implement one of these (and &qu= ot;method not allowed" is the right response for that imo), but its li= miting what clients can achieve with it.

<= /div>
SHOULD clients handle a "method not allowed" by = retrying with the other method?
=C2=A0

-P

On Sat, Mar 17,= 2018 at 1:43 PM, Patrick McManus <pmcmanus@mozilla.com> = wrote:
push #1: ant= icipate other needs of the client (as mentioned)

p= ush #2: its a different way to express additional records if that's a d= esirable thing (e.g. ttl granularity)



O= n Sat, Mar 17, 2018 at 1:16 PM, =C3=93lafur Gu=C3=B0mundsson <olafur@c= loudflare.com> wrote:
What is the usage case to Server push o= f DNS answers ?=C2=A0

Olafur

<= div class=3D"m_5845101593849560149m_6533794751218422872m_-63615482898149584= 80m_1600421060903506679HOEnZb">

On Sat, Mar 17, 2018 at 12:40 PM,= Daniel Stenberg <daniel@haxx.se> wrote:
On Sat, 17 Mar 2018, =C3=93lafur Gu=C3=B0mundsson wrote= :

Post MUST be supported Get MAY be supported, when GET is not supported the = error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

 You didn't say this, and it is a side-note about methods, but I still w= anted to just mention that when imlementing support for HTTP/2 server push = for DOH, you want the server to send that as a GET so that the query string= tells the client about the request it also sends the response to...
--

=C2=A0/ daniel.haxx.se


____________________________________= ___________
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




--0000000000006077bb0567ad0a04-- --0000000000006aedb40567ad0a2a 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAfkBGWyW+NdWIrKUNdiSa/ 2Qhz0VH9pLvThF9yc/o98jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMTgxMDA5NDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEADAsiJZL5URsam0oj8onFWDcsyiWIO5Y12Z43PSgN VsWN56TSnWK4cLtbcUhy2OylPJMzCmgFJXMWX+i+2Q7n6Aiki7+eMOBmt5ufYtOJggw1aOjH2Nk+ NtoDaML1TZ9+/6KCRT3Z4ZWOCR3pSU2wGbf7ZLN6WWIfsM+Q4i8ogksKbYlHbMYe/CBrNlsSyvgv don/FuQZEJiPNuVNayL/uOFa3Y9Ilw2Cpzih/TGov7VxbvBneBeGIY194SGhhWS5WGRTaSU/dC0a GczYcQAw2/yL7bpbzLko14WUOf/ixjpsmukks054/599Dzjwl1UhfwStXwlAgl2AWgGNkth9rA== --0000000000006aedb40567ad0a2a-- From nobody Sun Mar 18 03:12:00 2018 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 9BA791200A0 for ; Sun, 18 Mar 2018 03:11:59 -0700 (PDT) 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 8i2h9tE92HLW for ; Sun, 18 Mar 2018 03:11:57 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 C26201275F4 for ; Sun, 18 Mar 2018 03:11:43 -0700 (PDT) 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]:38244) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1exVHy-000exR-eF (Exim 4.89_2) (return-path ); Sun, 18 Mar 2018 10:11:42 +0000 Date: Sun, 18 Mar 2018 10:11:41 +0000 From: Tony Finch To: Ted Hardie cc: doh@ietf.org In-Reply-To: Message-ID: References: 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] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 10:11:59 -0000 Yesterday at the IETF 101 Hakathon I was working on a DoH server. I've written up some notes at https://fanf.dreamwidth.org/123507.html for those who might be interested. I was going to send this as a separate thread, but it's basically the same topic as Ted's message, so I'm sending it as a reply. The approach I have taken is basically Ted's option (2). The rest of this message is what I wrote before reading Ted's note... One of the questions I bumped into was what kind of HTTP errors my server should generate. I have had another quick look through the draft but I couldn't see anything particularly addressing this issue. So here are some sketchy suggestions. In the following I say "browser-friendly" to mean `text/html` or `text/plain` or something like that, but definitely not `application/dns-udpwireformat`. If the request is not HEAD/GET/POST, I return 405 Method Not Allowed with a browser-friendly body. For POST requests with an unknown Content-Type, or GET requests with an unknown or missing `ct=` parameter, my server returns 415 Unsupported Media Type with a browser-friendly body. If the `dns=` parameter is missing from a GET request, the best response seems to be a browser-friendly 400 Bad Request. Sam Kington (not an IETFer afaik) suggested 422 Unprocessable Entity, but that implies the request is well-formed which isn't really the case. (My server returns 418 I'm A Teapot for fun.) Bad `base64url` encoding should produce the same response. If the request's Accept: header doesn't allow `application/dns-udpwireformat` then the response should be a browser-friendly 406 Not Acceptable. I think if the request passes these checks, the server knows it has a request in DNS format and a client that wants a response in DNS format, so it can just hand over to its DNS processing code. Regardless of the DNS RCODE in the response, the HTTP status code should be 200 OK. My logic up to this point is to send a browser-friendly response if the client seems to be unprepared to talk to a DoH server. There are some other cases - e.g. HTTP authentication or redirects - which ought to be handled by the HTTP layers before the request processing gets to the DoH logic, so in these cases the response bodies will naturally be browser-friendly. But perhaps it's worth noting them in the draft so that DoH clients should be prepared to handle them gracefully. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Dover, Wight, Portland, Plymouth: Northeast, becoming cyclonic in Portland and Plymouth, 6 to gale 8. Moderate or rough. Occasional snow. Moderate or good, occasionally very poor. From nobody Sun Mar 18 03:19:28 2018 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 18C2C127077 for ; Sun, 18 Mar 2018 03:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 cUzQLD2Y8FoE for ; Sun, 18 Mar 2018 03:19:23 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 990B11200B9 for ; Sun, 18 Mar 2018 03:19:23 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id b136-v6so564702iti.3 for ; Sun, 18 Mar 2018 03:19:23 -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 :cc; bh=AmZ2Pt/DSp3R7z1CKbP8GjnmH5UhLrz5Nf7OQEx3gQc=; b=mJyhbfyMQwmcszZga45BGcqZiPlzrrI2sTHO3WZWqLWUZYt4SmWXJKZba8OLBkUsyJ XqpQLX2AuK1keIDum1kURESgkWd59o9FUDF5o6pNdmz7jXgFPc6mTAjffRZq6w9xCuIX DIE4MHO3tUzTSfGq02/VxsQgUbEZRGmxIShNWFLKFbGjz2R4fHmf2g77wuul1WvcItGd 6J0U+bKN8MCeu3bTfW5dVMSX8Tke2W0hWrmadXAwuJoVsrWottgKIVYCfFxs1P9SxTvS V69ewf4nyLEu+msTRhzQBGrJGpvmnn1FLvy7DF8GhImM1blaGfopv+ywi+ropzsWS3x4 JEiw== 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=AmZ2Pt/DSp3R7z1CKbP8GjnmH5UhLrz5Nf7OQEx3gQc=; b=pSj2E8htKi/akNR/vE+aL2mZFZtyTp66t2aVvMrq6YvCWyMJzZnxpKVmVR9/2EGsmr ire6gmqO/k3btA/+C5+bejjEIcuAw7Fd739wd9OxmY1LobHKONsIFXl25iA8NW1fTLx+ TlmU5jaylpo8WjICm2O8097bRRrKDRM1jHzT5UUTFG9ydmSw1AQAr3LpV0saKjVqQKJ5 IYHT0cx27cSSliQTzIm/8PILF3mna+NPPAR+fIdkOgDANV00f8c0+kWM6GnM0KWnXrq2 57YL8O9tz1t2m4k1AVk1LfP1/KSHen/py8sNoBCqA/NPvHSU6NgjgI5PzB1so8s258G8 Hslg== X-Gm-Message-State: AElRT7EpudA4JiHl2Vpp3k2cYpx8+2DN3HQ7OK0Iqs6OPVugoz0BkQMj GuT0EwZMq/qlTZOuQrvrkTpKxvJeqvrezaqhMrUBnw== X-Google-Smtp-Source: AG47ELsCseb1Mk0xwzR2QF2XjvgZZ68f+sqEr3f4Q+gtuoiqndbUCkKbNMEPSFIRExC7gyLQGHpz3HgGeV9Tl1JSrzA= X-Received: by 2002:a24:3093:: with SMTP id q141-v6mr7931384itq.21.1521368362501; Sun, 18 Mar 2018 03:19:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Sun, 18 Mar 2018 03:19:21 -0700 (PDT) In-Reply-To: References: From: Ben Schwartz Date: Sun, 18 Mar 2018 06:19:21 -0400 Message-ID: To: Patrick McManus Cc: Ted Hardie , doh@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000db1ce00567ad2c0b" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 10:19:27 -0000 --000000000000db1ce00567ad2c0b Content-Type: multipart/alternative; boundary="000000000000d277290567ad2c5b" --000000000000d277290567ad2c5b Content-Type: text/plain; charset="UTF-8" On Sun, Mar 18, 2018 at 5:22 AM, Patrick McManus wrote: > Hi Ted, thanks for writing this down. I think I understand it a bit better > now. > > I think the most relevant point is that DoH is the use of HTTP as a > substrate. As a user of HTTP RFC7231 is very relevant (HTTP status codes) > > > On Sat, Mar 17, 2018 at 5:42 PM, Ted Hardie wrote: > >> In particular, the HTTP semantics for redirection (e.g. HTTP response >> 307 or 308) and client error (e.g. HTTP response 403 or 451) may be >> difficult to map back into DNS errors when the target is a traditional DNS >> client. >> >> > 7231 defines 2xx as success.. If your code is not 2xx then your DoH > request did not succeed and you can feel confident in saying that you do > not have a dns response to the dns request that was made in the http > request. Conversely, a 2xx response needs to carry a DNS reply to your DNS > request. (now that can be a DNS failure - nxdomain, etc, but the 2xx at the > HTTP level is saying a valid DNS response to your request is contained > therein.. i.e. DoH has succeeded). > > non 2xx levels of response do not carry the answer to the DNS query. The > message in those responses is basically just FYI. HTTP allows you to put > any media type you want in there, so I'm not going to tell you you cannot > put DNS information in the body of a 404 if you think that's good FYI, but > I am going to say the body of a 4xx is not the dns answer to the DoH > request that generated it. > > A client may or may not be able to go further based on the response code. > e.g. a 3xx code can obviously be taken further with another request, as can > 401, or maybe even 405. There is a general expectation that clients that > can act on http response codes other than 2xx do so, but its their > decision. So I would say all HTTP clients, including DoH clients but not in > any special way, are expected to follow redirects within the scope of how > the particular redirect is defined, and the message body of the [345]xx is > not very interesting. > > As noted above, if you don't end this process with a 2xx you don't have a > DNS response to the DNS query of the original request - the transport has > failed. I would say you should map that into the traditional DNS in the > same fashion as any other transport failure... e.g. UDP timing out, or TCP > generating RST, or TLS failing verification. An HTTP non-success isn't > going to give you rich DNS information.. if the failure is at the DNS level > and not the DOH level, then the DNS failure can be carried in a 2xx HTTP > response. > > I hope all that helps. I hope that's what things like BCP56bis are aimed > at - we don't want to write down all the HTTP rules for every application > that uses HTTP as a substrate each time. And of course I would expect that > new DoH clients would reuse old HTTP stacks where possible as they should > already encapsulate these rules. > > >> To take an example from the redirection side, if a client has configured >> an ordered list of recursive resolvers and gets a redirect from the DOH >> server, it could theoretically either follow the redirect or move down its >> own list (treating the redirect as an offered member for the list, but >> sorted below the current list). The behavior for that might be influenced >> by the body included in the response. A 307 with a response body containing >> the UDP wire format DNS response for SRVFAIL, for example, might cause the >> DNS client to move down the ordered list, where a 307 with no response body >> might be handled entirely within HTTP's semantics, prior to returning a >> message to the DNS client code. (Note that the choice between these two >> may result in different privacy considerations, especially if resolvers >> later in the list do not use DOH or DNS over TLS). >> > > The udp body in the 307 that you posit is not the dns response to the > original dns question it is just FYI and doesn't have a programmatic > interpretation in the way the 307 and the Location response header do. The > expectation is that if you would like to complete that original request you > should make a new request to the redirected location.. Aborting or pushing > a new approach on top of the stack is fine, but I feel like you feel you're > getting more information from that 307 than you really are. All you know is > its in progress and how to continue. > > > >> Similarly, it was not clear to me whether a response like 451 could >> contain a UDP wireformat body and, if so, what it would be. If it contains >> no body, the DNS implementation might continue attempting to query for the >> information.. If it contains a REFUSED RCODE, in contrast, it would see a >> policy-based error. The document simply provides very little guidance on >> how to handle cases like these. >> >> > Similarly to above, 451 is defined by 7225. DoH seeks to _not_ restate all > the existing HTTP definitions, it just seeks to use them. If DoH was doing > something inconsistent with 7225 that would imo probably be a doh bug. In > the case of 451 In this case 7225 defines the response body as a human > readable description of the censorship - so I don't think wireformat would > be a good choice. (7225 doesn't make an exception for non human clients, of > which there have always been many). It is interesting to note how the code > itself is indeed actionable - the DoH client might choose to repeat the > same query of a VPN or Tor knowing this information. > > > >> There appear to be two extreme positions possible: >> >> 1) DOH servers should, as much as possible, encode all the semantics in >> UDP wireformat DNS messages and return appropriate messages when using >> HTTP's redirection, authorization, or caching semantics. Clients can then >> act on the DNS messages within a structure that may include other recursive >> resolvers. >> > > I hope this message has shed some light on this. wireformat in a non 2xx > response, while legal, is not the response to the dns query in the http > request. I would say its probably not a good idea either, but ymmv. > > >> 2) DOH clients should use HTTP semantics as faithfully as possible, >> returning UDP wireformat DNS messages only after the full HTTP protocol >> mechanics have been worked out and synthesizing DNS messages (such as >> SRVFAIL) when these are implied by the HTTP exchange. >> >> > I hope the situation is a bit clearer that this - but yes this is closer. > > >> The document leans more toward 2 than 1, but does not do so in a way that >> makes it mandatory; you would appear to be able to write a conformant >> server or client using either theory (or much in between). I suspect that >> leaning is due to the web application use case's presumed popularity >> compared to the traditional DNS client use case, but I could be wrong. >> >> I think I disagree here. While you can indeed stick wireformat into all > kinds of non 2xx responses, I do not believe it means what you thought it > meant when you wrote this :) > > > >> Whatever the cause, I believe that additional clarity here is important >> and that some text specifically on the interplay in semantics would be >> useful. >> > > The text you cited in the top of your mail (which I've trimmed here > prematurely) was meant to be part of that, but more important the "over > HTTP" parts are meant to make it clear that HTTP semantics carry the DNS > semantics. > > I'm certainly happy to add a sentence or two to help make that more clear > (suggestions?) but I don't want to start defining/reiterating HTTP > semantics in the DoH doc - we've already got lots of documents (i.e. > rfc723x.. which are all included normatively by 7230 which doh includes > normatively) that do that and its not in doh's charter to mess those things > anyhow. > Thanks for the very clear writeup, Patrick. Indeed, it's not in our charter to mess with any of that stuff. However, it is worthwhile for us to produce a document that is intelligible to DNS experts who do not have deep experience in HTTP. It seems we have some work to do there, and restating relevant results from other drafts may be an appropriate way to improve clarity. > > >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000d277290567ad2c5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 18, 2018 at 5:22 AM, Patrick McManus <= pmcmanus@mozilla.= com> wrote:
Hi Ted, thanks for writing this down. I think I understand it a bit = better now.

I think the most relevant point is tha= t DoH is the use of HTTP as a substrate. As a user of HTTP RFC7231 is very = relevant (HTTP status codes)


On Sat, Mar 17, 2018 at 5:= 42 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
=C2=A0 In particular, the HTTP semantics for redirectio= n (e.g. HTTP response 307 or 308) and client error (e.g. HTTP response 403 = or 451) may be difficult to map back into DNS errors when the target is a t= raditional DNS client.


7231 defines 2xx as= success.. If your code is not 2xx then your DoH request did not succeed an= d you can feel confident in saying that you do not have a dns response to t= he dns request that was made in the http request. Conversely, a 2xx respons= e needs to carry a DNS reply to your DNS request. (now that can be a DNS fa= ilure - nxdomain, etc, but the 2xx at the HTTP level is saying a valid DNS = response to your request is contained therein.. i.e. DoH has succeeded).

non 2xx levels of response do not carry the answer t= o the DNS query. The message in those responses is basically just FYI. HTTP= allows you to put any media type you want in there, so I'm not going t= o tell you you cannot put DNS information in the body of a 404 if you think= that's good FYI, but I am going to say the body of a 4xx is not the dn= s answer to the DoH request that generated it.

A client may or may not be able to go further based on the response code. = e.g. a 3xx code can obviously be taken further with another request, as can= 401, or maybe even 405. There is a general expectation that clients that c= an act on http response codes other than 2xx do so, but its their decision.= So I would say all HTTP clients, including DoH clients but not in any spec= ial way, are expected to follow redirects within the scope of how the parti= cular redirect is defined, and the message body of the [345]xx is not very = interesting.

As noted above, if you don't end = this process with a 2xx you don't have a DNS response to the DNS query = of the original request - the transport has failed. I would say you should = map that into the traditional DNS in the same fashion as any other transpor= t failure... e.g. UDP timing out, or TCP generating RST, or TLS failing ver= ification. An HTTP non-success isn't going to give you rich DNS informa= tion.. if the failure is at the DNS level and not the DOH level, then the D= NS failure can be carried in a 2xx HTTP response.

= I hope all that helps. I hope that's what things like BCP56bis are aime= d at - we don't want to write down all the HTTP rules for every applica= tion that uses HTTP as a substrate each time. And of course I would expect = that new DoH clients would reuse old HTTP stacks where possible as they sho= uld already encapsulate these rules.
=C2=A0<= /div>
To take an= example from the redirection side, if a client has configured an ordered l= ist of recursive resolvers and gets a redirect from the DOH server, it coul= d theoretically either follow the redirect or move down its own list (treat= ing the redirect as an offered member for the list, but sorted below the cu= rrent list).=C2=A0 The behavior for that might be influenced by the body in= cluded in the response. A 307 with a response body containing the UDP wire = format DNS response for SRVFAIL, for example, might cause the DNS client to= move down the ordered list, where a 307 with no response body might be han= dled entirely within HTTP's semantics, prior to returning a message to = the DNS client code.=C2=A0 (Note that the choice between these two may resu= lt in different privacy considerations, especially if resolvers later in th= e list do not use DOH or DNS over TLS).
<= /div>

The udp body= in the 307 that you posit is not the dns response to the original dns ques= tion it is just FYI and doesn't have a programmatic interpretation in t= he way the 307 and the Location response header do. The expectation is that= if you would like to complete that original request you should make a new = request to the redirected location.. Aborting or pushing a new approach on = top of the stack is fine, but I feel like you feel you're getting more = information from that 307 than you really are. All you know is its in progr= ess and how to continue.

=C2= =A0
Similarly, it was not clear to me whether a re= sponse like 451 could contain a UDP wireformat body and, if so, what it wou= ld be.=C2=A0 If it contains no body, the DNS implementation might continue = attempting to query for the information..=C2=A0 If it contains a REFUSED RC= ODE, in contrast, it would see a policy-based error.=C2=A0 The document sim= ply provides very little guidance on how to handle cases like these.

Similarly to above, 451 is defined by 7225. DoH seeks to _no= t_ restate all the existing HTTP definitions, it just seeks to use them. If= DoH was doing something inconsistent with 7225 that would imo probably be = a doh bug. In the case of 451 In this case 7225 defines the response body a= s a human readable description of the censorship - so I don't think wir= eformat would be a good choice. (7225 doesn't make an exception for non= human clients, of which there have always been many). It is interesting to= note how the code itself is indeed actionable - the DoH client might choos= e to repeat the same query of a VPN or Tor knowing this information.
<= span class=3D"">

=C2=A0
=
There appear to be two extreme positions possible:= =C2=A0

1) DOH servers should, as much as possible, encode all the s= emantics in UDP wireformat DNS messages and return appropriate messages whe= n using HTTP's redirection, authorization, or caching semantics.=C2=A0 = Clients can then act on the DNS messages within a structure that may includ= e other recursive resolvers.
=

I hope this message has shed some l= ight on this. wireformat in a non 2xx response, while legal, is not the res= ponse to the dns query in the http request. I would say its probably not a = good idea either, but ymmv.


2) DOH clients should use HTTP = semantics as faithfully as possible, returning UDP wireformat DNS messages = only after the full HTTP protocol mechanics have been worked out and synthe= sizing DNS messages (such as SRVFAIL) when these are implied by the HTTP ex= change.


<= /div>
I hope the situation is a bit clearer that this - but yes = this is closer.
=C2=A0
The document leans more toward 2 than 1, but does n= ot do so in a way that makes it mandatory; you would appear to be able to w= rite a conformant server or client using either theory (or much in between)= .=C2=A0 I suspect that leaning is due to the web application use case's= presumed popularity compared to the traditional DNS client use case, but I= could be wrong.

=
I think I disagree here. While you can indeed stick wireformat into al= l kinds of non 2xx responses, I do not believe it means what you thought it= meant when you wrote this :)

=C2=A0
Whatever the cause, I believe that additional clarity her= e is important and that some text specifically on the interplay in semantic= s would be useful.=C2=A0
<= br>
The text you cited in the top of your mail (which I= 9;ve trimmed here prematurely) was meant to be part of that, but more impor= tant the "over HTTP" parts are meant to make it clear that HTTP s= emantics carry the DNS semantics.

I'm certain= ly happy to add a sentence or two to help make that more clear (suggestions= ?) but I don't want to start defining/reiterating HTTP semantics in the= DoH doc - we've already got lots of documents (i.e. rfc723x.. which ar= e all included normatively by 7230 which doh includes normatively) that do = that and its not in doh's charter to mess those things anyhow.

Thanks for the very cle= ar writeup, Patrick.=C2=A0 Indeed, it's not in our charter to mess with= any of that stuff.=C2=A0 However, it is worthwhile for us to produce a doc= ument that is intelligible to DNS experts who do not have deep experience i= n HTTP.=C2=A0 It seems we have some work to do there, and restating relevan= t results from other drafts may be an appropriate way to improve clarity.
=C2=A0




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


--000000000000d277290567ad2c5b-- --000000000000db1ce00567ad2c0b 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAYvAhecTg+iaSiZk///NH+ qqEUhKlY3ljZgZ5q2tcQSDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMTgxMDE5MjNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEARjZ4VeR5X9Qxvog8mbWfaTLi7C5DBtv2QsohVRd7 WFXSmaA6C4i7j7cZ0dlkYDJJfb+Im/Q9jMj86ClKnsIxBNISowzgtzoHGs6Sr3ubk+gTAOPFO+pp pfuMciA2YfqtcLfD9kt81Ht3M8dr1LvXoHHjXPusOqKsRFA61xuU1d/Y2Mz4K53sMx08XU9IeRbs Oh9hDjZjlZNbpq/FFSEUzac6SmP2ppq+qgn4c20UefyI6U7SGWGm/uRG3MXkuS6eIrMGxUymBjnX GiVi/AhJROGej8nnXzk4d70oMYDujfYDSB9XVs59hAcDqkwZ+qT+wqHSYmz3QjmVne7k2HUxzA== --000000000000db1ce00567ad2c0b-- From nobody Sun Mar 18 03:31:48 2018 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 F1E8F1275F4 for ; Sun, 18 Mar 2018 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoRN_7-g9HDK for ; Sun, 18 Mar 2018 03:31:45 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92BD12741D for ; Sun, 18 Mar 2018 03:31:44 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id h21so10306572wmd.1 for ; Sun, 18 Mar 2018 03:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=oHQvW3tfoG9vN7s7ePQ/w5ZAvzZ4q1U3gF2BKXAD1wc=; b=m4jEBCOVqR/5z+Ugucb05mljn4O+8qqYnPWbn692lBazDH2UHwhympKFrYLkHBwg15 kf7vbE+NCfzEg3ZAywnStJEYQJ5IyneHPoD9/EYh3dSuwuq4BGG49nkUlA1VSeRsJQbL vDKadqdWa8zHI959Iw6cHL74caUFDkh0Wpx1Abku4zomAKmHOQRgJX3ePQlh1TNHa5c1 e4T6GIWNZV1k1UdiQ9ynG6hlMp854QshzQ4q7U2UayqAt/j9eV1GoV+ZPkMco5OsQ3Zc T7O+igXjsmwwV+bttxFYIEPCQwipAThCcBHxRQNuPBYjPLIcrfGjXr+ZSWd/VwW4iERU dcLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=oHQvW3tfoG9vN7s7ePQ/w5ZAvzZ4q1U3gF2BKXAD1wc=; b=R7pTR4ld0wJqLM13ynLIbL+gZ3O6bXGo7+9TecMwvshubevcXRb+vrE0NwaOiwFRA7 jNJNU2iAwVy+cU+gY0B6UB0mFo3t5zzylM2zOdEFJLQx96fnEhm7D0Or86bRqb6VIiCS iNONDymIxWToimHyq9EZT6RBSpirvXE2Db6eHNmWWkyyCFf0dpMl00aRA60yWKcC+jrE fcM6yv/6HXmsDHsxR7uxaJ3G7ZAv07UzKV/7507yhEy0Ziws/q/C4S6LGj29zv4VHcky fdjqzbLbehWTpp5Zv1GEE9K0L31vYVQZZA/ED/jaf8K5wRI+2JPySSYDsXz3oB1C0lA6 oqYA== X-Gm-Message-State: AElRT7FvKNxTdrKjxh4PmAOGx+LCSqrBPB20SCJcoqbCdF2HnM+WFWIg SQYoPBK7FMlCv5+eM9Z8I8obS9FgDTo= X-Google-Smtp-Source: AG47ELvf32hnZE7gOFe7bt7IQcTiZhgetjTGfavrHvBlUP7z3zq0piFhYc3ZowVCBQr2XHsOK7mN/w== X-Received: by 10.28.198.13 with SMTP id w13mr1175530wmf.108.1521369102999; Sun, 18 Mar 2018 03:31:42 -0700 (PDT) Received: from miek.nl ([2001:67c:1232:144:b320:5945:16d2:52c4]) by smtp.gmail.com with ESMTPSA id n62sm4245040wmf.13.2018.03.18.03.31.41 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 18 Mar 2018 03:31:42 -0700 (PDT) Date: Sun, 18 Mar 2018 10:31:41 +0000 From: Miek Gieben To: DoH WG Message-ID: <20180318103141.a5wacb75qzsgsjqp@miek.nl> Mail-Followup-To: DoH WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: [Doh] IETF hackathon client implementation report 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, 18 Mar 2018 10:31:47 -0000 FYI: Goal: Implement DoH in miekg/dns (Go DNS library) Try to mimic DNS-over-TLS, which was relatively painless to incorperate. I attempted to make DNS over HTTPS a first class citizen, i.e. create a DNS connection and have 1 configuration item set to "https" and then have DoH "just work". This approach worked for DNS-over-TLS (but side steps some advanaced features). This ran into a few snags which makes this approach infeasible meaning I can't easily incorperate it without major rewrites of the library: * http/2 (in Go) has it's own socket pipelining so I can't give it a socket and make it run with it. This breaks an assumption in this library. * The Go http client setup has a function called client.Do which sends a reply and waits for a reponse, ala Exchange() in this library. But this library uses "WriteMsg" and "ReadMsg" as two calls; which can't be implemented as such for DoH. I ended up with some (trivial) helper functions that parse from and to the http/2 request world, but nothing more tangible. See https://github.com/miekg/dns/pull/647 . /Miek -- Miek Gieben From nobody Sun Mar 18 03:33:51 2018 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 CDAAD1275F4 for ; Sun, 18 Mar 2018 03:33:49 -0700 (PDT) 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 qdBs9Y3OTrQR for ; Sun, 18 Mar 2018 03:33:47 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A2270127599 for ; Sun, 18 Mar 2018 03:33:47 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 506AC3A021 for ; Sun, 18 Mar 2018 06:33:46 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id 71so651601oie.12 for ; Sun, 18 Mar 2018 03:33:46 -0700 (PDT) X-Gm-Message-State: AElRT7Ea1lvfnIXua0qXpMXsa1gUCLkWLU9+2Qa4zYY7vMg6i4+a2yuE ZWFZs66fywOWM2ss7i5GZMEm41tTMomen7D54/o= X-Google-Smtp-Source: AG47ELsu/08JEmSIBBTrQZIBdNrbKhhPvi8flGTZuveCAzQgyKp1CzNKJKcy6ndkRnOfcMomXHSSotU+60RzIy0y5mg= X-Received: by 10.202.94.132 with SMTP id s126mr4561690oib.155.1521369225983; Sun, 18 Mar 2018 03:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 03:33:45 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sun, 18 Mar 2018 10:33:45 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Tony Finch Cc: Ted Hardie , doh@ietf.org Content-Type: multipart/alternative; boundary="001a113d51604980050567ad60ec" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 10:33:50 -0000 --001a113d51604980050567ad60ec Content-Type: text/plain; charset="UTF-8" On Sun, Mar 18, 2018 at 10:11 AM, Tony Finch wrote: > > server should generate. I have had another quick look through the > draft but I couldn't see anything particularly addressing this issue. > we should have a look at section 4.6 of bcp56bis - which warns against defining a laundry list of error codes in application protocols like DoH. For each of these cases HTTP has an appropriate code, which can be consumed by other HTTP clients in the HTTP ecosystem to mean the same thing. There might be more than one way to express something at the HTTP layer and, as long as the consumers follow the HTTP definitions, that's ok and doesn't need specification by DoH. > If the request is not HEAD/GET/POST, I return 405 Method Not Allowed > with a browser-friendly body. > > that seems reasonable to me. > For POST requests with an unknown Content-Type, or GET requests with > an unknown or missing `ct=` parameter, my server returns 415 > Unsupported Media Type with a browser-friendly body. > > that seems reasonable to me > If the `dns=` parameter is missing from a GET request, the best > response seems to be a browser-friendly 400 Bad Request. Sam Kington > (not an IETFer afaik) suggested 422 Unprocessable Entity, but that > implies the request is well-formed which isn't really the case. (My > server returns 418 I'm A Teapot for fun.) Bad `base64url` encoding > should produce the same response. > > 400 makes the most sense to me. > If the request's Accept: header doesn't allow > `application/dns-udpwireformat` then the response should be a > browser-friendly 406 Not Acceptable. > > this is probably a tad too strong. First, the absence of a request header indicates the client will take anything - I'm not sure if that is included in your definition of allow the mti (maybe it does?). Second, 7231 5.3.2 covers this case : If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation. so the server certainly has the option of just returning 200+wireformat. Realistically given the size of wireformat that's probably the right thing to do both paths seem legal. > I think if the request passes these checks, the server knows it has a > request in DNS format and a client that wants a response in DNS > format, so it can just hand over to its DNS processing code. > Regardless of the DNS RCODE in the response, the HTTP status code > should be 200 OK. > > Thanks! > My logic up to this point is to send a browser-friendly response if > the client seems to be unprepared to talk to a DoH server. There are > some other cases - e.g. HTTP authentication or redirects - which ought > to be handled by the HTTP layers before the request processing gets to > the DoH logic, so in these cases the response bodies will naturally be > browser-friendly. But perhaps it's worth noting them in the draft so > that DoH clients should be prepared to handle them gracefully. > > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > punycode > Dover, Wight, Portland, Plymouth: Northeast, becoming cyclonic in Portland > and > Plymouth, 6 to gale 8. Moderate or rough. Occasional snow. Moderate or > good, > occasionally very poor. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113d51604980050567ad60ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 18, 2018 at 10:11 AM, Tony Finch <dot@dotat.at> w= rote:

server should generate. I have had another quick look through the
draft but I couldn't see anything particularly addressing this issue.

we should have a look at section 4.6 of = bcp56bis - which warns against defining a laundry list of error codes in ap= plication protocols like DoH. For each of these cases HTTP has an appropria= te code, which can be consumed by other HTTP clients in the HTTP ecosystem = to mean the same thing. There might be more than one way to express somethi= ng at the HTTP layer and, as long as the consumers follow the HTTP definiti= ons, that's ok and doesn't need specification by DoH.

=C2=A0
If the request is not HEAD/GET/POST, I return 405 Method Not Allowed
with a browser-friendly body.


that seems reasonable to me.
=
=C2=A0
For POST requests with an unknown Content-Type, or GET requests with
an unknown or missing `ct=3D` parameter, my server returns 415
Unsupported Media Type with a browser-friendly body.


that seems reasonable to me
<= div>=C2=A0
If the `dns=3D` parameter is missing from a GET request, the best
response seems to be a browser-friendly 400 Bad Request. Sam Kington
(not an IETFer afaik) suggested 422 Unprocessable Entity, but that
implies the request is well-formed which isn't really the case. (My
server returns 418 I'm A Teapot for fun.) Bad `base64url` encoding
should produce the same response.

400 makes the most sense to me.
=C2=A0<= /div>
If the request's Accept: header doesn't allow
`application/dns-udpwireformat` then the response should be a
browser-friendly 406 Not Acceptable.

this is probably a tad too strong.

First, the absence of a request header indicates the client will tak= e anything - I'm not sure if that is included in your definition of all= ow the mti (maybe it does?).

Second, 7231 5.3.2 co= vers this case :
   If the header field is =
present in a request and none of the available representations for
   the response have a media type that is listed as acceptable, the
   origin server can either honor the header field by sending a 406 (Not
   Acceptable) response or disregard the header field by treating the
   response as if it is not subject to content negotiation.
so the ser= ver certainly has the option of just returning 200+wireformat. Realisticall= y given the size of wireformat that's probably the right thing to do bo= th paths seem legal.
=C2=A0
I think if the request passes these checks, the server knows it has a
request in DNS format and a client that wants a response in DNS
format, so it can just hand over to its DNS processing code.
Regardless of the DNS RCODE in the response, the HTTP status code
should be 200 OK.


Thanks!
=C2=A0
My logic up to this point is to send a browser-friendly response if
the client seems to be unprepared to talk to a DoH server. There are
some other cases - e.g. HTTP authentication or redirects - which ought
to be handled by the HTTP layers before the request processing gets to
the DoH logic, so in these cases the response bodies will naturally be
browser-friendly. But perhaps it's worth noting them in the draft so that DoH clients should be prepared to handle them gracefully.


Tony.
--
f.anthony.n.finch=C2=A0 <dot@dotat.at>=C2=A0 http://dotat.at/=C2=A0 -=C2=A0 I xn--zr8h punycode
Dover, Wight, Portland, Plymouth: Northeast, becoming cyclonic in Portland = and
Plymouth, 6 to gale 8. Moderate or rough. Occasional snow. Moderate or good= ,
occasionally very poor.

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

--001a113d51604980050567ad60ec-- From nobody Sun Mar 18 04:04:03 2018 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 C89C712D88D for ; Sun, 18 Mar 2018 04:03:59 -0700 (PDT) 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 Mn3G-HRzGZPJ for ; Sun, 18 Mar 2018 04:03:58 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D1BC312DA09 for ; Sun, 18 Mar 2018 04:03:57 -0700 (PDT) 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]:39041) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1exW6V-000EJs-e4 (Exim 4.89_2) (return-path ); Sun, 18 Mar 2018 11:03:55 +0000 Date: Sun, 18 Mar 2018 11:03:55 +0000 From: Tony Finch To: Patrick McManus cc: Ted Hardie , doh@ietf.org In-Reply-To: Message-ID: References: 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] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 11:04:02 -0000 Patrick McManus wrote: > > we should have a look at section 4.6 of bcp56bis - which warns against > defining a laundry list of error codes in application protocols like DoH. > For each of these cases HTTP has an appropriate code, which can be consumed > by other HTTP clients in the HTTP ecosystem to mean the same thing. There > might be more than one way to express something at the HTTP layer and, as > long as the consumers follow the HTTP definitions, that's ok and doesn't > need specification by DoH. Right, that makes sense. Regarding "more than one way to express something", the DoH draft describes two fairly specific ways to express a DoH request, so it seems to me that it would be right to be equally specific about the error cases, as well as the success case. Maybe there is some way to explain what to do without being as verbose as I was :-) Re. Accept: > so the server certainly has the option of just returning 200+wireformat. > Realistically given the size of wireformat that's probably the right thing > to do both paths seem legal. Being lazy, I'm happy that you say I don't need to implement any Accept: processing :-) Thanks for the helpful reply! Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Forties, Cromarty, Forth: East 5 to 7, backing northeast 4 or 5 later. Moderate or rough, occasionally very rough at first except in Cromarty. Snow showers. Good, occasionally poor. From nobody Sun Mar 18 04:24:53 2018 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 4AEC01243FE for ; Sun, 18 Mar 2018 04:24:52 -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, 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 Xc1ZyTyd1X_e for ; Sun, 18 Mar 2018 04:24:50 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 8E97D1242F5 for ; Sun, 18 Mar 2018 04:24:50 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id y11-v6so14654962otg.0 for ; Sun, 18 Mar 2018 04:24:50 -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=jcHm4E96n96nbcYYYXudJGu50lrTT0Fz5mdkc6WPieI=; b=D2+p3UyL2Wqrr9aKRhrXQhm2ThKsstVGxwvIZdTBHQoETwuJmmqghSgluwbjMKLF+D W7nHE5Sp0P1aP5FOSRgSSbbHTfqns7fc5DCErOozK8qi9pSeG3XDcMV3I2PHXkQkw1lv UEDrtXY3z1h7OBSRtePRfgo5M3O4VnuglXanj+kywB/PGrqbNWKBBHaXFXS8LkyPZ6vH kJY4DhJ7vuURDnJeIxEmJNfC/jSGVynAraWirsWw+Y4Ho/YMnWdgHDBeH32LP62R4vPL YkgPSXhWM6dy/goyou3LjBDf0XZrSZDDwFu4RNK4SKsMuL7K7et4p5QpBACHEykXu5LX hrFw== 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=jcHm4E96n96nbcYYYXudJGu50lrTT0Fz5mdkc6WPieI=; b=pJO0l8N0mpOMePyJJd2QEQcnFVfq8EBygUShJ+uohQuU7IFveTzh08PDl58VyrvoC0 kVjXccKKsXRQ36Y0NDZAgVflPe/VhY3us3OU9902rwD5WwuEgO+wyex0RWhnH0ItDq3l Di0mNuG72GpMCO0/tlpibxl5nw5caTtl3Zyl0zd7Mb9PV8a1Vh1OpgXLa76S/xBilxdS fRiYhpKXOoxQ/WWomCuYMGzyIjAiuzL9odhmzLAX7B4Cyh/t6hxc2rjk8YSXP0yu2Ub5 Qngo5GX4VOM+wr9XxgNnSCFpX+dj7xpog8Kuj2VSt2EfSs8uE3yHgXTD4FUUcrn0WPfF KX/Q== X-Gm-Message-State: AElRT7FPklJMXLZSwNMwpZvYfrdkPWQ+souuVBnOdI6mV89Xpaemd5P2 p6wzEPAVKBvvIa+OxICD9UVl5jV3uJT53TFcIAR34w== X-Google-Smtp-Source: AG47ELshkkc4opjpiMkMbDpYISbuQuRQk9uNcmb2IfQYOQLRSK7PmXhIUu4Fy3lVYwhHtJiUtxSKDKa3xtmvKWJrfpE= X-Received: by 2002:a9d:fa1:: with SMTP id d30-v6mr695940otd.18.1521372289650; Sun, 18 Mar 2018 04:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Sun, 18 Mar 2018 04:24:19 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Sun, 18 Mar 2018 04:24:19 -0700 Message-ID: To: Ben Schwartz Cc: Patrick McManus , doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000e557df0567ae1608" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 11:24:52 -0000 --000000000000e557df0567ae1608 Content-Type: text/plain; charset="UTF-8" For some reason, I am seeing Ben's reply, but not Patrick's mail. Replying to this as a result. On Sun, Mar 18, 2018 at 3:19 AM, Ben Schwartz wrote: > > > On Sun, Mar 18, 2018 at 5:22 AM, Patrick McManus > wrote: > >> Hi Ted, thanks for writing this down. I think I understand it a bit >> better now. >> >> I think the most relevant point is that DoH is the use of HTTP as a >> substrate. As a user of HTTP RFC7231 is very relevant (HTTP status codes) >> >> >> On Sat, Mar 17, 2018 at 5:42 PM, Ted Hardie wrote: >> >>> In particular, the HTTP semantics for redirection (e.g. HTTP response >>> 307 or 308) and client error (e.g. HTTP response 403 or 451) may be >>> difficult to map back into DNS errors when the target is a traditional DNS >>> client. >>> >>> >> 7231 defines 2xx as success.. If your code is not 2xx then your DoH >> request did not succeed and you can feel confident in saying that you do >> not have a dns response to the dns request that was made in the http >> request. Conversely, a 2xx response needs to carry a DNS reply to your DNS >> request. (now that can be a DNS failure - nxdomain, etc, but the 2xx at the >> HTTP level is saying a valid DNS response to your request is contained >> therein.. i.e. DoH has succeeded). >> >> Saying something in the document like "only 2xx response codes will carry response bodies with DNS UDP wireformat" would be a short and sweet way of saying that in the document, if there is working group consensus that this is true. Based on my conversations yesterday, I am not sure that there is complete consensus on this point, though there may very well be rough consensus. However, I don't think this formulation is quite enough: > As noted above, if you don't end this process with a 2xx you don't have a > DNS response to the DNS query of the original request - the transport has > failed. > A pure transport failure may result in a retry. There are some of these responses which strongly indicate that such a retry will result in failures (e.g. 403). If you do not synthesize some message to the DNS client about the type of failure, and the server does not provide one, what part of the system avoids the retry? Ted --000000000000e557df0567ae1608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For some reason, I am seeing Ben's reply, but not Patr= ick's mail.=C2=A0 Replying to this as a result.

On Sun, Mar 18, 2018 at 3:19 AM, Ben = Schwartz <bemasc@google.com> wrote:


On Sun, Mar 18, 2018 at 5:22 AM, Patrick = McManus <pmcmanus@mozilla.com> wrote:
Hi Ted, thanks for = writing this down. I think I understand it a bit better now.

=
I think the most relevant point is that DoH is the use of HTTP a= s a substrate. As a user of HTTP RFC7231 is very relevant (HTTP status code= s)


On Sat, Mar 17, 2018 at 5:42 PM, Ted Har= die <ted.ietf@gmail.com> wrote:
=C2=A0 In particular, the HTTP semantics for redir= ection (e.g. HTTP response 307 or 308) and client error (e.g. HTTP response= 403 or 451) may be difficult to map back into DNS errors when the target i= s a traditional DNS client.


7231 de= fines 2xx as success.. If your code is not 2xx then your DoH request did no= t succeed and you can feel confident in saying that you do not have a dns r= esponse to the dns request that was made in the http request. Conversely, a= 2xx response needs to carry a DNS reply to your DNS request. (now that can= be a DNS failure - nxdomain, etc, but the 2xx at the HTTP level is saying = a valid DNS response to your request is contained therein.. i.e. DoH has su= cceeded).


Saying something in the document like = "only 2xx response codes will carry response bodies with DNS UDP wiref= ormat" would be a short and sweet way of saying that in the document, = if there is working group consensus that this is true.=C2=A0 Based on my co= nversations yesterday, I am not sure that there is complete consensus on th= is point, though there may very well be rough consensus.

= However, I don't think this formulation is quite enough:
=C2=A0
As noted above, if you don't end this process with a 2xx yo= u don't have a DNS response to the DNS query of the original request - = the transport has failed.

A pure = transport failure may result in a retry.=C2=A0 There are some of these resp= onses which strongly indicate that such a retry will result in failures (e.= g. 403).=C2=A0 If you do not synthesize some message to the DNS client abou= t the type of failure,=C2=A0 and the server does not provide one, what part= of the system avoids the retry?

Ted
--000000000000e557df0567ae1608-- From nobody Sun Mar 18 04:44:02 2018 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 C5F681270A7 for ; Sun, 18 Mar 2018 04:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YUhI9CWXAJOW for ; Sun, 18 Mar 2018 04:43:58 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 176791242F5 for ; Sun, 18 Mar 2018 04:43:57 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w2IBhsgA025990 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Mar 2018 12:43:54 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w2IBhr3b025938; Sun, 18 Mar 2018 12:43:53 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 18 Mar 2018 12:43:53 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Ted Hardie cc: Ben Schwartz , doh@ietf.org, Patrick McManus In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 11:44:00 -0000 On Sun, 18 Mar 2018, Ted Hardie wrote: > Saying something in the document like "only 2xx response codes will carry > response bodies with DNS UDP wireformat" would be a short and sweet way of > saying that in the document, if there is working group consensus that this > is true. Based on my conversations yesterday, I am not sure that there is > complete consensus on this point, though there may very well be rough > consensus. I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I don't even understand how it would work otherwise. What other HTTP response codes could be used to transmit DNS responses? > A pure transport failure may result in a retry. There are some of these > responses which strongly indicate that such a retry will result in failures > (e.g. 403). If you do not synthesize some message to the DNS client about > the type of failure, and the server does not provide one, what part of the > system avoids the retry? For all 4xx HTTP response codes, the "fault" is in the client side (the request) so if you as a client decide to retry the request it doesn't at least make any sense to send an identical request again. I don't think 4xx strictly avoids retries. It informs the client about the fact that the request, as-is, was denied. A retry would then have to change something in the request for it to be successful. 401 and 407 are good examples of this, for which clients often retry with a modified request (with added auth headers). -- / daniel.haxx.se From nobody Sun Mar 18 05:19:16 2018 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 45F171270A7 for ; Sun, 18 Mar 2018 05:19:14 -0700 (PDT) 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 gsJUB1-nhE_t for ; Sun, 18 Mar 2018 05:19:12 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5612704A for ; Sun, 18 Mar 2018 05:19:12 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id D7B463A060 for ; Sun, 18 Mar 2018 08:19:11 -0400 (EDT) Received: by mail-oi0-f49.google.com with SMTP id e9so12189374oii.0 for ; Sun, 18 Mar 2018 05:19:11 -0700 (PDT) X-Gm-Message-State: AElRT7HDiYHpjyfWEQFF47BiGqNWFyNB16doxZIFg5LZB+3XNabOGsvJ yScU9CPxy/dkhh/Xbfw20P4RByDEU0OGtEPfCok= X-Google-Smtp-Source: AG47ELtl8duZmrnMq5FBFVgpbHt3MThTFJH5WFWdNEhH6zSC7Zvp0fMIO3jTcELqK64fpVTiDFrjGHEoUhwidDLp3Kg= X-Received: by 10.202.3.198 with SMTP id 189mr4676669oid.132.1521375551478; Sun, 18 Mar 2018 05:19:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 05:19:10 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sun, 18 Mar 2018 12:19:10 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Tony Finch Cc: Patrick McManus , Ted Hardie , doh@ietf.org Content-Type: multipart/alternative; boundary="001a11c0463c50e3f20567aed925" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 12:19:14 -0000 --001a11c0463c50e3f20567aed925 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 18, 2018 at 11:03 AM, Tony Finch wrote: > Patrick McManus wrote: > > > Right, that makes sense. Regarding "more than one way to express > something", the DoH draft describes two fairly specific ways to express a > DoH request, so it seems to me that it would be right to be equally > specific about the error cases, as well as the success case. > The subtlety here is that the response the DoH client consumes is not necessarily generated by the DoH server - it might be some other HTTP server in the chain. For instance, a cache/LB front end like Apache Traffic Server might, instead of routing directly to the DoH server, send back a redirect or a 401 or a 5xx if its just overloaded beyond hope. That's all valid HTTP behavior in reaction to valid HTTP request by an entity that isn't particularly DoH aware (that's the point of using HTTP!) - so you aren't going to get it to constrain its responses in anyway more specific than HTTP itself requires. --001a11c0463c50e3f20567aed925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 18, 2018 at 11:03 AM, Tony Finch <dot@dotat.at> w= rote:
Patrick McManus &l= t;pmcmanus@mozilla.com> wrot= e:
>
Right, that makes sense. Regarding "more than one way to expres= s
something", the DoH draft describes two fairly specific ways to expres= s a
DoH request, so it seems to me that it would be right to be equally
specific about the error cases, as well as the success case.

The subtlety here is that the response the DoH clien= t consumes is not necessarily generated by the DoH server - it might be som= e other HTTP server in the chain. For instance, a cache/LB front end like A= pache Traffic Server might, instead of routing directly to the DoH server, = send back a redirect or a 401 or a 5xx if its just overloaded beyond hope. = That's all valid HTTP behavior in reaction to valid HTTP request by an = entity that isn't particularly DoH aware (that's the point of using= HTTP!) - so you aren't going to get it to constrain its responses in a= nyway more specific than HTTP itself requires.


--001a11c0463c50e3f20567aed925-- From nobody Sun Mar 18 06:13:25 2018 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 A05D812D0C3 for ; Sun, 18 Mar 2018 06:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fUSSGMMeQnbn for ; Sun, 18 Mar 2018 06:13:22 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 AECAF1204DA for ; Sun, 18 Mar 2018 06:13:22 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id E55FCA05CF; Sun, 18 Mar 2018 14:13:18 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 9C36DEC0B87; Sun, 18 Mar 2018 14:11:39 +0100 (CET) Date: Sun, 18 Mar 2018 13:11:39 +0000 From: Stephane Bortzmeyer To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= Cc: doh@ietf.org Message-ID: <20180318131139.GA1127@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] Support requirements for Head 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, 18 Mar 2018 13:13:25 -0000 On Sat, Mar 17, 2018 at 12:27:09PM +0000, Ólafur Guðmundsson wrote a message of 56 lines which said: > Based on experience at the IETF101 Hackathon this issue came up. A related issue is HEAD support. Today, one implementation rejects both GET and HEAD (405), one accepts GET but HEAD triggers a 400 (probably a bug, reported). My personal opinion is "if you support GET, you MUST support HEAD". Any HTTP advice? (Technically, it's nothing, the vast majority of DoH clients and servers already handle HEAD.) From nobody Sun Mar 18 06:30:41 2018 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 6374512D77C for ; Sun, 18 Mar 2018 06:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JOrpF_WFFnbs for ; Sun, 18 Mar 2018 06:30:37 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9068A129515 for ; Sun, 18 Mar 2018 06:30:37 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w2IDUYLV030017 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Mar 2018 14:30:35 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w2IDUYPh030012; Sun, 18 Mar 2018 14:30:34 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 18 Mar 2018 14:30:34 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Stephane Bortzmeyer cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= , doh@ietf.org In-Reply-To: <20180318131139.GA1127@laperouse.bortzmeyer.org> Message-ID: References: <20180318131139.GA1127@laperouse.bortzmeyer.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] Support requirements for Head 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, 18 Mar 2018 13:30:39 -0000 On Sun, 18 Mar 2018, Stephane Bortzmeyer wrote: > My personal opinion is "if you support GET, you MUST support HEAD". Any HTTP > advice? (Technically, it's nothing, the vast majority of DoH clients and > servers already handle HEAD.) That is not strictly stated in RFC 7231 and the web is already populated with lots of servers that don't respond to HEAD while responding fine to GET. -- / daniel.haxx.se From nobody Sun Mar 18 06:57:42 2018 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 376D012711A for ; Sun, 18 Mar 2018 06:57:41 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 EEThWvIsnU6S for ; Sun, 18 Mar 2018 06:57:39 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 54269126C0F for ; Sun, 18 Mar 2018 06:57:39 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id c12so12256738oic.7 for ; Sun, 18 Mar 2018 06:57:39 -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=Negjez1tf0ZUWEWI0aZeTcCcpAAah7U+jELNo1QWXbA=; b=CAtHh7w8VvJQHfy0gFXQfURJr6Xu1EiIpsYmi8z3yUXFjBbTno9FVU4LNPLlK2gi9c nTU3n971vRWf7pBkwyfprDpSQcyKXvQDtUggLFYjunZMzplldbo9l8d2NiYj1xjcfkso BFsVuhwuzkpdz1NLspvUpLf+/T9iWcSa1DvBjDasZWlZefj3uGxi51rZg8ojHwr8l3Z6 EVZoXcQ3TVFKYHUleGH2L9HPwfJSCwvQCAfhWEz5pipR5SktjT/IaCBwvov7QB08VHTT yH6OI+AXz30CipW3UPgbU2inSNeSmgbfPSv8CK7pcCYvQpq94TrAZtsqtbYkOCfMkmYg kvRQ== 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=Negjez1tf0ZUWEWI0aZeTcCcpAAah7U+jELNo1QWXbA=; b=kujT5rzbtMBnzc60dMjAhB7FJyGpk8iNdShtoQJOmS9fEZwFgPQjPKEYlXJENmAgHj Wsd6sMdbND1wxTnICBL7j4fspjfFONGL45KIatZDCcuI/kchs6TmBneFd6dr3q1fapOb v89ERqNmyzqKBwnzFSZHcIgi03DAf4m+ofQidhlJ7nyjZKaU1Y5T86R8bqPQKYdjy0qB XXtxcqQkm4wlZMXl0QZE/SeC8PAZRLj+dmFZJggai/WIB4bOWWF106KcUN6QCA4vukMH AEKSYWxOQMHNcWNx0X6yIgda60sgVr2R9VoRYnk2mLh4QDnqBqNUHhOq+ChPFmUsgOVV tj2g== X-Gm-Message-State: AElRT7EK4veVMTjTJpefpex/iCtj54Jkl2YuRaF7vj9VuYEXO3TDwTEY S4ysEyCHwWNpah5MmoP9riABhm60M3JF9PzgFo8= X-Google-Smtp-Source: AG47ELvGCA0DfGWenzklsmPsI84+u0owwe+DCc10m4vGypQj36SSSFdEVxBwbgB3I5OV7lpAo+sbKkndFKPGZLtpxR0= X-Received: by 10.202.225.67 with SMTP id y64mr5452329oig.122.1521381458342; Sun, 18 Mar 2018 06:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Sun, 18 Mar 2018 06:57:07 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Sun, 18 Mar 2018 06:57:07 -0700 Message-ID: To: Daniel Stenberg Cc: Ben Schwartz , doh@ietf.org, Patrick McManus Content-Type: multipart/alternative; boundary="001a113d4d6e647d1b0567b0394d" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 13:57:41 -0000 --001a113d4d6e647d1b0567b0394d Content-Type: text/plain; charset="UTF-8" Howdy, On Sun, Mar 18, 2018 at 4:43 AM, Daniel Stenberg wrote: > On Sun, 18 Mar 2018, Ted Hardie wrote: > > Saying something in the document like "only 2xx response codes will carry >> response bodies with DNS UDP wireformat" would be a short and sweet way of >> saying that in the document, if there is working group consensus that this >> is true. Based on my conversations yesterday, I am not sure that there is >> complete consensus on this point, though there may very well be rough >> consensus. >> > > I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I > don't even understand how it would work otherwise. > > What other HTTP response codes could be used to transmit DNS responses? > > The 4xx ones, might, as I noted below. > A pure transport failure may result in a retry. There are some of these >> responses which strongly indicate that such a retry will result in failures >> (e.g. 403). If you do not synthesize some message to the DNS client about >> the type of failure, and the server does not provide one, what part of the >> system avoids the retry? >> > > For all 4xx HTTP response codes, the "fault" is in the client side (the > request) so if you as a client decide to retry the request it doesn't at > least make any sense to send an identical request again. > > I think you're thinking of a different layering than I am. If the DNS client is talking to the HTTP stack as if it were a transport, and it gets nothing back (transport failure), it may construct and send the query again (it might do that in the UDP transport case, for example, on the theory that the network had dropped the response packet). To avoid that, you might want to send a DNS message that encodes the information that this server will not fulfill this request over this transport. regards, Ted > I don't think 4xx strictly avoids retries. It informs the client about the > fact that the request, as-is, was denied. A retry would then have to change > something in the request for it to be successful. 401 and 407 are good > examples of this, for which clients often retry with a modified request > (with added auth headers). > > -- > > / daniel.haxx.se > --001a113d4d6e647d1b0567b0394d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Sun, Mar 18, 2018 at 4:43 AM, Daniel Stenberg <daniel@hax= x.se> wrote:
On Sun, 18 Mar 2018, Ted Hardie wrote:

Saying something in the document like "only 2xx response codes will ca= rry response bodies with DNS UDP wireformat" would be a short and swee= t way of saying that in the document, if there is working group consensus t= hat this is true.=C2=A0 Based on my conversations yesterday, I am not sure = that there is complete consensus on this point, though there may very well = be rough consensus.

 I'm firmly in the only-2xx-carry-response-bodies-to-care-about cam= p. I don't even understand how it would work otherwise.

What other HTTP response codes could be used to transmit DNS responses?


The 4xx ones, might, as I noted= below.
=C2=A0
A pure transport failure may result in a retry.=C2=A0 There are some of the= se responses which strongly indicate that such a retry will result in failu= res (e.g. 403).=C2=A0 If you do not synthesize some message to the DNS clie= nt about the type of failure, and the server does not provide one, what par= t of the system avoids the retry?

 For all 4xx HTTP response codes, the "fault" is in the client sid= e (the request) so if you as a client decide to retry the request it doesn&= #39;t at least make any sense to send an identical request again.


I think you're thinking of a diffe= rent layering than I am.=C2=A0 If the DNS client is talking to the HTTP sta= ck as if it were a transport, and it gets nothing back (transport failure),= it may construct and send the query again (it might do that in the UDP tra= nsport case, for example, on the theory that the network had dropped the re= sponse packet).=C2=A0 To avoid that, you might want to send a DNS message t= hat encodes the information that this server will not fulfill this request = over this transport.

regards,

Ted
=C2=A0
I don't think 4xx strictly avoids retries. It informs the client about = the fact that the request, as-is, was denied. A retry would then have to ch= ange something in the request for it to be successful. 401 and 407 are good= examples of this, for which clients often retry with a modified request (w= ith added auth headers).

--

=C2=A0/ daniel.haxx.se

--001a113d4d6e647d1b0567b0394d-- From nobody Sun Mar 18 07:11:05 2018 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 202A112783A for ; Sun, 18 Mar 2018 07:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNoGA6AkUlRB for ; Sun, 18 Mar 2018 07:11:02 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9280812711A for ; Sun, 18 Mar 2018 07:11:02 -0700 (PDT) Received: from dhcp-86a7.meeting.ietf.org (dhcp-86a7.meeting.ietf.org [31.133.134.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 7EAED886 for ; Sun, 18 Mar 2018 10:05:49 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <07A79B82-9B30-4BA6-96C8-175707581178@bangj.com> Date: Sun, 18 Mar 2018 14:10:59 +0000 To: doh@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Doh] Hackathon javascript client & browser issue 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, 18 Mar 2018 14:11:04 -0000 Working in the hackathon, I created a simple node javascript client to = test DoH. https://github.com/pusateri/doh-client This works fine and then St=C3=A9phane asked if it could run in the = browser. So I did this: https://github.com/pusateri/doh-webpack However, when sending a POST to a test server, I am getting a error = (400) response to an initial pre-flight OPTIONS request. According to = https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests The only content types allowed for a POST are: =E2=80=A2 application/x-www-form-urlencoded =E2=80=A2 multipart/form-data =E2=80=A2 text/plain so a question I have, should the DoH servers respond to a pre-flight = OPTIONS method or are things working as designed because this = shouldn=E2=80=99t be allowed to run in a browser? Thanks, Tom From nobody Sun Mar 18 07:19:59 2018 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 A9AEC12D7FC for ; Sun, 18 Mar 2018 07:19:57 -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, 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 QeoPEDVThA7o for ; Sun, 18 Mar 2018 07:19:53 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 4C48912783A for ; Sun, 18 Mar 2018 07:19:53 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a22-v6so21697147lfg.9 for ; Sun, 18 Mar 2018 07:19:53 -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=g+d7gc79h9NFWgOBO3Y64NXPVJpo9OeSRmJksk6JHdA=; b=d9aTo2C6Z9X+GEm2bnkGHi9efLU6Uic0rzXqUYbAbYWoyiLOO1Sk5skhmm0M5I9TTG vIy9DHp7uStAKRef/bGDj3HKAwglFVAEqCy5yTdolnXcmnuDAYCRmQJbEaq88/nVKOQF AxiOUwA7ihD26gbo2Wj+FMGftRM5+P76ycViJB04iZKyqpr699DdSpokJdxgGWyqBJvN nRdzJ54aoP8X3AMzJhKXJ5n5ouaB9sNV42Melhs7GaEP53lggexf+0G7HVWpdy5sYA1q EGjfTmiyBZWFkTdz9mEUIL+LhuKs/Dh42Y1KwJfXOLuklkpBL6dZEu9JbOFsT9SNkQni iNFw== 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=g+d7gc79h9NFWgOBO3Y64NXPVJpo9OeSRmJksk6JHdA=; b=SqVOqFI/6z03/XBuleB7L39POh98r6KZtkyVLsJVrYAG0yAYyNyqkZjGsk70NTHX2q GqhBxLzMnJBzUR+GNl80aP98amcbQYspUM7o6J7s6T+PYPHILiU7ultsCFfGRpy4RoeN mph9u3je0Dl9EZtyu1AmfVKFyYX0PgBDcJjsF867PPvRrxrF0VX0NJFZxKa0inZpTfOP dsNCF+hxmnJfdAcJ96Xp3o08fg8PksWK6zkXMYMsZ+0zRL3YyenVOVZdaE2cCG8bhhPd vBXm4K91x+qmRM+tBwJBxstzzO6OqtLLPAJCyq/BlGr9R6lOsTkPKjVa22GPXYRe/mUb iQow== X-Gm-Message-State: AElRT7GE5kCc9bXrhYbQ5hemxDFlkEN0ovLm1R6LM6oVxDrmuvBnX1Zt duLstXVdSv0qNTrcXXL729sYXcq+ED5StXOWhyI= X-Google-Smtp-Source: AG47ELucnihjxvJQi2A0V94UkepseoCB2zBSCsjhRbXYjxgH+NsR7jCrSYBoas1Pvhu9Uz/Ye/o275ta5yLnrfnx44w= X-Received: by 2002:a19:4f0a:: with SMTP id d10-v6mr5957035lfb.134.1521382791587; Sun, 18 Mar 2018 07:19:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d8a:0:0:0:0:0 with HTTP; Sun, 18 Mar 2018 07:19:50 -0700 (PDT) In-Reply-To: References: <20180318131139.GA1127@laperouse.bortzmeyer.org> From: Massimiliano Fantuzzi Date: Sun, 18 Mar 2018 15:19:50 +0100 Message-ID: To: Daniel Stenberg Cc: Stephane Bortzmeyer , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000dc2e080567b08855" Archived-At: Subject: Re: [Doh] Support requirements for Head 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, 18 Mar 2018 14:19:58 -0000 --000000000000dc2e080567b08855 Content-Type: text/plain; charset="UTF-8" Either answer with 405 or support it as "cache-primer" helper ? As Daniel says, many servers drop this method... but in DOH context it may come helpful, IMHO. HEAD is there to asses the existence of a resource, why shall we not bring it along ? (i.e. may be supported but not a must ?) Best regards, max On Sun, Mar 18, 2018 at 2:30 PM, Daniel Stenberg wrote: > On Sun, 18 Mar 2018, Stephane Bortzmeyer wrote: > > My personal opinion is "if you support GET, you MUST support HEAD". Any >> HTTP advice? (Technically, it's nothing, the vast majority of DoH clients >> and servers already handle HEAD.) >> > > That is not strictly stated in RFC 7231 and the web is already populated > with lots of servers that don't respond to HEAD while responding fine to > GET. > > -- > > / daniel.haxx.se > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- *Massimiliano Fantuzzi* *IT professional, expert in DB Linux and networks.* *+41 76 754 1037 <%2B41%2076%20754%201037>* --000000000000dc2e080567b08855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Either answer with 405 or support it as "cache-primer= " helper ?
As Daniel says, many servers drop this method... b= ut in DOH context it may come helpful, IMHO.

HEAD is ther= e to asses the existence of a resource, why shall we not bring it along ? (= i.e. may be supported but not a must ?)

Best= regards,
max

On Sun, Mar 18, 2018 at 2:30 PM, Daniel Stenberg <danie= l@haxx.se> wrote:
On Sun, = 18 Mar 2018, Stephane Bortzmeyer wrote:

My personal opinion is "if you support GET, you MUST support HEAD"= ;. Any HTTP advice? (Technically, it's nothing, the vast majority of Do= H clients and servers already handle HEAD.)

That is not strictly stated in RFC 7231 and the web is already populated wi= th lots of servers that don't respond to HEAD while responding fine to = GET.

--

=C2=A0/ daniel.haxx.se

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



--

Massimiliano Fantuzzi
IT professional, expert in DB Linux and networks.

<= /div>
--000000000000dc2e080567b08855-- From nobody Sun Mar 18 07:38:18 2018 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 77A2312D80E for ; Sun, 18 Mar 2018 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhHq6VhpxV2b for ; Sun, 18 Mar 2018 07:38:15 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 7E9A012D7FC for ; Sun, 18 Mar 2018 07:38:15 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l9so1739686wmh.2 for ; Sun, 18 Mar 2018 07:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=Xyny/fdOfRwOC0A8VlFgUZO+ozsn+Yllg8W39Oj54w0=; b=SH1XVGWXnmDFi4NoaVJqDfg5Lt0pfvIRE8+l6nqD5puZgWH7KlKBPYS9gNBFUO1K// +4pMVh4YsEEXydknugvWf1frH3KIPQfK9ULIlvsf1z5Tpx4w5/FrFjs4Ag1DeB2M6eqd 4oTrjGAEl5BNLA4nR6cT3w5SwrcONpiFCxlK3AMVdSqojo91CFGEXQd778YTMm4lx4kU FF+83PfL9WdJBsSrVyyWSjO4eiBlAtg0AqVXARlWKR+y2VhcpC2TxdbkCTujGXvmKJG+ rAuD/QlorhgtUjQMGBI1WWf3iwK0WIHq6bFRat8KGhHFLAPCjSM3jG8xnTA2HqsSMCQC RCJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=Xyny/fdOfRwOC0A8VlFgUZO+ozsn+Yllg8W39Oj54w0=; b=Cnnsyo5x5PkriZItJVtudfYBSCLsRa2J/jT3oc+HhsiB2cMbBTrFCyc2qWDuqna2N+ 7ZzU8OUF9P9/wMltbe2kODBLr7t9H4421ZQcea6nkn7ysXGAILgrXAxowU2I13L5p56r oZ8+/17JfOCSp/8oYkPWn1pBxvvhZdiHSeCbXmIfRXL8nbJYB8Me1WdJXuhP6LwIg22o N5ne14IYUR4fqhlnjw9BOS9UwoDvlOF5KreAkZI517y5JeUWLKOc4N/u8onrHXg4fqYr 39DSJTndqYVlHM2/lRyDEkO8b0Do7ov7A9WiBg0wk79rjfOKdgT5yxbLd/4DVc7pt9Fy qGxw== X-Gm-Message-State: AElRT7HxGx2FBmNOAIyJ24AWPlb4/XqVh0iYAE67+4UTk59FsOoD0E2t lZyoYBez8OZsP9dX/psnaoIZVcXjb/k= X-Google-Smtp-Source: AG47ELs/EBTJ3NYOuc+jVOPIL61jkT9v9cYUXViJ4XXPsg3dtzonT+OVDsYT/gcpn5cMCUzdiodLAw== X-Received: by 10.28.159.68 with SMTP id i65mr6696956wme.27.1521383893496; Sun, 18 Mar 2018 07:38:13 -0700 (PDT) Received: from miek.nl ([2001:67c:1232:144:b320:5945:16d2:52c4]) by smtp.gmail.com with ESMTPSA id q6sm12482878wrc.30.2018.03.18.07.38.12 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 18 Mar 2018 07:38:12 -0700 (PDT) Date: Sun, 18 Mar 2018 14:38:11 +0000 From: Miek Gieben To: DoH WG Message-ID: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> Mail-Followup-To: DoH WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: [Doh] meta qtypes 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, 18 Mar 2018 14:38:17 -0000 Hi, -03 has the following text in section 7.1. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. DNS API servers may wish to consider whether providing these validation enabling response headers is worthwhile. this implies DoH servers need to support IXFR/AXFR (fine), but that replies to these may now be cached? I think this is new behavior from a DNS standpoint. (Should the draft also mention dynamic updates, notify messages and other opcodes as being supported?) /Miek -- Miek Gieben From nobody Sun Mar 18 07:53:38 2018 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 0114112D87D for ; Sun, 18 Mar 2018 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=evequefou.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 N9KOwwocXxfy for ; Sun, 18 Mar 2018 07:53:34 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0104.outbound.protection.outlook.com [104.47.42.104]) (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 876BC12D7FC for ; Sun, 18 Mar 2018 07:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gHZMK9fB62X7qjR9eeiXGhdBfXgCe0JlfGhrVzKEtnE=; b=V4cLxMrogfeKU8C8y8gGwTt8FXGC7eHhapDr0Ktak3JenVOcMeCYqN9EkQqsWvV/39WQYryHUrSitT/gFYctnJTeC4xLRJCL7RpPg0Z6NpKk67aFt+IV/on3U5HgOODvbWjZ+Pjeu8+qRpgIzxST4Ey6Y46RsdEZPCD6r/LisYs= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1966.namprd08.prod.outlook.com (10.169.39.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sun, 18 Mar 2018 14:53:31 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::b057:7190:752f:8cb9]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::b057:7190:752f:8cb9%13]) with mapi id 15.20.0588.016; Sun, 18 Mar 2018 14:53:31 +0000 From: Mike Bishop To: Tom Pusateri , "doh@ietf.org" Thread-Topic: [Doh] Hackathon javascript client & browser issue Thread-Index: AQHTvsL3ia8DzTa8Yk6+MsfLjroAf6PWD+kw Date: Sun, 18 Mar 2018 14:53:31 +0000 Message-ID: References: <07A79B82-9B30-4BA6-96C8-175707581178@bangj.com> In-Reply-To: <07A79B82-9B30-4BA6-96C8-175707581178@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:1232:144:95df:aab5:e062:49aa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1966; 7:qfm7//hbavWXH2Rz2dXabSDdI1Wny67KO8IaxcqMi6ZQmP/VNlS5yVWWfOKjwOtKXMpwItD3bvwmtbqo2uvqr/kvqSkjttjAOn4axfNAYmyb9XLF9Zgt/5CkC/ddOwHUumEcMMhscQ3vmVUePCNBHmp14+1QgtYRbpX1CQvLzRGwaiPWKNwFZZrGenioFdmuYMDxiLfEffFlPABLGulMV6ej02uC2wc+ejDRkizQEynBPvlF7BvdICFfpD3Plyo+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 32979f70-0f95-4fe6-b7d7-08d58ce0045c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1966; x-ms-traffictypediagnostic: SN1PR08MB1966: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(38517522185527)(126947320029983); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(10201501046)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1966; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1966; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39830400003)(366004)(396003)(376002)(39380400002)(346002)(199004)(189003)(13464003)(478600001)(966005)(8676002)(8936002)(6436002)(81166006)(106356001)(6116002)(102836004)(7696005)(76176011)(105586002)(53936002)(6506007)(97736004)(81156014)(33656002)(68736007)(59450400001)(53546011)(316002)(2900100001)(99286004)(110136005)(3660700001)(86362001)(25786009)(5250100002)(6306002)(9686003)(46003)(5660300001)(55016002)(74482002)(186003)(2950100002)(74316002)(3280700002)(229853002)(2501003)(7736002)(6246003)(305945005)(14454004)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1966; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: gZxb6dDWLjVjAKJmbkvvUW8C58j/59ckk6TNbFOndYwxtcoUUlQgW7YYQiLmprp6WRFZLxQ+aGlCJnFe4Y4t+qzp2o2Fn8KEib4ojZ0B5ZxwQfERJYN7abSxWGsJFZi8/qrofVL35od7GXKe1/EkLbqA2AE8tdNV0mJIO4m+18VyvVuTatVw6I9mBt2tYKqelPJWewcphEBFfCc8M3YtDpgP7t2jHOQy74ZUnU00u2sdR8HavwIyGWTr4sGVhKDLLwGMTzzsnc5Tl9QamjLAGP35pUbeBXboUibvgvXx497hqT55rd8VrHzGDGzcO6vw8m0UoT5J6O0VNY+xMzJFDg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 32979f70-0f95-4fe6-b7d7-08d58ce0045c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2018 14:53:31.5447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1966 Archived-At: Subject: Re: [Doh] Hackathon javascript client & browser issue 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, 18 Mar 2018 14:53:37 -0000 SSB0aGluayB0aGUgYW5zd2VyIGlzICJ5ZXMiIHRvIGJvdGgsIGFjdHVhbGx5LiAgQSBzZXJ2ZXIg dGhhdCB3YW50cyB0byBhbnN3ZXIgcmVxdWVzdHMgZnJvbSBjb250ZW50IG9uIG90aGVyIHNpdGVz IHNob3VsZCBhY2NlcHQgdGhlIHByZS1mbGlnaHQuICBCdXQgaXQncyB3b3JraW5nIGFzIGludGVu ZGVkIHRvIGtlZXAgeW91IGZyb20gZmlyaW5nIG9mZiBETlMgcmVxdWVzdHMgdG8gYXJiaXRyYXJ5 IHNlcnZlcnMuDQoNClByZXN1bWFibHkgRG9IIGJlaW5nIGRvbmUgYnkgdGhlIGJyb3dzZXIgb3Ig c3lzdGVtLCByYXRoZXIgdGhhbiBieSBhIHdlYnBhZ2UgaXRzZWxmLCB3b3VsZG4ndCBiZSBzdWJq ZWN0IHRvIHRoZXNlIHJlc3RyaWN0aW9ucy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IERvaCA8ZG9oLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb20gUHVzYXRl cmkNClNlbnQ6IFN1bmRheSwgTWFyY2ggMTgsIDIwMTggMjoxMSBQTQ0KVG86IGRvaEBpZXRmLm9y Zw0KU3ViamVjdDogW0RvaF0gSGFja2F0aG9uIGphdmFzY3JpcHQgY2xpZW50ICYgYnJvd3NlciBp c3N1ZQ0KDQpXb3JraW5nIGluIHRoZSBoYWNrYXRob24sIEkgY3JlYXRlZCBhIHNpbXBsZSBub2Rl IGphdmFzY3JpcHQgY2xpZW50IHRvIHRlc3QgRG9ILg0KDQpodHRwczovL2dpdGh1Yi5jb20vcHVz YXRlcmkvZG9oLWNsaWVudA0KDQpUaGlzIHdvcmtzIGZpbmUgYW5kIHRoZW4gU3TDqXBoYW5lIGFz a2VkIGlmIGl0IGNvdWxkIHJ1biBpbiB0aGUgYnJvd3Nlci4gU28gSSBkaWQgdGhpczoNCg0KaHR0 cHM6Ly9naXRodWIuY29tL3B1c2F0ZXJpL2RvaC13ZWJwYWNrDQoNCkhvd2V2ZXIsIHdoZW4gc2Vu ZGluZyBhIFBPU1QgdG8gYSB0ZXN0IHNlcnZlciwgSSBhbSBnZXR0aW5nIGEgZXJyb3IgKDQwMCkg cmVzcG9uc2UgdG8gYW4gaW5pdGlhbCBwcmUtZmxpZ2h0IE9QVElPTlMgcmVxdWVzdC4NCg0KQWNj b3JkaW5nIHRvIGh0dHBzOi8vZGV2ZWxvcGVyLm1vemlsbGEub3JnL2VuLVVTL2RvY3MvV2ViL0hU VFAvQ09SUyNTaW1wbGVfcmVxdWVzdHMNCg0KVGhlIG9ubHkgY29udGVudCB0eXBlcyBhbGxvd2Vk IGZvciBhIFBPU1QgYXJlOg0KDQoJ4oCiIGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2Rl ZA0KCeKAoiBtdWx0aXBhcnQvZm9ybS1kYXRhDQoJ4oCiIHRleHQvcGxhaW4NCg0Kc28gYSBxdWVz dGlvbiBJIGhhdmUsIHNob3VsZCB0aGUgRG9IIHNlcnZlcnMgcmVzcG9uZCB0byBhIHByZS1mbGln aHQgT1BUSU9OUyBtZXRob2Qgb3IgYXJlIHRoaW5ncyB3b3JraW5nIGFzIGRlc2lnbmVkIGJlY2F1 c2UgdGhpcyBzaG91bGRu4oCZdCBiZSBhbGxvd2VkIHRvIHJ1biBpbiBhIGJyb3dzZXI/DQoNClRo YW5rcywNClRvbQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRG9oIG1haWxpbmcgbGlzdA0KRG9oQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvaA0K From nobody Sun Mar 18 08:09:18 2018 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 B122C126E01 for ; Sun, 18 Mar 2018 08:09:16 -0700 (PDT) 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 zUmfoSTdFYCV for ; Sun, 18 Mar 2018 08:09:14 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8B123126BF7 for ; Sun, 18 Mar 2018 08:09:14 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id C24BB3A021 for ; Sun, 18 Mar 2018 11:09:13 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id 20so5257271oiq.5 for ; Sun, 18 Mar 2018 08:09:13 -0700 (PDT) X-Gm-Message-State: AElRT7FtvqfF0nQvWVZRQuFzkyZC1jTeFCkGUN7PCuLUJiVFrwPlH/4w lcmEg3w+KPBE5BgEJhBJe/0jJ6pR6p1SYDkhbdQ= X-Google-Smtp-Source: AG47ELvH75M5PmEQwZ5WzibLkNyFfqAc3S4e2Xui3goyzeSkqA+hWPlUCRJKpKv2rQQGcEM8ezgqU2fC1sOdP/qDRRI= X-Received: by 10.202.3.65 with SMTP id 62mr5470809oid.38.1521385753350; Sun, 18 Mar 2018 08:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 08:09:12 -0700 (PDT) In-Reply-To: <07A79B82-9B30-4BA6-96C8-175707581178@bangj.com> References: <07A79B82-9B30-4BA6-96C8-175707581178@bangj.com> From: Patrick McManus Date: Sun, 18 Mar 2018 15:09:12 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Tom Pusateri Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a113ba08065212d0567b13930" Archived-At: Subject: Re: [Doh] Hackathon javascript client & browser issue 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, 18 Mar 2018 15:09:16 -0000 --001a113ba08065212d0567b13930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Layers ahoy! The rules that govern javascript networking are broadly from xhr/fetch/CORS (non IETF standards) and these apply to javascript using any HTTP API. There is nothing particular of DoH, but a browser-js implementation of DoH is subject to them (as would be accessing a published REST API for example). In the configuration you describe, the HTTP server is indeed going to need to whitelist the preflight - but neither the preflight request or response is itself a DoH request/response.Indeed, they are literally the pre-flight before the DoH flight. And its a bit of an aside, but I'm pretty happy with this outcome. It means DNS is accessible from js-content but only subject to the web's existing Same-Origin/Cross-Origin security model.. which is something that has known properties. -P On Sun, Mar 18, 2018 at 2:10 PM, Tom Pusateri wrote: > Working in the hackathon, I created a simple node javascript client to > test DoH. > > https://github.com/pusateri/doh-client > > This works fine and then St=C3=A9phane asked if it could run in the brows= er. So > I did this: > > https://github.com/pusateri/doh-webpack > > However, when sending a POST to a test server, I am getting a error (400) > response to an initial pre-flight OPTIONS request. > > According to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS# > Simple_requests > > The only content types allowed for a POST are: > > =E2=80=A2 application/x-www-form-urlencoded > =E2=80=A2 multipart/form-data > =E2=80=A2 text/plain > > so a question I have, should the DoH servers respond to a pre-flight > OPTIONS method or are things working as designed because this shouldn=E2= =80=99t be > allowed to run in a browser? > > Thanks, > Tom > > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113ba08065212d0567b13930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Layers ahoy!

The rules that = govern javascript networking are broadly from xhr/fetch/CORS (non IETF stan= dards) and these apply to javascript using any HTTP API. There is nothing p= articular of DoH, but a browser-js implementation of DoH is subject to them= (as would be accessing a published REST API for example). In the configura= tion you describe, the HTTP server is indeed going to need to whitelist the= preflight - but neither the preflight request or response is itself a DoH = request/response.Indeed, they are literally the pre-flight before the DoH f= light.

And its a bit of an aside, but I'm = pretty happy with this outcome. It means DNS is accessible from js-content = but only subject to the web's existing Same-Origin/Cross-Origin securit= y model.. which is something that has known properties.

-P

On Sun, Mar 18, 2018 at 2:10 PM, Tom Pusateri <pusa= teri@bangj.com> wrote:
Work= ing in the hackathon, I created a simple node javascript client to test DoH= .

https://github.com/pusateri/doh-client

This works fine and then St=C3=A9phane asked if it could run in the browser= . So I did this:

https://github.com/pusateri/doh-webpack

However, when sending a POST to a test server, I am getting a error (400) r= esponse to an initial pre-flight OPTIONS request.

According to https://developer= .mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests

The only content types allowed for a POST are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 application/x-www-form-urlencode= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 multipart/form-data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 text/plain

so a question I have, should the DoH servers respond to a pre-flight OPTION= S method or are things working as designed because this shouldn=E2=80=99t b= e allowed to run in a browser?

Thanks,
Tom




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

--001a113ba08065212d0567b13930-- From nobody Sun Mar 18 08:31:51 2018 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 23FE312D80F for ; Sun, 18 Mar 2018 08:31:48 -0700 (PDT) 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 hpDzrAnNQMeE for ; Sun, 18 Mar 2018 08:31:46 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 4E04B126E01 for ; Sun, 18 Mar 2018 08:31:46 -0700 (PDT) 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]:54875) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1exaHh-000Y8i-JP (Exim 4.89_2) for doh@ietf.org (return-path ); Sun, 18 Mar 2018 15:31:45 +0000 Date: Sun, 18 Mar 2018 15:31:44 +0000 From: Tony Finch To: DoH WG In-Reply-To: <20180318103141.a5wacb75qzsgsjqp@miek.nl> Message-ID: References: <20180318103141.a5wacb75qzsgsjqp@miek.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: [Doh] doh101: IETF hackathon server implementation 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, 18 Mar 2018 15:31:48 -0000 I have published my OpenResty-based DNS-over-TLS and DNS-over-HTTPS proxy at https://dotat.at/cgi/git/doh101.git and https://github.com/fanf2/doh101 The name refers both to the IETF 101 hackathon and to the fact that it is very basic. It comes with a trivial perl test client. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher: East 5 or 6, backing northwest 5 to 7. Slight or moderate, occasionally rough. Fair. Good. From nobody Sun Mar 18 08:45:00 2018 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 4E1B8127AD4 for ; Sun, 18 Mar 2018 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 r18zQzScwSE7 for ; Sun, 18 Mar 2018 08:44:57 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 40AAE1242EA for ; Sun, 18 Mar 2018 08:44:57 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id C79353A021 for ; Sun, 18 Mar 2018 11:44:55 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id 20so5296724oiq.5 for ; Sun, 18 Mar 2018 08:44:55 -0700 (PDT) X-Gm-Message-State: AElRT7F1S1jeIwJYPTbFhN8CA+XnHonF++lyYWLrTGwg3egKSFy8dO/m Dp8u1BGWMgsiznYAfjYZVln89zkaQICJZTyR6h0= X-Google-Smtp-Source: AG47ELs8VmSud4PKuAc3qdpLwoBhLWtrrYmJdGmJCENwuQiRPeqv2Q0gNbtIySqLhYrbEwnpMgHXm5gwop1KesLCrdM= X-Received: by 10.202.178.195 with SMTP id b186mr4894972oif.337.1521387895504; Sun, 18 Mar 2018 08:44:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 08:44:54 -0700 (PDT) In-Reply-To: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> From: Patrick McManus Date: Sun, 18 Mar 2018 15:44:54 +0000 X-Gmail-Original-Message-ID: Message-ID: To: DoH WG Content-Type: multipart/alternative; boundary="001a113ce93213c6e60567b1b948" Archived-At: Subject: Re: [Doh] meta qtypes 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, 18 Mar 2018 15:44:59 -0000 --001a113ce93213c6e60567b1b948 Content-Type: text/plain; charset="UTF-8" Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I'm not aware of whether it does or not) - the text is just meant to give the HTTP considerations when it does carry larger DNS responses such as that. WRT HTTP caching - section 4 of DoH talks about how HTTP freshness lifetimes should be set for DoH responses. Is there something different here? -Patrick On Sun, Mar 18, 2018 at 2:38 PM, Miek Gieben wrote: > Hi, > > -03 has the following text in section 7.1. > > Other types of DNS data, such as > zone transfers, may be larger and benefit more from revalidation. > DNS API servers may wish to consider whether providing these > validation enabling response headers is worthwhile. > > this implies DoH servers need to support IXFR/AXFR (fine), but that > replies to these may now be cached? I think this is new behavior from a DNS > standpoint. > > (Should the draft also mention dynamic updates, notify messages and other > opcodes as being supported?) > > /Miek > > -- > Miek Gieben > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113ce93213c6e60567b1b948 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi - DoH itself doesn't require axfr/etc anywhere= that DNS would not (I'm not aware of whether it does or not) - the tex= t is just meant to give the HTTP considerations when it does carry larger D= NS responses such as that.

WRT HTTP caching - sect= ion 4 of DoH talks about how HTTP freshness lifetimes should be set for DoH= responses. Is there something different here?

-Pa= trick


On Sun, Mar 18, 2018 at 2:38 PM, Miek Gieben <miek@miek.nl= > wrote:
Hi,

-03 has the following text in section 7.1.

=C2=A0 Other types of DNS data, such as
=C2=A0 zone transfers, may be larger and benefit more from revalidation. =C2=A0 DNS API servers may wish to consider whether providing these
=C2=A0 validation enabling response headers is worthwhile.

this implies DoH servers need to support IXFR/AXFR (fine), but that replies= to these may now be cached? I think this is new behavior from a DNS standp= oint.

(Should the draft also mention dynamic updates, notify messages and other o= pcodes as being supported?)

/Miek

--
Miek Gieben

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

--001a113ce93213c6e60567b1b948-- From nobody Sun Mar 18 09:37:01 2018 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 4D5B9127275 for ; Sun, 18 Mar 2018 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4EELFA_ue_40 for ; Sun, 18 Mar 2018 09:36:57 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 42580126C25 for ; Sun, 18 Mar 2018 09:36:57 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 990ADA05CF; Sun, 18 Mar 2018 17:36:54 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 9ACDCEC0B87; Sun, 18 Mar 2018 17:35:22 +0100 (CET) Date: Sun, 18 Mar 2018 16:35:22 +0000 From: Stephane Bortzmeyer To: Daniel Stenberg Cc: Stephane Bortzmeyer , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , doh@ietf.org Message-ID: <20180318163522.GA6724@laperouse.bortzmeyer.org> References: <20180318131139.GA1127@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] Support requirements for Head 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, 18 Mar 2018 16:36:59 -0000 On Sun, Mar 18, 2018 at 02:30:34PM +0100, Daniel Stenberg wrote a message of 17 lines which said: > the web is already populated with lots of servers that don't respond > to HEAD while responding fine to GET. "The Web is large, and full of errors" (the red priestess, in Game of Thrones). Seriously, I know that no RFC will make errors and bugs disappear but we can at least express a preference? From nobody Sun Mar 18 09:43:27 2018 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 86B0412946D for ; Sun, 18 Mar 2018 09:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Elas9GX45b6e for ; Sun, 18 Mar 2018 09:43:24 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 425FE128961 for ; Sun, 18 Mar 2018 09:43:24 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id E2173A05CF; Sun, 18 Mar 2018 17:43:22 +0100 (CET) Received: by godin (Postfix, from userid 1000) id C86A1EC0B87; Sun, 18 Mar 2018 17:43:07 +0100 (CET) Date: Sun, 18 Mar 2018 16:43:07 +0000 From: Stephane Bortzmeyer To: Ted Hardie Cc: doh@ietf.org Message-ID: <20180318164307.GB6724@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 16:43:25 -0000 On Sat, Mar 17, 2018 at 10:42:08AM -0700, Ted Hardie wrote a message of 182 lines which said: > Similarly, it was not clear to me whether a response like 451 could > contain a UDP wireformat body and, if so, what it would be. If it > contains no body, the DNS implementation might continue attempting > to query for the information. If it contains a REFUSED RCODE, in > contrast, it would see a policy-based error. That's an interesting example. If a DoH server replies 451, does it mean that access to this DoH service is blocked, for policy reasons, or that access to this specific DNS data is blocked, for policy reasons? In other words, can a HTTP response from a DoH server depend on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?) May be a way to address this issue would be to say "HTTP status code depends only on the HTTP request and server, never (MUST NOT) on the DNS question"? From nobody Sun Mar 18 09:44:06 2018 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 71408127369 for ; Sun, 18 Mar 2018 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 J_6iM4YGQtfM for ; Sun, 18 Mar 2018 09:44:02 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1F4126C25 for ; Sun, 18 Mar 2018 09:44:02 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w2IGhxCN020966 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Mar 2018 17:43:59 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w2IGhxZQ020962; Sun, 18 Mar 2018 17:43:59 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 18 Mar 2018 17:43:59 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Stephane Bortzmeyer cc: =?ISO-8859-15?Q?=D3lafur_Gu=F0mundsson?= , doh@ietf.org In-Reply-To: <20180318163522.GA6724@laperouse.bortzmeyer.org> Message-ID: References: <20180318131139.GA1127@laperouse.bortzmeyer.org> <20180318163522.GA6724@laperouse.bortzmeyer.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] Support requirements for Head 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, 18 Mar 2018 16:44:05 -0000 On Sun, 18 Mar 2018, Stephane Bortzmeyer wrote: > Seriously, I know that no RFC will make errors and bugs disappear but we can > at least express a preference? I argued against a MUST where the HTTP spect itself doesn't have a MUST. I think that is stronger than "a preference". I'm fine with a preference! -- / daniel.haxx.se From nobody Sun Mar 18 09:56:19 2018 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 87429128C0A for ; Sun, 18 Mar 2018 09:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aWagvTq57mNe for ; Sun, 18 Mar 2018 09:56:17 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 DDBBA1289B0 for ; Sun, 18 Mar 2018 09:56:16 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 4B960A05CF; Sun, 18 Mar 2018 17:56:15 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 0457CEC0B87; Sun, 18 Mar 2018 17:53:57 +0100 (CET) Date: Sun, 18 Mar 2018 16:53:57 +0000 From: Stephane Bortzmeyer To: Tony Finch Cc: Ted Hardie , doh@ietf.org Message-ID: <20180318165356.GA7198@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 16:56:18 -0000 On Sun, Mar 18, 2018 at 10:11:41AM +0000, Tony Finch wrote a message of 62 lines which said: > If the request is not HEAD/GET/POST, I return 405 Method Not Allowed > with a browser-friendly body. > > For POST requests with an unknown Content-Type, or GET requests with > an unknown or missing `ct=` parameter, my server returns 415 > Unsupported Media Type with a browser-friendly body. > > If the `dns=` parameter is missing from a GET request, the best > response seems to be a browser-friendly 400 Bad Request. > If the request's Accept: header doesn't allow > `application/dns-udpwireformat` then the response should be a > browser-friendly 406 Not Acceptable. I agree with all this (and my hackathon-developed server does the same) but, to follow Patrick McManus' idea of not restating everything which is in HTTP, may be this could go in a non-normative appendix such as "Implementation suggestions for non-HTTP experts"? With lowercase "should" (specially for the last one: today, all the DoH servers completely ignore Accept:) From nobody Sun Mar 18 11:18:36 2018 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 95B1B126BF3 for ; Sun, 18 Mar 2018 11:18:34 -0700 (PDT) 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 UzJca3h6nLpw for ; Sun, 18 Mar 2018 11:18:31 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDD124D6C for ; Sun, 18 Mar 2018 11:18:31 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id A62933A051 for ; Sun, 18 Mar 2018 14:18:30 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id u73so12558380oie.3 for ; Sun, 18 Mar 2018 11:18:30 -0700 (PDT) X-Gm-Message-State: AElRT7F0CtmAncUCko+Wx0FxrKwXezbfoW/dfxhep7iwzdwMEEGUoJxR j8A/v9XsaQK6T+RbL8Qk3f6wGJmiyqr2+LB4f7w= X-Google-Smtp-Source: AG47ELtVQpYXisJbvKvhLEN/29onKDYRXsB1Vs9qaMw07l1NUoCF/lbSEezfkVQbXUMELQFhAwVRYOgloWKucpdlPQA= X-Received: by 10.202.178.195 with SMTP id b186mr5092183oif.337.1521397110295; Sun, 18 Mar 2018 11:18:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 11:18:29 -0700 (PDT) In-Reply-To: <20180318164307.GB6724@laperouse.bortzmeyer.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> From: Patrick McManus Date: Sun, 18 Mar 2018 18:18:29 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Stephane Bortzmeyer Cc: Ted Hardie , DoH WG Content-Type: multipart/alternative; boundary="001a113ce932525dda0567b3deca" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 18 Mar 2018 18:18:35 -0000 --001a113ce932525dda0567b3deca Content-Type: text/plain; charset="UTF-8" On Sun, Mar 18, 2018 at 4:43 PM, Stephane Bortzmeyer wrote: > On Sat, Mar 17, 2018 at 10:42:08AM -0700, > Ted Hardie wrote > a message of 182 lines which said: > > > Similarly, it was not clear to me whether a response like 451 could > > contain a UDP wireformat body and, if so, what it would be. If it > > contains no body, the DNS implementation might continue attempting > > to query for the information. If it contains a REFUSED RCODE, in > > contrast, it would see a policy-based error. > > That's an interesting example. If a DoH server replies 451, does it > mean that access to this DoH service is blocked, for policy reasons, > or that access to this specific DNS data is blocked, for policy > reasons? In other words, can a HTTP response from a DoH server depend > on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?) > > Unfortunately I don't think HTTP is going to clarify for you why HTTP is giving the 451 - all you know is that the response body is not the answer to your DoH request. The 451 could be based on anything in the HTTP request - which includes the query params and the message body as well as the path and origin. So you don't know what was wrong with the request in particular. So it could imo be as general as the hostname or as specific as a qtype. But I can say concretely that the message body of the 451 isn't going to clear that up in anything other than a human readable way. -P --001a113ce932525dda0567b3deca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 18, 2018 at 4:43 PM, Stephane Bortzmeyer = <bortzmeyer@nic.f= r> wrote:
On Sat, Mar 17, 2= 018 at 10:42:08AM -0700,
=C2=A0Ted Hardie <ted.ietf@gmail.com> wrote
=C2=A0a message of 182 lines which said:

> Similarly, it was not clear to me whether a response like 451 could > contain a UDP wireformat body and, if so, what it would be.=C2=A0 If i= t
> contains no body, the DNS implementation might continue attempting
> to query for the information.=C2=A0 If it contains a REFUSED RC= ODE, in
> contrast, it would see a policy-based error.

That's an interesting example. If a DoH server replies 451, does= it
mean that access to this DoH service is blocked, for policy reasons,
or that access to this specific DNS data is blocked, for policy
reasons? In other words, can a HTTP response from a DoH server depend
on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?)


Unfortunately I don't think HTTP i= s going to clarify for you why HTTP is giving the 451 - all you know is tha= t the response body is not the answer to your DoH request. The 451 could be= based on anything in the HTTP request - which includes the query params an= d the message body as well as the path and origin. So you don't know wh= at was wrong with the request in particular. So it could imo be as general = as the hostname or as specific as a qtype.

But I c= an say concretely that the message body of the 451 isn't going to clear= that up in anything other than a human readable way.

<= div>-P


--001a113ce932525dda0567b3deca-- From nobody Sun Mar 18 12:08:14 2018 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 A18A8126D73 for ; Sun, 18 Mar 2018 12:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCrqzc93nitS for ; Sun, 18 Mar 2018 12:08:11 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 A69A8126BF3 for ; Sun, 18 Mar 2018 12:08:10 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id s10so3604062wra.13 for ; Sun, 18 Mar 2018 12:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=aGfBa2OHxkrZBj3LO3qAN+N6OH3qlWi1qnaw7BJB1dQ=; b=CX62ZVwswmKIkD/1AGd4to/zyPGqxwqnXC7GT/Uqe6+LZRq4Yh8mKdR2doo+hNPDR7 7ROAjlXTMpoucKiSKf1hJj2Z2iZMgIp0h1KcFWHAgU+lIMTbVjWXgNquOV9hUTn8t8qr 3wRT1FIOP7k0ZemApzfQEtjMmMke7qesC9rSDAAvPDMdD1O1/xLuYcIgC/mscvgJCn2k SiyWkHSclhk8hbHf9egXCCPAvywMVVYojSku1FFjWNK8vB9Sq/sVZ6MQaeG+dn7eGsX0 2DvEoxBANmRLOq6VDnlC95aqlj/JsRmLN031g2LFGClPaq4GdQlwNd0Ucp5NXplL9cTj Ta/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=aGfBa2OHxkrZBj3LO3qAN+N6OH3qlWi1qnaw7BJB1dQ=; b=AibO6D3HoudePvDIAwh4YkuYg/2PMOeDJWt3dvHeBF4CZZ2n1bVbRcTtifS0pk73iH 8q1/cgdJljk88sJe3SSKsCTit40YIx1XZx4iA1O5IMXerHI91yTX3Ba2pXOZCXph7QcJ ACZTxGuXcdq+ugQ50MG+hqmwcVAt32EgrFSxW039UPpF4zT6vIau2PfO6dJkm2SDnK89 6l45+g66EqKVVS4CxghoXUwwvitRSnG76XJBb/TZL8mubEF2LmSS5UeYKWroM9AisDF+ CHgDgPPhBKbox6zapIrjxeem0+/FjBAe14PceFSOC/gHBb2wsuyn+xSKrEQuQi+yRWxk Lcbg== X-Gm-Message-State: AElRT7EZF88HyIQuj5PuRZt1zRv6FGFa8axt1dx4cqtECmyIpOUQM4bW tpyEHl/IylN7OwtLxqn8TjG7qw== X-Google-Smtp-Source: AG47ELux1Dtwm1jdENLZ1tmkDmTM0H88/0+P9ZiJY4LooMGy5j21uiYoiR28ACLotHYhwmI9g1jB5g== X-Received: by 10.223.150.11 with SMTP id b11mr6801964wra.55.1521400088472; Sun, 18 Mar 2018 12:08:08 -0700 (PDT) Received: from miek.nl (3.a.e.9.4.2.6.a.6.1.a.8.c.5.1.f.f.3.c.4.9.5.f.b.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf59:4c3f:f15c:8a16:a624:9ea3]) by smtp.gmail.com with ESMTPSA id s26sm15682523wrb.10.2018.03.18.12.08.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 18 Mar 2018 12:08:06 -0700 (PDT) Date: Sun, 18 Mar 2018 19:08:04 +0000 From: Miek Gieben To: Patrick McManus Cc: DoH WG Message-ID: <20180318190804.5mgxarazepfut56i@miek.nl> Mail-Followup-To: Patrick McManus , DoH WG References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] meta qtypes 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, 18 Mar 2018 19:08:13 -0000 [ Quoting in "Re: [Doh] meta qtypes..." ] >Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I'm >not aware of whether it does or not) - the text is just meant to give the >HTTP considerations when it does carry larger DNS responses such as that. > >WRT HTTP caching - section 4 of DoH talks about how HTTP freshness >lifetimes should be set for DoH responses. Is there something different >here? This HTTP caching opens up a pretty big can of worms on what to set the cache TTL to. If we consider HTTP/2 *just* the transport than it should not be concerned with caching (i.e. TCP doesn't cache). If we do want to cache on this layer a server implementing DoH needs to inspect the DNS packet, it should (among other things), look for a SOA record to get a TTL or MINTTL, or get the minimum TTL of all the records in the message, or look for RRSIG expiration times and distill a minimum TTL from those. I think this draft should say "MUST not cache these responses". /Miek -- Miek Gieben From nobody Sun Mar 18 12:20:41 2018 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 48FBB129C6D for ; Sun, 18 Mar 2018 12:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=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 IRRxWzHyXbxG for ; Sun, 18 Mar 2018 12:20:37 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4695B1270A0 for ; Sun, 18 Mar 2018 12:20:37 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id y128so811106iod.4 for ; Sun, 18 Mar 2018 12:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=WGYduFJj91AGsoSftkmy3Wac1q+UlUCm2J26A50Aox8=; b=t3C3TAHFZm791r7JtJnfTZ21JPPdTpdZ9jSEH4Jw81EkyY5xU0ZhaOc7e7r6EEy/AY /Lrq12kSuvi4Oi5M4YVVBOyLrfsbYG4R3+uy3gPquXgpuArQb6kKSZnppjb/15+vrKYx 25ElA7IUfoy9KLwKBeueF2xybFOMUOa/6D9MAlOdghIlAd2qZGfuCxB1zAwsvb2b2GRU 1i1i6y5fir7m6CulSHM8VU+GeK5/T4ZgPXmw7Io4zUcZX0A3b+PZ8ZAF9E5cRWMNPM8+ dAnQYJyWBLU37j+Pmgws4Bc3fzaz9/vQsQ+3A6fKWXQHjfnsIKhPWgs6grFfUW7zo+ij Vy/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=WGYduFJj91AGsoSftkmy3Wac1q+UlUCm2J26A50Aox8=; b=oezhBOkKnZ17YbJ17nnc6HtsXoMrYTDXYv0XNSNpxaA0RlI9Zt05hhbM8Lojt9Uc4e GKa72pqjx87zrRTbjIU8lluk54bN2pkMrFuIcVqL0kB0KNzpPVHRqN2xAMvKbmUXDQcV l8Bgb6jDJansz4YtcPUPj9bnGDVXK3VrNhLMyplV3+uuezyCROGr54TA4yLLAa8gN6wd PZML1gK8h/bk3zwIn/x08EHEBfBIqPGQyRly7hB5agO5Bzy+1QIXfquuxBH3buicvf5b XtVw3RJDtDuNMj0URA6VDfzLTYDyrOnkV/VWSiZaj4bWqB8PCoKySuEkfl7JwW3DJ7Ta U2Sw== X-Gm-Message-State: AElRT7HdHrvnisphjQmvKFt3lwQsbXQzRgqGDVSBvQIszYm4LxYMuizh Q7BsFiIMn6OaOB3zomrDXKZqrhyX3ZqkYJKyhI08JbwR X-Google-Smtp-Source: AG47ELtH7MFvNLtdqBYLKjLHbDrNGW4Igsie/LGx0xZ1r+IYjkIfSDUUrGs74utIJb/9VW7wFnREB0UaAwhFJvW4+to= X-Received: by 10.107.166.209 with SMTP id p200mr5201182ioe.214.1521400836252; Sun, 18 Mar 2018 12:20:36 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.79.161.219 with HTTP; Sun, 18 Mar 2018 12:20:35 -0700 (PDT) From: Erik Nygren Date: Sun, 18 Mar 2018 19:20:35 +0000 X-Google-Sender-Auth: uZnID0eqXC0hg_1r69RED7a0c1E Message-ID: To: doh@ietf.org, Jordi Palet Martinez , Lee Howard Content-Type: multipart/alternative; boundary="001a1141457a67e74a0567b4bc6d" Archived-At: Subject: [Doh] DNS64 and 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, 18 Mar 2018 19:20:39 -0000 --001a1141457a67e74a0567b4bc6d Content-Type: text/plain; charset="UTF-8" In reading through the dns-over-https draft I'm wondering if we should have some better coverage of DNS64 which is becoming widely deployed in some mobile environments. (See https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00 for some discussions which is on the v6ops agenda for this week.) Thinking some about this (and general IPv6-only deployments): * The section mentioning using IP literals as DOH service end-points may wish to point out the risk that this may have challenges due to mixtures of IPv6-only, dual-stacked, and IPv4-only environments. * It would be good to add a section on how applications using DOH may wish to handle "A" lookups in DNS64 environments. In particular, to do the DNS64-synthesis and construction in the client when no AAAA record is available and when a NAT64 prefix is available through a mechanism such as: RFC 7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis, RFC 7225 - Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) Doing the synthesis in the client seems preferable over trying to get the server to do synthesis with the proper prefix in most scenarios, plus in cases where the client is using the results directly this will get around some of the DNSSEC issues. At least for mobile, not using DNS64 synthesis in the client will likely result in this either breaking the client in NAT64 environments or causing something lower in the stack to do the equivalent (a 464xlat CLAT on Android or bump-in-the-API on iOS). Erik --001a1141457a67e74a0567b4bc6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In reading through the dns-over-https draft I= 9;m wondering if we should have some better coverage of DNS64 which is beco= ming widely deployed in some mobile environments.

(See http= s://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00 for some = discussions which is on the v6ops agenda for this week.)

= Thinking some about this (and general IPv6-only deployments):

=
* The section mentioning using IP literals as DOH service end-points m= ay wish to point out the risk that this may have challenges due to mixtures= of IPv6-only, dual-stacked, and IPv4-only environments.

= * It would be good to add a section on how applications using DOH may wish = to handle "A" lookups in DNS64 environments.=C2=A0 In particular,= to do the DNS64-synthesis and construction in the client when no AAAA reco= rd is available and when a NAT64 prefix is available through a mechanism su= ch as:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 RFC 7050 - Discovery of = the IPv6 Prefix Used for IPv6 Address Synthesis,
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC 7225 - Discovering NAT64 IPv6 P= refixes Using the Port Control Protocol (PCP)
=C2=A0Doing the= synthesis in the client seems preferable over trying to get the server to = do synthesis with the proper prefix in most scenarios, plus in cases where = the client is using the results directly this will get around some of the D= NSSEC issues.

At least for mobile, not using DNS64 synth= esis in the client will likely result in this either breaking the client in= NAT64 environments or causing something lower in the stack to do the equiv= alent (a 464xlat CLAT on Android or bump-in-the-API on iOS).
= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

--001a1141457a67e74a0567b4bc6d-- From nobody Sun Mar 18 12:48:00 2018 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 4F237129C59 for ; Sun, 18 Mar 2018 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 CZY-VklVl0UG for ; Sun, 18 Mar 2018 12:47:56 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6D126D73 for ; Sun, 18 Mar 2018 12:47:56 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id E3AB53A019 for ; Sun, 18 Mar 2018 15:47:55 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 71so1238334oie.12 for ; Sun, 18 Mar 2018 12:47:55 -0700 (PDT) X-Gm-Message-State: AElRT7Fmi/snq8HLfL1xvhW81pdHuIZkBo50BVXHXOqnuYiq7LEOJRdU mOiKaGjuUYhu9kVp/cp9tGj3+TSYV8nRaM6BcOc= X-Google-Smtp-Source: AG47ELvRr6Au9L893roDmE2vFR2hN9BZkNvyQeUfv3jhG4ft/OXmyRJL/0K+d3wpmvDsAqfzF+XwUpurRh+5ZiWEw84= X-Received: by 10.202.3.198 with SMTP id 189mr5282653oid.132.1521402475550; Sun, 18 Mar 2018 12:47:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 12:47:54 -0700 (PDT) Received: by 10.74.66.212 with HTTP; Sun, 18 Mar 2018 12:47:54 -0700 (PDT) In-Reply-To: <20180318190804.5mgxarazepfut56i@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> From: Patrick McManus Date: Sun, 18 Mar 2018 19:47:54 +0000 X-Gmail-Original-Message-ID: Message-ID: To: DoH WG Content-Type: multipart/alternative; boundary="001a11c0463c1d9d2a0567b51e07" Archived-At: Subject: Re: [Doh] meta qtypes 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, 18 Mar 2018 19:47:58 -0000 --001a11c0463c1d9d2a0567b51e07 Content-Type: text/plain; charset="UTF-8" Section 4 has spme rules about generating http freshness lifetimes from dns responses. Is there a text change to that you are proposing? On Mar 18, 2018 7:08 PM, "Miek Gieben" wrote: > [ Quoting in "Re: [Doh] meta qtypes..." ] > >> Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I'm >> not aware of whether it does or not) - the text is just meant to give the >> HTTP considerations when it does carry larger DNS responses such as that. >> >> WRT HTTP caching - section 4 of DoH talks about how HTTP freshness >> lifetimes should be set for DoH responses. Is there something different >> here? >> > > This HTTP caching opens up a pretty big can of worms on what to set the > cache > TTL to. > > If we consider HTTP/2 *just* the transport than it should not be concerned > with > caching (i.e. TCP doesn't cache). > > If we do want to cache on this layer a server implementing DoH needs to > inspect the DNS packet, it should (among other things), look for a SOA > record to get a TTL or MINTTL, or get the minimum TTL of all the records in > the message, or look for RRSIG expiration times and distill a minimum TTL > from those. > > I think this draft should say "MUST not cache these responses". > > /Miek > > -- > Miek Gieben > --001a11c0463c1d9d2a0567b51e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 4 has spme rules about generating http freshness = lifetimes from dns responses. Is there a text change to that you are propos= ing?

On Mar = 18, 2018 7:08 PM, "Miek Gieben" <miek@miek.nl> wrote:
[ Quoting <pmcmanus@mozilla.com> in "Re: [Doh] meta qtypes..."= ; ]
Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I= 'm
not aware of whether it does or not) - the text is just meant to give the HTTP considerations when it does carry larger DNS responses such as that.
WRT HTTP caching - section 4 of DoH talks about how HTTP freshness
lifetimes should be set for DoH responses. Is there something different
here?

This HTTP caching opens up a pretty big can of worms on what to set the cac= he
TTL to.

If we consider HTTP/2 *just* the transport than it should not be concerned = with
caching (i.e. TCP doesn't cache).

If we do want to cache on this layer a server implementing DoH needs to ins= pect the DNS packet, it should (among other things), look for a SOA record = to get a TTL or MINTTL, or get the minimum TTL of all the records in the me= ssage, or look for RRSIG expiration times and distill a minimum TTL from th= ose.

I think this draft should say "MUST not cache these responses".
/Miek

--
Miek Gieben
--001a11c0463c1d9d2a0567b51e07-- From nobody Mon Mar 19 02:01:54 2018 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 EEF47124BFA for ; Mon, 19 Mar 2018 02:01:52 -0700 (PDT) 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 IUSHOaQWGE8E for ; Mon, 19 Mar 2018 02:01:50 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 B444D1200F1 for ; Mon, 19 Mar 2018 02:01:50 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id E7483A05D0; Mon, 19 Mar 2018 10:01:46 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 3EC2FEC0BB8; Mon, 19 Mar 2018 10:00:48 +0100 (CET) Date: Mon, 19 Mar 2018 09:00:48 +0000 From: Stephane Bortzmeyer To: Erik Nygren Cc: doh@ietf.org, Jordi Palet Martinez , Lee Howard Message-ID: <20180319090048.GB16151@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] DNS64 and 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: Mon, 19 Mar 2018 09:01:53 -0000 On Sun, Mar 18, 2018 at 07:20:35PM +0000, Erik Nygren wrote a message of 86 lines which said: > At least for mobile, not using DNS64 synthesis in the client will > likely result in this either breaking the client in NAT64 > environments Is it a DNS64-specific problem? It could also happen if you have local-only domain names, dummy local TLDs, alternative roots, split-horizon, CDN, geo-based answers, or other DNS tricks. Yesterday, one IETFer told me that DoH was a bad idea because it allows people to avoid DNS-based national censorship… May be a warning "the DoH resolver may give you a different answer from what you would have got from the usual resolver"? From nobody Mon Mar 19 02:07:27 2018 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 5E53C126CE8 for ; Mon, 19 Mar 2018 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 jsQwt8CXVDwD for ; Mon, 19 Mar 2018 02:07:24 -0700 (PDT) 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 22D4A124BFA for ; Mon, 19 Mar 2018 02:07:24 -0700 (PDT) Received: from dhcp-9b0e.meeting.ietf.org (dhcp-9b0e.meeting.ietf.org [31.133.155.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id E8372242147B; Mon, 19 Mar 2018 09:07:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Jim Reid In-Reply-To: <20180319090048.GB16151@laperouse.bortzmeyer.org> Date: Mon, 19 Mar 2018 09:07:20 +0000 Cc: DOH Working Group Content-Transfer-Encoding: 7bit Message-Id: <675681BA-2B19-41A8-A8B9-F5BA1B0C2D50@rfc1035.com> References: <20180319090048.GB16151@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] DNS64 and 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: Mon, 19 Mar 2018 09:07:25 -0000 > On 19 Mar 2018, at 09:00, Stephane Bortzmeyer wrote: > > May be a warning "the DoH resolver may give you a different answer > from what you would have got from the usual resolver"? Surely not! DNS sometimes lies. Tell me it isn't so. :-) From nobody Mon Mar 19 02:18:59 2018 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 40EDC126DD9 for ; Mon, 19 Mar 2018 02:18:58 -0700 (PDT) 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 ziqz_EIQ746d for ; Mon, 19 Mar 2018 02:18:57 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 4C6A4124BFA for ; Mon, 19 Mar 2018 02:18:57 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id F1B85A05CF; Mon, 19 Mar 2018 10:18:55 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 4D47AEC0BB8; Mon, 19 Mar 2018 10:16:34 +0100 (CET) Date: Mon, 19 Mar 2018 09:16:34 +0000 From: Stephane Bortzmeyer To: Patrick McManus , DoH WG Message-ID: <20180319091634.GC16151@laperouse.bortzmeyer.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180318190804.5mgxarazepfut56i@miek.nl> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 09:18:58 -0000 On Sun, Mar 18, 2018 at 07:08:04PM +0000, Miek Gieben wrote a message of 31 lines which said: > I think this draft should say "MUST not cache these responses". I have a less radical proposal: "DoH servers SHOULD return a Cache-Control header (RFC 7234, section 5.2.2). They MAY send "Cache-control: no-cache" in all cases [if they're lazy]. For positive answers (ANCOUNT>0), if the DoH server returns "Cache-control: max-age=N", the maximum age MUST be the TTL of the answer seen by the Doh server. For negative answers (NXDOMAIN), if the DoH server returns "Cache-control: max-age=N", the maximum age MUST be calculated from the SOA record of the zone (RFC 2308, section 3) [note it allows a server to return "Cache-control: no-cache" only for NXDOMAIN]" From nobody Mon Mar 19 02:49:19 2018 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 CC19E1270B4 for ; Mon, 19 Mar 2018 02:49:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW4DZFxgwX4H for ; Mon, 19 Mar 2018 02:49:16 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 27755127010 for ; Mon, 19 Mar 2018 02:49:16 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id o8so17924477wra.1 for ; Mon, 19 Mar 2018 02:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2tRM2t0FEgzfzp/17hWew7SEfzQFklGfxxAw+22wbAA=; b=BVN98XZkCpz3SOZYtkYxfgw6zD7ApseYjPiOriZ8iPmeml4AOJcV1uUoWcC+G7bLbw epE6vvKmxV37Loud5eGOUS3166xlVBb59Cx5fw0EoDvpxXZSxzbjwUq+tqbtCa2vZERb Q+gk1oI36W24UWRkGW7QAifdUbKhrIF0b8lCTxMAFv6oxwGAxC/6IzTpAXMDy41RrvlM DbarIKdoYR2rRf+265Uj91kHYLwcimkaC5PZGn9Y6a1tNicyHJz0uSJw2beE+apN+ipp 34JJ6oZ+jbhjh3uqi03T458oIXciBD3jTmzAqwWirAN45DPw+S+oHy5BInfFqQWhdpcx 7CLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2tRM2t0FEgzfzp/17hWew7SEfzQFklGfxxAw+22wbAA=; b=ZBkneS8lt+EwijJkqOlpxPewNpEzyx8RLYTGayUa7iutoB9Iy3rbs0NEfY+cr4s8NU OaDiDIZql356zx8SbC2btbReNDhGeMA6qgj8QWc6wBMjYZxglFmiQmgYfM1a2K0grbUv TOhEWEEmRF35OGWfUpjoSF3dFVfCgPsDocPl9hOGcEc1ZeZ0lQjQqf6sqKMlSPontU9x I0C97ivu4ccor2WOSaPteBzup5sJWX3bJxDd49kWHEHhGblF5q5dWXNxuv4pYHaubIDj SjsuWTKoRBjIkiBtrGh5DsKiIMh1mfJu15YWwXn5YBLENLeZ1BZDZwH8WR++vLVN9Y3P 7HdA== X-Gm-Message-State: AElRT7FNYHz5nZkNbvzX1YJLR2sESRnjeQWIe8yFSPixQ5dWRWMD59xb zOQ+6IqexCjzX7b8j10k+xZ5Fw== X-Google-Smtp-Source: AG47ELsskNhzmFaB12bjLdMm/iYiv9ZRePGVWE7gvhSFixNC7LP7XbQQ5ICp2+xO+SWeUIrulSkLtQ== X-Received: by 10.223.131.37 with SMTP id 34mr9128889wrd.169.1521452954566; Mon, 19 Mar 2018 02:49:14 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:fe79:234c]) by smtp.gmail.com with ESMTPSA id z3sm12289130wme.3.2018.03.19.02.49.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 02:49:13 -0700 (PDT) Date: Mon, 19 Mar 2018 09:49:12 +0000 From: Miek Gieben To: Stephane Bortzmeyer Cc: Patrick McManus , DoH WG Message-ID: <20180319094912.46fts2zxxlk6o2jx@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180319091634.GC16151@laperouse.bortzmeyer.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 09:49:18 -0000 [ Quoting in "Re: [Doh] meta qtypes..." ] >> I think this draft should say "MUST not cache these responses". > >I have a less radical proposal: > >"DoH servers SHOULD return a Cache-Control header (RFC 7234, section >5.2.2). They MAY send "Cache-control: no-cache" in all cases [if >they're lazy]. For positive >answers (ANCOUNT>0), if the DoH server returns "Cache-control: >max-age=N", the maximum age MUST be the TTL of the answer seen by the >Doh server. For negative answers (NXDOMAIN), if the DoH server returns "Cache-control: >max-age=N", the maximum age MUST be calculated from the SOA record of >the zone (RFC 2308, section 3) [note it allows a server to return >"Cache-control: no-cache" only for NXDOMAIN]" I agree that this works (but still leaves out RRSIGs). The (major) downside is that a DoH server doesn't just ship bytes anymore; it need to fully inspect the payload to make an informed cache TTL decision. Note: I'm fine with either - nocache or something along the lines Stephane proposes. /Miek -- Miek Gieben From nobody Mon Mar 19 02:50:14 2018 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 17FD71270B4 for ; Mon, 19 Mar 2018 02:50:13 -0700 (PDT) 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 tZj0rxRbz3zF for ; Mon, 19 Mar 2018 02:50:11 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 87B9C127010 for ; Mon, 19 Mar 2018 02:50:11 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id y27so9572759oix.10 for ; Mon, 19 Mar 2018 02:50:11 -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=KxGQ1K/OX6bpO3SVl8O6gszTklB/msQ81R6N65CU+iY=; b=HWGHRk8vy9pRF4HAvvjrVt4UrLgqON7sGd+t91E5LhpLoQ59UMx+oj3ZcxqDg8hmlU WhSK0ACdwfMGmPYfvQpt9UmfwjqdrUuGns3QWV4p6GAtwWpD4rocy6HWcab/cGVo80My 1k/a/66H/1Yv9JafMXdDThqMBABlaLACllEfVG0in9IWGRZ+VeMiSXsLmC2zFN782YsT lgahYGgh7yNRbeQU9fopPZwy+FfXDdWkbAbJCrSEapx1gKTZXaE35RGkYCEtfV2sjONa uVqnjVZ6d4/ntNknK2US1Gynt6r0GzsFw/muDK1pkzgg/AjReZi23ZlUJNujo7K64VQG t6zQ== 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=KxGQ1K/OX6bpO3SVl8O6gszTklB/msQ81R6N65CU+iY=; b=UEN9uymfEmkqzEutvzi3ByBySbGJT4A5+gRQ2r6rtduDTCG3MJ8wJTwCETZ563zST+ bft9r5y0Aj6edilVz34BxJ//+18vFzlb30JCDsuEg2CHR8uiX5fMhk6YdnbcDHslvTLH 0t5z5S+SbcfNHadawTMlQQgdLino2v/YG2Dr9pnlSuWAqYJOGc6iIFln6CTp51FD2qV7 JbP9fArSThfMZvKwJotGPy8md5EfhZ5Ni9DTHjfEIaO67U32PVDVWwOeOVKk4Yu+pa2D qN93+XVNuaqINjrl+oPkM4I1GVFrEWKfBPRIRSlTM86jFTVHWSRwfM9AEgUB3aWlhip7 FrAw== X-Gm-Message-State: AElRT7HdxKoiubaKZ28fkWBJSRslNwNgRNOfHUERew0rFy5UEW21+uWc aHW7j3VmUcvMoxWszyItN/Y3C7zEF/EWddhPRfc= X-Google-Smtp-Source: AG47ELuB54wp/dyufORnldt5KGFuJtAu3P7fK5wbrKK3JsN4yIzG2+nb+WUsz53GgI82Gkl2wzDzYCMQchdcY46PZsQ= X-Received: by 10.202.190.70 with SMTP id o67mr3876648oif.103.1521453010816; Mon, 19 Mar 2018 02:50:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Mon, 19 Mar 2018 02:49:40 -0700 (PDT) In-Reply-To: References: <20180318164307.GB6724@laperouse.bortzmeyer.org> From: Ted Hardie Date: Mon, 19 Mar 2018 02:49:40 -0700 Message-ID: To: Patrick McManus Cc: Stephane Bortzmeyer , DoH WG Content-Type: multipart/alternative; boundary="001a113dd2804091a50567c0e284" Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 09:50:13 -0000 --001a113dd2804091a50567c0e284 Content-Type: text/plain; charset="UTF-8" In-line On Sun, Mar 18, 2018 at 11:18 AM, Patrick McManus wrote: > > > On Sun, Mar 18, 2018 at 4:43 PM, Stephane Bortzmeyer > wrote: > >> On Sat, Mar 17, 2018 at 10:42:08AM -0700, >> Ted Hardie wrote >> a message of 182 lines which said: >> >> > Similarly, it was not clear to me whether a response like 451 could >> > contain a UDP wireformat body and, if so, what it would be. If it >> > contains no body, the DNS implementation might continue attempting >> > to query for the information. If it contains a REFUSED RCODE, in >> > contrast, it would see a policy-based error. >> >> That's an interesting example. If a DoH server replies 451, does it >> mean that access to this DoH service is blocked, for policy reasons, >> or that access to this specific DNS data is blocked, for policy >> reasons? In other words, can a HTTP response from a DoH server depend >> on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?) >> >> > Unfortunately I don't think HTTP is going to clarify for you why HTTP is > giving the 451 - all you know is that the response body is not the answer > to your DoH request. The 451 could be based on anything in the HTTP request > - which includes the query params and the message body as well as the path > and origin. So you don't know what was wrong with the request in > particular. So it could imo be as general as the hostname or as specific as > a qtype. > > But I can say concretely that the message body of the 451 isn't going to > clear that up in anything other than a human readable way. > > The message body may not be able to answer this question completely, but it can clarify at the DNS level that this was REFUSED. The semantics of that are much closer to 451's meaning than producing no DNS-level response at all (which maps to "query did not complete" if I understand it correctly). Ted > -P > > > --001a113dd2804091a50567c0e284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In-line

On Sun, Mar 18, 2018 at 11:18 AM, Patrick M= cManus <pmcmanus@mozilla.com> wrote:


On Sun, Mar 18, 2018 at 4:43 PM, Stephane Bortzmeyer <bortzm= eyer@nic.fr> wrote:
On Sat,= Mar 17, 2018 at 10:42:08AM -0700,
=C2=A0Ted Hardie <ted.ietf@gmail.com> wrote
=C2=A0a message of 182 lines which said:

> Similarly, it was not clear to me whether a response like 451 could > contain a UDP wireformat body and, if so, what it would be.=C2=A0 If i= t
> contains no body, the DNS implementation might continue attempting
> to query for the information.=C2=A0 If it contains a REFUSED RC= ODE, in
> contrast, it would see a policy-based error.

That's an interesting example. If a DoH server replies 451, does= it
mean that access to this DoH service is blocked, for policy reasons,
or that access to this specific DNS data is blocked, for policy
reasons? In other words, can a HTTP response from a DoH server depend
on the QNAME? (Or on the tuple {QCLASS, QTYPE, QNAME}?)


Unfortunately I don't think= HTTP is going to clarify for you why HTTP is giving the 451 - all you know= is that the response body is not the answer to your DoH request. The 451 c= ould be based on anything in the HTTP request - which includes the query pa= rams and the message body as well as the path and origin. So you don't = know what was wrong with the request in particular. So it could imo be as g= eneral as the hostname or as specific as a qtype.

= But I can say concretely that the message body of the 451 isn't going t= o clear that up in anything other than a human readable way.


The message body may not be able= to answer this question completely, but it can clarify at the DNS level th= at this was REFUSED.=C2=A0 The semantics of that are much closer to 451'= ;s meaning than producing no DNS-level response at all (which maps to "= ;query did not complete" if I understand it correctly).

<= div>Ted

=C2=A0
-P



--001a113dd2804091a50567c0e284-- From nobody Mon Mar 19 03:12:44 2018 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 2CDC4126DC2 for ; Mon, 19 Mar 2018 03:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 csmqB1L50KkC for ; Mon, 19 Mar 2018 03:12:42 -0700 (PDT) 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 26095126CE8 for ; Mon, 19 Mar 2018 03:12:42 -0700 (PDT) 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; Mon, 19 Mar 2018 03:12:40 -0700 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; Mon, 19 Mar 2018 03:12:40 -0700 From: Paul Hoffman To: Ted Hardie CC: DoH WG Thread-Topic: [Ext] [Doh] A question on the mix of DNS and HTTP semantics Thread-Index: AQHTv2rP/VUpr+taDUO0M0VJnys/ag== Date: Mon, 19 Mar 2018 10:12:39 +0000 Message-ID: <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.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.47.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] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 10:12:43 -0000 On Mar 19, 2018, at 9:49 AM, Ted Hardie wrote: > The message body may not be able to answer this question completely, but = it can clarify at the DNS level that this was REFUSED. The semantics of th= at are much closer to 451's meaning than producing no DNS-level response at= all (which maps to "query did not complete" if I understand it correctly). Hopping up one level, I think you are describing a DOH server that inspects= queries or responses and chooses to change the HTTP response to use a non-= 2xx code. That seems fine, but it also seems like you are saying that the D= NS response inside that HTTP response should be understood by the client, a= nd in a code-specific way. Is that a fair summary? --Paul Hoffman= From nobody Mon Mar 19 03:13:21 2018 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 7EEAA12DA08 for ; Mon, 19 Mar 2018 03:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 z7pdrY3v4AuW for ; Mon, 19 Mar 2018 03:13:09 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 95005126DEE for ; Mon, 19 Mar 2018 03:13:09 -0700 (PDT) Received: from mail-ot0-f170.google.com (mail-ot0-f170.google.com [74.125.82.170]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0A9A43A052 for ; Mon, 19 Mar 2018 06:13:09 -0400 (EDT) Received: by mail-ot0-f170.google.com with SMTP id q5-v6so6093479oth.12 for ; Mon, 19 Mar 2018 03:13:09 -0700 (PDT) X-Gm-Message-State: AElRT7ErGZ/OdwUAUM1tdiozc3+y2LqKDG4vgn0uHVKcAvlU7TzPFxXJ ZUwx+4KTpIYnvsQfNqc7scHj0u9VZ59ugGsJe/E= X-Google-Smtp-Source: AG47ELulleiHwK0M8WZUmKgCQXNi6gSNCB2yyobcdcoEdFpamkpaT94SosFuUVEv2IZDb0/DhlNv16drqFJohAJ0oAk= X-Received: by 2002:a9d:17e3:: with SMTP id j90-v6mr7738491otj.2.1521454388727; Mon, 19 Mar 2018 03:13:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 03:13:08 -0700 (PDT) In-Reply-To: <20180319094912.46fts2zxxlk6o2jx@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> <20180319094912.46fts2zxxlk6o2jx@miek.nl> From: Patrick McManus Date: Mon, 19 Mar 2018 10:13:08 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Miek Gieben Cc: Stephane Bortzmeyer , Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="00000000000061d66c0567c1342c" Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 10:13:14 -0000 --00000000000061d66c0567c1342c Content-Type: text/plain; charset="UTF-8" we need to be careful about recommending a blind tunnel (aspect) of using HTTP by just disabling caches. That's not really great and doesn't meet the DoH goals - HTTP has a rich language to control caching at its level which I think can be well aligned with the DNS TTL architecture (and if no-cache plays a role for some small part, that's fine.). There is document text that already tries to discuss that in Section 6. Hopefully we can revise that if necessary. The text already contains a normative MUST NOT about using a http freshness lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH server that cannot figure this out can comply with a freshness lifetime of 0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel. Please note the draft uses language about freshness lifetime instead of normatively referencing cache-control for a reason (cc is used in "such as" and in an example). There are a number of ways in HTTP to express this concept and you want to be compatible with the existing definitions. Perhaps it just needs an additional para indicating a response bearing a negative answer needs a more pessimal algorithm (e.g. either not cachable or the SOA approach)? On Mon, Mar 19, 2018 at 9:49 AM, Miek Gieben wrote: > [ Quoting in "Re: [Doh] meta qtypes..." ] > >> I think this draft should say "MUST not cache these responses". >>> >> >> I have a less radical proposal: >> >> "DoH servers SHOULD return a Cache-Control header (RFC 7234, section >> 5.2.2). They MAY send "Cache-control: no-cache" in all cases [if >> they're lazy]. For positive >> answers (ANCOUNT>0), if the DoH server returns "Cache-control: >> max-age=N", the maximum age MUST be the TTL of the answer seen by the >> Doh server. For negative answers (NXDOMAIN), if the DoH server returns >> "Cache-control: >> max-age=N", the maximum age MUST be calculated from the SOA record of >> the zone (RFC 2308, section 3) [note it allows a server to return >> "Cache-control: no-cache" only for NXDOMAIN]" >> > > I agree that this works (but still leaves out RRSIGs). > > The (major) downside is that a DoH server doesn't just ship bytes anymore; > it need to fully inspect the payload to make an informed cache TTL decision. > > Note: I'm fine with either - nocache or something along the lines Stephane > proposes. > > /Miek > > -- > Miek Gieben > --00000000000061d66c0567c1342c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
we need to be careful about recommending a blind tunn= el (aspect) of using HTTP by just disabling caches. That's not really g= reat and doesn't meet the DoH goals - HTTP has a rich language to contr= ol caching at its level which I think can be well aligned with the DNS TTL = architecture (and if no-cache plays a role for some small part, that's = fine.). There is document text that already tries to discuss that in Sectio= n 6. Hopefully we can revise that if necessary.

Th= e text already contains a normative MUST NOT about using a http freshness l= ifetimes that exceeds DNS based TTL lifetimes of the response. A DOH server= that cannot figure this out can comply with a freshness lifetime of 0 - bu= t the goal here is not that a DOH server is a non-DNS-aware tunnel.

Please note the draft uses language about freshness l= ifetime instead of normatively referencing cache-control for a reason (cc i= s used in "such as" and in an example). There are a number of way= s in HTTP to express this concept and you want to be compatible with the ex= isting definitions.

Perhaps it just needs an= additional para indicating a response bearing a negative answer needs a mo= re pessimal algorithm (e.g. either not cachable or the SOA approach)?
=



On Mon, Mar 19, 2018 at 9:49 AM, Miek Gieben <miek@miek.nl= > wrote:
[ Quoting <bortzmeyer@nic.fr>= ; in "Re: [Doh] meta qtypes..." ]
I think this draft should say "MUST not cache these responses".

I have a less radical proposal:

"DoH servers SHOULD return a Cache-Control header (RFC 7234, section 5.2.2). They MAY send "Cache-control: no-cache" in all cases [if<= br> they're lazy]. For positive
answers (ANCOUNT>0), if the DoH server returns "Cache-control:
max-age=3DN", the maximum age MUST be the TTL of the answer seen by th= e
Doh server. For negative answers (NXDOMAIN), if the DoH server returns &quo= t;Cache-control:
max-age=3DN", the maximum age MUST be calculated from the SOA record o= f
the zone (RFC 2308, section 3) [note it allows a server to return
"Cache-control: no-cache" only for NXDOMAIN]"

 I agree that this works (but still leaves out RRSIGs).

The (major) downside is that a DoH server doesn't just ship bytes anymo= re; it need to fully inspect the payload to make an informed cache TTL deci= sion.

Note: I'm fine with either - nocache or something along the lines Steph= ane proposes.

/Miek

--
Miek Gieben

--00000000000061d66c0567c1342c-- From nobody Mon Mar 19 03:17:29 2018 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 6D555126E64 for ; Mon, 19 Mar 2018 03:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 EyHKX0o5BgD8 for ; Mon, 19 Mar 2018 03:17:26 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E1126DC2 for ; Mon, 19 Mar 2018 03:17:26 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id 2CAF63A056 for ; Mon, 19 Mar 2018 06:17:26 -0400 (EDT) Received: by mail-ot0-f169.google.com with SMTP id h8-v6so16764931oti.6 for ; Mon, 19 Mar 2018 03:17:26 -0700 (PDT) X-Gm-Message-State: AElRT7H6/oN1aBVZhQBAGda/PVM9iQzPjGD8UQhiPM2cxLHuF/JoKV80 eYcsHf68U+RYahyZ/sOf+FwR7GyuJavPGdojc7Q= X-Google-Smtp-Source: AG47ELvNdxoJR4OeIb87Yq3LC3E3CR0igMxTIknB/3XmU7xxla8Lb1pgb/ikx8SZT/8nJhbGFtAg9nZWBLGj3Q+/GnE= X-Received: by 2002:a9d:26d4:: with SMTP id i20-v6mr5485268otd.214.1521454645922; Mon, 19 Mar 2018 03:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 03:17:25 -0700 (PDT) In-Reply-To: <20180319090048.GB16151@laperouse.bortzmeyer.org> References: <20180319090048.GB16151@laperouse.bortzmeyer.org> From: Patrick McManus Date: Mon, 19 Mar 2018 10:17:25 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Stephane Bortzmeyer Cc: Erik Nygren , Lee Howard , DoH WG , Jordi Palet Martinez Content-Type: multipart/alternative; boundary="000000000000b653570567c1439f" Archived-At: Subject: Re: [Doh] DNS64 and 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: Mon, 19 Mar 2018 10:17:27 -0000 --000000000000b653570567c1439f Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 9:00 AM, Stephane Bortzmeyer wrote: > > May be a warning "the DoH resolver may give you a different answer > from what you would have got from the usual resolver"? > > that text exists in section 10 --000000000000b653570567c1439f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 19, 2018 at 9:00 AM, Stephane Bortzmeyer = <bortzmeyer@nic.f= r> wrote:

May be a warning "the DoH resolver may give you a different answer
from what you would have got from the usual resolver"?


that text exists in section 10
--000000000000b653570567c1439f-- From nobody Mon Mar 19 03:19:22 2018 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 603D4126CE8 for ; Mon, 19 Mar 2018 03:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0v4dRIyYmTla for ; Mon, 19 Mar 2018 03:19:18 -0700 (PDT) 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 44842126CBF for ; Mon, 19 Mar 2018 03:19:18 -0700 (PDT) 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; Mon, 19 Mar 2018 03:19:16 -0700 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; Mon, 19 Mar 2018 03:19:16 -0700 From: Paul Hoffman To: Erik Nygren CC: DoH WG Thread-Topic: [Ext] [Doh] DNS64 and DOH Thread-Index: AQHTvu43kfOSXubl4Um8L8KFA2lIOqPXzvOA Date: Mon, 19 Mar 2018 10:19:16 +0000 Message-ID: References: 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.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <64A58650D035CC47B5E20F6819DAFBD1@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS64 and 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: Mon, 19 Mar 2018 10:19:19 -0000 On Mar 18, 2018, at 7:20 PM, Erik Nygren wrote: > At least for mobile, not using DNS64 synthesis in the client will likely = result in this either breaking the client in NAT64 environments or causing = something lower in the stack to do the equivalent (a 464xlat CLAT on Androi= d or bump-in-the-API on iOS). > =20 This is true for DNS64 in any environment, not just DOH, correct? If a clie= nt has two resolvers configured and only one is doing DNS64, or they are do= ing it differently, you have the same problem, yes? --Paul Hoffman= From nobody Mon Mar 19 03:27:04 2018 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 605A9126CBF for ; Mon, 19 Mar 2018 03:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.735 X-Spam-Level: X-Spam-Status: No, score=0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNNFGm8dQ_SG for ; Mon, 19 Mar 2018 03:27:00 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 CAA07126DC2 for ; Mon, 19 Mar 2018 03:26:59 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f125so6168465wme.4 for ; Mon, 19 Mar 2018 03:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Q4xzypKhF3Jjeo/p5k315P4vPKeQEOwV0seuPO6BiRo=; b=Oe6iPTLCCla/YJJ5Vskh8NEboptrWZL74bDMzXNKNjem0dw4d5CzkMYEbC5tfU1a1m UMOO8bqFD8SQ4hdCxAq9ajzNA7GrUPExomuH7TOwaT+3she5ye5gK9PS6e1XhTE9Ytls AcXeef5mLDcY+hUHl8cA1HDyeCvuT05iuZM1Y4cWyG1zfBefn5TZtHs+LcXjD8m7xxLP b2IN6ZKhK0Fds9qXBEvqTeDDaK2OTNavr42GLFD7l+B4KbptYnLbq8TX24EplP1hljYC nk0FwGkKlyRaMBn3MuVN5mb2EEtMPa02ztdFRjrUTC/jy1s6Ej4+bmF7GVAid1KlwHLR UUZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Q4xzypKhF3Jjeo/p5k315P4vPKeQEOwV0seuPO6BiRo=; b=pRZSbIX/SUPzpI6PhdcyoSnpUKWwqrRiD5wfocA+AjklLxPWenSxDFH6Miz+PkORsA l+TM6BXcc6EvukVm+duJI9GdSrsyEPBxYE38PUW093dTL5/5vhGwNd6k/24AFvBgWlev hCM0Yzofm/VJaN7Q4HPTXdKB/PjlTlb6iunXVNLRrmcT1BGd1ym8uDrYOE4aGC77tZBx 27HXPvS7G3v6/aZ/y/9mLIwzBDGEhSzj+y4j7JyP07FOp/RwNWEnyNijeds/Njo5aLTO yXdS2JVpVjvYDro/vKDKNffzAXvGQ9WnwFEfT4FCyOCPxlbHby/hemn1wUr8zZWMa1mx UkkQ== X-Gm-Message-State: AElRT7H+3vdu3yLLu0DCsTxl+lZCXEaQuC+dOTWRttfgjcsk2mCzZAJL pG1tPHgExPVacNFthSc/GGI3sQ== X-Google-Smtp-Source: AG47ELvIAFJc24HSCAzib4i0HtHdFD4MNYivl881nK9uJ9baNzLCLAH+Nnj7XEhCDMmOHNIr/9SonA== X-Received: by 10.28.129.86 with SMTP id c83mr7892705wmd.37.1521455218041; Mon, 19 Mar 2018 03:26:58 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:fe79:234c]) by smtp.gmail.com with ESMTPSA id y42sm12618214wry.97.2018.03.19.03.26.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 03:26:57 -0700 (PDT) Date: Mon, 19 Mar 2018 10:26:56 +0000 From: Miek Gieben To: Patrick McManus Cc: Stephane Bortzmeyer , DoH WG Message-ID: <20180319102656.vgmu645h6bfjj3wr@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> <20180319094912.46fts2zxxlk6o2jx@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 10:27:01 -0000 [ Quoting in "Re: [Doh] meta qtypes..." ] >we need to be careful about recommending a blind tunnel (aspect) of using >HTTP by just disabling caches. That's not really great and doesn't meet the >DoH goals - HTTP has a rich language to control caching at its level which >I think can be well aligned with the DNS TTL architecture (and if no-cache >plays a role for some small part, that's fine.). There is document text >that already tries to discuss that in Section 6. Hopefully we can revise >that if necessary. > >The text already contains a normative MUST NOT about using a http freshness >lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH >server that cannot figure this out can comply with a freshness lifetime of >0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel. > >Please note the draft uses language about freshness lifetime instead of >normatively referencing cache-control for a reason (cc is used in "such as" >and in an example). There are a number of ways in HTTP to express this >concept and you want to be compatible with the existing definitions. > >Perhaps it just needs an additional para indicating a response bearing a >negative answer needs a more pessimal algorithm (e.g. either not cachable >or the SOA approach)? I think it should. I really wish we could point to one DNS RFC that tells implementers on how to determine the cache TTL, but afaik that does not exist. So, yes, either new text in this I-D or referencing a whole slew of DNS RFCs that say things about TTL in relation to caching. /Miek -- Miek Gieben From nobody Mon Mar 19 03:33:24 2018 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 EB419126DC2 for ; Mon, 19 Mar 2018 03:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=Pz+nwvsn; dkim=pass (1024-bit key) header.d=yitter.info header.b=loHXZPse 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 HvISvIS1Nj9A for ; Mon, 19 Mar 2018 03:33:22 -0700 (PDT) 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 E7AD5126CBF for ; Mon, 19 Mar 2018 03:33:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 59A93BE780 for ; Mon, 19 Mar 2018 10:33:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521455601; bh=uZ+qxXJ+rL8P8jqxPLCCsfAsrk8o/3sdHBvTVhrStxQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Pz+nwvsnydrpP5HsjjXoop+IVqoCHGXfV21zxQLD71rmOZZ/lqsiTMYC0FNAZM8PM dlNFEDxfP3viDEGo4T8bUreyE0ECfVQ3PKvjIPlA11uGTNTE9dcngEoKdrrQZ5JZh1 cqJbUa+dVNDSzS3ntQadgetTa26pbOdarjyIQifE= 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 1aOxIDnFlmLV for ; Mon, 19 Mar 2018 10:33:20 +0000 (UTC) Date: Mon, 19 Mar 2018 06:33:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521455600; bh=uZ+qxXJ+rL8P8jqxPLCCsfAsrk8o/3sdHBvTVhrStxQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=loHXZPse8ybzjQQ+c/CofNg34IbTUr+GuooSCdLdqA/Z6q4Fh/KXY9WVZLYt8SbtM oBPqGlWNtxevS2qEIdrNapVHIv42tCVgt9iruB8bcYlJJEqPTGwLrBpUpqmnZV2u8U MLg6eciiC7t3eW+ntuZQlEvRYDmiFMXUonQSwSok= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] DNS64 and 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: Mon, 19 Mar 2018 10:33:23 -0000 On Mon, Mar 19, 2018 at 10:19:16AM +0000, Paul Hoffman wrote: > > This is true for DNS64 in any environment, not just DOH, correct? If a client has two resolvers configured and only one is doing DNS64, or they are doing it differently, you have the same problem, yes? > Quite so, but even in a MIF (split horizon) environment the different-scope resolution is not usually imagined to be two different paths to the whole Internet. I think the point is basically that, if the host is doing DNS64 for resolution but somehow gets DOH that is not using the DNS64 path, there's a problem. That does seem worth noting. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 19 03:43:01 2018 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 B12EE12D87A for ; Mon, 19 Mar 2018 03:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=evequefou.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 beT73t8OkM_E for ; Mon, 19 Mar 2018 03:42:49 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0117.outbound.protection.outlook.com [104.47.36.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423C512E038 for ; Mon, 19 Mar 2018 03:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=noyJTaHlkNSoGPCj6bldZ0I0wZ+JfvFQyqMoDkIZf6s=; b=pnxBwVroSrI9XGPD6TuXaIrCz4fsMWeb9Mgau2gS3CrXzluA6+nqj0qfufzfXULLq0q8VjFSTsTZex920s75/YJofX9N0oAMmZGyWk8hJhtv4bDOmuDamVBYXa2XHPv5JIt/fiy1Hhp28+qvjRSI2kBz/hilVQEn/mFcutZwlbU= Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1807.namprd08.prod.outlook.com (10.162.134.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Mon, 19 Mar 2018 10:42:42 +0000 Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::b057:7190:752f:8cb9]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::b057:7190:752f:8cb9%13]) with mapi id 15.20.0588.016; Mon, 19 Mar 2018 10:42:42 +0000 From: Mike Bishop To: Paul Hoffman , Ted Hardie CC: DoH WG Thread-Topic: [Doh] [Ext] A question on the mix of DNS and HTTP semantics Thread-Index: AQHTv2rVWIFyL1L2SkOraaHrAS9gW6PXXmXg Date: Mon, 19 Mar 2018 10:42:42 +0000 Message-ID: References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> In-Reply-To: <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [31.133.157.41] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR08MB1807; 7:buRyP4qDMXNl3XAIv8X3OYXGZK/v40GwV9EPy/v0njHlg9joz4lT2OD5IkD8Qyf3d7EC1bnDMof79fhlOld2duxS5NvURBjSl7Eq27YXIyq25t1uy7+xPXuttZLg1+BYoDPxuXFExw3snNnD0KwNmN+vUE3ysHTJYUlSb15f13M45mkOSL8kV7CRwXjRS7jX1CZj0/DX4j07Aw3EW1e2PhoA5Nz/Xk6cxNoAyGHriQhCR/2z8qPYA8wcc22BbHmX x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 49e0275e-c3c4-4396-11c3-08d58d862508 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1807; x-ms-traffictypediagnostic: SN1PR08MB1807: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501300)(52105095)(10201501046)(3002001)(6041310)(20161123564045)(20161123560045)(2016111802025)(20161123562045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:SN1PR08MB1807; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1807; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(39380400002)(376002)(346002)(396003)(13464003)(189003)(199004)(53936002)(33656002)(6436002)(5250100002)(229853002)(74482002)(6506007)(106356001)(316002)(9686003)(6246003)(55016002)(3846002)(93886005)(6116002)(110136005)(86362001)(8676002)(3660700001)(8936002)(26005)(186003)(81156014)(81166006)(5660300001)(66066001)(3280700002)(6306002)(7696005)(99286004)(105586002)(97736004)(4326008)(7736002)(76176011)(39060400002)(25786009)(2900100001)(14454004)(102836004)(966005)(2950100002)(305945005)(68736007)(53546011)(74316002)(2906002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1807; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 69+ipkqizST7CdC3SLS4QWXrWG3ppj5Ge8Hg/kFo3OjySN3xZr7quYMv77TItmxZ2EyjeRfozXfnbpvJY29ka7qnwLaxgzJAcbKBv2aanO1xiwJIxnx46oSQHMtUp7CRlt7e2TGlA5eJWH5UaKTU8PvW/TlEF28TLwV8r9wGDO4VUhvezvscGZSdMqiYsinb2g4BfYpymyLicW3tONaT/doxU17Sj+421UN472oHMWG+7HsMNt/Rn0JBqwwgAWE0gYYmhNIGjhhx6EH+1vzO5zQvcxkLyZK1FB75idWuHhecdVEnz9ynXmqbhLsQBXoQaO+2MUOrlzP/jD5TvkIWHg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 49e0275e-c3c4-4396-11c3-08d58d862508 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2018 10:42:42.8119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1807 Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 10:42:59 -0000 There's a reasonable argument that if Content-Type is application/dns-udpwi= reformat, it should be processed by the DNS client regardless of the HTTP s= tatus code. (And that a 200 with any other Content-Type is an error.) -----Original Message----- From: Doh On Behalf Of Paul Hoffman Sent: Monday, March 19, 2018 10:13 AM To: Ted Hardie Cc: DoH WG Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics On Mar 19, 2018, at 9:49 AM, Ted Hardie wrote: > The message body may not be able to answer this question completely, but = it can clarify at the DNS level that this was REFUSED. The semantics of th= at are much closer to 451's meaning than producing no DNS-level response at= all (which maps to "query did not complete" if I understand it correctly). Hopping up one level, I think you are describing a DOH server that inspects= queries or responses and chooses to change the HTTP response to use a non-= 2xx code. That seems fine, but it also seems like you are saying that the D= NS response inside that HTTP response should be understood by the client, a= nd in a code-specific way. Is that a fair summary? --Paul Hoffman _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh From nobody Mon Mar 19 03:44:10 2018 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 3051F126E64 for ; Mon, 19 Mar 2018 03:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 twYn37F64QZG for ; Mon, 19 Mar 2018 03:44:07 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::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 8FBA3126DEE for ; Mon, 19 Mar 2018 03:44:07 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id v194-v6so9739858itb.0 for ; Mon, 19 Mar 2018 03:44:07 -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 :cc; bh=1fGRcZDkLekociHZhlK5t4jCJ/qm+2vtUtsVLoTdtcs=; b=mkcjBKucdCztyjpk3goAZkt7LF2nkS4mKDVgXmt9DQ44XbvamMBHL0zBMwHQqKMmrr P3jaNpLgtktzch+119tMtl2WO/oYVnfmGF6uI7biNdzJVJe6DHkw85hiV80P/GwUsBur UDoSsokqNnCJyfSvAK4KgwE54hkEWLd8p2EXiau788myhtWRvl2kMhanA9BiQTSjn5Kn lhNa8NsWJwDA0XH/Lnr2y8YHoegvo68eanBcynibxN9t/2o6Dptyi8M41fJ7tmxypKtY ocLptSE9Hv+iAqtb2vPwub3GaLW596X9BCZs7SKcUlzwvyON/2ZkA1yzjnCxy3l/X9BL Pupw== 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=1fGRcZDkLekociHZhlK5t4jCJ/qm+2vtUtsVLoTdtcs=; b=Dl0Mkb81HymemQDXKJXJ9VXzhi4rFMOKaDpNOz9qozucrBtOkyRB0lviN1C1cXdCnC I8hWZB9/7ryhi1VKdRDHDsMyljePjRPCbgO1z5s5uxlUmhaf1n8/oDusuBaZfbFXjR9e u7YugK0xg68FLfUcGkOgYivQQpDwUnIulp0mocKjoZOmvA5FB5uLjRWazX+ngcQYTgYq bfJkdhIcX/z1T9gDt5JBppmBT1qHo+C4hg/UvmtRAnUCju7IdZdvhyLuDExWiHTGKVwZ it9/uJ69xUNf+bB5dVVnzcM+RmMZL635tpHvaf4kR576o1saDw2WtZLmIiwAkHOFUA8a KaVQ== X-Gm-Message-State: AElRT7HSLVB2iwNVICuNMRiAgmKMEsBgAUXjRoiT0RQgSZu4mvF4UzOr IsAJ2vdHWREbML8l0/Mo8T9hMOHM1n6xrPGDVUU9ZA== X-Google-Smtp-Source: AG47ELuzAknC7cOnH1238uAkb64K+l3QQPEaOvoG80DjLh2BkARwsUFH3Dt5UUoV95OVL2YzXkmb/j06CvCyrwSmTdo= X-Received: by 2002:a24:3093:: with SMTP id q141-v6mr10968903itq.21.1521456246232; Mon, 19 Mar 2018 03:44:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Mon, 19 Mar 2018 03:44:05 -0700 (PDT) In-Reply-To: <20180319102656.vgmu645h6bfjj3wr@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> <20180319094912.46fts2zxxlk6o2jx@miek.nl> <20180319102656.vgmu645h6bfjj3wr@miek.nl> From: Ben Schwartz Date: Mon, 19 Mar 2018 06:44:05 -0400 Message-ID: To: Miek Gieben Cc: Patrick McManus , DoH WG , Stephane Bortzmeyer Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000025aaf10567c1a3a7" Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 10:44:09 -0000 --00000000000025aaf10567c1a3a7 Content-Type: multipart/alternative; boundary="00000000000019ea2b0567c1a34e" --00000000000019ea2b0567c1a34e Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 6:26 AM, Miek Gieben wrote: > [ Quoting in "Re: [Doh] meta qtypes..." ] > >> we need to be careful about recommending a blind tunnel (aspect) of using >> HTTP by just disabling caches. That's not really great and doesn't meet >> the >> DoH goals - HTTP has a rich language to control caching at its level which >> I think can be well aligned with the DNS TTL architecture (and if no-cache >> plays a role for some small part, that's fine.). There is document text >> that already tries to discuss that in Section 6. Hopefully we can revise >> that if necessary. >> >> The text already contains a normative MUST NOT about using a http >> freshness >> lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH >> server that cannot figure this out can comply with a freshness lifetime of >> 0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel. >> >> Please note the draft uses language about freshness lifetime instead of >> normatively referencing cache-control for a reason (cc is used in "such >> as" >> and in an example). There are a number of ways in HTTP to express this >> concept and you want to be compatible with the existing definitions. >> >> Perhaps it just needs an additional para indicating a response bearing a >> negative answer needs a more pessimal algorithm (e.g. either not cachable >> or the SOA approach)? >> > > I think it should. I really wish we could point to one DNS RFC that tells > implementers on how to determine the cache TTL, but afaik that does not > exist. > Could you expand on this? NXDOMAIN has an explicit TTL, so I don't understand why the "negative answer" case requires a different algorithm. What are you thinking of? Could you suggest some text? > So, yes, either new text in this I-D or referencing a whole slew of DNS > RFCs that say things about TTL in relation to caching. > > > /Miek > > -- > Miek Gieben > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000019ea2b0567c1a34e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 19, 2018 at 6:26 AM, Miek Gieben <miek@miek.nl> w= rote:
[ Quoting <pmcmanus@mozilla.com> in "= Re: [Doh] meta qtypes..." ]
we need to be careful about recommending a blind tunnel (aspect) of using HTTP by just disabling caches. That's not really great and doesn't = meet the
DoH goals - HTTP has a rich language to control caching at its level which<= br> I think can be well aligned with the DNS TTL architecture (and if no-cache<= br> plays a role for some small part, that's fine.). There is document text=
that already tries to discuss that in Section 6. Hopefully we can revise that if necessary.

The text already contains a normative MUST NOT about using a http freshness=
lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH
server that cannot figure this out can comply with a freshness lifetime of<= br> 0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel.
Please note the draft uses language about freshness lifetime instead of
normatively referencing cache-control for a reason (cc is used in "suc= h as"
and in an example). There are a number of ways in HTTP to express this
concept and you want to be compatible with the existing definitions.

Perhaps it just needs an additional para indicating a response bearing a negative answer needs a more pessimal algorithm (e.g. either not cachable or the SOA approach)?

 I think it should. I really wish we could point to one DNS RFC that tells i= mplementers on how to determine the cache TTL, but afaik that does not exis= t.

Could you expand on this?=C2=A0 NXDO= MAIN has an explicit TTL, so I don't understand why the "negative = answer" case requires a different algorithm.=C2=A0 What are you thinki= ng of?=C2=A0 Could you suggest some text?
=C2=A0
So, yes, either new text in this I-D or referencing a whole slew of DNS RFC= s that say things about TTL in relation to caching.


/Miek

--
Miek Gieben

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

--00000000000019ea2b0567c1a34e-- --00000000000025aaf10567c1a3a7 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBQZAt/hc0Mc8lnikxq0PRF WZkbZU3X8+z4uEEjnG+VhTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMTkxMDQ0MDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAYF36S2pXdkbZ9tAkfHZfddH1WG8QZ1CoAvMzXFqj XxegS0QYHrHs6QxMo6goeNZlznwd+nvZ4vaLiMpBogqpw+QeDpjhKD341uu5MwJGVABiyjRMhUnm 885h8FGQFgvISpaMe0On0yLGHqZ3PuANBka80RCag1oBRwwakldijQh+Tfr4GdHosxTIG8E3Eq++ LGtXObJXDNkH6T88DPeitGdn/JQabVIlNgNEEh0G1THcQjCLP9s07TvyXJmfrbb7wLFEGtark768 Ho8BnCE76FtDSBYBHMbiLpGVLNaN15Oytw2xCbx27YBhe09YJ9NFumJ9VhQa5xBvvruMLG9kSw== --00000000000025aaf10567c1a3a7-- From nobody Mon Mar 19 03:52:04 2018 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 2B65D127522 for ; Mon, 19 Mar 2018 03:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 44Z6wYfFyCon for ; Mon, 19 Mar 2018 03:52:01 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A964126FDC for ; Mon, 19 Mar 2018 03:52:01 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id d13-v6so9851112itf.0 for ; Mon, 19 Mar 2018 03:52:01 -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 :cc; bh=4jHfsvKnhjhLvq9bBpeeK4dPx04R3tamfQ6NMrxnZso=; b=HXZdPJl6hg8T6HUJCh6gpoRFmCxxhuSD6SFvzTcQkAsz++ZEf4yPALpjycjBYSy3wh 1Vt1HrFZ89Ckv7/OtphJ56du4i+47ka1nYW4wz3NIJmXaLn4x19oPRckEjf53N/wsFba +xP0Eb0LV2is5oiUYBkz9jsaKhoKreUqnXuXTwTyGUhY6gyHUsI7GUESy+5HcuOZNQ1w m13eWC/dassZ/gGAaQjP1Dt65LU3rDB8bYKc+EE8K6wjos6RUjnP1JF7WSUBah/2eHXv QMep7SM1bzOPh2OflbvfMD097BUJF30mHjj+o3UsU/uXKocud50nlrkLuSBhYqX63oJl 8EqQ== 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=4jHfsvKnhjhLvq9bBpeeK4dPx04R3tamfQ6NMrxnZso=; b=bq4ZOQ4k3kQzyOEVMV2PpAN762xhj6D2IMan/ET/VhRIPTL4wBEy/857etMDT7vLDe i3QsSlkPtmxQkPfgfsvmhfDGcAd/6HN1mclP8rPf+1DNAaTOIfdku+ofQBUdJ7q8ITZ2 wTKPe474h1HKiovltrrkQcYIz28S5bDitYYC2436nuF20CqhGCMcThL/FL0Cbw6+rMhv nhuxjryrWeLQbOq1CJCh0HUllcw3goSDY9BpKYzedOzygt2Pc9JJFkHxf3kpbgvHn45t VWLFHiqJE3mYJBO0pnYj9fIURuqikA1CgUpffOmLphLRzhvG3mtOFUNBhstVi5YITX/D +ZLg== X-Gm-Message-State: AElRT7Fj/2swq6y6acv3uRd4uBp5todxaxzDM6r+0niA0XJGoOYAf8Dv nZyh2AfW5SA8wmzLuGZUF5LwqalwfBqxv/XKJ5zGkTzO X-Google-Smtp-Source: AG47ELvgPH9Vi9TgEQaS1M/r9RSbDVZWgdVVGYOHjxpF4kDHZDiCfqlnPowiUmsLBah6zaCjAqNeGcQlM5+OzAYUEPw= X-Received: by 2002:a24:a0cc:: with SMTP id o195-v6mr11328677ite.3.1521456720526; Mon, 19 Mar 2018 03:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Mon, 19 Mar 2018 03:51:59 -0700 (PDT) In-Reply-To: <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> References: <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> From: Ben Schwartz Date: Mon, 19 Mar 2018 06:52:00 -0400 Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000677bfe0567c1bf23" Archived-At: Subject: Re: [Doh] [Ext] DNS64 and 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: Mon, 19 Mar 2018 10:52:03 -0000 --000000000000677bfe0567c1bf23 Content-Type: multipart/alternative; boundary="0000000000005eed650567c1bffc" --0000000000005eed650567c1bffc Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 6:33 AM, Andrew Sullivan wrote: > On Mon, Mar 19, 2018 at 10:19:16AM +0000, Paul Hoffman wrote: > > > > This is true for DNS64 in any environment, not just DOH, correct? If a > client has two resolvers configured and only one is doing DNS64, or they > are doing it differently, you have the same problem, yes? > > > > Quite so, but even in a MIF (split horizon) environment the > different-scope resolution is not usually imagined to be two different > paths to the whole Internet. I think the point is basically that, if > the host is doing DNS64 for resolution but somehow gets DOH that is > not using the DNS64 path, there's a problem. That does seem worth > noting. > I am fine with a note on this topic, but I will observe that RFC 7858 (DNS over TLS) feels no need to mention DNS64, so I think we are free to take a similar approach here. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000005eed650567c1bffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 19, 2018 at 6:33 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
On Mon, Mar 19, 2018 at 10:19:16AM +0000, Paul Hoffman wrote:
>
> This is true for DNS64 in any environment, not just DOH, correct? If a= client has two resolvers configured and only one is doing DNS64, or they a= re doing it differently, you have the same problem, yes?
>

Quite so, but even in a MIF (split horizon) environment the
different-scope resolution is not usually imagined to be two different
paths to the whole Internet.=C2=A0 I think the point is basically that, if<= br> the host is doing DNS64 for resolution but somehow gets DOH that is
not using the DNS64 path, there's a problem.=C2=A0 That does seem worth=
noting.

I am fine with a note on this t= opic, but I will observe that RFC 7858 (DNS over TLS) feels no need to ment= ion DNS64, so I think we are free to take a similar approach here.
=C2=A0

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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

--0000000000005eed650567c1bffc-- --000000000000677bfe0567c1bf23 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBYc1peOVfn1EOpHal3u6lk IDiXB4L/QV+va6NB+be4PzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMTkxMDUyMDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAqh2YQmA96MDPDN5o39OfXXM4xEKcwYlhRwqzcnBe T+HYqSXZucTIJmr7l1eKPqYBbMizBoQQmiC+6XD1d5zfZjNdcPTWzmghiKZ/Hx0aV4IWhvEys69+ CA6C83pyQDst+myUZ2636KHM1DmORtgcsPxyUrxfdyPkugHjB5G8/lVhaUoGzMVUg+bQ7q+CRKvZ XDxgBQFfxelPnbXgZlE2XqB7XZ2dF0yzdGO2QT7eFitTnlJFv/v6xwjnjJBb6JjPKw8Goy640yfw zUqgK9s8+xjWMnNvC7juSuIiRahSI1ziIdKWJxiFQMoHMBHi1uVkcxO4KEJaMYWBOenp/ews6A== --000000000000677bfe0567c1bf23-- From nobody Mon Mar 19 04:04:30 2018 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 870AE127419 for ; Mon, 19 Mar 2018 04:04:28 -0700 (PDT) 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 KwI_T8ASjZXM for ; Mon, 19 Mar 2018 04:04:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 B56351200B9 for ; Mon, 19 Mar 2018 04:04:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id a189so6948264oii.2 for ; Mon, 19 Mar 2018 04:04:26 -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=COidHCNi3qDnDNOy52V0H+y2pwI7qjOiMyWfjtI2BC8=; b=N8TCfw0yptIjo6rZI5HefmICpqOKbTO2yxwJW//fWUTuXAN+YqVKrbdrwVwf62LewJ L4S68dcrQzlhL5YRGPnE9SFNJYGAwYv0StmLv+8D+QZ+6nsR0uPQKaM6d/D00Kr6pNBE YvbjVv3q42XZslUvhQ14sXBi6Yo7k2Vp6DjLf2OvaQ6ys54tvYyKmFnNvs5q/4/AGvgJ NmENEg/t8cdffJkABcaQtmjMq7lp1Ee2i4wG86vPxiaBGCxELd3SQnR0iPDBd8xsBWWz ddpkUUcoF4ODIDUdbQjWldyp4ExTNvhgHRlVR2H6wWKgMpB6hOeq5vCXb+bWKiYwIA/2 a7qg== 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=COidHCNi3qDnDNOy52V0H+y2pwI7qjOiMyWfjtI2BC8=; b=dWYZNOS7DsDqQRdGfOhfUaZQ5xyOv6gyh/OqqDQo38Hn+yh6nffRXxJ+7M3LIcO8hO 12o+9G/mJ6sHyN0u9k4+IvaWLmLx15TNC2aNXByEpNr+VBHXvSMFaDfae3R6pvoX2Gnn RQpJaO4izVAfL/35KVbi+82BqdThr832qs4yrzuiN5D8CKCAFJADEc/CQkX4Av3yctS9 It4XWcLFbWnxQuIqVQerzN1BV5EgsYLsdG1Qi4m/xEduNP7BkDExYu+V7gjTxmwUt32U Fz743yhGBrJYy8Q9zJ5/ErMLx4/apOxtJ1p5ZbkL53GtmsNNRZhYl3DfKWS4Y0QI074L FXeQ== X-Gm-Message-State: AElRT7FR4gqixSPfW0sNaSY9JCJJmMaecimna/tebjejZ//M1VJDkHXH IZBxZbePYxzx7tWeqgR5sKC5SmPDq9sk7EG9XD4= X-Google-Smtp-Source: AG47ELvf6c+minnHThKr6QpuZCBfTWd/rjvgbnWIf0FbbZeUsITomOvMplXfJvLCtu2LD3XuM0R2Kg41DBIxJ9NrzcY= X-Received: by 10.84.68.7 with SMTP id k7mr6490339oiw.118.1521457464072; Mon, 19 Mar 2018 04:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Mon, 19 Mar 2018 04:03:53 -0700 (PDT) In-Reply-To: References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> From: Ted Hardie Date: Mon, 19 Mar 2018 04:03:53 -0700 Message-ID: To: Mike Bishop Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="f4f5e808e574afe0da0567c1eb51" Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 11:04:28 -0000 --f4f5e808e574afe0da0567c1eb51 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 3:42 AM, Mike Bishop wrote: > There's a reasonable argument that if Content-Type is > application/dns-udpwireformat, it should be processed by the DNS client > regardless of the HTTP status code. (And that a 200 with any other > Content-Type is an error.) > > I think this makes sense. Ted > -----Original Message----- > From: Doh On Behalf Of Paul Hoffman > Sent: Monday, March 19, 2018 10:13 AM > To: Ted Hardie > Cc: DoH WG > Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics > > On Mar 19, 2018, at 9:49 AM, Ted Hardie wrote: > > The message body may not be able to answer this question completely, but > it can clarify at the DNS level that this was REFUSED. The semantics of > that are much closer to 451's meaning than producing no DNS-level response > at all (which maps to "query did not complete" if I understand it > correctly). > > Hopping up one level, I think you are describing a DOH server that > inspects queries or responses and chooses to change the HTTP response to > use a non-2xx code. That seems fine, but it also seems like you are saying > that the DNS response inside that HTTP response should be understood by the > client, and in a code-specific way. Is that a fair summary? > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f4f5e808e574afe0da0567c1eb51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 19, 2018 at 3:42 AM, Mike Bishop <mbishop@= evequefou.be> wrote:
There's a reasonable ar= gument that if Content-Type is application/dns-udpwireformat, it should be = processed by the DNS client regardless of the HTTP status code.=C2=A0 (And = that a 200 with any other Content-Type is an error.)

<= br>
I think this makes sense.

Ted
=C2=A0
-----Original Message-----
From: Doh <doh-bounces@ietf.org<= /a>> On Behalf Of Paul Hoffman
Sent: Monday, March 19, 2018 10:13 AM
To: Ted Hardie <ted.ietf@gmail.com= >
Cc: DoH WG <doh@ietf.org>
Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics
On Mar 19, 2018, at 9:49 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> The message body may not be able to answer this question completely, b= ut it can clarify at the DNS level that this was REFUSED.=C2=A0 The semanti= cs of that are much closer to 451's meaning than producing no DNS-level= response at all (which maps to "query did not complete" if I und= erstand it correctly).

Hopping up one level, I think you are describing a DOH server that inspects= queries or responses and chooses to change the HTTP response to use a non-= 2xx code. That seems fine, but it also seems like you are saying that the D= NS response inside that HTTP response should be understood by the client, a= nd in a code-specific way. Is that a fair summary?

--Paul Hoffman
_______________________= ________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--f4f5e808e574afe0da0567c1eb51-- From nobody Mon Mar 19 04:15:14 2018 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 36AA212741D for ; Mon, 19 Mar 2018 04:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 MwZZWwUejB80 for ; Mon, 19 Mar 2018 04:15:10 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 554B212D889 for ; Mon, 19 Mar 2018 04:15:07 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id E0FC43A04F for ; Mon, 19 Mar 2018 07:15:06 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id h8-v6so16921316oti.6 for ; Mon, 19 Mar 2018 04:15:06 -0700 (PDT) X-Gm-Message-State: AElRT7EMaTwvkQOF/DhgK7aKhv8Uz5h2GwEloRm4IBIwfbfZ4NAb/UUG RfvI+rZoRzbpVkIFc34XY14blziWOEauclgk4Hs= X-Google-Smtp-Source: AG47ELuQvi91RnP70Qd/gfCJx8WxHdXCh5JR7AQoWUUTXQhSUxN44LyU/C71b1jlyknvGHyzgS2XTVcGrv86P7I4mAc= X-Received: by 2002:a9d:1189:: with SMTP id v9-v6mr6933560otf.397.1521458103368; Mon, 19 Mar 2018 04:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 04:15:02 -0700 (PDT) In-Reply-To: References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> From: Patrick McManus Date: Mon, 19 Mar 2018 11:15:02 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: Mike Bishop , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000cac43f0567c21155" Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 11:15:12 -0000 --000000000000cac43f0567c21155 Content-Type: text/plain; charset="UTF-8" there is a really fine line here. You can process a message body from a 4xx anyway you want - its trying to communicate information to you and the content-type is going to tell you how to go about trying to process it. But, very clearly, that message body is not the answer to the DNS query that was part of the HTTP request. If you can interpret it in some way that makes your DNS gateway code richer, that's fine.. but its not a requirement this protocol can, imo, put on a non success response beyond what is already defined. I don't think the message body has any practical epigrammatic interop value. On Mon, Mar 19, 2018 at 11:03 AM, Ted Hardie wrote: > On Mon, Mar 19, 2018 at 3:42 AM, Mike Bishop wrote: > >> There's a reasonable argument that if Content-Type is >> application/dns-udpwireformat, it should be processed by the DNS client >> regardless of the HTTP status code. (And that a 200 with any other >> Content-Type is an error.) >> >> > I think this makes sense. > > Ted > > >> -----Original Message----- >> From: Doh On Behalf Of Paul Hoffman >> Sent: Monday, March 19, 2018 10:13 AM >> To: Ted Hardie >> Cc: DoH WG >> Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics >> >> On Mar 19, 2018, at 9:49 AM, Ted Hardie wrote: >> > The message body may not be able to answer this question completely, >> but it can clarify at the DNS level that this was REFUSED. The semantics >> of that are much closer to 451's meaning than producing no DNS-level >> response at all (which maps to "query did not complete" if I understand it >> correctly). >> >> Hopping up one level, I think you are describing a DOH server that >> inspects queries or responses and chooses to change the HTTP response to >> use a non-2xx code. That seems fine, but it also seems like you are saying >> that the DNS response inside that HTTP response should be understood by the >> client, and in a code-specific way. Is that a fair summary? >> >> --Paul Hoffman >> _______________________________________________ >> 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 > > --000000000000cac43f0567c21155 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
there is a really fine line here. You can process a m= essage body from a 4xx anyway you want - its trying to communicate informat= ion to you and the content-type is going to tell you how to go about trying= to process it. But, very clearly, that message body is not the answer to t= he DNS query that was part of the HTTP request. If you can interpret it in = some way that makes your DNS gateway code richer, that's fine.. but its= not a requirement this protocol can, imo, put on a non success response be= yond what is already defined. I don't think the message body has any pr= actical epigrammatic interop value.


On Mon, Mar 19, 2018 at 11= :03 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Mar 19, 201= 8 at 3:42 AM, Mike Bishop <mbishop@evequefou.be> wrote:
There's a reasonable argument that= if Content-Type is application/dns-udpwireformat, it should be processed b= y the DNS client regardless of the HTTP status code.=C2=A0 (And that a 200 = with any other Content-Type is an error.)


I think this mak= es sense.

Ted
<= /font>
=C2=A0
-----Original Message-----
From: Doh <doh= -bounces@ietf.org> On Behalf Of Paul Hoffman
Sent: Monday, March 19, 2018 10:13 AM
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: DoH WG <doh@ietf.o= rg>
Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics
On Mar 19, 2018, at 9:49 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> The message body may not be able to answer this question completely, b= ut it can clarify at the DNS level that this was REFUSED.=C2=A0 The semanti= cs of that are much closer to 451's meaning than producing no DNS-level= response at all (which maps to "query did not complete" if I und= erstand it correctly).

Hopping up one level, I think you are describing a DOH server that inspects= queries or responses and chooses to change the HTTP response to use a non-= 2xx code. That seems fine, but it also seems like you are saying that the D= NS response inside that HTTP response should be understood by the client, a= nd in a code-specific way. Is that a fair summary?

--Paul Hoffman
_______________________________________________
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


--000000000000cac43f0567c21155-- From nobody Mon Mar 19 04:17:57 2018 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 A791A127599 for ; Mon, 19 Mar 2018 04:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 CpTuTWtgdSop for ; Mon, 19 Mar 2018 04:17:55 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B3F12741D for ; Mon, 19 Mar 2018 04:17:55 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 88552381AC; Mon, 19 Mar 2018 07:17:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.40034.541003.659743@gro.dd.org> Date: Mon, 19 Mar 2018 07:17:54 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <20180318164307.GB6724@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [Doh] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 11:17:57 -0000 Ted Hardie writes: > but it can clarify at the DNS level that this was REFUSED. The > semantics of that are much closer to 451's meaning Well, yes and no. REFUSED is hopelessly overloaded, with only one of its meanings being semantically in the neighborhood or 451. It is also used to signal lame delegations, and even rejecting an EDNS option. Thus we have a draft for extended errors in DNS responses to make things clearer. From nobody Mon Mar 19 04:36:46 2018 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 7AEC01276AF for ; Mon, 19 Mar 2018 04:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Q9LJ7Onw9yAw for ; Mon, 19 Mar 2018 04:36:42 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783C2127077 for ; Mon, 19 Mar 2018 04:36:42 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id C29B0381BE; Mon, 19 Mar 2018 07:36:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.41161.776447.904626@gro.dd.org> Date: Mon, 19 Mar 2018 07:36:41 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180318190804.5mgxarazepfut56i@miek.nl> <20180319091634.GC16151@laperouse.bortzmeyer.org> <20180319094912.46fts2zxxlk6o2jx@miek.nl> <20180319102656.vgmu645h6bfjj3wr@miek.nl> Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 11:36:43 -0000 Ben Schwartz writes: > NXDOMAIN has an explicit TTL, so I don't understand > why the "negative answer" case requires a different algorithm. NXDOMAIN's (and pseudo-rcode NODATA's) version of "explicit TTL" is: 1) Is there an SOA in authority? Use the mininmum of the RR TTL or the negative TTL in rdata. 2) No SOA? Implementation dependent. Please try to pick a subjectively sane value. And that's just NXDOMAIN/NODATA, not REFUSED, SERVFAIL, or other non-NOERROR rcodes. Personally I think that the best that can be hoped for when you don't get back RRSets with clear TTLs, or an SOA for negative answers, is probably no-cache, with "please try to pick something subjectively sane" a not unreasonable choice. From nobody Mon Mar 19 05:16:07 2018 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 0F4B7127775 for ; Mon, 19 Mar 2018 05:16:05 -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 (1024-bit key) header.d=cloudflare.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 w292ZxAoPGCA for ; Mon, 19 Mar 2018 05:16:02 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F057D1270AE for ; Mon, 19 Mar 2018 05:16:01 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id l16so5865854wmh.3 for ; Mon, 19 Mar 2018 05:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uItFKVeVEx/Umych2E3nCI5tC/XKgfpXU9jRSRvhb70=; b=Nk0xu91en08vFE24Ef84OW04+1RszeIebZgEde4fplHlRjEMdbd2mI7oQEjJ8GlDuy xYhZEEiAhzH/59Z3nM/hl7WzDiqdhcERA2AH7gGbrP4N2jPAiWuwP3T2cZG5r8eMNm8n lrCdQbPYcLVlu/nnyKSqwrFOF4tVg47XeQHwk= 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=uItFKVeVEx/Umych2E3nCI5tC/XKgfpXU9jRSRvhb70=; b=kLHyHZXa+dlKa+WN5iSdTofKKevdL8sh0GMeLY7mbmkcbJNMsDSv1AY6F57rGSYLp5 TRLM//qgVKiyxsoqQrlj+ZsPYj3JkhoaLXsNMo/DO6pouaAN2QVX8wkhz6ZT+bbrc2eD B8wT1LGi15qKRKjynD3zK+SgS15FOSsiC2Y0ZZgDUG2WQafI0DIskbT7aw2yzXnv6AM2 86R+Xot6AoU52telxkdWgVBFZXTMY8hxn72b6c+arepMSHaHJj3s3Zgo4/peol75VMsr ZJC/VQYK5I9ZgUFuOXtEcxaF3Qlt2YGdLwfoquSyr5eT4fO+0blt7mHxLOa9PiwJxrf/ Obcw== X-Gm-Message-State: AElRT7Hg7fHC18ys4QqWU7t1/r2AiJeUkRLUuA5XDAOCOexKL+Q4BJI1 uNvbf0z6I/9qtWLhjmj2aqDhga3lc4lO40mZy1tFnw== X-Google-Smtp-Source: AG47ELtlhiWIE0U3OSGFnhCyjNlYGcBlGGg6DJRQXhsIxHR6D+KbaR5n6kfKFQFogelcj64wIWys5zF+4/b905nkG8k= X-Received: by 10.28.234.207 with SMTP id g76mr5555198wmi.43.1521461760383; Mon, 19 Mar 2018 05:16:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.41 with HTTP; Mon, 19 Mar 2018 05:15:59 -0700 (PDT) In-Reply-To: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Mon, 19 Mar 2018 12:15:59 +0000 Message-ID: To: Patrick McManus Cc: DoH WG Content-Type: multipart/alternative; boundary="001a11468132c486250567c2ebc9" Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 12:16:05 -0000 --001a11468132c486250567c2ebc9 Content-Type: text/plain; charset="UTF-8" I would prefer if the draft did NOT even consider Meta types, but limited itself to pure queries i.e. excluded query type's 128..255 Additionally doing other things like Updates and Zone transfers should involve different meta types (lets learn from experience here not repeat mistakes) While I do not mind having the udpdnswire format for now, I think most users would prefer to use a simple Jason format of answers like the ones that Google provides https://dns.google.com/resolve?name=www.cloudflare.com?type=aaaa As for a more expressive format that supports doing DNSSEC validation that is IMHO a separate goal, as we need to think about usage cases i.e. does the client trust the resolver or not if the client trusts then the AD bit good enough, if the client wants to verify then the client should express that in the query either by adding field or ask for different media type. Just MHO Olafur On Sun, Mar 18, 2018 at 3:44 PM, Patrick McManus wrote: > Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I'm > not aware of whether it does or not) - the text is just meant to give the > HTTP considerations when it does carry larger DNS responses such as that. > > WRT HTTP caching - section 4 of DoH talks about how HTTP freshness > lifetimes should be set for DoH responses. Is there something different > here? > > -Patrick > > > On Sun, Mar 18, 2018 at 2:38 PM, Miek Gieben wrote: > >> Hi, >> >> -03 has the following text in section 7.1. >> >> Other types of DNS data, such as >> zone transfers, may be larger and benefit more from revalidation. >> DNS API servers may wish to consider whether providing these >> validation enabling response headers is worthwhile. >> >> this implies DoH servers need to support IXFR/AXFR (fine), but that >> replies to these may now be cached? I think this is new behavior from a DNS >> standpoint. >> >> (Should the draft also mention dynamic updates, notify messages and other >> opcodes as being supported?) >> >> /Miek >> >> -- >> Miek Gieben >> >> _______________________________________________ >> 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 > > --001a11468132c486250567c2ebc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would prefer if the draft did NOT even consider= Meta types, but limited itself to pure queries i.e. excluded query type= 9;s 128..255
Additionally doing other things like Updates and Zon= e transfers should involve different meta types (lets learn from experience= here not repeat mistakes)=C2=A0

While I do not mi= nd having the udpdnswire format for now,=C2=A0
I think most users= would prefer to use a simple Jason format of answers like the ones that Go= ogle provides=C2=A0

As for a mor= e expressive format that supports doing DNSSEC validation that is IMHO a se= parate=C2=A0 goal,=C2=A0
as we need to think about usage cases i.= e. does the client trust the resolver or not if the client trusts then the = AD bit good enough, if the client wants to verify then the client should ex= press that in the query=C2=A0
either by adding field or ask for d= ifferent media type.=C2=A0
Just MHO=C2=A0

Olafur


On Sun, Mar 18, 2018 at 3:44 PM, Patrick McManus <pmc= manus@mozilla.com> wrote:
<= div dir=3D"ltr">
Hi - DoH itself doesn't require axfr/etc anywhere = that DNS would not (I'm not aware of whether it does or not) - the text= is just meant to give the HTTP considerations when it does carry larger DN= S responses such as that.

WRT HTTP caching - secti= on 4 of DoH talks about how HTTP freshness lifetimes should be set for DoH = responses. Is there something different here?
<= font color=3D"#888888">

-Patrick


On Sun, Mar 18, 2018 at 2:38 PM, Mi= ek Gieben <miek@miek.nl> wrote:
Hi,

-03 has the following text in section 7.1.

=C2=A0 Other types of DNS data, such as
=C2=A0 zone transfers, may be larger and benefit more from revalidation. =C2=A0 DNS API servers may wish to consider whether providing these
=C2=A0 validation enabling response headers is worthwhile.

this implies DoH servers need to support IXFR/AXFR (fine), but that replies= to these may now be cached? I think this is new behavior from a DNS standp= oint.

(Should the draft also mention dynamic updates, notify messages and other o= pcodes as being supported?)

/Miek

--
Miek Gieben

_______________________________________________
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


--001a11468132c486250567c2ebc9-- From nobody Mon Mar 19 06:11:42 2018 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 25BCC1275FD for ; Mon, 19 Mar 2018 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGjG6CB-07rv for ; Mon, 19 Mar 2018 06:11:38 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 F028A12704A for ; Mon, 19 Mar 2018 06:11:37 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id e194so15008892wmd.3 for ; Mon, 19 Mar 2018 06:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=D+ASLvfGjrE46tf6tBuWtOqGNh/2umxfAFZP+NkDleM=; b=C5wlZu42YYkGKyZ0eI+YLM6xmy+0HfcmxOp6bIwUXgCYQ9mcceQ2SVI+sBMNEKFbmZ XyU90ZAmL5ln2RRio+whcFzFPFtaDbpPlFreJBUjTR/L0uZPZlREaDiJN+r/Y7//RQCT +vzeUZ5Bt+y2z5UQb7VthVUu5A2dHw5TBlH0rYLa85XlxtUEdNBFapTDaaoK2NH3dVko EmVOD1C9LTc7RBbW7rdXsbT9Hl+Z328hPs9TEtxn0LykGF0kwOhc2/Hz6PpT5xX1x3Jr KmGq+rEUzw728kaPcs5y+GKauHmu2pT+O8D1G+KiQNE6zTC4EEdOS70UDLSd/2JqbDnL G8HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D+ASLvfGjrE46tf6tBuWtOqGNh/2umxfAFZP+NkDleM=; b=oc95e8eC7QEEtDxeQUXoC0hjDc72RLXq1I56MqGKmHYBxzkEsOKTgeludgIS/YYSs/ nT4s2xHHZGvv+LGi8Yso2ca2qC0Tsm5boNdirdVH3XokBwAX1Npolr5Ah9rl1a7PRY2K LflxeT8/MNIJm7lvSPbIjsfMvbvmlmIU3n35ndnRBNcJdSlV5VHhO0lkYHYAJZSx67Z1 GNa2MgG3e7nTC7gWjS1LYsn9dMyh516+bhe+PeibufqfiiWsc0gjhgu/yThCPpdk6jNA hwbZNFtAk53xdbM02+OrctnP5K+k9adCwPsD6ENz8recNsrto7BVd0CPGlB1JtXBkqlt syEA== X-Gm-Message-State: AElRT7FLrPch40XfPou/pVfjKZ890yhgopv4vbjJIo0g0P89sPCgUt5k mFDyHtmirULQ69ecsxELHAWl3w== X-Google-Smtp-Source: AG47ELtkFvyaly5znWkdoxRecDGiu8sG0eAsJc/4Rkzlue0T9xvvRimED2kes3MrF9Asw5/o/I+O4A== X-Received: by 10.28.164.3 with SMTP id n3mr9061354wme.121.1521465096166; Mon, 19 Mar 2018 06:11:36 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:fe79:234c]) by smtp.gmail.com with ESMTPSA id p79sm438268wmf.34.2018.03.19.06.11.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 06:11:35 -0700 (PDT) Date: Mon, 19 Mar 2018 13:11:34 +0000 From: Miek Gieben To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: Patrick McManus , DoH WG Message-ID: <20180319131134.46hjo2eo757jqe7d@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 13:11:40 -0000 [ Quoting in "Re: [Doh] meta qtypes..." ] >I would prefer if the draft did NOT even consider Meta types, but limited >itself to pure queries i.e. excluded query type's 128..255 >Additionally doing other things like Updates and Zone transfers should >involve different meta types (lets learn from experience here not repeat >mistakes) Yes! So make the draft say? MUST support opcode QUERY. MUST NOT support any other opcode. MUST support all RR types excluding the meta range 128..255. A non supported query MUST be rejected with a ... ? /Miek -- Miek Gieben From nobody Mon Mar 19 06:49:41 2018 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 7F03D1277BB for ; Mon, 19 Mar 2018 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Fqc6ILzXRsNi for ; Mon, 19 Mar 2018 06:49:21 -0700 (PDT) Received: from jax4mhob06.myregisteredsite.com (jax4mhob06.myregisteredsite.com [64.69.218.86]) (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 EF09F126FB3 for ; Mon, 19 Mar 2018 06:49:09 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id w2JDn7PI018001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Mar 2018 09:49:07 -0400 Received: (qmail 14605 invoked by uid 0); 19 Mar 2018 13:49:07 -0000 X-TCPREMOTEIP: 31.133.142.80 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.142.80?) (lee@asgard.org@31.133.142.80) by 0 with ESMTPA; 19 Mar 2018 13:49:07 -0000 To: Stephane Bortzmeyer , Erik Nygren Cc: doh@ietf.org, Jordi Palet Martinez References: <20180319090048.GB16151@laperouse.bortzmeyer.org> From: Lee Howard Message-ID: <9417fccd-b993-9ef6-fff0-35a779a0e28a@asgard.org> Date: Mon, 19 Mar 2018 13:49:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180319090048.GB16151@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] DNS64 and 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: Mon, 19 Mar 2018 13:49:27 -0000 On 03/19/2018 09:00 AM, Stephane Bortzmeyer wrote: > On Sun, Mar 18, 2018 at 07:20:35PM +0000, > Erik Nygren wrote > a message of 86 lines which said: > >> At least for mobile, not using DNS64 synthesis in the client will >> likely result in this either breaking the client in NAT64 >> environments > Is it a DNS64-specific problem? It could also happen if you have > local-only domain names, dummy local TLDs, alternative roots, > split-horizon, CDN, geo-based answers, or other DNS tricks. > > Yesterday, one IETFer told me that DoH was a bad idea because it allows > people to avoid DNS-based national censorship… > > May be a warning "the DoH resolver may give you a different answer > from what you would have got from the usual resolver"? Well, in the mobile NAT64 case, "a different answer" will be "an unusable answer," wouldn't it? Lee From nobody Mon Mar 19 07:01:37 2018 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 9BDA3126D45 for ; Mon, 19 Mar 2018 07:01:35 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 6OECcaoBYOyI for ; Mon, 19 Mar 2018 07:01:29 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354D71204DA for ; Mon, 19 Mar 2018 07:01:29 -0700 (PDT) Received: from dhcp-86a7.meeting.ietf.org (dhcp-86a7.meeting.ietf.org [31.133.134.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EA36F9EB; Mon, 19 Mar 2018 09:56:11 -0400 (EDT) From: Tom Pusateri Message-Id: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7899F905-2351-46F9-ACA6-8630B5FE790F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Mar 2018 14:01:25 +0000 In-Reply-To: <20180319131134.46hjo2eo757jqe7d@miek.nl> Cc: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , DoH WG , Patrick McManus To: Miek Gieben References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 14:01:36 -0000 --Apple-Mail=_7899F905-2351-46F9-ACA6-8630B5FE790F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2018, at 1:11 PM, Miek Gieben wrote: >=20 > [ Quoting in "Re: [Doh] meta qtypes..." ] >> I would prefer if the draft did NOT even consider Meta types, but = limited >> itself to pure queries i.e. excluded query type's 128..255 >> Additionally doing other things like Updates and Zone transfers = should >> involve different meta types (lets learn from experience here not = repeat >> mistakes) >=20 > Yes! So make the draft say? >=20 > MUST support opcode QUERY. MUST NOT support any other opcode. > MUST support all RR types excluding the meta range 128..255. >=20 > A non supported query MUST be rejected with a ... ? >=20 >=20 > /Miek No, please don=E2=80=99t prevent DNS Stateful Operations from working = which is in Last Call and uses a new Opcode. https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ = Tom --Apple-Mail=_7899F905-2351-46F9-ACA6-8630B5FE790F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 19, 2018, at 1:11 PM, Miek Gieben <miek@miek.nl> = wrote:

[ Quoting <olafur@cloudflare.com> in "Re: [Doh] meta qtypes..." = ]
I would prefer if = the draft did NOT even consider Meta types, but limited
itself to pure queries i.e. excluded query type's 128..255
Additionally doing other things like Updates and Zone = transfers should
involve different meta types (lets learn = from experience here not repeat
mistakes)

Yes! So make the draft say?

  MUST support opcode QUERY. MUST = NOT support any other opcode.
  MUST support = all RR types excluding the meta range 128..255.

  A non supported query MUST be rejected with a = ... ?


/Miek

No, please = don=E2=80=99t prevent DNS Stateful Operations from working which is in = Last Call and uses a new Opcode.


Tom

= --Apple-Mail=_7899F905-2351-46F9-ACA6-8630B5FE790F-- From nobody Mon Mar 19 07:19:02 2018 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 53EE6126FB3 for ; Mon, 19 Mar 2018 07:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SET0kAD544ge for ; Mon, 19 Mar 2018 07:18:59 -0700 (PDT) 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 322391204DA for ; Mon, 19 Mar 2018 07:18:59 -0700 (PDT) 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; Mon, 19 Mar 2018 07:18:57 -0700 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; Mon, 19 Mar 2018 07:18:57 -0700 From: Paul Hoffman To: Tom Pusateri CC: DoH WG Thread-Topic: [Ext] [Doh] meta qtypes Thread-Index: AQHTv403rJ8yD4wbHkOLCBQeOr3JYw== Date: Mon, 19 Mar 2018 14:18:56 +0000 Message-ID: <98B6C5DC-27F9-4A9F-8BFC-187D4F5878A8@icann.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> In-Reply-To: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.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.47.234] Content-Type: text/plain; charset="utf-8" Content-ID: <47B09E42DF1B7747A9FD7454D4592894@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] meta qtypes 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, 19 Mar 2018 14:19:00 -0000 T24gTWFyIDE5LCAyMDE4LCBhdCAyOjAxIFBNLCBUb20gUHVzYXRlcmkgPHB1c2F0ZXJpQGJhbmdq LmNvbT4gd3JvdGU6DQo+IE5vLCBwbGVhc2UgZG9u4oCZdCBwcmV2ZW50IEROUyBTdGF0ZWZ1bCBP cGVyYXRpb25zIGZyb20gd29ya2luZyB3aGljaCBpcyBpbiBMYXN0IENhbGwgYW5kIHVzZXMgYSBu ZXcgT3Bjb2RlLg0KDQpET0ggaXMgbm90IGFuIGFwcHJvcHJpYXRlIHRyYW5zcG9ydCBmb3Igc3Rh dGVmdWwgc2Vzc2lvbnMuDQoNCi0tUGF1bCBIb2ZmbWFu From nobody Mon Mar 19 07:20:58 2018 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 B309412778D for ; Mon, 19 Mar 2018 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 qVCWTyDuHC2L for ; Mon, 19 Mar 2018 07:20:55 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4030D1270A3 for ; Mon, 19 Mar 2018 07:20:48 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id A7E4D3A058 for ; Mon, 19 Mar 2018 10:20:47 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id c12so14419011oic.7 for ; Mon, 19 Mar 2018 07:20:47 -0700 (PDT) X-Gm-Message-State: AElRT7EDUbiaxoC9qpSSbNaNbLY1eaBDmi20u383QU9dLeZnp4/LgTDn GduHvf3H32aPvczCsWmshNvSc4kjp5x4ieG8EuA= X-Google-Smtp-Source: AG47ELshGj1veJ70FvR7281kFd+ZRH+LvCDEv68wl9tUM1JepfdHXU+zlXH3Se1WkgbVuRgd1wUAHF/GLOEJoqJyEyQ= X-Received: by 10.202.3.198 with SMTP id 189mr6683485oid.132.1521469247208; Mon, 19 Mar 2018 07:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 07:20:46 -0700 (PDT) In-Reply-To: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> From: Patrick McManus Date: Mon, 19 Mar 2018 14:20:46 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Tom Pusateri Cc: Miek Gieben , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , DoH WG , Patrick McManus Content-Type: multipart/alternative; boundary="001a11c0463c0446580567c4aa68" Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 14:20:58 -0000 --001a11c0463c0446580567c4aa68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm happy to learn more, but it appears to me that DoH is not suitable for use with session signal because: 1] DSO messages communicate operations within persistent stateful sessions and 2] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol The HTTP semantics that DoH uses (i.e. it does not require a particular usage of a particular HTTP wire protocol - it exists at the method and URI level of things) don't give you basic properties like a stateful session layer. For instance, your messages could go out of order or even to different servers. On Mon, Mar 19, 2018 at 2:01 PM, Tom Pusateri wrote: > > On Mar 19, 2018, at 1:11 PM, Miek Gieben wrote: > > [ Quoting in "Re: [Doh] meta qtypes..." ] > > I would prefer if the draft did NOT even consider Meta types, but limited > itself to pure queries i.e. excluded query type's 128..255 > Additionally doing other things like Updates and Zone transfers should > involve different meta types (lets learn from experience here not repeat > mistakes) > > > Yes! So make the draft say? > > MUST support opcode QUERY. MUST NOT support any other opcode. > MUST support all RR types excluding the meta range 128..255. > > A non supported query MUST be rejected with a ... ? > > > /Miek > > > No, please don=E2=80=99t prevent DNS Stateful Operations from working whi= ch is in > Last Call and uses a new Opcode. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > Tom > > --001a11c0463c0446580567c4aa68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy to learn more, but it appears to me tha= t DoH is not suitable for use with session signal because:

1] DSO messages communicate operations within persistent statefu= l sessions

and 2] The Hypertext Transfer Prot= ocol (HTTP) is a stateless application-level protocol

The HTTP semantics that DoH uses (i.e. it does not require a partic= ular usage of a particular HTTP wire protocol - it exists at the method and= URI level of things) don't give you basic properties like a stateful s= ession layer. For instance, your messages could go out of order or even to = different servers.


On Mon, Mar 19, 2018 at 2:01 PM, Tom Pusate= ri <pusateri@bangj.com> wrote:

On Mar 19, 2018, at 1:11 PM, Miek Gieben <miek@miek.nl> wrote:
[= Quoting <ola= fur@cloudflare.com> in "Re: [Doh] meta qtypes..." ]
I would prefer if the draft did NOT even consider Me= ta types, but limited
itself to pure queries i.e. excluded query type= 9;s 128..255
Additionally doing other things like Updates and Zone trans= fers should
involve different meta types (lets learn from experience her= e not repeat
mistakes)

Yes! So make the draft say?
=C2=A0=C2=A0MUST support opcode QUERY. MUST NOT support any other op= code.
=C2=A0=C2=A0MUST support all RR types excluding the meta range 12= 8..255.

=C2=A0=C2=A0A non supported query MUST be rejected with a .= .. ?


/Miek

No,= please don=E2=80=99t prevent DNS Stateful Operations from working which is= in Last Call and uses a new Opcode.


<= /div>
Tom


--001a11c0463c0446580567c4aa68-- From nobody Mon Mar 19 07:22:23 2018 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 7F62B126FB3 for ; Mon, 19 Mar 2018 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB9L770GbwWY for ; Mon, 19 Mar 2018 07:22:18 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 A5C761204DA for ; Mon, 19 Mar 2018 07:22:18 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id h2so18756289wre.12 for ; Mon, 19 Mar 2018 07:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Wrxx5BJTUgqPNf4PvirV3m+DCd5YQ+ZWbFrLiV9cqnU=; b=mpXdbSj7G903ft4V4GvNOcngXyIDHvjr7ekxNcVHHMG8PwvztC3Gwoj4nXElZbxsO1 WW1p6f4OvI5DsBd5M4UI2f0tTSeJ9kk4ucbvGEmhx6nHHsxRBeoeqmtq05cjzF/dPLex ymChUnjqhq0+uiq5D1ayxkSbox7b2L0JyJGz3xKeBScz0DuiwN3GZg2neH838hR7a6xr 7Ll8DfLAN/S+HvxiOCn7BgLHJfdCt/y2Bbcsx4L2edXzDNGlcE1dzpmffbL7AAA6snRe j9ZE+mqFrvsfvOxtxY8c9Q7tFA7Thm0IIsBi4CPz8OFKhoezSovn9FMRSdtQb+fgKe/g 6y2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Wrxx5BJTUgqPNf4PvirV3m+DCd5YQ+ZWbFrLiV9cqnU=; b=PZn4ko3guIBfu1ZYyMvYt31HhHO2CNwBI8mSvSNcDx1JPyZnT6VMmpJX2fNnJAQKrG AQCPDVKy1aLY68hw4GWCaoYliiwYBvaurIjIUWNbWh3ClGJ/GnfeFMLLmIzkVQUMlpoT LFIQlIvKC9wRP7tkpTfRcyjuK3lDJs7wfcgxwV4vmASaDxOBAxF3c49jlBXnJHEZlz+Y VpNl2THRPSVlpN433M7k5ybKxSCc2WzxBsXX+TfpDCRBQzFFPBrvi17C0SvUuHpwpOho Kn5+bL5NWmUNC8EmQOMhBPVoOTZEgRgovHJPo6j8SN8nC+9cz3TcxFqVL9nbiLmxAcrz slQg== X-Gm-Message-State: AElRT7FP54SbgYq1rGStksmTZNWNRsd7Tt/lUcoG48RUYtLIQpS6E4aB z3X7Y8umumRnA68xGryMBEERzA== X-Google-Smtp-Source: AG47ELvp9PYEve1bYRncSH7ohf6RWVPL6sj4Hp3IUfRNoneBoaA0ggnDqTWnAx+Sb7tpKDssInDY0g== X-Received: by 10.223.201.142 with SMTP id f14mr10055302wrh.40.1521469337081; Mon, 19 Mar 2018 07:22:17 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:fe79:234c]) by smtp.gmail.com with ESMTPSA id p78sm626517wmg.47.2018.03.19.07.22.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Mar 2018 07:22:16 -0700 (PDT) Date: Mon, 19 Mar 2018 14:22:16 +0000 From: Miek Gieben To: Tom Pusateri Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , DoH WG , Patrick McManus Message-ID: <20180319142216.cfb4oy3wyusogp2e@miek.nl> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 14:22:21 -0000 [ Quoting in "Re: [Doh] meta qtypes..." ] >> Yes! So make the draft say? >> >> MUST support opcode QUERY. MUST NOT support any other opcode. >> MUST support all RR types excluding the meta range 128..255. >> >> A non supported query MUST be rejected with a ... ? >> >> >> /Miek > >No, please don’t prevent DNS Stateful Operations from working which is in Last Call and uses a new Opcode. > >https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ OK, so put the above wording in the context of disallowing any caching on the HTTP layer and not rejecting anything out right. From nobody Mon Mar 19 07:24:58 2018 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 4F604127077 for ; Mon, 19 Mar 2018 07:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pxZcx24WgvMw for ; Mon, 19 Mar 2018 07:24:55 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A609D1204DA for ; Mon, 19 Mar 2018 07:24:55 -0700 (PDT) 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]:39292) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1exviV-000T9i-dM (Exim 4.89_2) (return-path ); Mon, 19 Mar 2018 14:24:51 +0000 Date: Mon, 19 Mar 2018 14:24:50 +0000 From: Tony Finch To: Tom Pusateri cc: Miek Gieben , =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , DoH WG , Patrick McManus In-Reply-To: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> Message-ID: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-2022160737-1521469491=:20806" Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 14:24:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-2022160737-1521469491=:20806 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Tom Pusateri wrote: > No, please don=E2=80=99t prevent DNS Stateful Operations from working whi= ch is > in Last Call and uses a new Opcode. The way I would like a DoH proxy to work is to have a pool of persistent TCP connections from the proxy to the DNS server; the proxy would then multiplex queries from HTTPS onto the backend TCP connections with no particular coupling between client TLS connections and backend TCP connections. The problem with AXFR is the response is multiple messages, and it takes over the connection, so it doesn't fit into my proxy model, nor does it fit into the udpwireformat media type. Stateful options have a similar problem. Really, the state of the backend connection belongs to the proxy, not to the https client. Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Malin: East, becoming variable 3 or 4, occasionally 5 at first. Slight or moderate. Fair. Good. --1870870841-2022160737-1521469491=:20806-- From nobody Mon Mar 19 07:27:18 2018 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 E50691275FD for ; Mon, 19 Mar 2018 07:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=GIGzTdse; dkim=pass (1024-bit key) header.d=yitter.info header.b=RPv59XI1 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 rlAJ7oCpwuV5 for ; Mon, 19 Mar 2018 07:27:15 -0700 (PDT) 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 3129C12D870 for ; Mon, 19 Mar 2018 07:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 78707BE780 for ; Mon, 19 Mar 2018 14:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521469568; bh=AmDoyLcfSMRLxu2XMFzJnoLbB+9h1zHPD48ijXu6CcU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GIGzTdseBzCi1OTFTWOTcNtHu50XRKpl8EpHUpcplTO8Io0M8z+EuBK8S+8nFyJrk TJ9f7LWbUSnzjxqY1j+50XG8zbbcqgWOmBOCcWlZ2/68pXZxkmmSjaHw9u6B6EKuZt W+ZWcNq4NlbBPUSLvDu/m1fV/YohkNpyASc906bU= 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 Zw5sI3ttDOrO for ; Mon, 19 Mar 2018 14:26:07 +0000 (UTC) Date: Mon, 19 Mar 2018 10:26:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521469567; bh=AmDoyLcfSMRLxu2XMFzJnoLbB+9h1zHPD48ijXu6CcU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RPv59XI1Tvl+0oOjojwoSTf223ZZACv6QgkgfWl9k5q6IbfmFF4a3OFKzpdOp1Qa3 dL1a8dByxEfqJjOrjMM5ezJ+iKek73rq+eUK5KZKsd0FxVxFTUq4SSSesJi2jo6a81 ko8mDa8+7Z1Wt6IGSUZaztC84eoK4r61AN1HoFis= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180319142603.6jlcbrk2ank5sotc@mx4.yitter.info> References: <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] DNS64 and 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: Mon, 19 Mar 2018 14:27:17 -0000 On Mon, Mar 19, 2018 at 06:52:00AM -0400, Ben Schwartz wrote: > > I am fine with a note on this topic, but I will observe that RFC 7858 (DNS over > TLS) feels no need to mention DNS64, so I think we are free to take a similar > approach here. The draft already explicitly calls out DNS64. Section 4.1 says that it won't support network-specific DNS64. It is possible that this means it won't work in lots of the cases people are worried about, however. I just don't know. In any case, I think simply making a small modification to section 10 would be enough: OLD 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's choice of DNS server may affect the responses it gets to its queries. NEW 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's choice of DNS server may affect the responses it gets to its queries. In the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 19 07:29:20 2018 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 B658D1275FD for ; Mon, 19 Mar 2018 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 tD9JJsdR33fk for ; Mon, 19 Mar 2018 07:29:17 -0700 (PDT) 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 3B2D912741D for ; Mon, 19 Mar 2018 07:29:17 -0700 (PDT) Received: from dhcp-8ed0.meeting.ietf.org (dhcp-8ed0.meeting.ietf.org [31.133.142.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id DDF38242147B; Mon, 19 Mar 2018 14:29:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Jim Reid In-Reply-To: <20180319142603.6jlcbrk2ank5sotc@mx4.yitter.info> Date: Mon, 19 Mar 2018 14:29:13 +0000 Cc: doh@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20180319103315.zubfti6m4zoscas5@mx4.yitter.info> <20180319142603.6jlcbrk2ank5sotc@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [Ext] DNS64 and 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: Mon, 19 Mar 2018 14:29:19 -0000 > On 19 Mar 2018, at 14:26, Andrew Sullivan wrote: > > In any case, I think simply making a small modification to section 10 > would be enough: wfm From nobody Mon Mar 19 07:30:01 2018 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 3E67D1270A3 for ; Mon, 19 Mar 2018 07:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 pkfA4ZKZg5Yq for ; Mon, 19 Mar 2018 07:29:58 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7055126FB3 for ; Mon, 19 Mar 2018 07:29:58 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9911C382DC; Mon, 19 Mar 2018 10:29:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.51557.607100.712220@gro.dd.org> Date: Mon, 19 Mar 2018 10:29:57 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> Archived-At: Subject: [Doh] DNS Session Signalling (was: meta qtypes) 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, 19 Mar 2018 14:30:00 -0000 Tom Pusateri writes: > No, please don t prevent DNS Stateful Operations from working which > is in Last Call and uses a new Opcode. Please refer to: https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/68 From nobody Mon Mar 19 07:36:39 2018 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 251431241F3 for ; Mon, 19 Mar 2018 07:36:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 Fj-9_gOuH3_Y for ; Mon, 19 Mar 2018 07:36:36 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4EA127735 for ; Mon, 19 Mar 2018 07:36:36 -0700 (PDT) Received: from dhcp-86a7.meeting.ietf.org (dhcp-86a7.meeting.ietf.org [31.133.134.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id D3B0AA01; Mon, 19 Mar 2018 10:31:18 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1CBD7780-74A4-4A0A-9A80-6CACBEE468C3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Mar 2018 14:36:31 +0000 In-Reply-To: <23215.51557.607100.712220@gro.dd.org> Cc: DoH WG To: Dave Lawrence References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.51557.607100.712220@gro.dd.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] DNS Session Signalling (was: meta qtypes) 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, 19 Mar 2018 14:36:38 -0000 --Apple-Mail=_1CBD7780-74A4-4A0A-9A80-6CACBEE468C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 19, 2018, at 2:29 PM, Dave Lawrence wrote: >=20 > Tom Pusateri writes: >> No, please don t prevent DNS Stateful Operations from working which >> is in Last Call and uses a new Opcode. >=20 > Please refer to: >=20 > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/68 = Thanks for the pointer. I missed that discussion. Tom --Apple-Mail=_1CBD7780-74A4-4A0A-9A80-6CACBEE468C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 19, 2018, at 2:29 PM, Dave Lawrence <tale@dd.org> = wrote:

Tom Pusateri writes:
No, please don t prevent DNS Stateful Operations from working = which
is in Last Call and uses a new Opcode.

Please refer to:

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/6= 8

Thanks for the pointer. I missed that = discussion.

Tom


= --Apple-Mail=_1CBD7780-74A4-4A0A-9A80-6CACBEE468C3-- From nobody Mon Mar 19 07:40:08 2018 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 0650A12741D for ; Mon, 19 Mar 2018 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=L/W+5L6t; dkim=pass (1024-bit key) header.d=yitter.info header.b=mwG9wqnd 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 4_1XT1ZNk2ud for ; Mon, 19 Mar 2018 07:40:05 -0700 (PDT) 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 A1AEF1241F3 for ; Mon, 19 Mar 2018 07:40:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 1161BBE780 for ; Mon, 19 Mar 2018 14:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521470375; bh=Y/nlS8LFgrve819BQ7HIUnvon4OOQpXy3N8w0jPLagk=; h=Date:From:To:Subject:From; b=L/W+5L6t0IWnePoEA5OyKP665JSV9b0rcbm5xIi6UhY7RWXYkPwHxXOO0BsNf1D/U X8H6cwUZIUNs63wDLhP/NYovT7CG2VnwwlAavFz+XTXPEX/e9eyLIKGAt+jMcSCADs +Jld1oLiv7tcyqOsQFkWyIj/GcF0gkEYX/uWMako= 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 tpO1RmS90owY for ; Mon, 19 Mar 2018 14:39:33 +0000 (UTC) Date: Mon, 19 Mar 2018 10:39:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521470373; bh=Y/nlS8LFgrve819BQ7HIUnvon4OOQpXy3N8w0jPLagk=; h=Date:From:To:Subject:From; b=mwG9wqndHDtA+dgfMCUeMGEt/rkJe8D76GrWManoLnRQ40XErW93VoY2vREI+cGWY vQs0a/Xs1QZ5XK2QAaJJpu0GO/3z9Z8RmAj6+2OLi24nPZnTUzPN5HzZSxTU8LcEic 8CjbIhL6uxZyNhgqbG9uOZl8NL8PT+9NXiPUqafQ= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180319143929.tgndmrvdggewpcqv@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Doh] DNSSEC, DOH, and DNS headers 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, 19 Mar 2018 14:40:07 -0000 Hi, Section 6 of -03 says this: Different response media types will provide more or less information from a DNS response. For example, one response type might include the information from the DNS header bytes while another might omit it. But section 9 says A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. It seems to me that these are in tension with one another, because the AD and CD bits are in the header that the response type is permitted to throw away. Maybe it could be resolved thus: NEW A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. This capability might be affected by the response media type a DNS API server supports. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 19 07:42:16 2018 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 3D1841275FD for ; Mon, 19 Mar 2018 07:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 yjRIH5wFyMQG for ; Mon, 19 Mar 2018 07:42:13 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AAF12741D for ; Mon, 19 Mar 2018 07:42:13 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9ABBB382F4; Mon, 19 Mar 2018 10:42:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.52292.616186.468475@gro.dd.org> Date: Mon, 19 Mar 2018 10:42:12 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 14:42:14 -0000 Tony Finch writes: > The problem with AXFR is [...] it [doesn't] fit into the > udpwireformat media type. Setting aside the other points you brought up ... it doesn't? I mean, sure, an AXFR would likely exceed UDP packet sizes typically seen in the wild, but why not a hypothetical jumbo packet, content-length mumblety-megabytes? dns-udpwireformat is not defined in the doc as intrinsically limiting message length; multiple messages happen with DNS/TCP only because of the defined 64k limit for them. "udp" in the type only means "doesn't have the 16 bit prefix length". Does this too need to be made more explicit in the doc? I don't recall any discussion of message size limits, or lack thereof. From nobody Mon Mar 19 08:10:24 2018 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 0283812783A for ; Mon, 19 Mar 2018 08:10:23 -0700 (PDT) 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 YSpWFWb2zICh for ; Mon, 19 Mar 2018 08:10:21 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 B7DC21270AB for ; Mon, 19 Mar 2018 08:10:21 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 4C886A05B9; Mon, 19 Mar 2018 16:10:20 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 24022EC0BB8; Mon, 19 Mar 2018 16:09:58 +0100 (CET) Date: Mon, 19 Mar 2018 15:09:58 +0000 From: Stephane Bortzmeyer To: Mike Bishop Cc: Paul Hoffman , Ted Hardie , DoH WG Message-ID: <20180319150958.GA23411@laperouse.bortzmeyer.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 15:10:23 -0000 On Mon, Mar 19, 2018 at 10:42:42AM +0000, Mike Bishop wrote a message of 24 lines which said: > There's a reasonable argument that if Content-Type is > application/dns-udpwireformat, it should be processed by the DNS > client regardless of the HTTP status code. It can be dangerous, no? If the status code is 500, it means there was a serious problem in the server, the content may be, for instance, truncated. > (And that a 200 with any other Content-Type is an error.) No, because we want to be future-proof (allow application/dns+json in the future). From nobody Mon Mar 19 08:22:06 2018 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 375A9129C56 for ; Mon, 19 Mar 2018 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=KL8di3gP; dkim=pass (1024-bit key) header.d=yitter.info header.b=ZohxQ7ex 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 zThKYRw4GaEc for ; Mon, 19 Mar 2018 08:22:03 -0700 (PDT) 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 E288F127873 for ; Mon, 19 Mar 2018 08:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 35D03BE780 for ; Mon, 19 Mar 2018 15:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521472892; bh=FtMvgt7atvbqiDg09f4fpelPsfwLq3PLNF2ue4HsdfU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KL8di3gP607tYwy8PqMGcp6jt2+nFvjc/TsEBcOUSRg2SfGV7CiFq8csQWuPHD++v MXeyEgqiElzQOUPIxA6wr+qmyTtuUhOo34khH8/+OmcV6LFibnCKgBq6uLKU8OoRZf BX2uwKkYFgJbbMjHeGr1iDBLyelaoARXck0RvU2Y= 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 EmiqrX_JQRZt for ; Mon, 19 Mar 2018 15:21:31 +0000 (UTC) Date: Mon, 19 Mar 2018 11:21:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521472891; bh=FtMvgt7atvbqiDg09f4fpelPsfwLq3PLNF2ue4HsdfU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ZohxQ7ex7Z7Ql8bAGH6sVeOszi4gYfTxlEUpxtlcoJ4UNhQZCMdoTjyHZa//87EHc +ua5o8Kzv+rBOe/NBw8EzbI5eBGEoMtJsimamD3OGyBcmbBh7TNAW5kioWcQ+0qu/c on9xrx02k5gTMzsvcAcn+ZuNCaYZ493PfqIZobe0= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319150958.GA23411@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 15:22:04 -0000 On Mon, Mar 19, 2018 at 03:09:58PM +0000, Stephane Bortzmeyer wrote: > On Mon, Mar 19, 2018 at 10:42:42AM +0000, > Mike Bishop wrote > a message of 24 lines which said: > > > There's a reasonable argument that if Content-Type is > > application/dns-udpwireformat, it should be processed by the DNS > > client regardless of the HTTP status code. > > It can be dangerous, no? If the status code is 500, it means there was > a serious problem in the server, the content may be, for instance, > truncated. If it were actually truncated, wouldn't the message have a TC bit set? If the message contained is short of the full UDP message, wouldn't the client-side processor be able to tell because the counts of actual RRs wouldn't match the header section counters? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 19 08:40:37 2018 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 3F15F12E051 for ; Mon, 19 Mar 2018 08:40:29 -0700 (PDT) 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 RWZNcN70kIia for ; Mon, 19 Mar 2018 08:40:27 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 1FCC212E036 for ; Mon, 19 Mar 2018 08:40:25 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id EC322A05BA; Mon, 19 Mar 2018 16:40:22 +0100 (CET) Received: by godin (Postfix, from userid 1000) id E8624EC0BB8; Mon, 19 Mar 2018 16:39:58 +0100 (CET) Date: Mon, 19 Mar 2018 15:39:58 +0000 From: Stephane Bortzmeyer To: Andrew Sullivan Cc: doh@ietf.org Message-ID: <20180319153958.GA24327@laperouse.bortzmeyer.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 15:40:32 -0000 On Mon, Mar 19, 2018 at 11:21:27AM -0400, Andrew Sullivan wrote a message of 29 lines which said: > If it were actually truncated, wouldn't the message have a TC bit > set? Truncated for HTTP reasons (error 500 : the server crashed), not for DNS reasons. If the DNS answer is truncated for DNS reasons (EDNS buffer size too small), I would expect the HTTP status code to be 200. From nobody Mon Mar 19 09:03:16 2018 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 DF5AC12D94C for ; Mon, 19 Mar 2018 09:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 oy67_sc2vTlF for ; Mon, 19 Mar 2018 09:03:06 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4948812DA51 for ; Mon, 19 Mar 2018 09:03:06 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 85A0A3A04F for ; Mon, 19 Mar 2018 12:03:05 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id u141so2852043oif.1 for ; Mon, 19 Mar 2018 09:03:05 -0700 (PDT) X-Gm-Message-State: AElRT7E0NBdUc7WAOUAtnO1AgK0QaZ991rb5pAlXbtmyOaKEBIF8H+JQ 6zg4AbdvOKFwtzfUvnIEaVBY9s/lGHHneXC01/k= X-Google-Smtp-Source: AG47ELtoZVkNlfSeXBdrUEVhXDHz4+/ofAC/rBhvy2ya4yvx8jq9CtYRaKo80waAujVvktSJV0vwYFByXjuoJWb33dA= X-Received: by 10.202.178.195 with SMTP id b186mr6834810oif.337.1521475385248; Mon, 19 Mar 2018 09:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 09:03:04 -0700 (PDT) In-Reply-To: <20180319153958.GA24327@laperouse.bortzmeyer.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> <20180319153958.GA24327@laperouse.bortzmeyer.org> From: Patrick McManus Date: Mon, 19 Mar 2018 16:03:04 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Stephane Bortzmeyer Cc: Andrew Sullivan , DoH WG Content-Type: multipart/alternative; boundary="001a113ce932df53a90567c6176c" Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 16:03:10 -0000 --001a113ce932df53a90567c6176c Content-Type: text/plain; charset="UTF-8" I agree with Stephane. DNS information in non-successful HTTP responses (i.e. not a 2xx) is not the answer to the question you asked in the HTTP request. I can't tell you what it is - its normally just defined as human readable explanation. It may certainly be generated by HTTP servers that do not understand DoH. On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzmeyer wrote: > On Mon, Mar 19, 2018 at 11:21:27AM -0400, > Andrew Sullivan wrote > a message of 29 lines which said: > > > If it were actually truncated, wouldn't the message have a TC bit > > set? > > Truncated for HTTP reasons (error 500 : the server crashed), not for > DNS reasons. > > If the DNS answer is truncated for DNS reasons (EDNS buffer size too > small), I would expect the HTTP status code to be 200. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113ce932df53a90567c6176c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Stephane. DNS information in non-success= ful HTTP responses (i.e. not a 2xx) is not the answer to the question you a= sked in the HTTP request. I can't tell you what it is - its normally ju= st defined as human readable explanation. It may certainly be generated by = HTTP servers that do not understand DoH.




On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzmeyer <bortzmeyer@nic.= fr> wrote:
On Mon, Mar 19, = 2018 at 11:21:27AM -0400,
=C2=A0Andrew Sullivan <ajs@anv= ilwalrusden.com> wrote
=C2=A0a message of 29 lines which said:

> If it were actually truncated, wouldn't the message have a TC bit<= br> > set?

Truncated for HTTP reasons (error 500 : the server crashed), not for=
DNS reasons.

If the DNS answer is truncated for DNS reasons (EDNS buffer size too
small), I would expect the HTTP status code to be 200.

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

--001a113ce932df53a90567c6176c-- From nobody Mon Mar 19 10:57:19 2018 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 BCFB012D873 for ; Mon, 19 Mar 2018 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HwcfP1PKX0vH for ; Mon, 19 Mar 2018 10:57:05 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B86612D88A for ; Mon, 19 Mar 2018 10:57:05 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 5D0C73843A; Mon, 19 Mar 2018 13:57:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23215.63984.364570.759118@gro.dd.org> Date: Mon, 19 Mar 2018 13:57:04 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 19 Mar 2018 17:57:08 -0000 Ben Schwartz writes: > So does that mean that a DOH server and client that both comply with all > SHOULD-strength requirements still may not be able to exchange any DNS data? > That seems like a weaker guarantee of compatibility than is typical at the > IETF. Has an answer to this question come through yet? > If following all the SHOULD-level recommendations is not sufficient > to ensure compatibility, then as an implementor I would appreciate > some clear additional guidance on what I have to do to make my > client compatible with any compliant DOH server (and vice versa as a > server implementor). Very much agree. From nobody Mon Mar 19 11:01:35 2018 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 B36AA12DA6F for ; Mon, 19 Mar 2018 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pJTiiZxerpBG for ; Mon, 19 Mar 2018 11:01:28 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id D725A12DA49 for ; Mon, 19 Mar 2018 11:01:27 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3D7A13A04F for ; Mon, 19 Mar 2018 14:01:27 -0400 (EDT) Received: by mail-oi0-f54.google.com with SMTP id u141so3183996oif.1 for ; Mon, 19 Mar 2018 11:01:27 -0700 (PDT) X-Gm-Message-State: AElRT7HiV/wCPJKMVs7wob/eUsW8Kpawq/3RrLZQ8X6y+1C8/xFkL0Gx WNXl12+VPTM3gcqKiHxJ3u/UEz2MLhS6H27jkXg= X-Google-Smtp-Source: AG47ELtJ+jEQqJ/ylO8D6ToWFRQMLNHiY9S70gtoN3+H0guKTfzP+0pVCFrQHUkfhdCsEqCzNMkzmPtDQuRb4gOEhBU= X-Received: by 10.202.3.65 with SMTP id 62mr7873055oid.38.1521482486935; Mon, 19 Mar 2018 11:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 11:01:25 -0700 (PDT) In-Reply-To: <23215.63984.364570.759118@gro.dd.org> References: <23215.63984.364570.759118@gro.dd.org> From: Patrick McManus Date: Mon, 19 Mar 2018 18:01:25 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: DoH WG Content-Type: multipart/alternative; boundary="001a113ba0802a84760567c7bfb7" Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 19 Mar 2018 18:01:33 -0000 --001a113ba0802a84760567c7bfb7 Content-Type: text/plain; charset="UTF-8" this is an open issue I was planning to address with f2f time of the wg as part of the slot related to this document (of course in addition to any mailing list comments). On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrence wrote: > Ben Schwartz writes: > > So does that mean that a DOH server and client that both comply with all > > SHOULD-strength requirements still may not be able to exchange any DNS > data? > > That seems like a weaker guarantee of compatibility than is typical at > the > > IETF. > > Has an answer to this question come through yet? > > > If following all the SHOULD-level recommendations is not sufficient > > to ensure compatibility, then as an implementor I would appreciate > > some clear additional guidance on what I have to do to make my > > client compatible with any compliant DOH server (and vice versa as a > > server implementor). > > Very much agree. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113ba0802a84760567c7bfb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this is an open issue I was planning to address with f2f t= ime of the wg as part of the slot related to this document (of course in ad= dition to any mailing list comments).
<= br>
On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrenc= e <ta= le@dd.org> wrote:
Ben Schwartz writes:
> So does that mean that a DOH server and client that both comply with a= ll
> SHOULD-strength requirements still may not be able to exchange any DNS= data?
> That seems like a weaker guarantee of compatibility than is typical at= the
> IETF.

Has an answer to this question come through yet?

> If following all the SHOULD-level recommendations is not sufficient > to ensure compatibility, then as an implementor I would appreciate
> some clear additional guidance on what I have to do to make my
> client compatible with any compliant DOH server (and vice versa as a > server implementor).

Very much agree.

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

--001a113ba0802a84760567c7bfb7-- From nobody Mon Mar 19 14:05:55 2018 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 42FE7127058 for ; Mon, 19 Mar 2018 14:05:54 -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 WjzwARD0ppfr for ; Mon, 19 Mar 2018 14:05:52 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4AE126D73 for ; Mon, 19 Mar 2018 14:05:52 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id 79-v6so18855064oth.11 for ; Mon, 19 Mar 2018 14:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oYW+N6S1V2S9aHj24rMAfEQ15BWuUGziFsTwLOXvMIA=; b=T0b/dZatnNXl/8+k2po5HB06e+A/rgnImBJhhFFhGzNKg0iyu2xcnrKLjdAx60hG7B 4ovkEzU0Nk1LQX4LEGAKm5Dq0OckxKK5bHPHCf/XZUSZJBTN+XPXJOT7kzjYad2Bc+7h 4r3gI9IQ+8FgQA9OGiUye/ACf4C3Q4CurM21AR41F72JEpCevPgr8HK3zISmaBUy+Vlv 0GVZGsE13BnT2X8Q2AaT3mMf63Or1gRL4lK+/T84P6v5SYVI8oa+ByCA9Kkd8vufgob4 dmgeCe00nbhct4QGAy3i4RLeiKWRfKDltbC0Cm4NdSwBvqERt6MrtNYhnXGsHy9JpxV5 pfRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oYW+N6S1V2S9aHj24rMAfEQ15BWuUGziFsTwLOXvMIA=; b=myuVTKcWQ7U/bxI4izlw8FNYndDpB0LY5aT9j7GHzgLrmN9pK0EGTSfOGeoE70s+PB JB8pfwn4oGSqcjUwqdlyxHPOdJhBThTcBju7FwvLuMvC98MyMAg6rGfGYeIuk8bCpxGs n5iY+O+kMdW6LzTbeVaxrXvo6XCvd9FVrG2uafI4ArsrW01QtB41Fn/XKXaMHnjLtP/6 417ehODBqQatqXibjeK2BjkTMRNQE6eyeMIFdwBBaFRkOZ57CIW9hCuV7zXezw3CP2qq ODkk4CVHoIkl9y77mmUvIohyZMAi9zWna+ENz9AsG2w4b27IaMsc/Z8+RD1dJlPuQqWS KtuQ== X-Gm-Message-State: AElRT7GzlwI4nfhRtxPbuNoM8Mg+BcXOHs2ARshrnpw2DzlQHh5rG0Uf +0eIlJdV2Xwi7FdpNHATRFi47b5PadEry4ADKPY= X-Google-Smtp-Source: AG47ELsUftciizoIzDa3brRqxRp/qHdL+NIH4vMi7r9OFQcB0Jm01ghgyoPd4B54VsLqwdSshVAmA5pVFQvxggEnU5U= X-Received: by 2002:a9d:e82:: with SMTP id 2-v6mr9104052otj.393.1521493551414; Mon, 19 Mar 2018 14:05:51 -0700 (PDT) MIME-Version: 1.0 References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> <20180319153958.GA24327@laperouse.bortzmeyer.org> In-Reply-To: From: Ted Hardie Date: Mon, 19 Mar 2018 21:05:40 +0000 Message-ID: To: Patrick McManus Cc: Andrew Sullivan , DoH WG , Stephane Bortzmeyer Content-Type: multipart/alternative; boundary="000000000000a903910567ca5242" Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 21:05:54 -0000 --000000000000a903910567ca5242 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 19, 2018 at 4:03 PM Patrick McManus wrote: > I agree with Stephane. DNS information in non-successful HTTP responses > (i.e. not a 2xx) is not the answer to the question you asked in the HTTP > request. I can't tell you what it is - its normally just defined as human > readable explanation. It may certainly be generated by HTTP servers that do > not understand DoH. > I think the point of saying that udp wire format responses should be passed to the dns sever, though, is that those will have been generated by a DNS aware system. Ted > > > > > On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzmeyer > wrote: > >> On Mon, Mar 19, 2018 at 11:21:27AM -0400, >> Andrew Sullivan wrote >> a message of 29 lines which said: >> >> > If it were actually truncated, wouldn't the message have a TC bit >> > set? >> >> Truncated for HTTP reasons (error 500 : the server crashed), not for >> DNS reasons. >> >> If the DNS answer is truncated for DNS reasons (EDNS buffer size too >> small), I would expect the HTTP status code to be 200. >> >> _______________________________________________ >> 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 > --000000000000a903910567ca5242 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Mar 19, 2018 = at 4:03 PM Patrick McManus <pmcm= anus@mozilla.com> wrote:
I agree with Stephane. DNS information in non-successful HTTP respon= ses (i.e. not a 2xx) is not the answer to the question you asked in the HTT= P request. I can't tell you what it is - its normally just defined as h= uman readable explanation. It may certainly be generated by HTTP servers th= at do not understand DoH.

I think the point of saying that udp wire f= ormat responses should be passed to the dns sever, though, is that those wi= ll have been generated by a DNS aware system.

Ted



<= div class=3D"gmail_quote">On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzme= yer <bortzm= eyer@nic.fr> wrote:
On Mon,= Mar 19, 2018 at 11:21:27AM -0400,
=C2=A0Andrew Sullivan <ajs@anvilwalrusden.com> wrote
=C2=A0a message of 29 lines which said:

> If it were actually truncated, wouldn't the message have a TC bit<= br> > set?

Truncated for HTTP reasons (error 500 : the server crashed), not for=
DNS reasons.

If the DNS answer is truncated for DNS reasons (EDNS buffer size too
small), I would expect the HTTP status code to be 200.

_______________________________________________
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
--000000000000a903910567ca5242-- From nobody Mon Mar 19 14:56:59 2018 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 0FEB412D72F for ; Mon, 19 Mar 2018 14:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 nWavvi8LwNeR for ; Mon, 19 Mar 2018 14:56:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 B6462127876 for ; Mon, 19 Mar 2018 14:56:55 -0700 (PDT) Received: from [192.168.0.235] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id DC6226095C for ; Mon, 19 Mar 2018 22:56:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521496613; bh=//nE5lG4RfxB72HzKvgPX1YNmhSkQ85hLYiKQqsIlEk=; h=To:From:Date; b=akVa+Q1SXhuHGTTHUfgxCM8ZV+GgCcY8yn5o2RQGOkjT0aCWUIvle5acSmmOV9auR PwwE7H2nhXNimd43bk5MH0CEq1QXBwHTIK5R/BIg2LaOtASO0P+r045fHwCXm3RCCE pBh2Z/ixSY61c2a/sENmh0vvqDyErPVsSwUhbf5g= To: doh@ietf.org References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> Date: Mon, 19 Mar 2018 22:56:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <23215.52292.616186.468475@gro.dd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] meta qtypes 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, 19 Mar 2018 21:56:58 -0000 On 19.3.2018 15:42, Dave Lawrence wrote: > Tony Finch writes: >> The problem with AXFR is [...] it [doesn't] fit into the >> udpwireformat media type. > > Setting aside the other points you brought up ... it doesn't? > > I mean, sure, an AXFR would likely exceed UDP packet sizes typically > seen in the wild, but why not a hypothetical jumbo packet, > content-length mumblety-megabytes? dns-udpwireformat is not defined in > the doc as intrinsically limiting message length; multiple messages > happen with DNS/TCP only because of the defined 64k limit for them. > "udp" in the type only means "doesn't have the 16 bit prefix length". Oh, but in that case the theoretical "proxy" would have re-assemble answers from TCP connection to a DNS server into jumbo-message. Bleh, please do not do this. DNS is complex as hell now and additional layer of complexity in translation is going to be major pain. Maybe we can get out first version without metatypes and add these later on, if there is an actual demand for them. Petr Å paÄek @ CZ.NIC > Does this too need to be made more explicit in the doc? I don't > recall any discussion of message size limits, or lack thereof From nobody Mon Mar 19 14:59:37 2018 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 A284812D94D for ; Mon, 19 Mar 2018 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 hS6EK6nvf2e8 for ; Mon, 19 Mar 2018 14:59:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 3557012D779 for ; Mon, 19 Mar 2018 14:59:34 -0700 (PDT) Received: from [192.168.0.235] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id 7994F6095C for ; Mon, 19 Mar 2018 22:59:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521496772; bh=41d6onL1SRbZuxd9tvwpExE5iI5IUog1l+8X36K3Jtw=; h=To:From:Date; b=Cen406vt1cwuuXEMU8vhYrINdDNHxEgZtz9GglwyeKB4nwyAeL81ZHFrj5EEKagFq FAUbDWcgUFpH7WfkWVH2YCR70rM0EbZ5KRYcCCtRCID9sD+cKdiQ7wKtpeicBrcep3 tL6wckUHrs3QJMoJ9RZKhQu72VMlqfyn5BgL/w1I= To: doh@ietf.org References: <23215.63984.364570.759118@gro.dd.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <958176d9-00cd-e8ba-8c74-c6c736ab99e8@nic.cz> Date: Mon, 19 Mar 2018 22:59:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 19 Mar 2018 21:59:36 -0000 On 19.3.2018 19:01, Patrick McManus wrote: > this is an open issue I was planning to address with f2f time of the wg > as part of the slot related to this document (of course in addition to > any mailing list comments). > > On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrence > wrote: > > Ben Schwartz writes: > > So does that mean that a DOH server and client that both comply with all > > SHOULD-strength requirements still may not be able to exchange any DNS data? > > That seems like a weaker guarantee of compatibility than is typical at the > > IETF. > > Has an answer to this question come through yet? > > > If following all the SHOULD-level recommendations is not sufficient > > to ensure compatibility, then as an implementor I would appreciate > > some clear additional guidance on what I have to do to make my > > client compatible with any compliant DOH server (and vice versa as a > > server implementor). > > Very much agree. A subversive question: Do we *actually* need GET and POST? Could we get away with just one of these? Please apologize my lack of HTTP knowledge, but it seems to me weird to start with both (as opposed to gradual addition of new ones as necessary). -- Petr Å paÄek @ CZ.NIC From nobody Mon Mar 19 15:05:48 2018 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 5AA4112D955 for ; Mon, 19 Mar 2018 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 VH42jeCeDSac for ; Mon, 19 Mar 2018 15:05:44 -0700 (PDT) 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 B2C2F12D94D for ; Mon, 19 Mar 2018 15:05:44 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2JM30HZ014991; Mon, 19 Mar 2018 22:05:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=LOsE5JUTUr/fAPycJZoqVQbPeJQDwfh+mxnowp6mA9E=; b=FwqrVu7GpOQuKUfnrSZ655cfa9CKMnfu+GzB2LYtfZWqjhzW9+1a049fZ3/blC24Vxld xPOgg0xvZZ0v9AgNsw0G5VB/+8bv2jCz2tJqui1/qs4ugMJnCBoGFBiAz9DFp10izPaK Lyiq95rOP7xixbeT+Ku6COo6tppWrWT5TPern2Py/gmg6aMlQNxfdmRlk0ru8kaC39N0 MFVR1IWTn8MhLDviCa7kLrVA5PqgYqNBH3sqLESGYOv9tlLwcwHp+toZ2KI7OBgq/Ltk TtcXtH5ZkzfcFw/O8v40Hne/J/jB7q1Gt+pG5aovWMs9N14XB6Nr+UXfG+gRw7c1oJlC MA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2gruxkxp8t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 22:05:44 +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 w2JLuhH8008829; Mon, 19 Mar 2018 18:05:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2grxbug6ad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 18:05:39 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Mar 2018 18:05:38 -0400 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, 19 Mar 2018 18:05:37 -0400 From: "Hewitt, Rory" To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , "doh@ietf.org" Thread-Topic: [Doh] Support requirements for Get and Post Thread-Index: AQHTvetL01SQQ5CXs0uHffNLDPsIYKPUoYOAgAAKFQCAAAdugIAAAR6AgAA8HwCAABL0AIABBnkAgAIU5wCAAAE4gIAAQoaA//++DdA= Date: Mon, 19 Mar 2018 22:05:37 +0000 Message-ID: <043564f6d79c4077b93464fdeb8fabbb@usma1ex-dag1mb3.msg.corp.akamai.com> References: <23215.63984.364570.759118@gro.dd.org> <958176d9-00cd-e8ba-8c74-c6c736ab99e8@nic.cz> In-Reply-To: <958176d9-00cd-e8ba-8c74-c6c736ab99e8@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.176] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0031_01D3BF93.BCA9AAD0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190235 Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 19 Mar 2018 22:05:46 -0000 ------=_NextPart_000_0031_01D3BF93.BCA9AAD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This thought has occurred to me also... At an ABSOLUTE MINIMUM, we'd need GET for typical DNS requests and POST = for e.g. AXFR. But if we didn't worry about AXFR (yet), then maybe only = GET. Of course, complex queries can get pretty out of hand size-wise, = especially if we're passing a Base64-encoded udpwireformat query = string... Rory -----Original Message----- From: Petr =C5=A0pa=C4=8Dek [mailto:petr.spacek@nic.cz]=20 Sent: Monday, March 19, 2018 3:00 PM To: doh@ietf.org Subject: Re: [Doh] Support requirements for Get and Post On 19.3.2018 19:01, Patrick McManus wrote: > this is an open issue I was planning to address with f2f time of the=20 > wg as part of the slot related to this document (of course in addition = > to any mailing list comments). >=20 > On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrence > wrote: >=20 > Ben Schwartz writes: > > So does that mean that a DOH server and client that both comply = with all > > SHOULD-strength requirements still may not be able to exchange = any DNS data? > > That seems like a weaker guarantee of compatibility than is = typical at the > > IETF. >=20 > Has an answer to this question come through yet? >=20 > > If following all the SHOULD-level recommendations is not = sufficient > > to ensure compatibility, then as an implementor I would = appreciate > > some clear additional guidance on what I have to do to make my > > client compatible with any compliant DOH server (and vice versa = as a > > server implementor). >=20 > Very much agree. A subversive question: Do we *actually* need GET and POST? Could we get away with just one of = these? Please apologize my lack of HTTP knowledge, but it seems to me weird to = start with both (as opposed to gradual addition of new ones as = necessary). -- Petr =C5=A0pa=C4=8Dek @ CZ.NIC _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh ------=_NextPart_000_0031_01D3BF93.BCA9AAD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDMxOTIyMDUzN1owIwYJKoZIhvcNAQkEMRYEFIJLp271foIWzaP4j/GaZgn0CE+FMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBADODn4Fo5GLEG8w5oSx5b2TSuGROtyWc84FKxgvjUrMgy6cv961SEhBvT5a0 G8EsqhqtPKliqk2o20B2rN3hi9mgiaHY4zHt1H2b7JRf5worhF6X83jOSribxHmQhiCEeHEkH/FD jipK4XAXbkuOr9ug24qX9cRrZZ8YHLsJc5DSO3G6Ep/tMxnc5qqwhQ/IUXH20d/AOCt2k96bddvE WcqHwJmC1oOA/NLmw3+r3yEd5inIxeDqlbLryTX2NOL5aI0XGQh9L8sTwCQ5Dm68hIF7ArGJFWZR LwsHYtrvgFu2BRAQj+Vw94weg5n6Tp6hYMg/W0KhXil04FEST4XAbXAAAAAAAAA= ------=_NextPart_000_0031_01D3BF93.BCA9AAD0-- From nobody Mon Mar 19 15:11:54 2018 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 1283E12D94D for ; Mon, 19 Mar 2018 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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=NS8Qk4a/; dkim=pass (1024-bit key) header.d=yitter.info header.b=hne30iqb 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 B2p5QyYlorYC for ; Mon, 19 Mar 2018 15:11:51 -0700 (PDT) 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 86F821200E5 for ; Mon, 19 Mar 2018 15:11:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A3FA3BE780 for ; Mon, 19 Mar 2018 22:11:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521497480; bh=MXCzUAXjn4HhxgF+t0Ey4NSZIMJTBbTyKvUC6zic31w=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NS8Qk4a/t4zcyapiis2bnMu39iUF8Qc9QzYOV5QC7TB4sIdWmPMsELIwGu08d6zuM 7H/HpMeJJOj4QdjBv7oEsNpVbdwWlzc7GEmHXQ+/8BtUbAabrRIF+49g92C4sBqjwJ ezs0u2rvLRdY5fiFsalW7ijHTZW8GnMa/xzJOlW8= 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 yZX41kDu8ud5 for ; Mon, 19 Mar 2018 22:11:19 +0000 (UTC) Date: Mon, 19 Mar 2018 18:11:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521497479; bh=MXCzUAXjn4HhxgF+t0Ey4NSZIMJTBbTyKvUC6zic31w=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hne30iqbbTpfyE2poxy8+tPYWJUngLRihbst6WnJQC5dCIlfew6ydw7kJyF/24tJs vRU7MGzqEMIvKwBQV5IeBZ6SvEBD1JTGzPURWfK5rY0q0jv6LI/+A8Pg42UEvjpZFa sXZh1xkXOmFvAMMgm3YJKDNvzoEgrZyHnVQo6vxE= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180319221116.2tooil7y64lv764q@mx4.yitter.info> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> <20180319153958.GA24327@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319153958.GA24327@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 22:11:53 -0000 On Mon, Mar 19, 2018 at 03:39:58PM +0000, Stephane Bortzmeyer wrote: > Truncated for HTTP reasons (error 500 : the server crashed), not for > DNS reasons. That's what I assumed, but my point is that the rule could still be that the client could be required to process it, because the client would fail. The truncated message would have a section count that was higher than the records actually contained there (because of the truncated message), so the client would have a partial message and would eventually do whatever it would do in that case (in ordinary DNS, time out). I think erro 500 would probably return faster, however. > If the DNS answer is truncated for DNS reasons (EDNS buffer size too > small), I would expect the HTTP status code to be 200. Also ok with me. But since it's a wire message, you still need a TC bit set, right? (Hard for the as-yet-unwritten cases where there are no such header bits, though, so 200 is probably better.) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 19 15:38:26 2018 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 73A5712D95B for ; Mon, 19 Mar 2018 15:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 Ex7_abnPuaVf for ; Mon, 19 Mar 2018 15:38:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 1DED5124BAC for ; Mon, 19 Mar 2018 15:38:21 -0700 (PDT) Received: from [192.168.0.237] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id CFFDD61070 for ; Mon, 19 Mar 2018 23:38:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521499098; bh=mkHKpyygKyyINHnVCzRkflI/z1j89PWk4M4hC/l6HrE=; h=To:From:Date; b=lL/hYX85NivOjj+IAVsB5yoThBPnjQVFMXVt4+u+3S85HPyk0ref+A+UWB7Jpw2Uv IedtOMaBrFKFXRPxQiQvePkwCQR/jWY08tmfM4Km2wRKItf9Csa6WAh24cP1kKY4NS WEeV9hhfRCqMq46bHGZjylm16N0r6j4+wI4JNLf4= To: doh@ietf.org References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> <20180319153958.GA24327@laperouse.bortzmeyer.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Mon, 19 Mar 2018 23:38:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] [Ext] A question on the mix of DNS and HTTP semantics 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, 19 Mar 2018 22:38:24 -0000 On 19.3.2018 17:03, Patrick McManus wrote: > I agree with Stephane. DNS information in non-successful HTTP responses > (i.e. not a 2xx) is not the answer to the question you asked in the HTTP > request. I can't tell you what it is - its normally just defined as > human readable explanation. It may certainly be generated by HTTP > servers that do not understand DoH. I agree, if there is a valid DNS message in the reply it should be HTTP 200 and anything else should be a HTTP-specific, e.g. Gateway Timeout when DNS server/proxy timed out. Attempting to mix HTTP and DNS semantics opens can of worms. If there is a taste/need for something new and fancy, let's design new protocol for stub-recursive communication with a proper REST interface from scratch. I believe that attempts to HTTP-ify current DNS (beyond plain encapsulation) are going to end up with epic fail... let's see. Petr Å paÄek @ CZ.NIC > > > > > On Mon, Mar 19, 2018 at 3:39 PM, Stephane Bortzmeyer > wrote: > > On Mon, Mar 19, 2018 at 11:21:27AM -0400, >  Andrew Sullivan > wrote >  a message of 29 lines which said: > > > If it were actually truncated, wouldn't the message have a TC bit > > set? > > Truncated for HTTP reasons (error 500 : the server crashed), not for > DNS reasons. > > If the DNS answer is truncated for DNS reasons (EDNS buffer size too > small), I would expect the HTTP status code to be 200. From nobody Mon Mar 19 15:41:20 2018 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 9576B124BAC for ; Mon, 19 Mar 2018 15:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_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 4gGhie-DZvs9 for ; Mon, 19 Mar 2018 15:41:18 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B764C1205F0 for ; Mon, 19 Mar 2018 15:41:17 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id z143-v6so21621254lff.3 for ; Mon, 19 Mar 2018 15:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zpcSpwq5SVbtaoZvUh+wlKYr1U5f8TRuoU3MKyWQM4Y=; b=JhEE78e8BauL4NJdvpQ7bjQZmyKuLeCtWuG+DbT4KgPHk0qNLJkHTwN2Vc+HEsiKto lucXN64tkUB788I7sbHPUlPn/LSNzwiAmCMFeJHxwCTjWXEWrNn/Er9WcuSoQ0DFce5a HBRa1ZTdYbA//b7jt7Vf9sQmO34vx3AEa5W1Zgpo3y4ZBAPFPmB3tV4ICiIwpihVS7gL 5e383lygXbK/9svjkqyeEbuGiu9LKFVHMtnKHaRat3k0QO9shQ9cjs02ihPDO13RdjKL 2MjfrCtUD/CMdqZrKacLN2QyNO9mez9PoisM6kSyisrQjKEGe92NtAj/xV1V2sQenglt IvFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zpcSpwq5SVbtaoZvUh+wlKYr1U5f8TRuoU3MKyWQM4Y=; b=eB7Wk20PsMswGvg38Aiq5EC2H2rOd7AGLUa8Z6rzWJlEXupwr64mUAjIkF02piaiN6 892OLgx8FVw55yE4DlG+h4+XQUCVmbA6VSFW9Ij5xTneQ84ZqNiRvBc6Gsr9SQt7l9NL H51K37f7FPTfxm9pGq2g4RDfWOMntNjexDRTGQlwZR2mncDzSpSegmYGjsvm+W7VP8YZ +I9cd5yYYn1kA+xO0HgPipe6rJExHjoMYQRBhnIeai+YVC79QpRM4KzzcQDFy6e0j+Z1 IbLh321+sg7gRiFJHl0tAN0pFj/3NCvZ6G5pn8UrBaAlEJSXtgswwEuQewiUwgvu+zW+ VwvQ== X-Gm-Message-State: AElRT7GkBQFv7NtNBQ2+iXVqrTKscahlGmT3zsoCPx4gk1bhGMBRX9Fi 7mevZwtJapoulKZgL7HTTNO5Q1BHpaozca7aTW7nSA== X-Google-Smtp-Source: AG47ELvpHMs+dXQoCwBmJy5wZn4GJLmXLo0lxX0xdiqnjU19a9FksqnifTb80yKcOx9CWUMs1+QAuhySZNuFIIrZcOk= X-Received: by 10.46.137.203 with SMTP id c11mr9448455ljk.61.1521499275920; Mon, 19 Mar 2018 15:41:15 -0700 (PDT) MIME-Version: 1.0 References: <20180319143929.tgndmrvdggewpcqv@mx4.yitter.info> In-Reply-To: <20180319143929.tgndmrvdggewpcqv@mx4.yitter.info> From: manu tman Date: Mon, 19 Mar 2018 22:41:04 +0000 Message-ID: To: Andrew Sullivan Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80f09e0de0dd20567cba772" Archived-At: Subject: Re: [Doh] DNSSEC, DOH, and DNS headers 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, 19 Mar 2018 22:41:20 -0000 --f4f5e80f09e0de0dd20567cba772 Content-Type: text/plain; charset="UTF-8" I think Paul remove the notion of different content type in a recent PR so we may as well remove this bit from section 6. Manu On Mon, Mar 19, 2018 at 2:40 PM Andrew Sullivan wrote: > Hi, > > Section 6 of -03 says this: > > Different response media types will provide more or less information > from a DNS response. For example, one response type might include > the information from the DNS header bytes while another might omit > it. > > But section 9 says > > A DNS API client may also perform full > DNSSEC validation of answers received from a DNS API server or it may > choose to trust answers from a particular DNS API server, much as a > DNS client might choose to trust answers from its recursive DNS > resolver. > > It seems to me that these are in tension with one another, because the > AD and CD bits are in the header that the response type is permitted > to throw away. Maybe it could be resolved thus: > > NEW > > A DNS API client may also perform full > DNSSEC validation of answers received from a DNS API server or it may > choose to trust answers from a particular DNS API server, much as a > DNS client might choose to trust answers from its recursive DNS > resolver. This capability might be affected by the response media > type a DNS API server supports. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f4f5e80f09e0de0dd20567cba772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Paul remove the notion of different content = type in a recent PR so we may as well remove this bit from section 6.
=
Manu

On Mon, Mar= 19, 2018 at 2:40 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,

Section 6 of -03 says this:

=C2=A0 =C2=A0Different response media types will provide more or less infor= mation
=C2=A0 =C2=A0from a DNS response.=C2=A0 For example, one response type migh= t include
=C2=A0 =C2=A0the information from the DNS header bytes while another might = omit
=C2=A0 =C2=A0it.

But section 9 says

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A DNS API client may also perform full =C2=A0 =C2=A0DNSSEC validation of answers received from a DNS API server or= it may
=C2=A0 =C2=A0choose to trust answers from a particular DNS API server, much= as a
=C2=A0 =C2=A0DNS client might choose to trust answers from its recursive DN= S
=C2=A0 =C2=A0resolver.

It seems to me that these are in tension with one another, because the
AD and CD bits are in the header that the response type is permitted
to throw away.=C2=A0 Maybe it could be resolved thus:

NEW

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A DNS API client may also perform full =C2=A0 =C2=A0DNSSEC validation of answers received from a DNS API server or= it may
=C2=A0 =C2=A0choose to trust answers from a particular DNS API server, much= as a
=C2=A0 =C2=A0DNS client might choose to trust answers from its recursive DN= S
=C2=A0 =C2=A0resolver.=C2=A0 This capability might be affected by the respo= nse media
=C2=A0 =C2=A0type a DNS API server supports.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--f4f5e80f09e0de0dd20567cba772-- From nobody Mon Mar 19 16:21:57 2018 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 87F8C12D95E for ; Mon, 19 Mar 2018 16:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 WOlY_lB8ynAQ for ; Mon, 19 Mar 2018 16:21:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 7CFAC12D7EF for ; Mon, 19 Mar 2018 16:21:53 -0700 (PDT) Received: from [192.168.0.237] (cpc130666-camd16-2-0-cust366.know.cable.virginm.net [82.36.141.111]) by mail.nic.cz (Postfix) with ESMTPSA id 4931D62373 for ; Tue, 20 Mar 2018 00:21:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521501711; bh=uWqjiWyjRJ4e/BxRzevjBKPJI6kff7DxjYTvcICLn94=; h=To:From:Date; b=W2wI7C06TWcJwdxgoGiQe4mNVipdx8vX9e9BXFv4dLz/XkvR0BDpuSqEcXDUh+O2F C5ll6Vo8TQplAXsVf2zNz54DhV0tO9f+yR4HPIqEvr5PVag4Kngay9WnAHTUb034SS 4HWSJcGhvEKkwDfUsE4S7IlO3UfVQvGesVFBQpa4= To: DoH WG From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Tue, 20 Mar 2018 00:21:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [Doh] conflict between HTTP and DNS cache granularity 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, 19 Mar 2018 23:21:55 -0000 Hello doh, section 7.1. Cache Interaction at the moment does not mention difference between DNS and HTTP caching granularity. Observations: - DNS answer might contain more than 1 RR type (CNAME + original QTYPE) - DNS TTL is per-RRset but HTTP caching header is per request, which in terms of DoH means per DNS message (which potentially combines multiple RRsets) Thus the HTTP "TTL" has to be derived somehow, most likely using minimal value from all RRsets present in the DNS message. Without this limit a bad things will happen when DNS message "partially" expires, which is not handled by DoH protocol itself and will be detected late in the process on the DoH client side. E.g. a browser receives cached DoH answer from a caching proxy. It contains the same DNS message as before with following RRs and headers: ; Age = 20 www.example.com. 100 CNAME srv.example.net. srv.example.net. 10 A 192.0.2.1 Now, the srv.example.net. A RR has TTL -10 seconds so its invalid and client has to deal with it somehow. It is up to WG to decide whether client should re-query for expired RRs by itself or if DoH server should handle this by shortening TTLs so the client cannot encounter this partial expiration ... Well, mixing DNS and HTTP semantics is fun. -- Petr Å paÄek @ CZ.NIC From nobody Mon Mar 19 16:23:55 2018 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 B33E312D95F for ; Mon, 19 Mar 2018 16:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 onoyHBEDSRy2 for ; Mon, 19 Mar 2018 16:23:51 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD1F12D7F4 for ; Mon, 19 Mar 2018 16:23:51 -0700 (PDT) Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id A07573A04F for ; Mon, 19 Mar 2018 19:23:50 -0400 (EDT) Received: by mail-ot0-f182.google.com with SMTP id i28-v6so14522865otf.8 for ; Mon, 19 Mar 2018 16:23:50 -0700 (PDT) X-Gm-Message-State: AElRT7GqKbE0sGBI+kQrQTqxsv4JdRGe3YzxZiLq72cV298vHjymL380 ZNQaRpTSC7ZXA92EcFlR4ZIXKHF+L0r/J6M+C3o= X-Google-Smtp-Source: AG47ELvm7paozMMtvSsFyfNG2vrx0Kd8D73nmLhMsXWIuBNzDPyh1Zqz/6A1GB06HJ9uuLpHbKySvi02MCBh0wSVJas= X-Received: by 2002:a9d:285d:: with SMTP id h29-v6mr7645075otd.205.1521501830358; Mon, 19 Mar 2018 16:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Mon, 19 Mar 2018 16:23:49 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Mon, 19 Mar 2018 23:23:49 +0000 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000001faf3a0567cc4006" Archived-At: Subject: Re: [Doh] conflict between HTTP and DNS cache granularity 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, 19 Mar 2018 23:23:54 -0000 --0000000000001faf3a0567cc4006 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable section 6 tries to deal with this.. On Mon, Mar 19, 2018 at 11:21 PM, Petr =C5=A0pa=C4=8Dek wrote: > Hello doh, > > section 7.1. Cache Interaction at the moment does not mention > difference between DNS and HTTP caching granularity. > > Observations: > - DNS answer might contain more than 1 RR type (CNAME + original QTYPE) > - DNS TTL is per-RRset but HTTP caching header is per request, which in > terms of DoH means per DNS message (which potentially combines multiple > RRsets) > > Thus the HTTP "TTL" has to be derived somehow, most likely using minimal > value from all RRsets present in the DNS message. > > Without this limit a bad things will happen when DNS message "partially" > expires, which is not handled by DoH protocol itself and will be > detected late in the process on the DoH client side. > > E.g. a browser receives cached DoH answer from a caching proxy. It > contains the same DNS message as before with following RRs and headers: > ; Age =3D 20 > www.example.com. 100 CNAME srv.example.net. > srv.example.net. 10 A 192.0.2.1 > > Now, the srv.example.net. A RR has TTL -10 seconds so its invalid and > client has to deal with it somehow. It is up to WG to decide whether > client should re-query for expired RRs by itself or if DoH server should > handle this by shortening TTLs so the client cannot encounter this > partial expiration ... > > Well, mixing DNS and HTTP semantics is fun. > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000001faf3a0567cc4006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
section 6 tries to deal with this..

On Mon, Mar 19, 2018 at 11:21 = PM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:
Hello doh,

section 7.1.=C2=A0 Cache Interaction at the moment does not mention
difference between DNS and HTTP caching granularity.

Observations:
- DNS answer might contain more than 1 RR type (CNAME + original QTYPE)
- DNS TTL is per-RRset but HTTP caching header is per request, which in
terms of DoH means per DNS message (which potentially combines multiple
RRsets)

Thus the HTTP "TTL" has to be derived somehow, most likely using = minimal
value from all RRsets present in the DNS message.

Without this limit a bad things will happen when DNS message "partiall= y"
expires, which is not handled by DoH protocol itself and will be
detected late in the process on the DoH client side.

E.g. a browser receives cached DoH answer from a caching proxy. It
contains the same DNS message as before with following RRs and headers:
; Age =3D 20
www= .example.com. 100 CNAME srv.example.net.
srv= .example.net. 10=C2=A0 =C2=A0 =C2=A0 A 192.0.2.1

Now, the srv.example.net. A RR has TTL -10 seconds so its invalid and
client has to deal with it somehow. It is up to WG to decide whether
client should re-query for expired RRs by itself or if DoH server should handle this by shortening TTLs so the client cannot encounter this
partial expiration ...

Well, mixing DNS and HTTP semantics is fun.

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

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

--0000000000001faf3a0567cc4006-- From nobody Tue Mar 20 00:51:37 2018 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 E9541120724 for ; Tue, 20 Mar 2018 00:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zsn0bRBQwuqP for ; Tue, 20 Mar 2018 00:51:34 -0700 (PDT) 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 E3D641201F2 for ; Tue, 20 Mar 2018 00:51:34 -0700 (PDT) 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, 20 Mar 2018 00:51:33 -0700 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, 20 Mar 2018 00:51:33 -0700 From: Paul Hoffman To: Andrew Sullivan CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] A question on the mix of DNS and HTTP semantics Thread-Index: AQHTv28QHeZwCg5oa0KiigaQhr0PcqPYHysAgAADNYCAAAUsAIAAbVQAgACiIAA= Date: Tue, 20 Mar 2018 07:51:33 +0000 Message-ID: <96D12257-F5CD-4A6A-8B2F-91FD440FE5B2@icann.org> References: <20180318164307.GB6724@laperouse.bortzmeyer.org> <88AB1743-7270-4D72-8C70-0AB6B74416BD@icann.org> <20180319150958.GA23411@laperouse.bortzmeyer.org> <20180319152126.c5ylchfawn4syfwb@mx4.yitter.info> <20180319153958.GA24327@laperouse.bortzmeyer.org> <20180319221116.2tooil7y64lv764q@mx4.yitter.info> In-Reply-To: <20180319221116.2tooil7y64lv764q@mx4.yitter.info> 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.47.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] A question on the mix of DNS and HTTP semantics 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, 20 Mar 2018 07:51:36 -0000 On Mar 19, 2018, at 10:11 PM, Andrew Sullivan wrot= e: >> If the DNS answer is truncated for DNS reasons (EDNS buffer size too >> small), I would expect the HTTP status code to be 200. >=20 > Also ok with me. But since it's a wire message, you still need a TC > bit set, right? =20 Yes. The transport (in HTTPS, in TLS, in SomeFutureTransport) should not af= fect this. --Paul Hoffman= From nobody Tue Mar 20 01:05:51 2018 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 39E9612D869 for ; Tue, 20 Mar 2018 01:05:39 -0700 (PDT) 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 J2vLLVDZ9XxC for ; Tue, 20 Mar 2018 01:05:37 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F99512D82F for ; Tue, 20 Mar 2018 01:05:37 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 9CCF93A04F for ; Tue, 20 Mar 2018 04:05:35 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id t2-v6so758887otj.4 for ; Tue, 20 Mar 2018 01:05:35 -0700 (PDT) X-Gm-Message-State: AElRT7GDWj+a31+DG1Lh+ZuXLd02s+COL/atu1rOdA9vZi0nuY5Qdf/s r56MGEeXSCh6UjrQxtmT5cFusVY0MoSq16hJPrM= X-Google-Smtp-Source: AG47ELvraX/xf4Si9qLvXs0MISfWYkS4R5BdHCwBwCH1+0F+tscoCG4XeiQWvbyFuim7AQPeb4p+wVT+kXJAwpGcXM8= X-Received: by 2002:a9d:213c:: with SMTP id i57-v6mr7983260otb.85.1521533135342; Tue, 20 Mar 2018 01:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.137.147 with HTTP; Tue, 20 Mar 2018 01:05:34 -0700 (PDT) In-Reply-To: <20180319143929.tgndmrvdggewpcqv@mx4.yitter.info> References: <20180319143929.tgndmrvdggewpcqv@mx4.yitter.info> From: Patrick McManus Date: Tue, 20 Mar 2018 08:05:34 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000000bd42c0567d38ad8" Archived-At: Subject: Re: [Doh] DNSSEC, DOH, and DNS headers 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, 20 Mar 2018 08:05:39 -0000 --0000000000000bd42c0567d38ad8 Content-Type: text/plain; charset="UTF-8" I appreciate this. we can make the change. On Mon, Mar 19, 2018 at 2:39 PM, Andrew Sullivan wrote: > Hi, > > Section 6 of -03 says this: > > Different response media types will provide more or less information > from a DNS response. For example, one response type might include > the information from the DNS header bytes while another might omit > it. > > But section 9 says > > A DNS API client may also perform full > DNSSEC validation of answers received from a DNS API server or it may > choose to trust answers from a particular DNS API server, much as a > DNS client might choose to trust answers from its recursive DNS > resolver. > > It seems to me that these are in tension with one another, because the > AD and CD bits are in the header that the response type is permitted > to throw away. Maybe it could be resolved thus: > > NEW > > A DNS API client may also perform full > DNSSEC validation of answers received from a DNS API server or it may > choose to trust answers from a particular DNS API server, much as a > DNS client might choose to trust answers from its recursive DNS > resolver. This capability might be affected by the response media > type a DNS API server supports. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000000bd42c0567d38ad8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I appreciate this. we can make the change.

On Mon, Mar 19, 2018 at= 2:39 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrot= e:
Hi,

Section 6 of -03 says this:

=C2=A0 =C2=A0Different response media types will provide more or less infor= mation
=C2=A0 =C2=A0from a DNS response.=C2=A0 For example, one response type migh= t include
=C2=A0 =C2=A0the information from the DNS header bytes while another might = omit
=C2=A0 =C2=A0it.

But section 9 says

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A DNS API client may also perform full =C2=A0 =C2=A0DNSSEC validation of answers received from a DNS API server or= it may
=C2=A0 =C2=A0choose to trust answers from a particular DNS API server, much= as a
=C2=A0 =C2=A0DNS client might choose to trust answers from its recursive DN= S
=C2=A0 =C2=A0resolver.

It seems to me that these are in tension with one another, because the
AD and CD bits are in the header that the response type is permitted
to throw away.=C2=A0 Maybe it could be resolved thus:

NEW

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A DNS API client may also perform full =C2=A0 =C2=A0DNSSEC validation of answers received from a DNS API server or= it may
=C2=A0 =C2=A0choose to trust answers from a particular DNS API server, much= as a
=C2=A0 =C2=A0DNS client might choose to trust answers from its recursive DN= S
=C2=A0 =C2=A0resolver.=C2=A0 This capability might be affected by the respo= nse media
=C2=A0 =C2=A0type a DNS API server supports.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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

--0000000000000bd42c0567d38ad8-- From nobody Tue Mar 20 02:38:06 2018 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 33314120721 for ; Tue, 20 Mar 2018 02:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2DNpBDnMk5ut for ; Tue, 20 Mar 2018 02:38:04 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473231200F1 for ; Tue, 20 Mar 2018 02:38:04 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 0114A38C1D; Tue, 20 Mar 2018 05:38:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Message-ID: <23216.54906.978869.638719@gro.dd.org> Date: Tue, 20 Mar 2018 05:38:02 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> Archived-At: Subject: Re: [Doh] meta qtypes 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, 20 Mar 2018 09:38:05 -0000 Petr =A9pa=E8ek writes: > Oh, but in that case the theoretical "proxy" would have re-assemble > answers from TCP connection to a DNS server into jumbo-message. Bleh,= > please do not do this. DNS is complex as hell now and additional laye= r > of complexity in translation is going to be major pain. If your HTTP server didn't want to do an AXFR because of the extra coding involved, it's got HTTP error codes to signal that. Should the doc recommend a specific one for whatever DNS features the HTTPS server chooses not to support=3F My main point is that on a practical level nothing precludes being able to do a DNS response greater than 64k over HTTPS, and if an implementer wants to support AXFR for whatever reason I don't see why they need to be blocked from that. From nobody Tue Mar 20 03:11:27 2018 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 DAE131243F6 for ; Tue, 20 Mar 2018 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 sVkraqoGedJB for ; Tue, 20 Mar 2018 03:11:24 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 405DD124319 for ; Tue, 20 Mar 2018 03:11:24 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 056E03A064 for ; Tue, 20 Mar 2018 06:11:23 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id q71-v6so832355oic.6 for ; Tue, 20 Mar 2018 03:11:23 -0700 (PDT) X-Gm-Message-State: AElRT7EUUnHnkcDh9MFz24AJSqgMNNwLz7FyO77uTyXyCC2vjnsPPl1u 5a2y1YEz9SwwFrqRI8Td/mqlc7GXqZu0SZF0MuQ= X-Google-Smtp-Source: AG47ELtXiMgAKWqYuMDijVKfxvjNzV2YgjfLz7Tkhbi6UJxdFeOgCdgN/UAlF+UsGyPolNs3MWUgTWRJEAvaLdpv7N4= X-Received: by 10.202.94.132 with SMTP id s126mr8410188oib.155.1521540682675; Tue, 20 Mar 2018 03:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.137.147 with HTTP; Tue, 20 Mar 2018 03:11:21 -0700 (PDT) In-Reply-To: <23216.54906.978869.638719@gro.dd.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> From: Patrick McManus Date: Tue, 20 Mar 2018 10:11:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: DoH WG Content-Type: multipart/alternative; boundary="001a113d5160e6fd880567d54b78" Archived-At: Subject: Re: [Doh] meta qtypes 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, 20 Mar 2018 10:11:26 -0000 --001a113d5160e6fd880567d54b78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2018 at 9:38 AM, Dave Lawrence wrote: > Petr =C5=A0pa=C4=8Dek writes: > > Oh, but in that case the theoretical "proxy" would have re-assemble > > answers from TCP connection to a DNS server into jumbo-message. Bleh, > > please do not do this. DNS is complex as hell now and additional layer > > of complexity in translation is going to be major pain. > > If your HTTP server didn't want to do an AXFR because of the extra > coding involved, it's got HTTP error codes to signal that. Should the > doc recommend a specific one for whatever DNS features the HTTPS > server chooses not to support? > > I know this is sounding like an old refrain - but we want clients to handle all applicable codes and also need to be aware that HTTP servers other than DoH servers might be generating error responses. So in general creating laundry lists of response codes is an anti-pattern of over specification. BCP56bis talks about this. In the case of a server that doesn't want to answer a request, 7231 provides all of 5xx to mean that. i.e. the server is aware it has erred or is incapable of handling the request. Restating just that is less objectionable but we run the risk of introduce subtle mistakes when all we want is redundancy. We're much better off just including HTTP by reference as we're doing. (personally I would use 501 or maybe 502 if I squinted at it hard.) > My main point is that on a practical level nothing precludes being > able to do a DNS response greater than 64k over HTTPS, and if an > implementer wants to support AXFR for whatever reason I don't see why > they need to be blocked from that. > > personally agree > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113d5160e6fd880567d54b78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 20, 2018 at 9:38 AM, Dave Lawrence <tale@dd.org> w= rote:
Petr =C5=A0pa=C4= =8Dek writes:
> Oh, but in that case the theoretical "proxy" would have re-a= ssemble
> answers from TCP connection to a DNS server into jumbo-message. Bleh,<= br> > please do not do this. DNS is complex as hell now and additional layer=
> of complexity in translation is going to be major pain.

If your HTTP server didn't want to do an AXFR because of the ext= ra
coding involved, it's got HTTP error codes to signal that.=C2=A0 Should= the
doc recommend a specific one for whatever DNS features the HTTPS
server chooses not to support?


I know this is sounding like an old re= frain - but we want clients to handle all applicable codes and also need to= be aware that HTTP servers other than DoH servers might be generating erro= r responses. So in general creating laundry lists of response codes is an a= nti-pattern of over specification. BCP56bis talks about this.

In the case of a server that doesn't want to answer a r= equest, 7231 provides all of 5xx to mean that. i.e. the server is aware it = has erred or is incapable of handling the request. Restating just that is l= ess objectionable but we run the risk of introduce subtle mistakes when all= we want is redundancy. We're much better off just including HTTP by re= ference as we're doing.

(personally I woul= d use 501 or maybe 502 if I squinted at it hard.)

<= div>=C2=A0
My main point is that on a practical level nothing precludes being
able to do a DNS response greater than 64k over HTTPS, and if an
implementer wants to support AXFR for whatever reason I don't see why they need to be blocked from that.

p= ersonally agree

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

--001a113d5160e6fd880567d54b78-- From nobody Tue Mar 20 03:11:32 2018 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 E9647124319 for ; Tue, 20 Mar 2018 03:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 0VhbWFWxWCrD for ; Tue, 20 Mar 2018 03:11:23 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 943EF1200F1 for ; Tue, 20 Mar 2018 03:11:23 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 02D9F3A04F for ; Tue, 20 Mar 2018 06:11:23 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id a16-v6so792981oia.13 for ; Tue, 20 Mar 2018 03:11:22 -0700 (PDT) X-Gm-Message-State: AElRT7EPfAqDk2l6oIUJVj3EucFMCyJv502+75VmQHnoIYaR4cGcea1Z HyyYON1M4nL+iJZ5cqo+tGkntL/sjrtH1Uq67mQ= X-Google-Smtp-Source: AG47ELv7BQ3F8pIs2jDjyHr1Csp09ZloB3qCsY5bxUGICLHk46KDbHx++Vxk39/5Yjypmetas/uTqwaYOKZp7NIzTy0= X-Received: by 10.202.6.195 with SMTP id 186mr8450338oig.347.1521540682689; Tue, 20 Mar 2018 03:11:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.137.147 with HTTP; Tue, 20 Mar 2018 03:11:21 -0700 (PDT) In-Reply-To: <23216.54906.978869.638719@gro.dd.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> From: Patrick McManus Date: Tue, 20 Mar 2018 10:11:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: DoH WG Content-Type: multipart/alternative; boundary="94eb2c13f9a0e732820567d54b5c" Archived-At: Subject: Re: [Doh] meta qtypes 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, 20 Mar 2018 10:11:26 -0000 --94eb2c13f9a0e732820567d54b5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2018 at 9:38 AM, Dave Lawrence wrote: > Petr =C5=A0pa=C4=8Dek writes: > > Oh, but in that case the theoretical "proxy" would have re-assemble > > answers from TCP connection to a DNS server into jumbo-message. Bleh, > > please do not do this. DNS is complex as hell now and additional layer > > of complexity in translation is going to be major pain. > > If your HTTP server didn't want to do an AXFR because of the extra > coding involved, it's got HTTP error codes to signal that. Should the > doc recommend a specific one for whatever DNS features the HTTPS > server chooses not to support? > > I know this is sounding like an old refrain - but we want clients to handle all applicable codes and also need to be aware that HTTP servers other than DoH servers might be generating error responses. So in general creating laundry lists of response codes is an anti-pattern of over specification. BCP56bis talks about this. In the case of a server that doesn't want to answer a request, 7231 provides all of 5xx to mean that. i.e. the server is aware it has erred or is incapable of handling the request. Restating just that is less objectionable but we run the risk of introduce subtle mistakes when all we want is redundancy. We're much better off just including HTTP by reference as we're doing. (personally I would use 501 or maybe 502 if I squinted at it hard.) > My main point is that on a practical level nothing precludes being > able to do a DNS response greater than 64k over HTTPS, and if an > implementer wants to support AXFR for whatever reason I don't see why > they need to be blocked from that. > > personally agree > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --94eb2c13f9a0e732820567d54b5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 20, 2018 at 9:38 AM, Dave Lawrence <tale@dd.org> w= rote:
Petr =C5=A0pa=C4= =8Dek writes:
> Oh, but in that case the theoretical "proxy" would have re-a= ssemble
> answers from TCP connection to a DNS server into jumbo-message. Bleh,<= br> > please do not do this. DNS is complex as hell now and additional layer=
> of complexity in translation is going to be major pain.

If your HTTP server didn't want to do an AXFR because of the ext= ra
coding involved, it's got HTTP error codes to signal that.=C2=A0 Should= the
doc recommend a specific one for whatever DNS features the HTTPS
server chooses not to support?


I know this is sounding like an old re= frain - but we want clients to handle all applicable codes and also need to= be aware that HTTP servers other than DoH servers might be generating erro= r responses. So in general creating laundry lists of response codes is an a= nti-pattern of over specification. BCP56bis talks about this.

In the case of a server that doesn't want to answer a r= equest, 7231 provides all of 5xx to mean that. i.e. the server is aware it = has erred or is incapable of handling the request. Restating just that is l= ess objectionable but we run the risk of introduce subtle mistakes when all= we want is redundancy. We're much better off just including HTTP by re= ference as we're doing.

(personally I woul= d use 501 or maybe 502 if I squinted at it hard.)

<= div>=C2=A0
My main point is that on a practical level nothing precludes being
able to do a DNS response greater than 64k over HTTPS, and if an
implementer wants to support AXFR for whatever reason I don't see why they need to be blocked from that.

p= ersonally agree

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

--94eb2c13f9a0e732820567d54b5c-- From nobody Tue Mar 20 03:22:56 2018 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 DDF9A1242F7 for ; Tue, 20 Mar 2018 03:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 f3JKBSR5o2fI for ; Tue, 20 Mar 2018 03:22:55 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC0C124207 for ; Tue, 20 Mar 2018 03:22:54 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E5C0038C73; Tue, 20 Mar 2018 06:22:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23216.57597.921103.960943@gro.dd.org> Date: Tue, 20 Mar 2018 06:22:53 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> Archived-At: Subject: Re: [Doh] meta qtypes 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, 20 Mar 2018 10:22:56 -0000 Patrick McManus writes: > (personally I would use 501 or maybe 502 if I squinted at it hard.) 501 is where I was going to go with it, but I appreciate your point about not specifying here. From nobody Tue Mar 20 11:27:11 2018 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 593B3128896 for ; Tue, 20 Mar 2018 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.com header.b=fkcjTgFZ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Uijqry00 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 1wuKg4vndtdI for ; Tue, 20 Mar 2018 11:27:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 87707127867 for ; Tue, 20 Mar 2018 11:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521570425; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0QTpqpj6Ru7vyesKXJaQztzq95xHy5aN1fMNVdtTxgU=; b=fkcjTgFZ77mGUIG95nzpAs5n/II7S5qzN17fTFirP3sw8mT9UthKJ+zmTtNYApdO xmnDgJTuA6c91uOY4wPaHwsQv2GZnv+ACT3edgktpJLLk/ByyIJx1FWdGMsyKb0R ZYBV9kIt+5/fPmORlL4XaRTJcfUNlmANHouhubfFj70=; X-AuditID: c1b4fb30-ad4c19c00000095a-d6-5ab1527995d4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.30.02394.97251BA5; Tue, 20 Mar 2018 19:27:05 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSHC023.ericsson.se (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 20 Mar 2018 19:27:02 +0100 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Tue, 20 Mar 2018 19:27:02 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Tue, 20 Mar 2018 19:27:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0QTpqpj6Ru7vyesKXJaQztzq95xHy5aN1fMNVdtTxgU=; b=Uijqry00OlU7YAK1Mlz4sSuBzVhauROQXE3ppwIeq2sLG04LdUS3NFGuSPW2EtkmM6zcGQs8QaJsPFHzbhmc1IR64wQxfjrk60k0u+luEEOEHjH8JFw/rGY+mdXnkkcj+B2Ct8zWYNBSqc5fmG6TLviOT2rgUHm5ho1wxWe3Obs= Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com (10.167.189.149) by HE1SPR00MB244.eurprd07.prod.outlook.com (10.171.98.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Tue, 20 Mar 2018 18:27:02 +0000 Received: from HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::7d80:1860:283c:5ef2]) by HE1PR0701MB2011.eurprd07.prod.outlook.com ([fe80::7d80:1860:283c:5ef2%3]) with mapi id 15.20.0609.009; Tue, 20 Mar 2018 18:27:00 +0000 From: John Mattsson To: "doh@ietf.org" Thread-Topic: [Doh] Changes for draft-ietf-doh-dns-over-https-03 Thread-Index: AQHTwHkG1qQ6gzKSr02wCWw32XXQ8g== Date: Tue, 20 Mar 2018 18:26:58 +0000 Message-ID: <0108299C-2CA0-4E56-B59F-C268A319FACA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [80.5.95.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1SPR00MB244; 7:LE0X9k59N2nO81v/cOJvE54wrBCo8OMAY2B6LHavOtRiGg9uEI07fz4jskXiVe+aMNIfTQMS8CSklpCcaq7w210mAgkZW0nW+vDb4g35dGq5L0ET51M6Vjh+1qkwxcqxCZlZDxIgsvVRKk87tR5xn7Vd4PqX9puBjrwPd5wuqwskRUU+bvfCdCqcDaG7K2xMthaJTJX7Mtl88FhE0aB2snKHO49AAhB/xoBpzUmkx/5Y0HpRy9ywmDdCbOSDosoN x-ms-office365-filtering-correlation-id: b6ab70c8-7b2d-4bcd-bc25-08d58e902ba9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1SPR00MB244; x-ms-traffictypediagnostic: HE1SPR00MB244: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231221)(944501313)(52105095)(3002001)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:HE1SPR00MB244; BCL:0; PCL:0; RULEID:; SRVR:HE1SPR00MB244; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(346002)(376002)(366004)(199004)(189003)(66066001)(102836004)(8676002)(305945005)(3846002)(6116002)(7736002)(6916009)(5640700003)(33656002)(83716003)(53936002)(68736007)(6246003)(36756003)(86362001)(25786009)(6512007)(316002)(229853002)(3660700001)(58126008)(3280700002)(5660300001)(105586002)(14454004)(2906002)(478600001)(99286004)(6486002)(6506007)(8936002)(97736004)(2351001)(186003)(106356001)(81166006)(6436002)(81156014)(1730700003)(2900100001)(5250100002)(82746002)(2501003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR00MB244; H:HE1PR0701MB2011.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: m2b2IJ37qQxUjsbsTkmllk+LY2zy1JRVfO7JUSaMzdTyMAu/Hfq408Bmkp3ES4GzJErhAfdbmCknU3UJvHalap5M1F1EkFHAonojl4QO0bO1AU/A0Nmmvxzhp9Jnqu5sWafQv7kr7TzlGJFee1PUhlJfvXbsF0iywlVtjK3fOQlFH62eRgBgI3xW+PadnmrQkvYtUtDCMeTdmQZoFXWzSm6TL9HWv3LiWXoT3bIogJHguRZbfNgelwy8AA5qmFc6nGWG7GSbXkDS2h957XHdY9xUyXbUF9IEQFQSuoZhfPxC64pnYWa5n1WASFLkjm678LE5BXKENg60GrarA0RLyw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b6ab70c8-7b2d-4bcd-bc25-08d58e902ba9 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 18:26:58.8333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR00MB244 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZGbE9XLcyaGOUweo1ShbX7l5kc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpXDv1gK+gQqPjw9wN7AeIO/i5GTQ0LAROLMjvMsXYxcHEIC hxklzm5cwA7hbGGUeDf3CBOE851R4vOB5YwQzlImib6fX8B6WAQ+MUnsvbSUGSIzhUli6ccu qGnPGCWOdK5hBVnDJmAgMXdPA1sXIweHiICixP0LziBhYQF7iQuv1jGC2CICDhKvZ85hg7D1 JN7cnQoWZxFQlbi67jrYGF6g+utNu5lAbEYBMYnvp9aA2cwC4hK3nsxngvhIQGLJnvPMELao xMvH/8B6RYFmNn+6zg7RGyvR2jqdFaJGTuLs00lsELasxKX53WBvSghsYZK4M/M+VJGvxO7V nVCJE0CP3d4EtI0dyNGS6CuDKMmWWL3hINQcH4lLTw+zQ5QvZZbY0vMc6jgZiek901kgEsdZ Jda1b2WewKg/C8kTs4BhxCygKbF+F1TYQ2L59r+MELaixJTuh+yzwGEhKHFy5hOWBYysqxhF i1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC08fBLb8NdjC+fO54iFGAg1GJh9fDemOUEGtiWXFl 7iFGCQ5mJRHeTAWgEG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkm Dk6pBsYo7ZOnBPll/sx6V/XmyI1j4tPO/Uibekpz3f/ud4kNk30XKsvMkWxRW+YS4l3dsvFs dub5DVdj7ouvOnRqxl/tHtWjzc8zG8XeWc8Ti2HdI6oXf+mJ7PNf604puDdZxRilu+8533xh +8Wiu9nBdqWPV3ZO9V5pEJG8er+Ucu27fZdusPqyzuZXYinOSDTUYi4qTgQAnOJsphsDAAA= Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 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, 20 Mar 2018 18:27:09 -0000 SGksDQoNCkxvb2tzIGdvb2QuIFNvbWUgY29tbWVudHM6DQoNCi0gU2VjdGlvbiAxLg0KIk9uLXBh dGggbmV0d29yayBkZXZpY2VzIG1heSBzcG9vZiBETlMgcmVzcG9uc2VzLCBibG9jayBETlMgcmVx dWVzdHMsIG9yIGp1c3QgcmVkaXJlY3QgRE5TIHF1ZXJpZXMgdG8gZGlmZmVyZW50IEROUyBzZXJ2 ZXJzIHRoYXQgZ2l2ZSBsZXNzLXRoYW4taG9uZXN0IGFuc3dlcnMuIg0KDQpDb3VsZCBtZW50aW9u IG1vcmUgdGhpbmdzIHJlZ2FyZGluZyB0aGUgImRpZmZlcmVudCBETlMgc2VydmVycyIuIFN1Z2dl c3Rpb246DQoiT24tcGF0aCBuZXR3b3JrIGRldmljZXMgbWF5IHNwb29mIEROUyByZXNwb25zZXMs IGJsb2NrIEROUyByZXF1ZXN0cywgb3IganVzdCByZWRpcmVjdCBETlMgcXVlcmllcyB0byBkaWZm ZXJlbnQgRE5TIHNlcnZlcnMgdGhhdCBtYXkgZ2l2ZSBsZXNzLXRoYW4taG9uZXN0IGFuc3dlcnMs IGhhdmUgbGFyZ2Ugb3IgdmFyaWFibGUgbGF0ZW5jeSwgb3IgbWF5IHNpbXBseSBub3Qgc3VwcG9y dCB0aGUgd2FudGVkIEROUyBmZWF0dXJlcy4iDQoNCg0KLSBTZWN0aW9uIDIuDQpUaGUgZHJhZnQg c2hvdWxkIHVzZSB0aGUgdXBkYXRlZCBib2lsZXJwbGF0ZSBpbiBSRkM4MTc0DQogICAgICJUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM DQogICAgICBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9U IFJFQ09NTUVOREVEIiwNCiAgICAgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcw0KICAgICAgZGVzY3JpYmVkIGluIEJDUCAxNCBb UkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkNCiAgICAgIGFwcGVh ciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuIg0KDQoNCi0gU2VjdGlvbiAzLiAgICAg IAkNCi0gImNsaWVudHMgLSB3aGV0aGVyIG9wZXJhdGluZyBzeXN0ZW1zIG9yIGluZGl2aWR1YWwg YXBwbGljYXRpb25zIg0KDQpXaGF0IGFib3V0IGhvbWUgcm91dGVycz8NCg0KDQotIFNlY3Rpb24g NS4gDQotICJwb3RlbnRpYWxseSBlbmNvZGVkIHdpdGggYmFzZTY0dXJsIg0KDQpXaHkgcG90ZW50 aWFsbHk/IFNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgbmVlZCB0byBiZSBzdGFuZGFyZGl6ZWQu IFN1Z2dlc3Rpb246ICJlbmNvZGVkIHdpdGggYmFzZTY0dXJsIg0KDQoNCi0gU29tZXdoZXJlDQpJ IHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgbWVudGlvbiBvdGhlciBiZW5lZml0cyBhdCB3ZWxsLiBT dWdnZXN0aW9uOg0KIlRoZSB1c2Ugb2YgRE9IIG1pdGlnYXRlcyBETlMgYW1wbGlmaWNhdGlvbiBh dHRhY2tzIGFuZCBhbGxvd3MgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBETlMgQVBJIHNlcnZl ciBhbmQgYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBvZiB0aGUgRE5TIEFQSSBjbGllbnQu Ig0KDQpDaGVlcnMsDQpKb2huDQoNCg== From m13253@hotmail.com Tue Mar 20 12:42:19 2018 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 17DCE128D2E for ; Tue, 20 Mar 2018 12:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 q_LMpYz6RF3x for ; Tue, 20 Mar 2018 12:42:17 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005033.outbound.protection.outlook.com [40.92.5.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763E01289B0 for ; Tue, 20 Mar 2018 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m4+Qf1Su9iC1FP5JV1fIlXTOMfPh9LE+6T34RIZeBmM=; b=MyQog9ojZJxMaxxFxx+B/6x5fxf+LVCsVTrpkzr+pDnvi5YgDWkC5vn78d0lvzoGW4Om9QHMalL4ubzg6HBX2Cpi/soP7Yw7FZm+LiIVxtTqLrM9nbCc7EF6S+UIwCzGLuZHaRDKI51xj7jXPtVTNloQdz8gbnYcqDGnqSILIFKUYWIApG219urYFnL/dkhDOgNN0sDyba0SV9JcJPyHOW+mnZ4sVsT3CbCBn3Fo8YDHwf/LUO7ZBSRu783VaQMR2kKm9M0eaW0023NeJh60ecqmvRLVtyBm/NPMa2YlTSthIU0IU8IOfWVhnmdQIEMq1yWDKl12a82pVRici9DxkA== Received: from SN1NAM02FT013.eop-nam02.prod.protection.outlook.com (10.152.72.58) by SN1NAM02HT198.eop-nam02.prod.protection.outlook.com (10.152.72.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.18; Tue, 20 Mar 2018 19:42:12 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.72.53) by SN1NAM02FT013.mail.protection.outlook.com (10.152.72.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.18 via Frontend Transport; Tue, 20 Mar 2018 19:42:12 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::49ab:17a3:df4c:17d9]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::49ab:17a3:df4c:17d9%13]) with mapi id 15.20.0588.016; Tue, 20 Mar 2018 19:42:12 +0000 From: Sam Bliss To: "doh@ietf.org" Thread-Topic: Another working code implementation Thread-Index: AQHTwINj05Q1/2IwpEG5gPgzIKw2iw== Date: Tue, 20 Mar 2018 19:42:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:596329E0AE42E367FE49425154062F318678203D4AFA1AE4C741148A9D98E8C1; UpperCasedChecksum:C9B94C7CF49F047AC3B35F0CB7C796908CF61B03090FF4FB6E86163723247E26; SizeAsReceived:6948; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [m4gcURpq6yR/pakKHuRzvRfwMBzMdDARgMAPv2iqy5HrcozLMeSbwVNs7vS/bwIa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT198; 6:D36RSFDs9E2EFIjH5qFh4yjfAon4e9wYESVMh5w0o4mNIFemGJdU9JhoqswiRpIKAd6Cjvm6dNEhJ8qOdVFZ1M6WAFlQWME5bkavyJSn8fiD9jIWLnjpT0CuLwjvqfMft+daDdVCV0Km+FdaU1TnCSHwpUnAj3dYDqQ49UtnSNr8KH91vhHOWoR8/eiovSwrsgYFsDTeN9S5gSQbR9kjeNenKu/Mg+TqdHkGd4N172sNno3d/+FoMvV0cgQP9yciAtnTEeM+YJOT+lKUkm76sEO0Zy9JF7PwejKawt8cMYGSjC322ucyT0m2jy7vwBe+pEg+XDQRTIMK8z752dfVkctLg1VH+lxgNQLNU0VF8Ck=; 5:6x2RfSKOzre1WUmV4FF/ahr9a8T3i7nyjHfLbkWp8RXURxpTJNIoeFfyvCpl03XNvsRR5HmYARmnFXP2KVuiBDgZVn9jkMC+G8vcDGNGf292krQpHdRRGAtbTI92Tz3qQrhJ+unqCPBv2MsO05oNl7liM9bAWfBciFG0tMB44To=; 24:N8NTqOa2eq2OWiVFWanO6vZLJoj2uJbOQEUrLeEidg0JLy3Ix5ET/RvlpGSmN8rFoyY2McBuUYu5naY3ufI91XT9fT0oo6a13q7iciL4pt8=; 7:VkA5wN7wHgljqGNfdAVbyUPMAFOiYso7YkZnH5lerSjWIXjQpazNmSMAlreEN/35r+pupc99hmIHQqDAto7NZgr68+69Glz8nMvwR4SDmqq6rLpAEVB6zWhkysVsiQPnizOnIoMmMs9lBn5Umvt2Kl1QCmGZdYVQVD23SF/fQRw8IbciGcrLgX0kdoirJ0VlLi7E13tzxRpbrup45JyLMqieb9ZBV/mIpmh9P62H6sEHNUDy1vE2i//DMusGcFJf x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SN1NAM02HT198; x-ms-traffictypediagnostic: SN1NAM02HT198: x-ms-office365-filtering-correlation-id: 7811bd4f-0aa1-404d-8eb9-08d58e9aad49 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM02HT198; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT198; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT198; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:; x-microsoft-antispam-message-info: R6HK2YJlpdwnEFHFW7ypgYj+T7k2onI/GIfTz/NIejjjLiD2No3yXIFzYGJSCE3ZS9k01SvO4CK+XDHwI5q+zR/N1qDPs5nLnh4Fzo4dzL6EkzQn//JjMIHGYf5TqnjstKYnEcDNKY+M3qan1j8STfzD6gb4WyKqP2DOEtQidmNm3JUxoCEgKrQMy26GLlQM spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7811bd4f-0aa1-404d-8eb9-08d58e9aad49 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 19:42:12.5398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT198 Archived-At: Subject: [Doh] Another working code implementation 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, 20 Mar 2018 19:43:39 -0000 Hello DoH working group,=0A= =0A= I have implemented a couple of DoH client/server using Go.=0A= =0A= The software supports 2 protocols: the old Google DoH protocol & the=0A= new IETF DoH protocol. The server side can detect the protocol=0A= automatically. Additionally, it supports EDNS0-Client-Subnet extension=0A= which is useful especially when Anycast is unavailable.=0A= =0A= The code is available under MIT license:=0A= https://github.com/m13253/dns-over-https=0A= =0A= There must be bugs in the newly added code. Please let me know if so.=0A= =0A= =0A= Best regards,=0A= StarBrilliant= From nobody Wed Mar 21 12:11:44 2018 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 C0AF312E03D for ; Wed, 21 Mar 2018 12:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0HCpz1c8w90Z for ; Wed, 21 Mar 2018 12:11:39 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8C012DA40 for ; Wed, 21 Mar 2018 12:11:34 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 100D9389B7; Wed, 21 Mar 2018 15:11:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23218.44644.48969.243875@gro.dd.org> Date: Wed, 21 Mar 2018 15:11:32 -0400 From: Dave Lawrence To: doh@ietf.org Archived-At: Subject: [Doh] DoH minutes taker and jabber scribe sought 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, 21 Mar 2018 19:11:43 -0000 So we don't have to do the find-some-volunteers dance tomorrow as the meeting starts, could we please get a volunteer for being the jabber scribe, and hopefully a couple as note takers? Thank you! From nobody Wed Mar 21 12:23:59 2018 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 771C5127201; Wed, 21 Mar 2018 12:23:57 -0700 (PDT) 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.76.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152166023744.7408.16631834664368776255@ietfa.amsl.com> Date: Wed, 21 Mar 2018 12:23:57 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-04.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: Wed, 21 Mar 2018 19:23:57 -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-04.txt Pages : 16 Date : 2018-03-21 Abstract: 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 [1] ]]. 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-04 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 Wed Mar 21 18:36:49 2018 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 C78F512D72F; Wed, 21 Mar 2018 18:36:43 -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, 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 Sf2EYhud-Z8g; Wed, 21 Mar 2018 18:36:41 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 82F6E12D0C3; Wed, 21 Mar 2018 18:36:41 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id c14so4594483uak.7; Wed, 21 Mar 2018 18:36:41 -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; bh=7PLCgKo9lbuefg4eGhKr8/Yqr0teXoCusccTYA9akxk=; b=l/4REVpvv/nFo7p8e7cLGyMwa9WcitKrskrigGWVqmT8tNDWg4IX2ZyC5lNoG4Sa6U /44XHYvfT4ymm9vxW+gC0EtFlA2gG+OUGK2LCuhZ9M1xHTOpFjW3oMOT0QZMVNOAfC1C sBLTyq0JN14mm+eRZGJFyYV4h1Lx8vTdF6nvR0NtMy8Hdk/2YJVz4XTJRmtLWHBUMmgY F66Gha5ChBSWukATm4nlEhzsgUDfjUV/e0pq1rII6BYFBeOGH0JhVAtVm3kaepxdyfKI LMdbq1u52YuxfOS1vBISrKfPJewoUtPcuD71AKEdvqGOT68my6/fhkm+oBzapSpnyRmE L7qg== 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=7PLCgKo9lbuefg4eGhKr8/Yqr0teXoCusccTYA9akxk=; b=lNCt79mAKLenZf0N3sXBifHdDp8YGvm/LvOmkxU5DmR4JqMyX6J2/sZ254kJclbs25 EXpFNHYEKMD6ZNp2w06YcK1nf5eaWh+lpcZgomxYTxPCJRHefQUD6FqPNE0n/NZMEJhk Q8Z+N5XpqDk5CUHWFU+0ED8N2uAjPrYEZNUEQpiIvnXsWPLg9Lhm9S68XGFnWgVhVpaB LBTlESL9cMXofol+S092xMb36vC4ar1qtGnwrZyi04djT+88SN74G3/oKD1dMb2Z23zX x//TdjIaztVjnjAH7IjUv0mQfdvnj9eN3C+LdE03KfS+6F/mbNIcP77QTWK+ek05u73L zi0g== X-Gm-Message-State: AElRT7FL/7TwGrCyLY2Hkkvx8/WjtFZtNMiIEdEG7xLizu8KFOHUKzrq dkLX0xvzyc2NfBML8PlgOk/3ZYlIvmigUyYi62gaQA== X-Google-Smtp-Source: AG47ELtb0KTTUicljxspf+Z+BvBJarpyvzIEnM1q05elG494lAOYGGLLyF6mJvwEPJ+j+wBfaJJ/JSMrV/J7G0R1Syk= X-Received: by 10.176.69.182 with SMTP id u51mr15038308uau.93.1521682600304; Wed, 21 Mar 2018 18:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Wed, 21 Mar 2018 18:36:39 -0700 (PDT) In-Reply-To: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> From: Davey Song Date: Thu, 22 Mar 2018 09:36:39 +0800 Message-ID: To: dnsop , doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c11b824da23b70567f6568b" Archived-At: Subject: [Doh] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 01:36:44 -0000 --94eb2c11b824da23b70567f6568b Content-Type: text/plain; charset="UTF-8" Hi folks, I just submit a updated version of dns wireformat over HTTP. This draft has been adopted as the dnsop wg document for quite a while before DOH. The original intention of this draft is to explore the possiblity of DNS over HTTP(s) use cases and demonstrate its capacity as an experimental draft. But the draft lacked enough specification on HTTP requirement and context at that time. Since DOH later was setup focusing on developing https as DNS transport protocol. So I updated this draft as a a special use case of DOH which served as DNS proxy. I would like to ask comments and advice in dnsop and doh wgs mainly two quesions: 1) (for dns people) Does this proxy use case sounds useful as a IETF experiment document . 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" acceptable specially for this use case. We also consider to introduce an optional parameter to existing "application/dns-udpwireformat" MIME in DOH document, because the two media type carries the identical message body (the udp dns wireformat) in DOH request in proxy use case. We need suggestion here. Thank to Tim and Paul Hoffman to bring this draft alive. Davey ---------- Forwarded message ---------- From: Date: 22 March 2018 at 08:59 Subject: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt To: Shane Kerr , Paul Vixie , Linjian Song A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt has been successfully submitted by Linjian Song and posted to the IETF repository. Name: draft-ietf-dnsop-dns-wireformat-http Revision: 02 Title: An Proxy Use Case of DNS over HTTPS Document date: 2018-03-21 Group: dnsop Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns- wireformat-http-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns- wireformat-http/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-dns- wireformat-http-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns- wireformat-http Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns- wireformat-http-02 Abstract: This memo introduces a DNS proxy use case to tunnel DNS query and response over HTTPs using DOH, a newly proposed DNS transport. This is useful in some situation where DNS is not working properly and DOH is not widely available for many stub-resolvers. 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. The IETF Secretariat --94eb2c11b824da23b70567f6568b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I just submit a updated versi= on of dns wireformat over HTTP. This draft has been adopted as the dnsop wg= document for quite a while before DOH.=C2=A0 The original intention of thi= s draft is to explore the possiblity of DNS over HTTP(s) use cases and demo= nstrate its capacity as an experimental draft. But the draft lacked enough = specification on HTTP requirement and context at that time. Since DOH later= was setup focusing on developing https as DNS transport protocol. So I upd= ated this draft as a a special use case of DOH which served as DNS proxy.= =C2=A0

I would like to ask comments and advice in = dnsop and doh wgs mainly two quesions:=C2=A0
1) (for dns people) = Does this proxy use case sounds useful as a IETF experiment document .
2) (for HTTP people) Is a media type "application/dns-tcpwirefor= mat" acceptable specially for this use case. We also consider to intro= duce an optional parameter to existing=C2=A0=C2=A0"application/dns-udpwireformat" MIME in DOH document, because th= e two media type carries the identical message body=20 (the udp dns wireformat)=C2=A0 in DOH request=C2=A0 in proxy use case. We need suggestion here.

Thank to Tim and Paul Hoffman to bring this draft ali= ve.=C2=A0=C2=A0

Davey
=C2=A0
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 22 Marc= h 2018 at 08:59
Subject: New Version Notification for draft-ietf-dnsop-d= ns-wireformat-http-02.txt
To: Shane Kerr <shane@time-travellers.org>, Paul Vixie <vixie@tisf.net>, Linjian Song <songlinjian@gmail.com>


=
A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dnsop-dns-wir= eformat-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An Proxy Use Case of DNS over HTTP= S
Document date:=C2=A0 2018-03-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-i= etf-dnsop-dns-wireformat-http-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-ht= tp-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns= -wireformat-http
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dn= sop-dns-wireformat-http-02

Abstract:
=C2=A0 =C2=A0This memo introduces a DNS proxy use case to tunnel DNS query = and
=C2=A0 =C2=A0response over HTTPs using DOH, a newly proposed DNS transport.= =C2=A0 This
=C2=A0 =C2=A0is useful in some situation where DNS is not working properly = and DOH
=C2=A0 =C2=A0is not widely available for many stub-resolvers.




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

The IETF Secretariat


--94eb2c11b824da23b70567f6568b-- From nobody Wed Mar 21 19:14:53 2018 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 8454D12D77D; Wed, 21 Mar 2018 19:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 zC1U6fXhHyye; Wed, 21 Mar 2018 19:14:48 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 F38C1126BF6; Wed, 21 Mar 2018 19:14:47 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2M2CZBB016610; Thu, 22 Mar 2018 02:14:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=RAYOxoAM0uYtG5Rv2MY/Hqer0gzzHOsXjwSQGZspW6g=; b=ZTuFpuYL5O19mXrxM59c0tSdwzb36kOxrxuBf/aDy/a5Hr3qXFQz+hOXhsRQoJ7hqS7v o4uTO+KNvD5NDcItM6VKsdMm/PH4raLy3TKXNjaI+qBBkppzxX6VvkdXDOFFwq9GgNwS gtJVhwBkEpsfVdZKvRquo2V3mOZEgv/Q9p5Uy7jhIPgoRVcVbq64HRp6W/Ue+Q3J24Db B5WdrTY4LFxko0UId/H3/d9K/STwK7+wErssB1gLneOMBoRQySKLXntr38ONChJYusHk xDXk4+xzgE5e0AfdYskyt+3D37+V7GwAjEMudcZkYd0qftG/fvAib+1mk4omihMVi6Xr Hw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2gv3ga805g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Mar 2018 02:14:46 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2M2EjCP020916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Mar 2018 02:14:45 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2M2Ejxl003593; Thu, 22 Mar 2018 02:14:45 GMT Received: from [192.168.1.213] (/75.67.242.31) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Mar 2018 19:14:44 -0700 To: Davey Song , dnsop , doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> From: Richard Gibson Message-ID: Date: Wed, 21 Mar 2018 22:14:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4335422296EBC3F550A4F602" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8839 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 02:14:50 -0000 This is a multi-part message in MIME format. --------------4335422296EBC3F550A4F602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I personally would rather see a single media type with a transport parameter than creation of a distinct media type for each transport (UDP, TCP, QUIC, …). On 03/21/2018 09:36 PM, Davey Song wrote: > Hi folks, > > I just submit a updated version of dns wireformat over HTTP. This > draft has been adopted as the dnsop wg document for quite a while > before DOH.  The original intention of this draft is to explore the > possiblity of DNS over HTTP(s) use cases and demonstrate its capacity > as an experimental draft. But the draft lacked enough specification on > HTTP requirement and context at that time. Since DOH later was setup > focusing on developing https as DNS transport protocol. So I updated > this draft as a a special use case of DOH which served as DNS proxy. > > I would like to ask comments and advice in dnsop and doh wgs mainly > two quesions: > 1) (for dns people) Does this proxy use case sounds useful as a IETF > experiment document . > 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" > acceptable specially for this use case. We also consider to introduce > an optional parameter to existing "application/dns-udpwireformat" MIME > in DOH document, because the two media type carries the identical > message body (the udp dns wireformat) in DOH request  in proxy use > case. We need suggestion here. > > Thank to Tim and Paul Hoffman to bring this draft alive. > > Davey > > ---------- Forwarded message ---------- > From: > > Date: 22 March 2018 at 08:59 > Subject: New Version Notification for > draft-ietf-dnsop-dns-wireformat-http-02.txt > To: Shane Kerr >, Paul Vixie >, Linjian Song > > > > > A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt > has been successfully submitted by Linjian Song and posted to the > IETF repository. > > Name:           draft-ietf-dnsop-dns-wireformat-http > Revision:       02 > Title:          An Proxy Use Case of DNS over HTTPS > Document date:  2018-03-21 > Group:          dnsop > Pages:          6 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt > > Status: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ > > Htmlized: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-02 > > > Abstract: >    This memo introduces a DNS proxy use case to tunnel DNS query and >    response over HTTPs using DOH, a newly proposed DNS transport.  This >    is useful in some situation where DNS is not working properly and DOH >    is not widely available for many stub-resolvers. > > > > > 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 > . > > The IETF Secretariat > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=0vF3P6joSTSHJBQKI3cszqFLbofqMLOmmZwYOKjdAtw&e= --------------4335422296EBC3F550A4F602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I personally would rather see a single media type with a transport parameter than creation of a distinct media type for each transport (UDP, TCP, QUIC, …).


On 03/21/2018 09:36 PM, Davey Song wrote:
Hi folks,

I just submit a updated version of dns wireformat over HTTP. This draft has been adopted as the dnsop wg document for quite a while before DOH.  The original intention of this draft is to explore the possiblity of DNS over HTTP(s) use cases and demonstrate its capacity as an experimental draft. But the draft lacked enough specification on HTTP requirement and context at that time. Since DOH later was setup focusing on developing https as DNS transport protocol. So I updated this draft as a a special use case of DOH which served as DNS proxy. 

I would like to ask comments and advice in dnsop and doh wgs mainly two quesions: 
1) (for dns people) Does this proxy use case sounds useful as a IETF experiment document .
2) (for HTTP people) Is a media type "application/dns-tcpwireformat" acceptable specially for this use case. We also consider to introduce an optional parameter to existing  "application/dns-udpwireformat" MIME in DOH document, because the two media type carries the identical message body (the udp dns wireformat)  in DOH request  in proxy use case. We need suggestion here.

Thank to Tim and Paul Hoffman to bring this draft alive.  

Davey
 
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 22 March 2018 at 08:59
Subject: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
To: Shane Kerr <shane@time-travellers.org>, Paul Vixie <vixie@tisf.net>, Linjian Song <songlinjian@gmail.com>



A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:           draft-ietf-dnsop-dns-wireformat-http
Revision:       02
Title:          An Proxy Use Case of DNS over HTTPS
Document date:  2018-03-21
Group:          dnsop
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-02

Abstract:
   This memo introduces a DNS proxy use case to tunnel DNS query and
   response over HTTPs using DOH, a newly proposed DNS transport.  This
   is useful in some situation where DNS is not working properly and DOH
   is not widely available for many stub-resolvers.




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.

The IETF Secretariat




_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=iL9ua2rpPYbCSUEq-K-R38UVlUtAtN8r1jwFWV5rSes&s=0vF3P6joSTSHJBQKI3cszqFLbofqMLOmmZwYOKjdAtw&e=

--------------4335422296EBC3F550A4F602-- From nobody Thu Mar 22 01:42:00 2018 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 E17851201FA for ; Thu, 22 Mar 2018 01:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AVIufYA4Cxlz for ; Thu, 22 Mar 2018 01:41:52 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 13DE9126C2F for ; Thu, 22 Mar 2018 01:41:50 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 205A2A05BB; Thu, 22 Mar 2018 09:41:48 +0100 (CET) Received: by godin (Postfix, from userid 1000) id AFFC1EC0B88; Thu, 22 Mar 2018 09:40:56 +0100 (CET) Date: Thu, 22 Mar 2018 08:40:56 +0000 From: Stephane Bortzmeyer To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: doh@ietf.org Message-ID: <20180322084056.GA30108@laperouse.bortzmeyer.org> References: <23215.63984.364570.759118@gro.dd.org> <958176d9-00cd-e8ba-8c74-c6c736ab99e8@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <958176d9-00cd-e8ba-8c74-c6c736ab99e8@nic.cz> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] Support requirements for Get and Post 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, 22 Mar 2018 08:41:54 -0000 On Mon, Mar 19, 2018 at 10:59:31PM +0100, Petr Å paÄek wrote a message of 25 lines which said: > A subversive question: > Do we *actually* need GET and POST? Could we get away with just one of > these? No, we don't NEED. But today, as Ben Schwartz and Dave Lawrence noticed, we have a much worse situation: clients and servers can choose and, as a result, they may be unable to interoperate. So, mandating GET *or* POST *or* both is necessary, to solve this interoperability problem. Now, regarding your question: experience from the hackathon seems to indicate that supporting both GET and POST is very little work. From nobody Thu Mar 22 01:46:09 2018 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 7C2DC126BF0 for ; Thu, 22 Mar 2018 01:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s9dUb4Cq1k6N for ; Thu, 22 Mar 2018 01:46:07 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 8E2B6120454 for ; Thu, 22 Mar 2018 01:46:07 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id DE70AA05BB; Thu, 22 Mar 2018 09:46:05 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 85D13EC0B88; Thu, 22 Mar 2018 09:43:50 +0100 (CET) Date: Thu, 22 Mar 2018 08:43:50 +0000 From: Stephane Bortzmeyer To: Patrick McManus Cc: Dave Lawrence , DoH WG Message-ID: <20180322084350.GB30108@laperouse.bortzmeyer.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] meta qtypes 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, 22 Mar 2018 08:46:08 -0000 On Tue, Mar 20, 2018 at 10:11:21AM +0000, Patrick McManus wrote a message of 122 lines which said: > Restating just that is less objectionable but we run the risk of > introduce subtle mistakes when all we want is redundancy. We're much > better off just including HTTP by reference as we're doing. I understand, but what about a non-normative appendix saying "This is non-normative text. The normative references is RFC [insert HTTP RFC number(s)]. Nevertheless, here is some guidance for the people who are not familiar with HTTP: [insert Tony Finch's proposed list of common error cases and recommended error codes]." From nobody Thu Mar 22 01:50:27 2018 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 B5C1E120454 for ; Thu, 22 Mar 2018 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fuQh89h-PmX8 for ; Thu, 22 Mar 2018 01:50:25 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (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 DEDB51201FA for ; Thu, 22 Mar 2018 01:50:24 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 94913A05BB; Thu, 22 Mar 2018 09:50:23 +0100 (CET) Received: by godin (Postfix, from userid 1000) id EC337EC0B88; Thu, 22 Mar 2018 09:46:16 +0100 (CET) Date: Thu, 22 Mar 2018 08:46:16 +0000 From: Stephane Bortzmeyer To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: DoH WG Message-ID: <20180322084616.GC30108@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] conflict between HTTP and DNS cache granularity 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, 22 Mar 2018 08:50:26 -0000 On Tue, Mar 20, 2018 at 12:21:50AM +0100, Petr Å paÄek wrote a message of 25 lines which said: > Thus the HTTP "TTL" has to be derived somehow, most likely using minimal > value from all RRsets present in the DNS message. Version -04 of the draft says "the smallest TTL in the Answer section of the response", which seems more reasonable to me. From nobody Thu Mar 22 02:21:01 2018 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 E642B126C19 for ; Thu, 22 Mar 2018 02:20: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, 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 4KqPZrbpzqDQ for ; Thu, 22 Mar 2018 02:20:58 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 648F2126BF0 for ; Thu, 22 Mar 2018 02:20:58 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id m47so5108360uae.6 for ; Thu, 22 Mar 2018 02:20:58 -0700 (PDT) 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=YfvhZxXCFErnVozauPAcKFr0lbj9WguqV4NcDFHjVYQ=; b=I47QmoYXaED9mg73GFq5/vEXpuC5O/1gLxQzwvWR4QUZlhNFwIoRdiQj4Q2jbPZU0+ xYlC8Bb3qKGxaN31tQWIAtA8NuA2XARBaVl1/gy+vhSwlFLdaOqIpLwDvryE+tf3eb+m rHUho2C4aJUSMLj9uYFya4nec0Gf3us0eMY+2Anf2FT2mWWIs+XedG6BtpHdT1bZ0IsV VPzfA8lj2MpYj7s2Q8g9nJSOtNTX+5/QpT9OssQHyA7Zgs5eVfNmUXQoVvD8f3hzfbXV YO5Zh2K9DVSBGuq6wSI0b/tYDgWtx/2uCHG0ApX2o21f+dhWGOnLosr6Iqg2c6NN/v0G JHfg== 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=YfvhZxXCFErnVozauPAcKFr0lbj9WguqV4NcDFHjVYQ=; b=SeQRRvWMlFMnT7wFrk/rCBAm41zUghPYjAWwPVecpU9QdBZbEaA1h5AH/EZOCaGZD3 Yk64n/BuEM8iYZrHUH1U8sl7fj0VQVHfwu6aW5OoFjAZA0sraA5r/AmwFjfXtzKeN6be j9ZCN8djXOzxZ/hNo3bGVoTG1vbQCqWGEmpQe2IiW1f2DniKgSwcnYt1cxBS41vzU7ro CqzC+BVA4aMaPjpMUWTIRi2q9SD/XW6MNMpoArQvN6zVQQGlite28o4mR1SkYfunQiMl OVrA8LuAE+dTyNgtXtr4WrS2R3KBmZ19VFfUnenIrGV0fVTAlCDkrfohLh5nUfjosu99 vWRA== X-Gm-Message-State: AElRT7GwLeFMKEdc4gkAu5RA+kU1QQfP04KL13MpURmL+DXecMeHPpTZ F5ekkh7/J1HhjCIZc5iDKjfsZJfIVDd4rk0s3eBu3w== X-Google-Smtp-Source: AG47ELt996396rXwaNUJFM1xnoU06gIzFtrAOj+Vq+QKaVsL1iC8aTizBM5Ccil9IpThWNcbE4tX/iKUVnhjHTXOUwY= X-Received: by 10.176.69.182 with SMTP id u51mr15645788uau.93.1521710457147; Thu, 22 Mar 2018 02:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Thu, 22 Mar 2018 02:20:56 -0700 (PDT) From: Davey Song Date: Thu, 22 Mar 2018 17:20:56 +0800 Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c11b8243fd72a0567fcd3e9" Archived-At: Subject: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 09:21:00 -0000 --94eb2c11b8243fd72a0567fcd3e9 Content-Type: text/plain; charset="UTF-8" Hi, Although the dns-udpwireformat MIME type was defined, the dns wireformat data should not be treated as a datagram encapsulted in a HTTPs header but a new byte stream over HTTPs (similar with DNS TCP usage). No truncation loop is needed. Peopole may take it for granted, but It should be explicitely mentioned in this draft. I mentioned this before in other mails but I notice it is not mentioned in the latest 03 version. Best regards, Davey --94eb2c11b8243fd72a0567fcd3e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Although the dns-udpwireformat MIME type was define= d, the dns wireformat data should not be treated as a datagram encapsulted = in a HTTPs header but a new byte stream over HTTPs (similar with DNS TCP us= age). No truncation loop is needed. Peopole may take it for granted, but It= should be explicitely mentioned in this draft.=C2=A0=C2=A0=C2=A0

I mentioned this before in other mails but I notice it is = not mentioned in the latest 03 version.=C2=A0

Best regards,
Davey
--94eb2c11b8243fd72a0567fcd3e9-- From nobody Thu Mar 22 03:01:42 2018 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 8489012DA1A for ; Thu, 22 Mar 2018 03:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 e64b2o7ZnfiM for ; Thu, 22 Mar 2018 03:01:32 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC9F12E8AC for ; Thu, 22 Mar 2018 03:01:27 -0700 (PDT) Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:53748) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eyx2D-0004jd-Mx (Exim 4.72) for doh@ietf.org (return-path ); Thu, 22 Mar 2018 10:01:25 +0000 To: doh@ietf.org From: Ray Bellis Message-ID: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> Date: Thu, 22 Mar 2018 10:01:25 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 10:01:41 -0000 I've just done a quick read of yesterday's -04 update. I think §5.0 could benefit from a reference to RFC 2308 to clarify that it's talking about negative answer caching. It also says: > A DNS API server SHOULD respond with HTTP status code 415 > (Unsupported Media Type) upon receiving a media type it is unable to > process. why not "MUST" ? In §7.1, the wire format description which only refers to RFC 1035 could be read as too prescriptive w.r.t. the packet length since it's limited to 512 bytes in RFC 1035. There's no need for that limitation, but consideration should be given to how a DNS API Server that is actually a proxy between DOH and real wire format should behave in the presence of a longer packet that isn't accompanied by an EDNS OPT RR. Ray From nobody Thu Mar 22 03:07:45 2018 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 E2BF7127873 for ; Thu, 22 Mar 2018 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 w_wbIfgwY9oX for ; Thu, 22 Mar 2018 03:07:42 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76C512D875 for ; Thu, 22 Mar 2018 03:07:42 -0700 (PDT) Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:53904) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eyx8G-0004sG-RK (Exim 4.72) for doh@ietf.org (return-path ); Thu, 22 Mar 2018 10:07:40 +0000 To: doh@ietf.org References: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> From: Ray Bellis Message-ID: <7b6ee873-9d46-2795-4401-72485fcd97b6@bellis.me.uk> Date: Thu, 22 Mar 2018 10:07:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 10:07:44 -0000 I forgot one: Why require base64url instead of plain base64? The latter is natively supported in web applications via the `window.btoa` and `.atob` functions. Ray From nobody Thu Mar 22 03:20:05 2018 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 6FAE71200C5 for ; Thu, 22 Mar 2018 03:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 T2eB7IGghwqs for ; Thu, 22 Mar 2018 03:19:59 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50867126C89 for ; Thu, 22 Mar 2018 03:19:59 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id d10so8081333wrf.3 for ; Thu, 22 Mar 2018 03:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=5qXlp1NBaFy2MUAN8R8lplc/MU6gS3xmZgSp3Je/SRA=; b=Kc/Q4EEETUWPRpYvTrMHrlMVthXYKklv/xPO273grPyn6fxZJRxu8iMmUBLUI6QK/t Z3M0zMG/3tb1txApf/jqyC+FD5R4kuoU5GfWK/X/iOZIADs2vLzKPuytlr40bwdxBuXs Rf9tnVaB8pLvdQ5SlcKBxjXEZnBfPJBQNOjcqVNuPRfAPiZRZQ5KXSP1IHdtQV9OpSQE vo+LX0GWApPTwR90EeRuGn0LGjpnsRAwMHXrxz06jNS5Bxt7Pu7WIIxHT1BkfDGmlw16 ywRidqW7jH3BFGBzscXONWyqySWZU0/XOncrdQVFbl9I6c3Dwd3oj2QK7b9lrpAIb58L PWfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5qXlp1NBaFy2MUAN8R8lplc/MU6gS3xmZgSp3Je/SRA=; b=e7R5qSZquWKaMOM1c6OT2Xso2JtC2BOHQsS194bGMBmV2yJAXmv6iB5WH4HF0jfyoa 3bDh+UiKyO8UzLuov57alR0YWWnysJfundJLyu2JUvoR9Cqpgkypd+pWz47HpF1prOY6 oVSGLdr2eGdJrJeEy4vacF8yf867nIiHilawQ/8VI14fd2PG93BR5whzxGdA/NPJhsk9 7GzAmdg0AnTwt3be5Vy7KvyeSVyOdq54o22RQy/b/X1uofxEQ2Lk5BARZkanXDOBNlj4 PZ/kZAynpJK1LesTs4Ig60xGVvaRcE+IQ/P+X16NA147MoS+XEQkAt21KxvUDuecASd3 ogcg== X-Gm-Message-State: AElRT7ECXrn/qOXGlPyX9BL5TAlPQJbgvxN+1/Qj+N33K+3k+sFWSTy7 1F/AR3h7FvMdnv6JZJZdjQRugg== X-Google-Smtp-Source: AG47ELvmwKeNCZ5RWWc5HEtFXZPOo/b9o4xcGUSnedPQwRUcu7E09svqvzj82hN1R3GUR8E8oyvyjw== X-Received: by 10.223.176.253 with SMTP id j58mr19180310wra.269.1521713997866; Thu, 22 Mar 2018 03:19:57 -0700 (PDT) Received: from raspberrypi ([2a02:c7f:629:a400:350:885e:dce0:c58d]) by smtp.gmail.com with ESMTPSA id z9sm8561041wrz.4.2018.03.22.03.19.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 03:19:57 -0700 (PDT) Date: Thu, 22 Mar 2018 10:19:53 +0000 From: Thomas Peterson To: Ray Bellis Cc: doh@ietf.org Message-ID: <20180322101953.GA20977@raspberrypi> References: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> <7b6ee873-9d46-2795-4401-72485fcd97b6@bellis.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7b6ee873-9d46-2795-4401-72485fcd97b6@bellis.me.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 10:20:03 -0000 The alternative to base64url encoding is URI encoding a base64 payload, a two step operation. A naïve parser in Javascript without needing anotherlibrary could be done in as little as[1]: atob(data.replace(/_/g, '/').replace(/-/g, '+')) Regards [1] https://stackoverflow.com/a/44528376 On Thu, Mar 22, 2018 at 10:07:41AM +0000, Ray Bellis wrote: > I forgot one: > > Why require base64url instead of plain base64? The latter is natively > supported in web applications via the `window.btoa` and `.atob` functions. > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Thu Mar 22 03:23:46 2018 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 0E4E712D7F5; Thu, 22 Mar 2018 03:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6NNnMLIqQIoi; Thu, 22 Mar 2018 03:23:43 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D0B126D05; Thu, 22 Mar 2018 03:23:43 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 2E83B391B5; Thu, 22 Mar 2018 06:23:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23219.33838.166003.614689@gro.dd.org> Date: Thu, 22 Mar 2018 06:23:42 -0400 From: Dave Lawrence To: Davey Song Cc: dnsop , doh@ietf.org In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 10:23:45 -0000 Davey Song writes: > Is a media type "application/dns-tcpwireformat" acceptable Without yet having (re-)read the draft, I'm unclear on what benefit this media type is bringing over dns-udpwireformat, since the only difference presumably is explicitly adding the two octets of a content-length <= 65535. Is it something other than that? From nobody Thu Mar 22 03:24:28 2018 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 BCC1C1205D3 for ; Thu, 22 Mar 2018 03:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2WvEQAtK3NPQ for ; Thu, 22 Mar 2018 03:24:24 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB061200C5 for ; Thu, 22 Mar 2018 03:24:24 -0700 (PDT) Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:54043) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eyxOQ-0005dp-Jf (Exim 4.72) for doh@ietf.org (return-path ); Thu, 22 Mar 2018 10:24:22 +0000 To: doh@ietf.org References: From: Ray Bellis Message-ID: Date: Thu, 22 Mar 2018 10:24:32 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 10:24:26 -0000 On 22/03/2018 09:20, Davey Song wrote: > Although the dns-udpwireformat MIME type was defined, the dns wireformat > data should not be treated as a datagram encapsulted in a HTTPs header > but a new byte stream over HTTPs (similar with DNS TCP usage). No > truncation loop is needed. Peopole may take it for granted, but It > should be explicitely mentioned in this draft.    If the DNS API Server is proxying between DOH and a real UDP DNS server then the UDP DNS server might still set the TC bit and the proxy could return that, so the client may still have to cope with +TC. The alternative is that the proxy has to have sufficient smarts to recognise the returned +TC and re-issue the request over TCP to the backend DNS server. Ray From nobody Thu Mar 22 03:29:24 2018 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 563141201F2 for ; Thu, 22 Mar 2018 03:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 X9uEJ61-ni5i for ; Thu, 22 Mar 2018 03:29:21 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8864F1200C5 for ; Thu, 22 Mar 2018 03:29:21 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id CEA21391BF; Thu, 22 Mar 2018 06:29:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23219.34176.821578.923227@gro.dd.org> Date: Thu, 22 Mar 2018 06:29:20 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <20180322084350.GB30108@laperouse.bortzmeyer.org> References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> <20180322084350.GB30108@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [Doh] meta qtypes 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, 22 Mar 2018 10:29:22 -0000 Stephane Bortzmeyer writes: > I understand, but what about a non-normative appendix saying "This is > non-normative text. The normative references is RFC [insert HTTP RFC > number(s)]. Nevertheless, here is some guidance for the people who are > not familiar with HTTP: [insert Tony Finch's proposed list of common > error cases and recommended error codes]." Personally (no hat) I like this idea. From nobody Thu Mar 22 03:32:09 2018 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 1A4211200C1 for ; Thu, 22 Mar 2018 03:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_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 Z-n4Vgi_63MF for ; Thu, 22 Mar 2018 03:32:01 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C75F1200C5 for ; Thu, 22 Mar 2018 03:32:00 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id o102-v6so12322164lfg.8 for ; Thu, 22 Mar 2018 03:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iFTBThVcWKmnh3ywqtsWFEvXbqqTAryuIqcHmfhNcsc=; b=IAUh1zy7HqRhSuj82Im4b3pGzBOH6gw0PTI1GV+QghUHTwoC5R4yPOkJGLT8uXi4jG DBlGflvcaH5Cj4J/i2ZEeN5yTJoRpH2toSW0YHCGeJZlQW1mcPxSGTuxBzwgDzqaEuiK lTZMnhPxLEi2FRVHlDSPC1bz/X1ZPZ48buGKkUx5FBtL4vYEq7CtOb8bq7lrwJWLEyKe DE75sW1nmsqIkFyK719VDhcGzRB6hOcK3ks2Vn4PdJr708wjroGCO6CCIWH902nfP+wS sfyLK6RuVZUK+h007ZhB1sMNa1v8nksNNxjx4VbxhA4UY6oS8CzVox/dNvxvpdTeDhtY YHfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iFTBThVcWKmnh3ywqtsWFEvXbqqTAryuIqcHmfhNcsc=; b=M0+GT7w4aS5mnh8kp4k8EYh7HwCwvZqVEX0eSy/P0767aYNPZyApa86ZVGd77f5lL6 qMZlOVPYScHQ4PJYW820WtxOngSHNYmSwWGntRTE9rPugjPrqyfCmwtfV/WKcSFpzEE/ RcdVSUI0xzSiaXeNtg2uEqBkCi63cfQS8wOesK1wjn77mDo1j74F6EB1He53x0PX9tXy iO1rnV87R31ho7+j11EuJi64pFdeDEaPQw/BqyqQVyfIocJsL/T/H/7aSr6Vm9qAeVcr /RpIF4jacs80XSqmUkoQzVz0ey421TquQnaUnCLNPmNzRJqOD5OEgtwBJqGLvzqX7Z2w 0exw== X-Gm-Message-State: AElRT7FrlibZxuzoGwLiyOAKZjSrFb7wP98DNU8IzYWn6TJbxWbFHG3/ my83HFBITC9WkBwAR3eaN1NInTZ2Nlj1o9ECwkexLg== X-Google-Smtp-Source: AG47ELtQfpg0gi+II5287Xbb6wBob3PeAZPAJ5qYIRsiX8fk2aLbrwQEAX658DM9aox3xzboIGX1WapKABW8MwIOJe8= X-Received: by 10.46.64.26 with SMTP id n26mr8083867lja.50.1521714718809; Thu, 22 Mar 2018 03:31:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: manu tman Date: Thu, 22 Mar 2018 10:31:47 +0000 Message-ID: To: Ray Bellis Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a64a643c12d0567fdd191" Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 10:32:04 -0000 --94eb2c1a64a643c12d0567fdd191 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 22, 2018 at 10:24 AM Ray Bellis wrote: > On 22/03/2018 09:20, Davey Song wrote: > > > Although the dns-udpwireformat MIME type was defined, the dns wireformat > > data should not be treated as a datagram encapsulted in a HTTPs header > > but a new byte stream over HTTPs (similar with DNS TCP usage). No > > truncation loop is needed. Peopole may take it for granted, but It > > should be explicitely mentioned in this draft. > > If the DNS API Server is proxying between DOH and a real UDP DNS server > then the UDP DNS server might still set the TC bit and the proxy could > return that, so the client may still have to cope with +TC. > > The alternative is that the proxy has to have sufficient smarts to > recognise the returned +TC and re-issue the request over TCP to the > backend DNS server. There is not much the client can be doing with the TC but here right. I mean it is using tcp already. When producing, IMO the proxy should be aware of the TC bit and retry over TCP when it happens. Manu > > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --94eb2c1a64a643c12d0567fdd191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Mar 22, 2018 = at 10:24 AM Ray Bellis <ray@bellis.m= e.uk> wrote:
On 22/03/2018 0= 9:20, Davey Song wrote:

> Although the dns-udpwireformat MIME type was defined, the dns wireform= at
> data should not be treated as a datagram encapsulted in a HTTPs header=
> but a new byte stream over HTTPs (similar with DNS TCP usage). No
> truncation loop is needed. Peopole may take it for granted, but It
> should be explicitely mentioned in this draft.=C2=A0=C2=A0=C2=A0

If the DNS API Server is proxying between DOH and a real UDP DNS server
then the UDP DNS server might still set the TC bit and the proxy could
return that, so the client may still have to cope with +TC.

The alternative is that the proxy has to have sufficient smarts to
recognise the returned +TC and re-issue the request over TCP to the
backend DNS server.

There is not much the client can be doing with the TC but here right. I = mean it is using tcp already. When producing, IMO the proxy should be aware= of the TC bit and retry over TCP when it happens.
M= anu


Ray

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--94eb2c1a64a643c12d0567fdd191-- From nobody Thu Mar 22 03:32:58 2018 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 79BAB120726 for ; Thu, 22 Mar 2018 03:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 owEq0HdwgDCS for ; Thu, 22 Mar 2018 03:32:55 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D7112E8AA for ; Thu, 22 Mar 2018 03:32:48 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 1547F391CE; Thu, 22 Mar 2018 06:32:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23219.34384.67213.938078@gro.dd.org> Date: Thu, 22 Mar 2018 06:32:48 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> References: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> Archived-At: Subject: Re: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 10:32:56 -0000 Ray Bellis writes: > > A DNS API server SHOULD respond with HTTP status code 415 > > (Unsupported Media Type) upon receiving a media type it is unable to > > process. > > why not "MUST" ? Because it might have good reasons for replying with some other code, if multiple issues exist with the request? From nobody Thu Mar 22 03:44:12 2018 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 6722B120726; Thu, 22 Mar 2018 03:44:05 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 0QOHvEQ3tKaJ; Thu, 22 Mar 2018 03:44:04 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 3BF611200C1; Thu, 22 Mar 2018 03:44:04 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r197so4914949vke.2; Thu, 22 Mar 2018 03:44:04 -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=YhNqkGmR/26pf8mCPb+VC303xhFIbsFiPtRM2g0auKI=; b=ErpKU/b+9vcJGQKPsnfFe22iNT8ncp7VFO0CGbWwIznA6XyGs8/kdJQRmfgDTjcXrR pe5rKWy8bQco4NB3oCa6rShytL5qzgpM878BqZeYlvKwShsgYQnRpTVp5HO//fr1hL8p m0Sw6D0OePNs7CABD7mdd5PR/7RZBLVf9eo9JB3AQMAfKx9vvGU9ArGqa19q+pvfUQ7Z /wZwfYZMFbbgsFE4LrqKTeZ0b22Cn5m9iP1UUz+I+H9RQcHI33vcuBPK4VYnds/2pB6n BWPNshKFSI44cwy3KlwJzZ9GC1BpdhZJ5nFonuMVCE+m0C9drBKBglqoaAZGpw8UL5TG kw1g== 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=YhNqkGmR/26pf8mCPb+VC303xhFIbsFiPtRM2g0auKI=; b=JJYHLQLarwFFYi+DRJkdZymHqn3BFsr085KLtp9x+OB3eC/Dco+3vU9QO9B8pRxXCD zb+LGtNhFosBIa24nhFfENM9dywlCP/4kLm/AEaONIHxlJxM9GE+tCR/FrLmcHqdCyOP kyeNCuNENpHhqJ5iokVubIMQGJS3soMfMebQF8ufAM4smhUGQatn7fzByq8phXt56hSE oOza0NpYN4j+a61AZ/VI1gPvwzSRG8buCnsP19uRMRW6nb3iGAnU/14gCJkiK1XHBtvQ hzeem8GtU2fKQWA/hTofxtd4G/airO8E9cyZ95+G3UBjCAeg5BSGMbJEIIeyV+DY169Q 7i9g== X-Gm-Message-State: AElRT7FT/H3bVODgj1bECpqF+JIy0ZIN5mIsKtGH7CKU1jQHioBSH7lL 3OaRwAFaM37RQdRnnhJXsp/qSEesX0o2WnlA0bc= X-Google-Smtp-Source: AG47ELuoR6Jd5B2bTt2+Whdu0lbAR8JwaLBPU5yRjgGz3qo0z2vbBGPPGPEOQrO+ieLLEl35cCbOlpDDtzM79vwVTig= X-Received: by 10.31.50.13 with SMTP id y13mr15390862vky.85.1521715443192; Thu, 22 Mar 2018 03:44:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Thu, 22 Mar 2018 03:44:02 -0700 (PDT) In-Reply-To: <23219.33838.166003.614689@gro.dd.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> From: Davey Song Date: Thu, 22 Mar 2018 18:44:02 +0800 Message-ID: To: Dave Lawrence Cc: dnsop , doh@ietf.org Content-Type: multipart/alternative; boundary="001a114405f070dd240567fdfc1a" Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 10:44:05 -0000 --001a114405f070dd240567fdfc1a Content-Type: text/plain; charset="UTF-8" To keep the transparency of DOH proxy, the proxy server should use the same transport as the proxy client receive queries from stub-resolver, transports patterns like UDP-DOH-UDP, and TCP-DOH-TCP. So the proxy client should signal the proxy server the initial transport recieve from stub-client. Davey On 22 March 2018 at 18:23, Dave Lawrence wrote: > Davey Song writes: > > Is a media type "application/dns-tcpwireformat" acceptable > > Without yet having (re-)read the draft, I'm unclear on what benefit > this media type is bringing over dns-udpwireformat, since the only > difference presumably is explicitly adding the two octets of a > content-length <= 65535. Is it something other than that? > > --001a114405f070dd240567fdfc1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To keep the transparency of DOH proxy, the proxy server sh= ould use the same transport as the proxy client receive queries from stub-r= esolver, transports patterns like UDP-DOH-UDP, and TCP-DOH-TCP. So the prox= y client should signal the proxy server the initial transport recieve from = stub-client.

Davey=C2=A0=C2=A0

On 22 March 2018 at 18:23, Dave= Lawrence <tale@dd.org> wrote:
<= span class=3D"">Davey Song writes:
> Is a media type "application/dns-tcpwireformat" accepta= ble

Without yet having (re-)read the draft, I'm unclear on what bene= fit
this media type is bringing over dns-udpwireformat, since the only
difference presumably is explicitly adding the two octets of a
content-length <=3D 65535.=C2=A0 Is it something other than that?


--001a114405f070dd240567fdfc1a-- From nobody Thu Mar 22 03:48:03 2018 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 0C05D1200C5 for ; Thu, 22 Mar 2018 03:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YAU2zOAv7fCG for ; Thu, 22 Mar 2018 03:47:59 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D11F1200C1 for ; Thu, 22 Mar 2018 03:47:59 -0700 (PDT) Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:54232) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eyxlF-0006d3-05 (Exim 4.72) for doh@ietf.org (return-path ); Thu, 22 Mar 2018 10:47:57 +0000 To: doh@ietf.org References: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> <23219.34384.67213.938078@gro.dd.org> From: Ray Bellis Message-ID: <257cc9e5-d4f2-71df-5798-56445e189043@bellis.me.uk> Date: Thu, 22 Mar 2018 10:47:57 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <23219.34384.67213.938078@gro.dd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 10:48:00 -0000 On 22/03/2018 10:32, Dave Lawrence wrote: > Because it might have good reasons for replying with some other code, > if multiple issues exist with the request? OK, so you need to allow for HTTP protocol layer errors such as 401, etc which happen earlier in the stream's processing. But if it gets that far, is there any other possible response than 415? I'm not sure how to phrase it, but I think it MUST be 415 *unless* some other error was *already* detected (at which point I'd expect request processing to have been aborted anyway). Ray From nobody Thu Mar 22 04:08:28 2018 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 039501200C5 for ; Thu, 22 Mar 2018 04:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 g-uA-rENiQEB for ; Thu, 22 Mar 2018 04:08:24 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id DBE901200C1 for ; Thu, 22 Mar 2018 04:08:23 -0700 (PDT) Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 991593A04F for ; Thu, 22 Mar 2018 07:08:22 -0400 (EDT) Received: by mail-ot0-f173.google.com with SMTP id i28-v6so8974822otf.8 for ; Thu, 22 Mar 2018 04:08:22 -0700 (PDT) X-Gm-Message-State: AElRT7FW7bgkUpcdEyJ5kC+713R4fkHEUkdqR03AYq2IR1FUobl0ZU1L td+DN13Tg8CTo5bupeunHlGZnToZ1OIl9EELaqc= X-Google-Smtp-Source: AG47ELuvqtJtaIuQt+Kkh/j6mX5St06ZHP6qK68zMUYh6xAamYwPw5pGM0h0I/dMcmczGZqkWHf8XiVmlz2pE5b/52k= X-Received: by 2002:a9d:213c:: with SMTP id i57-v6mr14083214otb.85.1521716902332; Thu, 22 Mar 2018 04:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.70.143 with HTTP; Thu, 22 Mar 2018 04:08:21 -0700 (PDT) In-Reply-To: <257cc9e5-d4f2-71df-5798-56445e189043@bellis.me.uk> References: <96afa3b5-2925-8276-9374-082b491f4216@bellis.me.uk> <23219.34384.67213.938078@gro.dd.org> <257cc9e5-d4f2-71df-5798-56445e189043@bellis.me.uk> From: Patrick McManus Date: Thu, 22 Mar 2018 11:08:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ray Bellis Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000006990ac0567fe5361" Archived-At: Subject: Re: [Doh] draft-ietf-doh-dns-over-https-04 feedback 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, 22 Mar 2018 11:08:26 -0000 --0000000000006990ac0567fe5361 Content-Type: text/plain; charset="UTF-8" Thanks Ray, imo pretty much this is what SHOULD already signals - I would phrase it as: that's the expected behavior unless you have a really good reason you cannot (Dave points out one really good reason - conflicting non-successful states). Its also plausible an HTTP gateway would not have enough information to determine more than "failure" and would want to fallback on 400 which would be less than optimal but ok. This is sort of a general problem and I don't think the draft is overall advantaged by doing this case by case. on the other hand we did add some similar text around success/non-success and how dns and http interact. That's also not strictly necessary but I think it has a broad enough impact that it is worth doing. I would hope to avoid doing that with a laundry list of codes (my approach is consistent with BCP56bis ) On Thu, Mar 22, 2018 at 10:47 AM, Ray Bellis wrote: > On 22/03/2018 10:32, Dave Lawrence wrote: > > > Because it might have good reasons for replying with some other code, > > if multiple issues exist with the request? > > OK, so you need to allow for HTTP protocol layer errors such as 401, etc > which happen earlier in the stream's processing. > > But if it gets that far, is there any other possible response than 415? > > I'm not sure how to phrase it, but I think it MUST be 415 *unless* some > other error was *already* detected (at which point I'd expect request > processing to have been aborted anyway). > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000006990ac0567fe5361 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ray,

imo pretty much = this is what SHOULD already signals - I would phrase it as: that's the = expected behavior unless you have a really good reason you cannot (Dave poi= nts out one really good reason - conflicting non-successful states). Its al= so plausible an HTTP gateway would not have enough information to determine= more than "failure" and would want to fallback on 400 which woul= d be less than optimal but ok. This is sort of a general problem and I don&= #39;t think the draft is overall advantaged by doing this case by case.

on the other hand we did add some similar text around= success/non-success and how dns and http interact. That's also not str= ictly necessary but I think it has a broad enough impact that it is worth d= oing. I would hope to avoid doing that with a laundry list of codes (my app= roach is consistent with BCP56bis )


On Thu, Mar 22, 2018 at 10:47 = AM, Ray Bellis <ray@bellis.me.uk> wrote:
On 22/03/2018 10:32, Dave Lawrence wrote:
> Because it might have good reasons for replying with some other code,<= br> > if multiple issues exist with the request?

OK, so you need to allow for HTTP protocol layer errors such as 401,= etc
which happen earlier in the stream's processing.

But if it gets that far, is there any other possible response than 415?

I'm not sure how to phrase it, but I think it MUST be 415 *unless* some=
other error was *already* detected (at which point I'd expect request processing to have been aborted anyway).

Ray

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

--0000000000006990ac0567fe5361-- From nobody Thu Mar 22 04:48:47 2018 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 0097F127873 for ; Thu, 22 Mar 2018 04:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 i_O-HbREHrg3 for ; Thu, 22 Mar 2018 04:48:44 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B035E12420B for ; Thu, 22 Mar 2018 04:48:44 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9470939263; Thu, 22 Mar 2018 07:48:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23219.38939.590564.787374@gro.dd.org> Date: Thu, 22 Mar 2018 07:48:43 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <23218.44644.48969.243875@gro.dd.org> References: <23218.44644.48969.243875@gro.dd.org> Archived-At: Subject: Re: [Doh] DoH minutes taker and jabber scribe sought 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, 22 Mar 2018 11:48:46 -0000 Got a Jabber scribe (thanks Suzanne Woolf!) but still looking for minutes takers. From nobody Thu Mar 22 05:08:33 2018 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 2BEBF127873 for ; Thu, 22 Mar 2018 05:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 sTai4v-ytTBW for ; Thu, 22 Mar 2018 05:08:30 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 3565F12D7F6 for ; Thu, 22 Mar 2018 05:08:25 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:9dd3:84be:b0d3:4284] (unknown [IPv6:2001:67c:370:128:9dd3:84be:b0d3:4284]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 5D57884F5 for ; Thu, 22 Mar 2018 13:08:23 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1521720503; bh=2UrHnqumdNTqA006fHRLnVrkFiKB8XTaa4ixe6IxtaI=; h=To:From:Subject:Date; b=JL9u1dycKz4JxNf+bx1lbQd5vjyLkzyxUiUutAZmotUJ0+3Q8Prb+Bf4wsRKsCVKm LI+JAl/z9ViiPmBsUCuEybNKsK3FZUdGPHA2WjMq/V+3Dma1U2vgKV33KrCBVY7GfL gFjKvZNTkkPjrJTm0qSNwyWfvEIVFIcogp3NYfJc= To: DoH WG From: Willem Toorop Message-ID: <6348107f-92d2-b0be-171b-521ec1a9590c@nlnetlabs.nl> Date: Thu, 22 Mar 2018 12:08:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Doh] DoH in getdns/Stubby 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, 22 Mar 2018 12:08:32 -0000 For the record, I started to work on DNS over HTTPS in getdns (and thus also Stubby) during the hackathon too. Stephane's asynchronous c-client implementation[1] fits getdns' internals very well, but some reorganizing of the surrounding managing architecture was needed to add it as a new upstream transport type. In the end I spend my time mostly on paving the way for DNS over HTTPs, but I made good progress and expect to have it available in an upcoming (perhaps beta) release, in the not too remote future. -- Willem [1] https://github.com/IETF-Hackathon/ietf101-project-presentations/blob/master/DoH/doh-nghttp.c From nobody Thu Mar 22 06:02:02 2018 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 33E1612D86B for ; Thu, 22 Mar 2018 06:02:01 -0700 (PDT) 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 Cm7aRxIUsn7d for ; Thu, 22 Mar 2018 06:01:58 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 7B6F4126CBF for ; Thu, 22 Mar 2018 06:01:58 -0700 (PDT) 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]:39742) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eyzqu-0008co-cl (Exim 4.89_2) (return-path ); Thu, 22 Mar 2018 13:01:56 +0000 Date: Thu, 22 Mar 2018 13:01:55 +0000 From: Tony Finch To: Dave Lawrence cc: DoH WG In-Reply-To: <23219.34176.821578.923227@gro.dd.org> Message-ID: References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org> <20180322084350.GB30108@laperouse.bortzmeyer.org> <23219.34176.821578.923227@gro.dd.org> 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] meta qtypes 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, 22 Mar 2018 13:02:01 -0000 Dave Lawrence wrote: > Stephane Bortzmeyer writes: > > I understand, but what about a non-normative appendix saying "This is > > non-normative text. The normative references is RFC [insert HTTP RFC > > number(s)]. Nevertheless, here is some guidance for the people who are > > not familiar with HTTP: [insert Tony Finch's proposed list of common > > error cases and recommended error codes]." > > Personally (no hat) I like this idea. As a lapsed Apache committer I have to say, +1 :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Forties, Cromarty, Forth, Tyne, Dogger: Southwest, backing south, 4 or 5, increasing 6 or 7. Slight or moderate, becoming rough. Rain later. Good occasionally poor. From nobody Thu Mar 22 06:05:27 2018 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 C305F12D869 for ; Thu, 22 Mar 2018 06:05:25 -0700 (PDT) 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 aLLHbBkMUxcN for ; Thu, 22 Mar 2018 06:05:20 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 E5268124319 for ; Thu, 22 Mar 2018 06:05:19 -0700 (PDT) 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]:34007) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eyzuA-000YKO-7S (Exim 4.89_2) (return-path ); Thu, 22 Mar 2018 13:05:18 +0000 Date: Thu, 22 Mar 2018 13:05:18 +0000 From: Tony Finch To: Davey Song cc: doh@ietf.org In-Reply-To: Message-ID: References: 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] No truncation for DNS over HTTPS 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, 22 Mar 2018 13:05:26 -0000 Davey Song wrote: > > Although the dns-udpwireformat MIME type was defined, the dns wireformat > data should not be treated as a datagram encapsulted in a HTTPs header but > a new byte stream over HTTPs (similar with DNS TCP usage). No truncation > loop is needed. Peopole may take it for granted, but It should be > explicitely mentioned in this draft. Agreed. The implementation I would like (when DOH is implemented by a proxy in front of an old-transport DNS server) has a pool of TCP connections from the proxy to the back-end DNS server(s), over which incoming requests can be multiplexed. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Forties, Cromarty, Forth, Tyne, Dogger: Southwest, backing south, 4 or 5, increasing 6 or 7. Slight or moderate, becoming rough. Rain later. Good occasionally poor. From nobody Thu Mar 22 06:28:14 2018 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 9197912D872 for ; Thu, 22 Mar 2018 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_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 gCehxdx1Ipwt for ; Thu, 22 Mar 2018 06:28:10 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 2175D12D86E for ; Thu, 22 Mar 2018 06:28:10 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id x205-v6so13147907lfa.0 for ; Thu, 22 Mar 2018 06:28:10 -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=bwZh6D1+u6wgxvF4stmQesSQ1LCDk2b3oIQfU+VZoBU=; b=KuWiXWFoFGhVYEbnUMhfvgS8XNbPFfGK9wMDaWUIqQaKEOncM9eKCysWorac/w1Njk Yo/CWVHbRTRypU6jxE9S+dnCaExLPA2l5ZNCF27FjL7/oqqm3Jtjni/eQ7dJ5+mgKqGw G4bU5D/yCK4h7HV5fLwiTF1WngVXfzp9xjJIxRQMKIINHR43QBM3yWL14V42Xa9XZugU eSA8RhirIuk9KQhRnJP39UAQ+2Y38E/cORjaroURm2IE9K1MURlxDmXQqfrsfisYviN3 PAc+uP41SahBGTnPcibQJ9Bb1QXRFhQSM4qzRKOTvm+vwhqEsI9aoTnLpliGyi4f+dOg 4v8g== 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=bwZh6D1+u6wgxvF4stmQesSQ1LCDk2b3oIQfU+VZoBU=; b=RKxCkgkqbz1r7p1EwCpx7N58QKx+fcYvIXtcNKXZMGqkjcQ+6vagUoemnkOXxT6Vl0 6NSg2wEkbcqwbz8o+3y4fVYd0A+yKoOXEiShbYOwbIo4FSZvPOqpkhAKO04wrBXRLAzx KlyybqVT3C1e2pdZ0mLutBz0u7ldteSH8zrXqW0W2SrltapykM7KV5zNk0rmG94rvQcQ jL5pOiX9/ydMSdZuVwCShe4UbuQFG1cXzi/HRPiSsw0KHluMmzXnl352jKv9W1usyy/A P4EX8hkXRgSvBsMVUijWA12ajm+PtF2gecLUqxuH2Zs3A8V5jSPa29dL9a0ICmQuoLLi D3TA== X-Gm-Message-State: AElRT7FFitGtnxouwvP/8jJZhVceBmC/63ICG6iMnU8GWUQ/OR1ZD2AU g+TTuXPi4g3Vg8DT6RVkYpELvYQTt2V7wbxRILPu10pD X-Google-Smtp-Source: AG47ELskEm4LSwR2qExcK4HC/7MaZty1t74+/Tr0Bt1/b+wD0bgCYipDgLFL2iXWy3S+mQ1S7ViGfCx3TcytDp0y2Wk= X-Received: by 10.46.91.21 with SMTP id p21mr13554268ljb.38.1521725288296; Thu, 22 Mar 2018 06:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:e34a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 06:28:07 -0700 (PDT) In-Reply-To: References: From: manu tman Date: Thu, 22 Mar 2018 13:28:07 +0000 Message-ID: To: Ray Bellis Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0d800c41395905680047d9" Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 13:28:13 -0000 --94eb2c0d800c41395905680047d9 Content-Type: text/plain; charset="UTF-8" edit: fixing autocorrect.... There is not much the client can be doing with the TC bit here right. I mean it is using tcp already. When proxying, IMO the proxy should be aware of the TC bit and retry over TCP when it happens. The client does not need to be aware of that. There would need to be some involvement from the proxy in not just passing around a packet, but actually introspect it a bit and make accurate decisions when this happens. Manu On Thu, Mar 22, 2018 at 10:31 AM, manu tman wrote: > > On Thu, Mar 22, 2018 at 10:24 AM Ray Bellis wrote: > >> On 22/03/2018 09:20, Davey Song wrote: >> >> > Although the dns-udpwireformat MIME type was defined, the dns wireformat >> > data should not be treated as a datagram encapsulted in a HTTPs header >> > but a new byte stream over HTTPs (similar with DNS TCP usage). No >> > truncation loop is needed. Peopole may take it for granted, but It >> > should be explicitely mentioned in this draft. >> >> If the DNS API Server is proxying between DOH and a real UDP DNS server >> then the UDP DNS server might still set the TC bit and the proxy could >> return that, so the client may still have to cope with +TC. >> >> The alternative is that the proxy has to have sufficient smarts to >> recognise the returned +TC and re-issue the request over TCP to the >> backend DNS server. > > > There is not much the client can be doing with the TC but here right. I > mean it is using tcp already. When producing, IMO the proxy should be aware > of the TC bit and retry over TCP when it happens. > Manu > >> >> >> Ray >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > --94eb2c0d800c41395905680047d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
edit: fixing autocorrect....

There is not much the client can be doing with the TC bit here r= ight. I mean it is using tcp already. When proxying, IMO the proxy should b= e aware of the TC bit and retry over TCP when it happens.
<= /div>
The client does not need to be aware o= f that. There would need to be some involvement from the proxy in not just = passing around a packet, but actually introspect it a bit and make accurate= decisions when this happens.
<= br>
Manu

On Thu, Mar 22, 2018 = at 10:31 AM, manu tman <chantr4@gmail.com> wrote:

On Thu, Mar 22, 2018 at 10:24 AM Ray Bellis <ray@bellis.me.uk> wro= te:
On 22/03/2018 09:20, Davey Song= wrote:

> Although the dns-udpwireformat MIME type was defined, the dns wireform= at
> data should not be treated as a datagram encapsulted in a HTTPs header=
> but a new byte stream over HTTPs (similar with DNS TCP usage). No
> truncation loop is needed. Peopole may take it for granted, but It
> should be explicitely mentioned in this draft.=C2=A0=C2=A0=C2=A0

If the DNS API Server is proxying between DOH and a real UDP DNS server
then the UDP DNS server might still set the TC bit and the proxy could
return that, so the client may still have to cope with +TC.

The alternative is that the proxy has to have sufficient smarts to
recognise the returned +TC and re-issue the request over TCP to the
backend DNS server.

There is not much the client can be doing with the TC but here ri= ght. I mean it is using tcp already. When producing, IMO the proxy should b= e aware of the TC bit and retry over TCP when it happens.
Manu


Ray

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

--94eb2c0d800c41395905680047d9-- From nobody Thu Mar 22 06:37:30 2018 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 56E281272E1 for ; Thu, 22 Mar 2018 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=cVY6mC2C; dkim=pass (1024-bit key) header.d=yitter.info header.b=TKvmlZE+ 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 pBoo0Bmj-JJl for ; Thu, 22 Mar 2018 06:37:28 -0700 (PDT) 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 1AF331200C5 for ; Thu, 22 Mar 2018 06:37:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 4F956BE780 for ; Thu, 22 Mar 2018 13:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521725847; bh=ekwUfIRC7mipNfXhI8YWNm6ALJk3GkStMoAOStAFBVQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cVY6mC2CbCNpZcJeH73sAYKzu1YqYNYkbWSJFu6ZjUEKQRVDc28iqyPxoMNs0X/ti 1dcF+unetwT5Tw7xxGXDgZ2WcseDpSD8vLIvYkk2qu5usLKtHUDMtHRJbHPukRpvZD KYFlK3or5K5UmfVhkvj1AqazJ5qyeudUkF6xdcV4= 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 LXRFbf7Rn1F0 for ; Thu, 22 Mar 2018 13:37:23 +0000 (UTC) Date: Thu, 22 Mar 2018 09:37:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521725843; bh=ekwUfIRC7mipNfXhI8YWNm6ALJk3GkStMoAOStAFBVQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TKvmlZE+0wdA1h8ucqhkmUui2oAkNRFXUrtetnIo9ZGj+hyv6q2kGQT9WW2en191K FrsA72ukKRgnsF6j3wEQRMn8dmxQ+0jm6Kxa+4OlDwPGhOxOYN0FZrxFzajjQPlXaa +zZp9jdeAaePIpqOUKKXtPP5jksmCg1H8YeGoqlE= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180322133717.hxsqb53brrivn75q@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 13:37:29 -0000 On Thu, Mar 22, 2018 at 01:05:18PM +0000, Tony Finch wrote: > > The implementation I would like (when DOH is implemented by a proxy in > front of an old-transport DNS server) has a pool of TCP connections from > the proxy to the back-end DNS server(s), over which incoming requests can > be multiplexed. That sounds like an implemntation decision or maybe a policy, not a protocol decision. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Mar 22 06:48:41 2018 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 630311200C5 for ; Thu, 22 Mar 2018 06:48:36 -0700 (PDT) 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 9Jc3XLr6Khna for ; Thu, 22 Mar 2018 06:48:35 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 D036812D96D for ; Thu, 22 Mar 2018 06:48:34 -0700 (PDT) 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]:34029) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1ez0a0-000GWz-6n (Exim 4.89_2) (return-path ); Thu, 22 Mar 2018 13:48:32 +0000 Date: Thu, 22 Mar 2018 13:48:32 +0000 From: Tony Finch To: Andrew Sullivan cc: doh@ietf.org In-Reply-To: <20180322133717.hxsqb53brrivn75q@mx4.yitter.info> Message-ID: References: <20180322133717.hxsqb53brrivn75q@mx4.yitter.info> 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] No truncation for DNS over HTTPS 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, 22 Mar 2018 13:48:36 -0000 Andrew Sullivan wrote: > > That sounds like an implemntation decision or maybe a policy, not a > protocol decision. True :-) I think my point is that if you have persistent back-end TCP connections (which you want for performance), there's no advantage to doing UDP - the TC dance slows things down, and dual-protocol backends have a complexity cost. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: North, backing west or northwest, 4 or 5. Moderate, occasionally rough at first. Rain later in northwest. Good, becoming moderate later in northwest. From nobody Thu Mar 22 06:52:13 2018 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 F3E87124234 for ; Thu, 22 Mar 2018 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=N56lRGLK; dkim=pass (1024-bit key) header.d=yitter.info header.b=RkbmV+44 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 A9_ht_nBaNFm for ; Thu, 22 Mar 2018 06:52:10 -0700 (PDT) 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 A68211200C5 for ; Thu, 22 Mar 2018 06:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 097F1BE780 for ; Thu, 22 Mar 2018 13:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521726730; bh=QRypZgdechLgydtB1iILsEz3RcZVZAIrjvkWmKi45xM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=N56lRGLKrXxcKaWDBOXpzeLDwSLOHDCaFXSpROD5PB5bk2NrBldF8DUft2Pbo9T82 S4ANw/rLkl8cNtNXzWT70kbwaoBljmXu6bGL0OpQin9FS8ggvukPUKuDd2xHzRq/xL mjl2S1MKix3B3HK3whmhMaFxrF9iOYkgIAFaYAQw= 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 tnS4J15yGH8L for ; Thu, 22 Mar 2018 13:52:08 +0000 (UTC) Date: Thu, 22 Mar 2018 09:52:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1521726728; bh=QRypZgdechLgydtB1iILsEz3RcZVZAIrjvkWmKi45xM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RkbmV+446gWC0YwB5mV1j74JI6dSwWm/35+mhI3O4yYbU62U29C1UJTrfH9Tzdw6a b4j4G4lZpR7b+oikNQSRLjKc/zl1DfgCS17/y5HqMUlvaxXhRrTAD7Xrzb2l9ctWjy g4WYn2GjEVKGMRCUtggvn/UqPOrLwBGcDutkSeIc= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180322135203.khatsujt6lym3vcb@mx4.yitter.info> References: <20180322133717.hxsqb53brrivn75q@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 13:52:12 -0000 On Thu, Mar 22, 2018 at 01:48:32PM +0000, Tony Finch wrote: > True :-) I think my point is that if you have persistent back-end TCP > connections (which you want for performance), there's no advantage to > doing UDP - the TC dance slows things down, and dual-protocol backends > have a complexity cost. No question that an implemntation that did _not_ do as you say would be boneheaded. I am totally prepared to support a paragraph with advice to implementers with this observation, but it's not 2119 protocol words, I think. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Mar 22 07:17:28 2018 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 004F8126D85 for ; Thu, 22 Mar 2018 07:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 JcKSghL0uPBZ for ; Thu, 22 Mar 2018 07:17:20 -0700 (PDT) Received: from jax4mhob19.registeredsite.com (jax4mhob19.registeredsite.com [64.69.218.107]) (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 74F9E12E887 for ; Thu, 22 Mar 2018 07:17:20 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id w2MEHDji048099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Mar 2018 10:17:14 -0400 Received: (qmail 7076 invoked by uid 0); 22 Mar 2018 14:17:13 -0000 X-TCPREMOTEIP: 31.133.147.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.147.181?) (lee@asgard.org@31.133.147.181) by 0 with ESMTPA; 22 Mar 2018 14:17:12 -0000 To: Stephane Bortzmeyer , Erik Nygren Cc: doh@ietf.org, Jordi Palet Martinez References: <20180319090048.GB16151@laperouse.bortzmeyer.org> From: Lee Howard Message-ID: <4c0b18e4-0f97-e1d5-7e93-1dc81d03f114@asgard.org> Date: Thu, 22 Mar 2018 14:17:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180319090048.GB16151@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] DNS64 and 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: Thu, 22 Mar 2018 14:17:27 -0000 On 03/19/2018 09:00 AM, Stephane Bortzmeyer wrote: > On Sun, Mar 18, 2018 at 07:20:35PM +0000, > Erik Nygren wrote > a message of 86 lines which said: > >> At least for mobile, not using DNS64 synthesis in the client will >> likely result in this either breaking the client in NAT64 >> environments > Is it a DNS64-specific problem? It could also happen if you have > local-only domain names, dummy local TLDs, alternative roots, > split-horizon, CDN, geo-based answers, or other DNS tricks. > > Yesterday, one IETFer told me that DoH was a bad idea because it allows > people to avoid DNS-based national censorship… > > May be a warning "the DoH resolver may give you a different answer > from what you would have got from the usual resolver"? Now that I have a couple more minutes, I thought I'd note Apple's measurements of IPv6-only hosts: https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trends-in-ipv6-support-tommy-pauly-00.pdf As of a year ago in maprg, 5-10% of hosts had no IPv4. Thanks for including the text, "For example, in the case of DNS64 [RFC6147], the choice could affect whether IPv6/IPv4 translation will work at all." It might not be immediately clear to a server operator that the implication of translation not working is that they must dual-stack the server. Proposed text: "... IPv6/IPv4 translation will work at all, so running both IPv4 and IPv6 on the server is recommended." If you don't like "is recommended" because it's rfc2119 language, maybe "will improve the chances of connecting." I'm also a little nervous about the text in Section 9 Operational Considerations describing the bootstrap problem, and suggesting as one possibility  "IP based URIs and corresponding IP based certificates for HTTPS". Using IP literals as the URI is the opposite of DNS. I think this is the fundamental resolution problem, which DNS solves with root hints and glue records. There are, of course, lots of problems with IP literals, including that the syntax is different in IPv4 and [IPv6], and that addresses change. Lee From nobody Thu Mar 22 07:30:08 2018 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 94D77126DFB for ; Thu, 22 Mar 2018 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 r2EylJkcoKiT for ; Thu, 22 Mar 2018 07:30:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532141243FE for ; Thu, 22 Mar 2018 07:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1521729000; x=1522333800; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Egqsh5aKHuhEPbNT+9iqinwbnbbOiFqQrDhY2WfP7TM=; b=QmEz6XW8NaFn1 0QH/Nb5zvz+BbBKq8piq2dMLZoTcYfFbh7qUQLOQxXgC6CngN8BZ/mSEt/xm/qYN 1Q32EVqWFzHJ4q2Hbgtf8IgBphh9sZstlROHIi4uTHNsaZ68+J4Gbg7QnxlodN/o cbD8mgRKq1FyeRnoLfzmP0bXlWXVxA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 22 Mar 2018 15:30:00 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 22 Mar 2018 15:30:00 +0100 Received: from [31.133.156.94] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005730313.msg for ; Thu, 22 Mar 2018 15:29:59 +0100 X-MDRemoteIP: 2001:67c:1232:144:b92d:f8a4:4f56:e2bb X-MDHelo: [31.133.156.94] X-MDArrival-Date: Thu, 22 Mar 2018 15:29:59 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=16191218c3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: doh@ietf.org User-Agent: Microsoft-MacOutlook/10.b.0.180311 Date: Thu, 22 Mar 2018 14:29:54 +0000 From: JORDI PALET MARTINEZ To: Lee Howard , Stephane Bortzmeyer , Erik Nygren CC: Message-ID: Thread-Topic: [Doh] DNS64 and DOH References: <20180319090048.GB16151@laperouse.bortzmeyer.org> <4c0b18e4-0f97-e1d5-7e93-1dc81d03f114@asgard.org> In-Reply-To: <4c0b18e4-0f97-e1d5-7e93-1dc81d03f114@asgard.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Doh] DNS64 and 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: Thu, 22 Mar 2018 14:30:08 -0000 I will also draft some text in https://tools.ietf.org/html/draft-palet-v6op= s-nat64-deployment-00, in order to consider different issues that have been= raised with this thread, so at least, those deploying NAT64s/DNS64s are aw= are of it. Regards, Jordi =20 =EF=BB=BF-----Mensaje original----- De: Doh en nombre de Lee Howard Fecha: jueves, 22 de marzo de 2018, 14:17 Para: Stephane Bortzmeyer , Erik Nygren CC: , Jordi Palet Martinez Asunto: Re: [Doh] DNS64 and DOH =20 =20 On 03/19/2018 09:00 AM, Stephane Bortzmeyer wrote: > On Sun, Mar 18, 2018 at 07:20:35PM +0000, > Erik Nygren wrote > a message of 86 lines which said: > >> At least for mobile, not using DNS64 synthesis in the client will >> likely result in this either breaking the client in NAT64 >> environments > Is it a DNS64-specific problem? It could also happen if you have > local-only domain names, dummy local TLDs, alternative roots, > split-horizon, CDN, geo-based answers, or other DNS tricks. > > Yesterday, one IETFer told me that DoH was a bad idea because it allo= ws > people to avoid DNS-based national censorship=E2=80=A6 > > May be a warning "the DoH resolver may give you a different answer > from what you would have got from the usual resolver"? =20 Now that I have a couple more minutes, I thought I'd note Apple's=20 measurements of IPv6-only hosts: https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-tr= ends-in-ipv6-support-tommy-pauly-00.pdf As of a year ago in maprg, 5-10% of hosts had no IPv4. Thanks for including the text, "For example, in the case of DNS64=20 [RFC6147], the choice could affect whether IPv6/IPv4 translation will= =20 work at all." It might not be immediately clear to a server operator=20 that the implication of translation not working is that they must=20 dual-stack the server. Proposed text: "... IPv6/IPv4 translation will work at all, so running both IPv4 and= =20 IPv6 on the server is recommended." If you don't like "is recommended"= =20 because it's rfc2119 language, maybe "will improve the chances of=20 connecting." =20 I'm also a little nervous about the text in Section 9 Operational=20 Considerations describing the bootstrap problem, and suggesting as one= =20 possibility "IP based URIs and corresponding IP based certificates for= =20 HTTPS". Using IP literals as the URI is the opposite of DNS. I think=20 this is the fundamental resolution problem, which DNS solves with root= =20 hints and glue records. There are, of course, lots of problems with IP= =20 literals, including that the syntax is different in IPv4 and [IPv6], an= d=20 that addresses change. =20 =20 Lee =20 =20 =20 =20 =20 =20 =20 _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 22 07:32:48 2018 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 E52D012DA05 for ; Thu, 22 Mar 2018 07:32:43 -0700 (PDT) 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 P1rokT42JC1j for ; Thu, 22 Mar 2018 07:32:42 -0700 (PDT) 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 2F198126D85 for ; Thu, 22 Mar 2018 07:32:42 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 126-v6so1527996oig.0 for ; Thu, 22 Mar 2018 07:32:42 -0700 (PDT) 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=384bM1mCMUaKGD6QrbcpM6Q/vgI0Pv5FpjUq0693P40=; b=aWDByl7onQNkgaA33YoDFA7pY74mgXAPbpQ3RR/yrY0FFAJLDAwpK7XGFljtO7CSVv A7Mjz3C77SXofulSrO1ncA0Buzm2P96BfYb8vfkwBALORVHcXv72EbJKTed9vbSCx0Jg el+6Y858Wk1cIwCmXh9GQeKybfjMk6g5JB51rF3FH7U2HObP17iSfsSv1ADrJZ1gSkLA BZf1DChCmWidUBzrb3e1SEjrz+XfgGAHEwdZbuwckeLsOrE0CBXpqRYkyYHv1qnfHrZx bjtecDinlyudorcVlzs0GcYNzf96YeRkJ/YeAxOjflf9S23N5t288Qyxy8MJLnSPVet1 e1Ig== 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=384bM1mCMUaKGD6QrbcpM6Q/vgI0Pv5FpjUq0693P40=; b=THU7rWVfTGguNvzhIKunOijr3xM0ied0uvd3Czj4S0uaPaQ7X4UNgSw0nBd+CE9yRR /zUssOReVdeDagxr/QPzwWHavRV0GrFjuNgVoyFAEHuaGwqeGwRye2mGz7ShrKqz++Tx YXtPhmyGVdisxroiop+afi/P+2l/T8mVJItBd+Dzbp4GAUUk+oX0Ha+RuZEkTWTcq0i3 sFm62B99Hyjo+469Inrl7uR8gQy9pPWBmIyNeHn0QklpKHKJAAVuEjZwKW/N8Jb1B9jF fjxMI2o7QdWoYYbOf9Chr8FQ7c4Qte1QApTRLyiKfUCknuSBu3y5Kv26bXtHY89gKiRp oYMA== X-Gm-Message-State: AElRT7FqzuHu87kzcYsbkDumLbOwUx7pEdGlvUuwdk9zhMQpvt/8D/Em bxxmKWYEc6CWT4Jwa4873yM9zC9eeatCMQbLI5Vluv4O X-Google-Smtp-Source: AG47ELsPkH0Hck+uUb2gvlSuzb98N/BPB/bO7TzyCeMCFUhdaYTzQMsujWzitRXRGH7DwPBfF6VUqVgoTRx/fXM5yC8= X-Received: by 10.202.198.141 with SMTP id w135mr1135649oif.215.1521729161134; Thu, 22 Mar 2018 07:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 07:32:40 -0700 (PDT) From: Martin Thomson Date: Thu, 22 Mar 2018 14:32:40 +0000 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Doh] New query formats 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, 22 Mar 2018 14:32:46 -0000 Right now, the draft assumes a model for requests that uses content type. This is natural, because the same mechanism translates neatly to both request forms. POST naturally uses content types, GET is made to follow suit. This has consequences for the introduction of new query formats (response formats are easy; see also conneg). Clients have a strong incentive to choose the wire format because any other format will cause the server to produce an error. A small change would allow GET-based queries to use new formats in parallel. It would also enable less constrained request forms that don't use a single block of octets. That change would be thus: 1. Undefine the ct parameter. 2. Define the dns as having a value that is exclusively the base64url encoding of the wire format. 3. Specify that other parameters can be used to carry information about queries. Servers that find unknown query parameters MUST ignore them. 4. Define a new registry for header field parameters. (The URI template would have covered this neatly, so you could avoid that.) This would enable simpler forms of query, like: https://doh.example.com/q?dns=&aaaa=example.com&RRSig As well as forms of request that are closer in form to the wireformat thing, in that it is a single blob, such as a JSON equivalent: https://doh.example.com/q?dns=&json= Note: existing implementations tolerate this sort of change, by virtue of there being no other formats, and that the default is sensible. That's not necessarily a permanent condition though. From nobody Thu Mar 22 07:41:30 2018 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 B491C12D94A for ; Thu, 22 Mar 2018 07:41:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 5NdpwoSX-dgU for ; Thu, 22 Mar 2018 07:41:23 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 6CCA412D87E for ; Thu, 22 Mar 2018 07:41:20 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id o102-v6so13510591lfg.8 for ; Thu, 22 Mar 2018 07:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PiQGvdl646FCYViuJbXdiN+Mj6OQZj/U89A+fEda9Nw=; b=hmdlqTpkuZb9l/BZ6iDwAO3GJ8hmrjHYducqlkqAuQE9gGVnvIUdQI4mKllDy5HTFc UIIni9K8cYHkwugmJDaLPGmnCGEA9MqUb1qM/mD3pYptHB02IqjwuTg9u7HU2p52Gkh8 LYLsI92ml25ErmZTQW8OOfmRj+yFn7VGWde83y4DOinrxSy8aOmpgtMlSwKGgnEcKxGW FpYTNtPVdIqapq4FKFlxo3G4z6hxX/uSIO7XwVSYkHZsV1U11chXP4f8Y9azLxXuP+Lr QZEouXKpCflf/w+WBj0LBVJVk/IrHlqqJ56kBL86goA5ROKAWGs34mjbDtU30Sy3Kxdp 3lXw== 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=PiQGvdl646FCYViuJbXdiN+Mj6OQZj/U89A+fEda9Nw=; b=RI1tZh1cG0HP7Kux2NL/tXY1xSkRRPVH3V//a9EfM9w/kgRDLAYe4mjqCz24u1Wg8h keLHCPblTCIQI88DZD+E7Xy8TEXaeeKWv7BIm0tRi2txP48rVskG4TCRTtpA8K26WO39 7SG2oGmIfE0rAcOdK8jCo25vTfNr8nj6N8gBk+o3PBbCHvP7DYg/EsaS+N0Dl+zRxGJX 7tk5+i/Zvv32Ydyv29rjo27k+B7uCdOwm8uG4ZX6DRHjLeJZJ1OaoaXHuFgaE+nlAFMd lumXXFT8Rtu1LHSHgfMOqdxD7Jh9iqwibthkW4pUoYeCDaRqTwGryvU/z2trVjmhBCbU /KOA== X-Gm-Message-State: AElRT7HvMWhPyEl7UV9DdFwiCw7J+E04/i5WI9h0PBrJHrqbNeaHcaN5 IDBuNZliuBLA/KSqfXAkAaPHzXGvlTVHvT/1znL4lmmL X-Google-Smtp-Source: AG47ELsbqbTQT7+10nIoT/MNlHmmTQXqLyQ5Ol+kO1OMCrw2f/6OxKzVjpIOvELf9hK5FpLSn6pJqxxSxRkqF3vfD9w= X-Received: by 2002:a19:2145:: with SMTP id h66-v6mr16146035lfh.63.1521729678554; Thu, 22 Mar 2018 07:41:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.155.140 with HTTP; Thu, 22 Mar 2018 07:41:17 -0700 (PDT) In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> From: Bob Harold Date: Thu, 22 Mar 2018 10:41:17 -0400 Message-ID: To: Davey Song Cc: dnsop , doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef92970568014c3b" Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 14:41:28 -0000 --000000000000ef92970568014c3b Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote: > Hi folks, > > I just submit a updated version of dns wireformat over HTTP. This draft > has been adopted as the dnsop wg document for quite a while before DOH. > The original intention of this draft is to explore the possiblity of DNS > over HTTP(s) use cases and demonstrate its capacity as an experimental > draft. But the draft lacked enough specification on HTTP requirement and > context at that time. Since DOH later was setup focusing on developing > https as DNS transport protocol. So I updated this draft as a a special use > case of DOH which served as DNS proxy. > > I would like to ask comments and advice in dnsop and doh wgs mainly two > quesions: > 1) (for dns people) Does this proxy use case sounds useful as a IETF > experiment document . > 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" > acceptable specially for this use case. We also consider to introduce an > optional parameter to existing "application/dns-udpwireformat" MIME in > DOH document, because the two media type carries the identical message body (the > udp dns wireformat) in DOH request in proxy use case. We need > suggestion here. > > Thank to Tim and Paul Hoffman to bring this draft alive. > > Davey > > ---------- Forwarded message ---------- > From: > Date: 22 March 2018 at 08:59 > Subject: New Version Notification for draft-ietf-dnsop-dns- > wireformat-http-02.txt > To: Shane Kerr , Paul Vixie , > Linjian Song > > > > A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt > has been successfully submitted by Linjian Song and posted to the > IETF repository. > > Name: draft-ietf-dnsop-dns-wireformat-http > Revision: 02 > Title: An Proxy Use Case of DNS over HTTPS > Document date: 2018-03-21 > Group: dnsop > Pages: 6 > URL: https://www.ietf.org/internet- > drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-ietf-dnsop-dns-wireformat-http/ > Htmlized: https://tools.ietf.org/html/d > raft-ietf-dnsop-dns-wireformat-http-02 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-dnsop-dns-wireformat-http > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-dnsop-dns-wireformat-http-02 > > Abstract: > This memo introduces a DNS proxy use case to tunnel DNS query and > response over HTTPs using DOH, a newly proposed DNS transport. This > is useful in some situation where DNS is not working properly and DOH > is not widely available for many stub-resolvers. > The first time "DOH" is used, it should be defined. Either: DOH (DNS over HTTP) or: DNS over HTTP (DOH) I think the second is the preferred method. -- Bob Harold --000000000000ef92970568014c3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 21, 2018 at 9:36 PM, Davey Song <songlinjian@gmail.com> wrote:
Hi = folks,

I just submit a updated version of dns wireformat= over HTTP. This draft has been adopted as the dnsop wg document for quite = a while before DOH.=C2=A0 The original intention of this draft is to explor= e the possiblity of DNS over HTTP(s) use cases and demonstrate its capacity= as an experimental draft. But the draft lacked enough specification on HTT= P requirement and context at that time. Since DOH later was setup focusing = on developing https as DNS transport protocol. So I updated this draft as a= a special use case of DOH which served as DNS proxy.=C2=A0

<= /div>
I would like to ask comments and advice in dnsop and doh wgs main= ly two quesions:=C2=A0
1) (for dns people) Does this proxy use ca= se sounds useful as a IETF experiment document .
2) (for HTTP peo= ple) Is a media type "application/dns-tcpwireformat" accepta= ble specially for this use case. We also consider to introduce an optional = parameter to existing=C2=A0=C2=A0"applicatio= n/dns-udpwireformat" MIME in DOH document, because the two media = type carries the identical message body=20 (the udp dns wireformat)=C2=A0 in DOH request=C2=A0 in proxy use case. We need suggestion here.

Thank to Tim and Paul Hoffman to bring this draft ali= ve.=C2=A0=C2=A0

Davey
=C2=A0
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 22 March 2018 at 08:59
Subject: New Version Notification for = draft-ietf-dnsop-dns-wireformat-http-02.txt
To: Shane Kerr <shane@time-trave= llers.org>, Paul Vixie <vixie@tisf.net>, Linjian Song <songlinjian@gmail.com>

<= br>
A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dnsop-dns-wireform= at-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An Proxy Use Case of DNS over HTTP= S
Document date:=C2=A0 2018-03-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-i= etf-dnsop-dns-wireformat-http-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wire= format-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-ht= tp-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns= -wireformat-http
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dn= sop-dns-wireformat-http-02

Abstract:
=C2=A0 =C2=A0This memo introduces a DNS proxy use case to tunnel DNS query = and
=C2=A0 =C2=A0response over HTTPs using DOH, a newly proposed DNS transport.= =C2=A0 This
=C2=A0 =C2=A0is useful in some situation where DNS is not working properly = and DOH
=C2=A0 =C2=A0is not widely available for many stub-resolvers.


The first time &quo= t;DOH" is used, it should be defined.=C2=A0 Either:
DOH (DNS= over HTTP)
or:
DNS over HTTP (DOH)

I think the second is the preferred method.

= --=C2=A0
Bob Harold
=C2=A0
--000000000000ef92970568014c3b-- From nobody Thu Mar 22 07:51:20 2018 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 DF4C012D87E for ; Thu, 22 Mar 2018 07:51:18 -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, 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 H03naJF7kIqV for ; Thu, 22 Mar 2018 07:51:17 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E195912D86E for ; Thu, 22 Mar 2018 07:51:16 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id f6so5739003ual.0 for ; Thu, 22 Mar 2018 07:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBsVoGWBPr54AcGgrNF/8jpKX/AxKYDjkEO3GdBcTIg=; b=R83LcvUg1uvT7hmDZjm5WIo6Pu81LC9TGE2FxtBw+NjzBuKfeMii000yyCs29q/ny9 FdjrrabxOPPv0LrEJsCVtt7CivFG1CBEzsqRXYsySqLedorTs8t2iQdpBctwSV79hYiw R2ZWVkRfqxVD5JNl2GCtkXJZ/JSWoJvRRlrFbMaIYwT9k808GgOTV9hc6uCZ8m1SxJw4 M7/pUFWyakdDQJW83l7bOE31DCFKHclJ2HlEIu1dVijgD4QtqGMogwYrJ1sYerybuhNZ n8iAXIb4DlRxs2KsU0t3ecXqfrQ2ObMvt1YQjXTF9tewubekGv5ZvhBL9Pfy9uaDrv86 58vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kBsVoGWBPr54AcGgrNF/8jpKX/AxKYDjkEO3GdBcTIg=; b=R7PSgrfu2GnsoEBs28MSQEuUcUfazFZVockbLUaMJjzk+3LNyU6Bdf3l/ADLQ2hQij /mvMpRJNWls6Kudr9fe5+JTUqTwCbwx2haVZoMn6Y670gTmt5iARpSsFJc8NSNdamjLn tq5XDJICUQRZAD823fKluru2PkftVPwgMFwYE6nB78mEfvkkTGV2EZF06zbm7P6ytwHt 2jHeoazyFJ1zWQtWsAQYMNMRdksgw9dQPfeBt46dkcmS1LogpULyF8pcroqDymCOQGNY n9PQIEPD055KaKNKaf8Z37SHFQqxsnmc+X5IRNaCnlpU1AN+gSnepIJcK4CCsZM6omF6 gvbQ== X-Gm-Message-State: AElRT7G10yFxm1YULCW6E2HyOnWyKtQg3SHLceovAnzggXtTk0cs0Rf8 rvzWnqmBZh0bdT0o6Nyf3jx7WQRSvJ/j5Tdg3wI= X-Google-Smtp-Source: AG47ELvuivRN2tM8dZVCrWNTIiGzR5BnNaeSEUEhwu5Oo49bMvCqUgx2dY2otmczO3ga5BMxSnG2ALK+8qWFTEb1O/k= X-Received: by 10.176.85.199 with SMTP id w7mr14477217uaa.145.1521730275854; Thu, 22 Mar 2018 07:51:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davey Song Date: Thu, 22 Mar 2018 14:51:04 +0000 Message-ID: To: Ray Bellis Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="f403045e343489501f056801705a" Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 14:51:19 -0000 --f403045e343489501f056801705a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry. We are talking about two different things. One is about DOH as a dns transport protocol. One is about the proxy use case. I'm told by the author that the doh draft is to define HTTPS as DNS native transport, just as DNS UDP and DNS TCP, that's why I'm asking more clarification on truncation. There is nothing to do with proxy use case. If the DNS API server is deployed as a proxy, it is introduced as a doh use case in another draft in dnsop: https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 In the doh proxy draft, it keeps the transparent principle which is proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 of rfc5625. So the "WAN interface" speaking normal UDP must recognize TC bit and be able to fall back to TCP. But the "LAN interface" speaking DOH should not do truncation. The process of truncation for stub-resolver should be done in the"LAN interface" of DNS API client, If I understand correctly. I will add your suggestion on doh proxy draft. It is recommended in rfc5625 though. Davey Ray Bellis =E4=BA=8E 2018=E5=B9=B43=E6=9C=8822=E6=97=A5= =E5=91=A8=E5=9B=9B 18:24=E5=86=99=E9=81=93=EF=BC=9A > On 22/03/2018 09:20, Davey Song wrote: > > > Although the dns-udpwireformat MIME type was defined, the dns wireforma= t > > data should not be treated as a datagram encapsulted in a HTTPs header > > but a new byte stream over HTTPs (similar with DNS TCP usage). No > > truncation loop is needed. Peopole may take it for granted, but It > > should be explicitely mentioned in this draft. > > If the DNS API Server is proxying between DOH and a real UDP DNS server > then the UDP DNS server might still set the TC bit and the proxy could > return that, so the client may still have to cope with +TC. > > The alternative is that the proxy has to have sufficient smarts to > recognise the returned +TC and re-issue the request over TCP to the > backend DNS server. > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f403045e343489501f056801705a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry. We are talking about two differe= nt things. One is about DOH as a dns transport protocol. One is about the p= roxy use case.

I'm t= old by the author that the doh draft is to define HTTPS as DNS native trans= port, just as DNS UDP and DNS TCP, that's why I'm asking more clari= fication on truncation.=C2=A0 There is nothing to do with proxy use case.= =C2=A0

If the DNS AP= I server is deployed as a proxy, it is introduced as a doh use case in anot= her draft in dnsop: https://tools.ietf.org/html/draft-ietf-dnsop-dns-w= ireformat-http-02=C2=A0

In the doh proxy draft, it keeps the transparent principle which is pro= posed in rfc5625 as well as full support on TCP proposed in s4.4.1 of rfc56= 25. So the "WAN interface" speaking normal UDP must recognize TC = bit and be able to fall back to TCP. But the "LAN interface" spea= king DOH should not do truncation. The process of truncation for stub-resol= ver should be done in the"LAN interface" of DNS API client, If I = understand correctly.=C2=A0

I will add your suggestion on doh proxy draft. It is recommended in rfc= 5625 though.

Davey
=


Ray Bellis <ray@bellis.me.u= k> =E4=BA=8E 2018=E5=B9=B43=E6=9C=8822=E6=97=A5=E5=91=A8=E5=9B=9B 18= :24=E5=86=99=E9=81=93=EF=BC=9A
On 2= 2/03/2018 09:20, Davey Song wrote:

> Although the dns-udpwireformat MIME type was defined, the dns wireform= at
> data should not be treated as a datagram encapsulted in a HTTPs header=
> but a new byte stream over HTTPs (similar with DNS TCP usage). No
> truncation loop is needed. Peopole may take it for granted, but It
> should be explicitely mentioned in this draft.=C2=A0=C2=A0=C2=A0

If the DNS API Server is proxying between DOH and a real UDP DNS server
then the UDP DNS server might still set the TC bit and the proxy could
return that, so the client may still have to cope with +TC.

The alternative is that the proxy has to have sufficient smarts to
recognise the returned +TC and re-issue the request over TCP to the
backend DNS server.

Ray

_______________________________________________
Doh mailing list
Doh@ie= tf.org
https://www.ietf.org/mailman/listinfo/doh
--f403045e343489501f056801705a-- From nobody Thu Mar 22 07:56:05 2018 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 1733412EAC4; Thu, 22 Mar 2018 07:55:54 -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, 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 A4rcqJpLUN9L; Thu, 22 Mar 2018 07:55:50 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E94012D96B; Thu, 22 Mar 2018 07:55:50 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r197so5395665vke.2; Thu, 22 Mar 2018 07:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wlm5ElUEfJk1GlJfbwyQ21P83JeQ0xdtBGv3w3+uOng=; b=VnmxgjmFxDsf6a7zxAtZGhch73HXASDpuuKOn8HY/5BAYdathZIpB/9L0xsJTfd6pF LKlzaOYb51KdqJf1ypQSJY+mHevBlhIXaLi3DRinQpnlyZyKy6kMerBguApgYnNL+DlS d3YxI8zdAoZ7WJfvc8tj98fAVOU7Isie+QbOzYmcGEn/MheZJbhW/lN+LaiscfkF8rFv ZCHg7OyVplcQxp303FrjeTIMyBBPosKpFTrlMAFG7tGrSM/IPbMEB4hZo+grmeWCdSB2 tDod9jEsfdnGxQtnEs+gchoECPr82/Pm+7pN5ohAI1gaAixpVYIxiG1pxuUL3xE8utmu xBsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wlm5ElUEfJk1GlJfbwyQ21P83JeQ0xdtBGv3w3+uOng=; b=QoL0QcAgPai94naMLIP2vOX3CT/VFf5Zv7uAuAJKLbAH9sKzMZ3Gh8sGLSR1r5VzOj g3oZxC+6/ewR2aG0fY+EvVhluOB3ZFqxnISZjTEuV2Ttg0rwXk5WMTVZ4xfvTvYVkCh2 PrRYGTjsy8CJh5M7eK0eNPPLx4E7uQ2D4B+xafUWK7Vq9L/VcVyE+SZ8kik6XiJ2y+g+ 3mLnOypaTObKnIo1zR5PoQchIrN0bHfMY6vlKUnJjyQGshTV2s7Y8OOLDmB4gk7R/sgG s2Fl6gv444iz7VOB0TsQ/839pn65eQBZ2U4GrqKnQhhbzSkY8DxiX2Sh12cgxeVTdttq duFQ== X-Gm-Message-State: AElRT7FLNfm7rDB50X29ct5gwk57/3aJnHZ8a1vktExDLK7VZ5bjeKPN Cdfx2Bx0fjKSOmiGHEjGCMpgJ3yA9odxVKd6l1lF9A== X-Google-Smtp-Source: AG47ELtZ9xSO575z60AnJoypyVmSMh6ePn73pghmHOIXxtLnmdaJifwWScQVvDGF+FGwGgFvUWeSdFmX61o87w4SIUE= X-Received: by 10.31.50.13 with SMTP id y13mr16020015vky.85.1521730549274; Thu, 22 Mar 2018 07:55:49 -0700 (PDT) MIME-Version: 1.0 References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> In-Reply-To: From: Davey Song Date: Thu, 22 Mar 2018 14:55:38 +0000 Message-ID: To: Bob Harold Cc: dnsop , doh@ietf.org Content-Type: multipart/alternative; boundary="001a114405f0d55f4a05680180c1" Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 14:55:57 -0000 --001a114405f0d55f4a05680180c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your advice. Davey Bob Harold =E4=BA=8E 2018=E5=B9=B43=E6=9C=8822=E6=97= =A5=E5=91=A8=E5=9B=9B 22:41=E5=86=99=E9=81=93=EF=BC=9A > > On Wed, Mar 21, 2018 at 9:36 PM, Davey Song wrote= : > >> Hi folks, >> >> I just submit a updated version of dns wireformat over HTTP. This draft >> has been adopted as the dnsop wg document for quite a while before DOH. >> The original intention of this draft is to explore the possiblity of DNS >> over HTTP(s) use cases and demonstrate its capacity as an experimental >> draft. But the draft lacked enough specification on HTTP requirement and >> context at that time. Since DOH later was setup focusing on developing >> https as DNS transport protocol. So I updated this draft as a a special = use >> case of DOH which served as DNS proxy. >> >> I would like to ask comments and advice in dnsop and doh wgs mainly two >> quesions: >> 1) (for dns people) Does this proxy use case sounds useful as a IETF >> experiment document . >> 2) (for HTTP people) Is a media type "application/dns-tcpwireformat" >> acceptable specially for this use case. We also consider to introduce an >> optional parameter to existing "application/dns-udpwireformat" MIME in >> DOH document, because the two media type carries the identical message b= ody (the >> udp dns wireformat) in DOH request in proxy use case. We need >> suggestion here. >> >> Thank to Tim and Paul Hoffman to bring this draft alive. >> >> Davey >> >> ---------- Forwarded message ---------- >> From: >> Date: 22 March 2018 at 08:59 >> Subject: New Version Notification for >> draft-ietf-dnsop-dns-wireformat-http-02.txt >> To: Shane Kerr , Paul Vixie , >> Linjian Song >> >> >> >> A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt >> has been successfully submitted by Linjian Song and posted to the >> IETF repository. >> >> Name: draft-ietf-dnsop-dns-wireformat-http >> Revision: 02 >> Title: An Proxy Use Case of DNS over HTTPS >> Document date: 2018-03-21 >> Group: dnsop >> Pages: 6 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-htt= p-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-ht= tp >> Diff: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dns-wireformat-http= -02 >> >> Abstract: >> This memo introduces a DNS proxy use case to tunnel DNS query and >> response over HTTPs using DOH, a newly proposed DNS transport. This >> is useful in some situation where DNS is not working properly and DOH >> is not widely available for many stub-resolvers. >> > > > The first time "DOH" is used, it should be defined. Either: > DOH (DNS over HTTP) > or: > DNS over HTTP (DOH) > > I think the second is the preferred method. > > -- > Bob Harold > > --001a114405f0d55f4a05680180c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your advice.

Davey


On Wed,= Mar 21, 2018 at 9:36 PM, Davey Song <songlinjian@g= mail.com> wrote:
Hi folks,

I just submit a updated version of dn= s wireformat over HTTP. This draft has been adopted as the dnsop wg documen= t for quite a while before DOH.=C2=A0 The original intention of this draft = is to explore the possiblity of DNS over HTTP(s) use cases and demonstrate = its capacity as an experimental draft. But the draft lacked enough specific= ation on HTTP requirement and context at that time. Since DOH later was set= up focusing on developing https as DNS transport protocol. So I updated thi= s draft as a a special use case of DOH which served as DNS proxy.=C2=A0

I would like to ask comments and advice in dnsop and = doh wgs mainly two quesions:=C2=A0
1) (for dns people) Does this = proxy use case sounds useful as a IETF experiment document .
2) (= for HTTP people) Is a media type "application/dns-tcpwireformat" = acceptable specially for this use case. We also consider to introduce an op= tional parameter to existing=C2=A0=C2=A0"app= lication/dns-udpwireformat" MIME in DOH document, because the two medi= a type carries the identical message body=20 (the udp dns wireformat)=C2=A0 in DOH request=C2=A0 in proxy use case. We need suggestion here.

Thank to Tim and Paul Hoffman to bring this draft ali= ve.=C2=A0=C2=A0

Davey
=C2=A0
---------- Forwarded message ----------
From: <internet-drafts@iet= f.org>
Date: 22 March 2018 at 08:59
Subject: New Versio= n Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
To: Shane= Kerr <shane@time-travellers.org>, Paul Vixie <vixie@tisf.= net>, Linjian Song <songlinjian@gmail.com>


<= br> A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dnsop-dns-wireform= at-http
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An Proxy Use Case of DNS over HTTP= S
Document date:=C2=A0 2018-03-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/d= raft-ietf-dnsop-dns-wireformat-http-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns= -wireformat-http/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-h= ttp-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dnsop= -dns-wireformat-http
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-dnsop-dns-wireformat-http-02

Abstract:
=C2=A0 =C2=A0This memo introduces a DNS proxy use case to tunnel DNS query = and
=C2=A0 =C2=A0response over HTTPs using DOH, a newly proposed DNS transport.= =C2=A0 This
=C2=A0 =C2=A0is useful in some situation where DNS is not working properly = and DOH
=C2=A0 =C2=A0is not widely available for many stub-resolvers.


The first time &quo= t;DOH" is used, it should be defined.=C2=A0 Either:
DOH (DNS= over HTTP)
or:
DNS over HTTP (DOH)

I think the second is the preferred method.

= --=C2=A0
Bob Harold
=C2=A0
--001a114405f0d55f4a05680180c1-- From nobody Thu Mar 22 08:02:15 2018 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 DC4F012D88A for ; Thu, 22 Mar 2018 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RPxbRsFQSF2X for ; Thu, 22 Mar 2018 08:02:07 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC0712D88D for ; Thu, 22 Mar 2018 08:02:07 -0700 (PDT) Received: from nat64-c2.meeting.ietf.org ([31.130.238.194]:56504 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1ez1jA-0002VH-On (Exim 4.72) (return-path ); Thu, 22 Mar 2018 15:02:04 +0000 To: Davey Song Cc: doh@ietf.org References: From: Ray Bellis Message-ID: <26c28a74-632d-4c9c-2a64-36711180bcaa@bellis.me.uk> Date: Thu, 22 Mar 2018 15:02:05 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 15:02:11 -0000 On 22/03/2018 14:51, Davey Song wrote: > Sorry. We are talking about two different things. One is about DOH as a > dns transport protocol. One is about the proxy use case. > > I'm told by the author that the doh draft is to define HTTPS as DNS > native transport, just as DNS UDP and DNS TCP, that's why I'm asking > more clarification on truncation.  There is nothing to do with proxy use > case. IMHO you can't separate the two. The client shouldn't be able to tell the difference between a "native" DOH Server endpoint and one that's being proxied through some smart middleware to a DNS server that only speaks "normal" UDP and TCP wire-format queries. [the analog is those using e.g. stunnel to provide DNS-over-TLS support as a front end to servers that don't natively support DNS-over-TLS] > If the DNS API server is deployed as a proxy, it is introduced as a doh > use case in another draft in dnsop: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02  > > In the doh proxy draft, it keeps the transparent principle which is > proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 of > rfc5625. So the "WAN interface" speaking normal UDP must recognize TC > bit and be able to fall back to TCP. But the "LAN interface" speaking > DOH should not do truncation. The process of truncation for > stub-resolver should be done in the"LAN interface" of DNS API client, If > I understand correctly. I believe that's consistent with what I wrote in my second paragraph: "The alternative is that the proxy has to have sufficient smarts to recognise the returned +TC and re-issue the request over TCP to the backend DNS server." That said (and as suggested a few messages back) a pool of persistent TCP connections between proxy and server would be preferable to using UDP and risking truncation. > I will add your suggestion on doh proxy draft. It is recommended in > rfc5625 though. Look at who wrote that RFC :p Ray From nobody Thu Mar 22 08:30:18 2018 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 80638126E64 for ; Thu, 22 Mar 2018 08:30:17 -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, 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 ZDuz2902iwzz for ; Thu, 22 Mar 2018 08:30:15 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 B0A5E12D893 for ; Thu, 22 Mar 2018 08:30:15 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id k187so5451156vke.12 for ; Thu, 22 Mar 2018 08:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4rJ3iITF2fCHsKB2fhaREaWDmJwjlhv2SBdx+IIZAnI=; b=uC5e4bcILvp/6qoI3yOsFqznhdVVjI3Z+Btvge2kzIHfP2zUuTbLj25+QtpGCqsFwU Y9b+QkgqpRlroTD/xMJkP4zCQ9/5iAnW5ao2DMx2cJmez/9S4gqV1xgDsTV35bxerOgc QsUICJK5r48Os3pO3xAx3YdYo3S7EHvF5FJp2TDxFZRgKIh/SOpwTqWnvTLGWtD5Pk8p yNxdEL7oyUkRucn14gixEIhCXHmWzVC3T73dKBIiVAAS5c6eb/ZuXmq+pjTVDuYtMWyk xOLDT/NziJEcan7zwOVfgffoEdDKjv3veaagxId71wbNkZloL9Lb336AV3+jz4Z3/S7D YSwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4rJ3iITF2fCHsKB2fhaREaWDmJwjlhv2SBdx+IIZAnI=; b=k9hUoE8zNjnmfLEakJTBsTW7xepnPTfn6GiyY8qRJi7B3UoLhfo8N1GGM5kQh1F54I OVjHdQvXrbaFhfO/srLA5g+eIIY4Va5IKQ/jJvUwoMTrwYO41QpRGRkDbSEulbyWGIYb 7IzfclYTBpI93gDrbeRExesVHQpNL8LaaALF20SvrVKH8T7ul842nQrkKcfUe+P8AubI 44dul2HJinzG8s97enbXtV4wVLiZlSWBN0nMQwKvUtVQV85VrNd4D0YHloZzg6+z6wbe tJIBPv17sKwjR7N+VQ17yP3x0PwDwr1r3ojt4L4AbsR0ApaxRv+/yWdUwU2P3ogqLkas xDCQ== X-Gm-Message-State: AElRT7Gxk+5836JognX7hkPSYH2sHzIoeVDK+sXGKNpTwLdA8FnDv5r6 0mHEctsyGQiD0UOCO3qja95BKYIj4WxjE1e+X5BzkA== X-Google-Smtp-Source: AG47ELtLapH7l+1ttLkasvD3jp+zRPVUcsavNDIAaa4HquYNwD3dq6pO0QO2S9uRBHTnXOVnOmZ9pYXLZVCqwcWBj2c= X-Received: by 10.31.50.13 with SMTP id y13mr16125564vky.85.1521732614657; Thu, 22 Mar 2018 08:30:14 -0700 (PDT) MIME-Version: 1.0 References: <26c28a74-632d-4c9c-2a64-36711180bcaa@bellis.me.uk> In-Reply-To: <26c28a74-632d-4c9c-2a64-36711180bcaa@bellis.me.uk> From: Davey Song Date: Thu, 22 Mar 2018 15:30:04 +0000 Message-ID: To: Ray Bellis Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a114405f0f09d57056801fba1" Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 15:30:18 -0000 --001a114405f0f09d57056801fba1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ray Bellis =E4=BA=8E 2018=E5=B9=B43=E6=9C=8822=E6=97=A5= =E5=91=A8=E5=9B=9B 23:02=E5=86=99=E9=81=93=EF=BC=9A > > IMHO you can't separate the two. > > The client shouldn't be able to tell the difference between a "native" > DOH Server endpoint and one that's being proxied through some smart > middleware to a DNS server that only speaks "normal" UDP and TCP > wire-format queries. Fair enough I believe that's consistent with what I wrote in my second paragraph: > Yes. I re-read your first comment. It is not a disagreement to my mail, but an adding. Thanks. > Look at who wrote that RFC :p > OK. You are the boss ; p Davey > --001a114405f0f09d57056801fba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ray Bell= is <ray@bellis.me.uk> =E4=BA= =8E 2018=E5=B9=B43=E6=9C=8822=E6=97=A5=E5=91=A8=E5=9B=9B 23:02=E5=86=99=E9= =81=93=EF=BC=9A

IMHO you can't separate the two.

The client shouldn't be able to tell the difference between a "nat= ive"
DOH Server endpoint and one that's being proxied through some smart
middleware to a DNS server that only speaks "normal" UDP and TCP<= br> wire-format queries.

=C2=A0Fair enough

I believe that's consistent with what I wrote in my second paragraph:

Yes. I re-read your first comment. It is not a dis= agreement to my mail, but an adding. Thanks.


Look at who wrote that RFC :p


OK. You are the bo= ss ; p

Davey
--001a114405f0f09d57056801fba1-- From nobody Thu Mar 22 08:43:17 2018 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 46234127076 for ; Thu, 22 Mar 2018 08:43:15 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 5rj7GohW4KgU for ; Thu, 22 Mar 2018 08:43:12 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 9C0D212D94A for ; Thu, 22 Mar 2018 08:43:11 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id j68-v6so13832164lfg.13 for ; Thu, 22 Mar 2018 08:43:11 -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=s1CAb0Wtu5DAjjaogZow1agJFvwW/YRgHBXPfF0zh/I=; b=ZWn4plZttxKA/6RMRMw2vrWGELD3mekRrU4NYvEZBQdEiR0TeYQSQ75iW45LmpKhOD qkG2V1sXdC7MWFr+dKL5xSZrRkuYbmYKYtVi18fmQ4+ZwS4rGWPobuEb5j5GB+D8k8l0 qxhn0WsUFAizryraK9jy0xuTb8dI33HQUul4iz/0Q6lCOB5YREsgxS/cmSc2QFya8EAo OqG+o8MxNjuYqsHw1O4tH1AF1ZqdwfzVm2VUlx5PMtCBnTHmHHN7lc4h1y3l2zQZaKqY cxR56N3ePYPqkhfUcBZ7tNBbRtjK4ifhCgxG0vGauN2uJXwDnNkH1cEbA4Od+fWRb/ej 7cVg== 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=s1CAb0Wtu5DAjjaogZow1agJFvwW/YRgHBXPfF0zh/I=; b=Yda37DTYDXqYdkb+bIY5+aj42QRY2glDdz35HmhmRyN5X8hrccWUNqHVKpm1bE8TUP aA/0X3RCJycfC2y+3s8qd1YpXOoAeIS2tiVgwgN/LrkudRi4t9JjkoYjX7vKcUanwOel nkEFBlXVmehqSSjS3O5SlT3irvcL/KEeCL5OoQLDzSiYb1CpbawbgqOhoTSc9UmnIYVa yYC/RLz6s/Q4reYwKi9bVPqG2HCcMi33aTkPkpfqQJno9iUpMHwMyQUbwxM1P871tLXq Q5E0TAksrx7e3/EzpUa3ajjntVRR2M6RTgFJHMHRuDmGN6UlHirIsr9YL12g9h4AiMV/ igCw== X-Gm-Message-State: AElRT7E454NoRUPZL9kA/0VPjPryyu+ByGsLrOD/oz+q1q2gi26BqK/f 1Mw88PoJ0BQbBMQ3u1aCumUmoXwixR5MGcX2tYE= X-Google-Smtp-Source: AG47ELspvdf74xItU0h8RdrAfdmG0y5zW10MODbLZJ4H4qbxZlEdFKoaWpm2/OVIGHUHIiNsN7ZvB81I7nPDTchnVlo= X-Received: by 10.46.34.70 with SMTP id i67mr16772676lji.143.1521733389839; Thu, 22 Mar 2018 08:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d8a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 08:43:08 -0700 (PDT) In-Reply-To: <26c28a74-632d-4c9c-2a64-36711180bcaa@bellis.me.uk> References: <26c28a74-632d-4c9c-2a64-36711180bcaa@bellis.me.uk> From: Massimiliano Fantuzzi Date: Thu, 22 Mar 2018 16:43:08 +0100 Message-ID: To: Ray Bellis Cc: Davey Song , doh@ietf.org Content-Type: multipart/alternative; boundary="f4030439a1f024f1ea0568022a95" Archived-At: Subject: Re: [Doh] No truncation for DNS over HTTPS 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, 22 Mar 2018 15:43:15 -0000 --f4030439a1f024f1ea0568022a95 Content-Type: text/plain; charset="UTF-8" Hi Ray, list, >The client shouldn't be able to tell the difference between a "native" >DOH Server endpoint and one that's being proxied through some smart >middleware to a DNS server that only speaks "normal" UDP and TCP >wire-format queries. That is key statement, shall be clear to everyone implementing clients-only ! > That said (and as suggested a few messages back) a pool of persistent > TCP connections between proxy and server would be preferable to using > UDP and risking truncation. Agree but driving towards TCP-only is not exactly desired either, is it ? More largely, we look at future. By the way, I agree to have two wireformats, UDP and TCP, helps the client flagging/react quicker. Today's DNS is *UDP and TCP only *wether DOH could benefit of other than TCP-only transport. IMHO, being liberal on any future transport, and be "sort of strict" on how backend messaging has to happen, has negative effect of limiting UDP/DNS initial usage. In a sense, setting or handling TC bit and siizes should not even be task of the DOH but demanded to the client implementation, what you think ? What is the sense of passing a wireformat, if "extra intelligence" is required outside of the specs of the proto ?? What's better than "forging" out the packet as-is in a pure DNS way ? Ok you might skip the forgery part but you already have a good packet to work with DNS standard stuff, why rework it further? I also wrote this comment on >512 sizes, few minutes ago: https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/110#issuecomment-375335739 Client implementation should be as easy and standard as possible. To copy dig source code and make it dig-o-h just a joke. Quick example, my pre-doh implementation used CURLlibs and system's resolver, so easy that is almost ugly (server-only from a DNS point of view). Works on every DNS client (and TCP was left in the TODO, just for the sake of precision). AND as a plus, enables DOH client and server implementations (client C, server PHP). I changed nothing in how the local and remote systems acquire or query DNS informations (i.e. DOH is already a proxy itself) Quoting your last, Ray > The client shouldn't be able to tell the difference Proxy specific reasoning has always represented an "added complexity" to become really transparent... I believe re-describing truncation or mentioning how-to proxyfication happens, are not primary goals in doh-draft, what are your thoughts ? If (1035) then (DNS). If (HTTP) then (stateless). = burden of the client to find it's way through standards of DNS querying (i.e. retry the same server after timeout, try next server and assume broken, retry in TCP, whatever). Sorry for long post. With kind regards, max On Thu, Mar 22, 2018 at 4:02 PM, Ray Bellis wrote: > On 22/03/2018 14:51, Davey Song wrote: > > Sorry. We are talking about two different things. One is about DOH as a > > dns transport protocol. One is about the proxy use case. > > > > I'm told by the author that the doh draft is to define HTTPS as DNS > > native transport, just as DNS UDP and DNS TCP, that's why I'm asking > > more clarification on truncation. There is nothing to do with proxy use > > case. > > IMHO you can't separate the two. > > The client shouldn't be able to tell the difference between a "native" > DOH Server endpoint and one that's being proxied through some smart > middleware to a DNS server that only speaks "normal" UDP and TCP > wire-format queries. > > [the analog is those using e.g. stunnel to provide DNS-over-TLS support > as a front end to servers that don't natively support DNS-over-TLS] > > > If the DNS API server is deployed as a proxy, it is introduced as a doh > > use case in another draft in dnsop: > > https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 > > > > In the doh proxy draft, it keeps the transparent principle which is > > proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 of > > rfc5625. So the "WAN interface" speaking normal UDP must recognize TC > > bit and be able to fall back to TCP. But the "LAN interface" speaking > > DOH should not do truncation. The process of truncation for > > stub-resolver should be done in the"LAN interface" of DNS API client, If > > I understand correctly. > > I believe that's consistent with what I wrote in my second paragraph: > > "The alternative is that the proxy has to have sufficient smarts to > recognise the returned +TC and re-issue the request over TCP to the > backend DNS server." > > That said (and as suggested a few messages back) a pool of persistent > TCP connections between proxy and server would be preferable to using > UDP and risking truncation. > > > I will add your suggestion on doh proxy draft. It is recommended in > > rfc5625 though. > > Look at who wrote that RFC :p > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- *Massimiliano Fantuzzi* *IT professional, expert in DB Linux and networks.* *+41 76 754 1037 <%2B41%2076%20754%201037>* --f4030439a1f024f1ea0568022a95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Ray, list,

>The client s= houldn't be able to tell the difference between a "native"
>DOH Server endpoint and one that's be= ing proxied through some smart
>middlewa= re to a DNS server that only speaks "normal" UDP and TCP>wire-format queries.

That is ke= y statement, shall be clear to everyone implementing clients-only !

= >=C2=A0That said (and as suggested a few mess= ages back) a pool of persistent
> TCP co= nnections between proxy and server would be preferable to using
> UDP and risking truncation.

=
Agree but driving towards = TCP-only is not exactly desired either, is it ? More largely, we look at fu= ture.
By the = way, I=C2=A0agree to have two wireformats,= UDP and TCP, helps the client flagging/react quicker.

Today's DNS i= s UDP and TCP only=C2=A0wether DOH could benefit of other than TCP-only transport.
IMHO,= being liberal on any future transport, and be "sort of strict" o= n how backend messaging has to happen, has negative effect of limiting UDP/= DNS initial usage.
In a sense, setting or handling TC bit and siizes should not=C2=A0even be = task of the DOH but demanded to the client implementation, what you think ?=

What is the sense of passing a wireformat, = if "extra intelligence" is required outside of the specs of the p= roto ??
What's better than "forging" out the packet as-is = in a pure DNS way ?
Ok you might skip = the forgery part but you already have a good packet to work with DNS standa= rd stuff, why rework it further?

I also wr= ote this comment on >512 sizes, few minutes ago:=C2=A0https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/110#i= ssuecomment-375335739
<= span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12= .8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb= (255,255,255);text-decoration-style:initial;text-decoration-color:initial;f= loat:none;display:inline">
Client implementation should be as easy a= nd standard as possible.=C2=A0To copy dig source code and make it dig-o-h just a joke.
Quick example, my pr= e-doh implementation used CURLlibs and system's resolver, so easy that = is almost ugly (server-only from a DNS point of view).
Works on every DN= S client (and TCP was left in the TODO, just for the sake of precision).
AND as a plus, enables DOH client and server implementations (client C, se= rver PHP).
I changed nothing in how the local and remote systems acqui= re or query DNS informations (i.e. DOH is already a proxy itself)

> The client shou= ldn't be able to tell the difference
Proxy specific reasoning has always repre= sented an "added complexity" to become really transparent...

=
I believe re-describing truncation or mentioning how-to proxyfication h= appens, are not primary goals in doh-draft, what are your thoughts ?
If = (1035) then (DNS). If (HTTP) then (stateless).
=C2=A0=3D burden of the c= lient to find it's way through standards of DNS querying (i.e. retry th= e same server after timeout,=C2=A0try next serve= r and assume broken,=C2=A0retry in TCP, whatever).

Sorry for long post.


Wit= h kind regards,
max


On Thu, Mar 22, 2018 at 4:02 PM, Ray = Bellis <ray@bellis.me.uk> wrote:
On 22/03/2018 14:51, Davey Song wrote:
> Sorry. We are talking about two different things. One is about DOH as = a
> dns transport protocol. One is about the proxy use case.
>
> I'm told by the author that the doh draft is to define HTTPS as DN= S
> native transport, just as DNS UDP and DNS TCP, that's why I'm = asking
> more clarification on truncation.=C2=A0 There is nothing to do with pr= oxy use
> case.

IMHO you can't separate the two.

The client shouldn't be able to tell the difference between a "nat= ive"
DOH Server endpoint and one that's being proxied through some smart
middleware to a DNS server that only speaks "normal" UDP and TCP<= br> wire-format queries.

[the analog is those using e.g. stunnel to provide DNS-over-TLS support
as a front end to servers that don't natively support DNS-over-TLS]

> If the DNS API server is deployed as a proxy, it is introduced as a do= h
> use case in another draft in dnsop:
> https://tools.ietf.org/html/= draft-ietf-dnsop-dns-wireformat-http-02=C2=A0
>
> In the doh proxy draft, it keeps the transparent principle which is > proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 = of
> rfc5625. So the "WAN interface" speaking normal UDP must rec= ognize TC
> bit and be able to fall back to TCP. But the "LAN interface"= speaking
> DOH should not do truncation. The process of truncation for
> stub-resolver should be done in the"LAN interface" of DNS AP= I client, If
> I understand correctly.

I believe that's consistent with what I wrote in my second paragraph:
"The alternative is that the proxy has to have sufficient smarts to recognise the returned +TC and re-issue the request over TCP to the
backend DNS server."

That said (and as suggested a few messages back) a pool of persistent
TCP connections between proxy and server would be preferable to using
UDP and risking truncation.

> I will add your suggestion on doh proxy draft. It is recommended in > rfc5625 though.

Look at who wrote that RFC :p

Ray

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



--

Massimiliano Fantuzzi
IT pro= fessional, expert in DB Linux and networks.

= <= div>
<= /div>
--f4030439a1f024f1ea0568022a95-- From nobody Thu Mar 22 09:42:43 2018 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 2E7EB124B17; Thu, 22 Mar 2018 09:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 aQhG3TBhV6ba; Thu, 22 Mar 2018 09:42:34 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB631242F5; Thu, 22 Mar 2018 09:42:34 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 0521A395B6; Thu, 22 Mar 2018 12:42:33 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23219.56569.2064.711002@gro.dd.org> Date: Thu, 22 Mar 2018 12:42:33 -0400 From: Dave Lawrence To: dnsop , doh@ietf.org In-Reply-To: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 16:42:36 -0000 Davey Song writes: > To keep the transparency of DOH proxy, the proxy server should use > the same transport as the proxy client receive queries from > stub-resolver, transports patterns like UDP-DOH-UDP, and > TCP-DOH-TCP. So the proxy client should signal the proxy server the > initial transport recieve from stub-client. I'm really not digging this as a good use of a media type, especially when the draft says: "If proxy client receives the query via TCP, then it will carry a new media type defined in this document "application/ dns-tcpwireformat" and speak DOH with proxy server with the same DNS query without the two-byte length field defined in DNS over TCP" So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte identical on the wire, and you're just using it as a signal for the transport you want the DOH Proxy Server to use when talking to a resolver (if indeed it is talking to separate resolver at all), is that right? If a transparent DOH proxy client is talking to a co-operating DOH proxy server, shouldn't they have a better signaling mechanism than that? Is there any other media type that directs a server on transport issues? The use case also doesn't really address why it is important to preserve the stub's udp-vs-tcp choice to its presumptive resolver, but rather only refers only vaguely to the transparency issue. It would be nice to have a clearer statement of what's driving this proposal. From nobody Thu Mar 22 10:02:16 2018 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 69447126D85; Thu, 22 Mar 2018 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xCrBaqrCx1Lt; Thu, 22 Mar 2018 10:02:07 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915A3126CF6; Thu, 22 Mar 2018 10:02:07 -0700 (PDT) Received: from [10.8.2.102] (185.173.180.112.mixvoip.solutions [185.173.180.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9F5727594C; Thu, 22 Mar 2018 17:02:06 +0000 (UTC) Message-ID: <5AB3E18A.1070109@redbarn.org> Date: Thu, 22 Mar 2018 10:02:02 -0700 From: Paul Vixie User-Agent: Postbox 5.0.24 (Windows/20180302) MIME-Version: 1.0 To: Dave Lawrence CC: dnsop , doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> In-Reply-To: <23219.56569.2064.711002@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 17:02:10 -0000 Dave Lawrence wrote: > I'm really not digging this as a good use of a media type, especially > when the draft says: > > ... nor i. apparently there were only worse choices, in the eyes of http folks. > So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte > identical on the wire, and you're just using it as a signal for the > transport you want the DOH Proxy Server to use when talking to a > resolver (if indeed it is talking to separate resolver at all), is > that right? yes. If a transparent DOH proxy client is talking to a > co-operating DOH proxy server, shouldn't they have a better signaling > mechanism than that? Is there any other media type that directs a > server on transport issues? i had originally proposed an http query header to inform the far end as to what transport the near end had received the question on. this was seen as "not http-friendly". thus we have the proposal you now see. > The use case also doesn't really address why it is important to > preserve the stub's udp-vs-tcp choice to its presumptive resolver, but > rather only refers only vaguely to the transparency issue. It would > be nice to have a clearer statement of what's driving this proposal. this is not a service, it's a proxy. that is, the far end should not start with udp (which is the usual dns initiator thing to do) and then make its own decision of whether to retry with tcp (for example on TC=1). the near end may already have tried udp and got TC=1. or the near end may have its own reasons for wanting to try tcp first. if we were specifying a transport to a servive, like the DOH draft does, then we would not care about this. but this is a firewall bypass tool, not a dns-via-http service. thus, the near side of the proxy has to tell the far end of the proxy how we heard the query, so that it can use the same transport when it regenerates it for us on the far end. -- P Vixie From nobody Thu Mar 22 10:04:49 2018 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 C492312711A for ; Thu, 22 Mar 2018 10:04:46 -0700 (PDT) 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, HTML_MESSAGE=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=umich.edu 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 YeYcWoW5NWLC for ; Thu, 22 Mar 2018 10:04:44 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 5302D12704A for ; Thu, 22 Mar 2018 10:04:44 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id v207-v6so14256630lfa.10 for ; Thu, 22 Mar 2018 10:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i8NYIl9jNr4b+HnuNupo/BFBGPHp7WH3p8IutNzTCQo=; b=LRuzS3sokvA0E54Er6JOE1jnY7zoC7n9DegTYcRKt6c9Tfp6gn0AKJ9XBQg0T10YVZ y/lYsSPNnzPBzouwXAhKDCNoSG0MMfflJ9yMKX0X6CtReAfCKjAF0wkvNuBmWKVImFWy 59uA8Nd/taX7J4d2WFe30DGYI+zyLYOFCHFr5vlE+ZgByi9LJUeV2ZKvsf+foS00bQ5n abbgw+7FXsociC6mt/hYGzQKPjpI9A1SIzIJ1a6rSjRGAhZNqCw8o931XOm4tgfjBfmy 4MIjVfJAUnFESNsV10rm836MvKrXtvaL+QfVFMNCB4UHJCQUEHWgY6TgoOitYb9xOsWk 12lw== 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=i8NYIl9jNr4b+HnuNupo/BFBGPHp7WH3p8IutNzTCQo=; b=Q1GcwG1OWQpB+ObvjQmKDt+Vb92kkCiKEAzm2PxTH6RfVyudavP9r3RQ8+L6cNjamG hnhgdVTNJ568SYovhrOU8BQwICitSZAGOYTZ4TyNHjSyLx7ZA+cNi7+cFeAi74Trkt5T N/WfmEIhO7s8EkvxAziOl8+Gba3YU3gulsfkbQkK8Bm54zeNE6x8z9017iUqiq6Wpvl1 1hY3jvGPZJcX2dt0n4Jw1xAdwxeoWpbBKXAq755Lua7KzylbXGh0JzO25LNpovAdw/ze kcoqU3mzSLPtOHDKATt5qcL9kNc7NjJ2/YrMQDVtXSzGgSDFkGQGycQIS2ST4oICryAw DR+A== X-Gm-Message-State: AElRT7EVSbyYGmH8JQLXeRMsVNhbSNy7YiHg9LIiddH5J265fsrjhF6L Esvwu3GQWHKjmyaMnarHAIkpRE1eaEXWlsx9tn6mnAc3 X-Google-Smtp-Source: AG47ELtfwK7OXXfLU6ah3CCSXtf1buB3ZghQ5hfrsDloGrqa1Opx5N21sn4UUWifA4kqS9OYrqXq/b+aPnm5y333vTo= X-Received: by 10.46.127.30 with SMTP id a30mr2340046ljd.93.1521738282487; Thu, 22 Mar 2018 10:04:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.155.140 with HTTP; Thu, 22 Mar 2018 10:04:41 -0700 (PDT) In-Reply-To: <23219.56569.2064.711002@gro.dd.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> From: Bob Harold Date: Thu, 22 Mar 2018 13:04:41 -0400 Message-ID: To: Dave Lawrence Cc: dnsop , doh@ietf.org Content-Type: multipart/alternative; boundary="089e082f4198c4dfd70568034d9e" Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 17:04:47 -0000 --089e082f4198c4dfd70568034d9e Content-Type: text/plain; charset="UTF-8" On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence wrote: > Davey Song writes: > > To keep the transparency of DOH proxy, the proxy server should use > > the same transport as the proxy client receive queries from > > stub-resolver, transports patterns like UDP-DOH-UDP, and > > TCP-DOH-TCP. So the proxy client should signal the proxy server the > > initial transport recieve from stub-client. > > I'm really not digging this as a good use of a media type, especially > when the draft says: > > "If proxy client receives the query via TCP, then it > will carry a new media type defined in this document "application/ > dns-tcpwireformat" and speak DOH with proxy server with the same > DNS query without the two-byte length field defined in DNS over > TCP" > > So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte > identical on the wire, and you're just using it as a signal for the > transport you want the DOH Proxy Server to use when talking to a > resolver (if indeed it is talking to separate resolver at all), is > that right? If a transparent DOH proxy client is talking to a > co-operating DOH proxy server, shouldn't they have a better signaling > mechanism than that? Is there any other media type that directs a > server on transport issues? > > The use case also doesn't really address why it is important to > preserve the stub's udp-vs-tcp choice to its presumptive resolver, but > rather only refers only vaguely to the transparency issue. It would > be nice to have a clearer statement of what's driving this proposal. > > Unfortunately, the resolver needs to make decisions based on the original transport, for example if the transport is TCP, it can send any size response. But if UDP, it needs to fit in a smaller size, and it often sends less info in the response. Likewise, session signalling, anti-spoofing decisions, etc depend on the transport. That brings up another question. Would it also need to know the MTU of the original connection, or any other info? (Assuming EDNS is not used) In that case, a different media type is not enough, and we need to change the format to add some 'header" info. -- Bob Harold --089e082f4198c4dfd70568034d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 22, 2018 at 12:42 PM, Dave Lawrence <tale@dd.org> wrot= e:
Davey Song writes: > To keep the transparency of DOH proxy, the proxy server should use
> the same transport as the proxy client receive queries from
> stub-resolver, transports patterns like UDP-DOH-UDP, and
> TCP-DOH-TCP. So the proxy client should signal the proxy server the > initial transport recieve from stub-client.

I'm really not digging this as a good use of a media type, espec= ially
when the draft says:

=C2=A0 "If proxy client receives the query via TCP, then it
=C2=A0 =C2=A0will carry a new media type defined in this document "app= lication/
=C2=A0 =C2=A0dns-tcpwireformat" and speak DOH with proxy server with t= he same
=C2=A0 =C2=A0DNS query without the two-byte length field defined in DNS ove= r
=C2=A0 =C2=A0TCP"

So, dns-tcpwireformat and dns-udpwireformat are byte-for-byte
identical on the wire, and you're just using it as a signal for the
transport you want the DOH Proxy Server to use when talking to a
resolver (if indeed it is talking to separate resolver at all), is
that right?=C2=A0 If a transparent DOH proxy client is talking to a
co-operating DOH proxy server, shouldn't they have a better signaling mechanism than that?=C2=A0 Is there any other media type that directs a
server on transport issues?

The use case also doesn't really address why it is important to
preserve the stub's udp-vs-tcp choice to its presumptive resolver, but<= br> rather only refers only vaguely to the transparency issue.=C2=A0 It would be nice to have a clearer statement of what's driving this proposal.

<= br>
Unfortunately, the resolver needs to make decisions based on = the original transport, for example if the transport is TCP, it can send an= y size response.=C2=A0 But if UDP, it needs to fit in a smaller size, and i= t often sends less info in the response.=C2=A0 Likewise, session signalling= , anti-spoofing decisions, etc depend on the transport.

That brings up another question.=C2=A0 Would it also need to know the= MTU of the original connection, or any other info?=C2=A0 (Assuming EDNS is= not used)=C2=A0 In that case, a different media type is not enough, and we= need to change the format to add some 'header" info.
--=C2=A0
Bob Harold

=
--089e082f4198c4dfd70568034d9e-- From nobody Thu Mar 22 10:11:29 2018 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 305F212704A; Thu, 22 Mar 2018 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 lqJnQMG9ZccM; Thu, 22 Mar 2018 10:11:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83A8126D85; Thu, 22 Mar 2018 10:11:21 -0700 (PDT) Received: from [10.8.2.102] (185.173.180.112.mixvoip.solutions [185.173.180.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DD9FE7594C; Thu, 22 Mar 2018 17:11:20 +0000 (UTC) Message-ID: <5AB3E3B7.3080607@redbarn.org> Date: Thu, 22 Mar 2018 10:11:19 -0700 From: Paul Vixie User-Agent: Postbox 5.0.24 (Windows/20180302) MIME-Version: 1.0 To: Bob Harold CC: Dave Lawrence , dnsop , doh@ietf.org References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt 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, 22 Mar 2018 17:11:23 -0000 Bob Harold wrote: > > ... > > Unfortunately, the resolver needs to make decisions based on the > original transport, for example if the transport is TCP, it can send any > size response. But if UDP, it needs to fit in a smaller size, and it > often sends less info in the response. Likewise, session signalling, > anti-spoofing decisions, etc depend on the transport. except that i don't find it unfortunately but simply factual, i agree. > > That brings up another question. Would it also need to know the MTU of > the original connection, or any other info? (Assuming EDNS is not > used) In that case, a different media type is not enough, and we need > to change the format to add some 'header" info. not in my opinion. if the far end has a larger MTU outbound than the near end had inbound, then truncation damage will occur -- and the original initiator will retry with TCP. we just need to be transparent so that the original initiator can drive its own transport selections. -- P Vixie From nobody Thu Mar 22 10:40:15 2018 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 1ED1B126C0F for ; Thu, 22 Mar 2018 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 feo2gpAa5DM3 for ; Thu, 22 Mar 2018 10:40:11 -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 50F3B126579 for ; Thu, 22 Mar 2018 10:40:11 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id m22-v6so10358681otf.10 for ; Thu, 22 Mar 2018 10:40:11 -0700 (PDT) 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=yyc0GLPmgJN659liyBYfrJzViCpvGEY+5IZLzlEIS/w=; b=MeFg+lEgpLFV97Y2+C0DMboziSd5So2FIg50+7/ZodyXrPDLlXJVcMVTxO04Slau0G FEhT+ezz7wkayUOEsogOWgo/vp2sQvreE5AGWEKj3Tg6yIe19ckWWJN85hLgS2I67Hj2 Qz6i3wsux/JrRu9OTU3VBXvzgZaxVV8BKHrTRT7JSmb+CgLK9I7yNeG0+wXN9+b6B7C1 bBcoIvHzDEX7VkZcA5uoR70437rgZj7l46vtNeZ5f7RFksiLzkCwULtnv+lofOtjYCbm jfGjf/JCpxjprIUEd1v6GjuQ2UMGuXM09oKvRT3ArvHCU0MalcaIaO5ixlWpian4FLR4 37zQ== 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=yyc0GLPmgJN659liyBYfrJzViCpvGEY+5IZLzlEIS/w=; b=fzx27nEDJI/xGuNmfwatZTeekvf3zqYmIIXbo7I/IDvH7WqbO7kf+tV4Aww7tLSPxt 7t5FflwNkkSGJ/9r7kkH8V5pDPdEVZAieymv3iXUzzm/GCp/DlKtsvcDxFS8P3c0bdCg ahxH39Fo84egX9Dk+rP//G409JBJZQ9xqcQFanHOcKR95h1OWu7GCeYmR+svp7yI3lUr R3zLvDgTBqdfLv7gKmcWqewtXM4THh/DLd/kj51dBsXUrgjVkf/Qo3WzN4x4Z7W2gJI1 UHItCgi8lKsXrjuZlyDEaczwj7njYmk1A14YZGz684I3dvE1udyMsaWn+uXjofRebPAM jv1w== X-Gm-Message-State: AElRT7EX7G4Wkveq8oeM22/gc/b9wuK/K7iMAfclTwaBJ3jlvStMuK3g X6FgLRqoGhe+Vo6+KNibArmntMQ70C8cH2WXVxBHzQ== X-Google-Smtp-Source: AIpwx49J5R/Z+9juyDGPwms9dzoxlhl83ACcbb3errjhCAiagIlp6Rl+L0vzgbGL8r5WUABtYObWxhgLMVtDmN8bCis= X-Received: by 2002:a9d:2c09:: with SMTP id f9-v6mr8744489otb.123.1521740410395; Thu, 22 Mar 2018 10:40:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.155.70 with HTTP; Thu, 22 Mar 2018 10:40:09 -0700 (PDT) From: Alexander Mayrhofer Date: Thu, 22 Mar 2018 17:40:09 +0000 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Doh] Review of draft-ietf-doh-dns-over-https-04 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, 22 Mar 2018 17:40:14 -0000 Hi, i've read through the -04 version of the draft. I've notices a few minor things: - Section 3 contains: "The queries and responses must be able to be flexible enough to express every normal DNS query." What's a "normal" DNS query? I do suggest we either remove that word, or specify which (abnormal) DNS queries are not supported (or explicitely list which we consider "normal). I suppose the "abnormal" would be UPDATE, NOTIFY, AXFR and the like? - Also in Section 3, we have "EDNS extensions". Are those supposed to be "EDNS options"? Suggest "EDNS options as well as future versions of EDNS".. - Also in Section 3, what's "legacy Version" of HTTP? If that should mean "any HTTP version below 2.0", then we should explicitely say so. This would also match the SHOULD in section 6.2 - Section 4 contains text about http/2 padding. Note that RFC7830 does also provide padding (on the application level of DNS) to obscure packet sizes, maybe a respective note should be added here. - Section 4.1 contains "EDNS extensions" again - suggest rewording to "EDNS options". (i have not validated the examples) - Section 5: Looking at the range of 2XX HTTP responses, i'm wondering whether it makes sense to restrict the valid HTTP responses further? I'm not a HTTP guru, so i'm specifically careful about this. Eg. 201 and 202 probably don't make any sense in the context of a DNS query/response transaction, 204 shouldn't happen if the DNS API server provides a valid DNS response, and 205 gives me the crazy ID that this could be used to "update" a local DNS cache with updated information... - Section 5: Has another instance of "EDNS extensions", suggest "EDNS options". "MAY have one or more EDNS extensions, depending on the extension definition of the extensions given in the DNS request." sounds.. confusing :) - Section 5, expiration: I think this should be reworded to be more concise, i do suggest the following text: The HTTP response freshness lifetime ([RFC7234] Section 4.2) should SHOULD be set to expire at the same time the first of the DNS resource record sets in the Answer section reach a 0 TTL, and MUST NOT be greater than that indicated by the DNS resource record set with the smallest TTL in the DNS response. (does the MUST NOT consider additional sections as well, or just the answer section - clarification needed..) Same for the remaining freshness text - all sections, or just "answer" section? tia, (for now) Alex From nobody Sun Mar 25 09:10:18 2018 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 8E1A1127876 for ; Sun, 25 Mar 2018 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6tujDRo-g9ig for ; Sun, 25 Mar 2018 09:10:15 -0700 (PDT) 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 BA6C51270B4 for ; Sun, 25 Mar 2018 09:10:12 -0700 (PDT) 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, 25 Mar 2018 09:10:11 -0700 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, 25 Mar 2018 09:10:11 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Proposed text for dealing with the old UDP 512-byte limitation and truncation Thread-Index: AQHTxFO/vYOFWpi8m0STf+1N9JFpng== Date: Sun, 25 Mar 2018 16:10:10 +0000 Message-ID: <97DE40CC-7B70-42F7-9FF5-B78F17CB7818@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.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D094D545F2793408DACBBEB1A387988@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Proposed text for dealing with the old UDP 512-byte limitation and truncation 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, 25 Mar 2018 16:10:16 -0000 Please see https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/120/files So that we don't get two threads of comments, please send them here to the = list. --Paul Hoffman= From nobody Sun Mar 25 09:30:33 2018 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 C2C77127136 for ; Sun, 25 Mar 2018 09:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 mQYD6XPD_DuN for ; Sun, 25 Mar 2018 09:30:30 -0700 (PDT) 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 39DA51200F1 for ; Sun, 25 Mar 2018 09:30:30 -0700 (PDT) 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, 25 Mar 2018 09:30:28 -0700 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, 25 Mar 2018 09:30:28 -0700 From: Paul Hoffman To: Alexander Mayrhofer CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] Review of draft-ietf-doh-dns-over-https-04 Thread-Index: AQHTwgTZbfyj/LwYUE2fJEakfilxAaPhnnSA Date: Sun, 25 Mar 2018 16:30:27 +0000 Message-ID: <715DB690-12D4-474C-8D60-FA03E6E9CA19@icann.org> References: 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.47.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] Review of draft-ietf-doh-dns-over-https-04 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, 25 Mar 2018 16:30:32 -0000 Some comments on your bigger suggested changes. On Mar 22, 2018, at 5:40 PM, Alexander Mayrhofer wrote: > - Section 5: Looking at the range of 2XX HTTP responses, i'm wondering > whether it makes sense to restrict the valid HTTP responses further? > I'm not a HTTP guru, so i'm specifically careful about this. Eg. 201 > and 202 probably don't make any sense in the context of a DNS > query/response transaction, 204 shouldn't happen if the DNS API server > provides a valid DNS response, and 205 gives me the crazy ID that this > could be used to "update" a local DNS cache with updated > information... The WG seemed hesitant to start listing speicfic types of response codes. > - Section 5, expiration: I think this should be reworded to be more > concise, i do suggest the following text: >=20 > The HTTP response freshness > lifetime ([RFC7234] Section 4.2) should SHOULD be set to expire at > the same time the first of the DNS resource record sets in the Answer s= ection > reach a 0 TTL, and MUST NOT be greater > than that indicated by the DNS resource record set with the smallest TT= L > in the DNS response. >=20 > (does the MUST NOT consider additional sections as well, or just the > answer section - clarification needed..) Your proposed text talks about the first RRset in the Answer section. Why? = If there are multiple RRsets with different TTLs, shouldn't the HTTP expira= tion be based on the shortest of them, not just the first? > Same for the remaining freshness text - all sections, or just "answer" se= ction? I used the Answer section because it is the one that is likely to be put in= to a cache. The data from the other sections might be used by the recursive= , but are unlikely to be put in the cache because of the anti-poisoning rul= es. --Paul Hoffman= From nobody Sun Mar 25 09:32:15 2018 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 DDBF4127869 for ; Sun, 25 Mar 2018 09:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01] 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 CxtqOb50JWJw for ; Sun, 25 Mar 2018 09:32:12 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 4D256127136 for ; Sun, 25 Mar 2018 09:32:12 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id e79so20424222ioi.7 for ; Sun, 25 Mar 2018 09:32:12 -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=3UG4QU4MQmDsLjESKZrOHtW4qQROTxfD1466HLCLg/g=; b=fo2EfasPv71xJOLZieDnLH4351rP4UBsoGYeDoWGFnA4ybHmqPFZMgG5jVrTATWSXk mvsqlUPsYL59lBXeAt7BC9OM/gr379mvCoa+eKp3qV/6RbQ8vFf7iZjGXO3i7VmCOSI3 GGyWRovgdU5+41pktmGq9fuTEedZqv1+TbaRyTGC7v2fLUn+4STDs1EeXfRDseIciRqs 0Iu0RYbnhc0mq6mbbs9FMgJ7ZL0zT4bEvPLG/F0xpHT941ffUYeuOrWVL2PZlwVZEQnP bqNceW4rwz2cnKSZoUOvIWI20t/iM5RG2fEAbvHrb+VNoYTY7lY+5uoaM8vRnTk7VO9A XPuA== 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=3UG4QU4MQmDsLjESKZrOHtW4qQROTxfD1466HLCLg/g=; b=eWAeC1wqBOw0S0zKx96LwBrx7uUIUsCRmbvUTPYzOwv4+fvLOYboFQaoHjJfTZS+jU zQtXen2fVNGHDh3b1YQmGzAnJREaZ+rsWyuU8N9ogqV5WRhaMjcnRzTRLfG9Mfo84odR 6kfSkizmGPoClStWbODs7FMm2N3k+Scw1cWivkLF28+ssObRgoyAexyrYFxssyBEUb3a E2QjhQtt4w1EfWtIS0JejGyPrj4nkfpZQXOkEkKeI2+PFOxivBC9vo3yYZjd5Pn2UDhR 0yDzqfYPIGbIstW8G3WiB3CTGxMDLc88PvmDfrGa0ckXk7Ir3KMCq3XNmfwGmj2ZkmGp nTPA== X-Gm-Message-State: AElRT7HEAfKitTZQBNbwMxsQZdyNYNSBOO//B4IVNmUPgkmP8XlZobm7 AMnx7hgLDzxyEM5ZxRqk3irkixtOYnbQVBCzOIVWhRNl X-Google-Smtp-Source: AIpwx4+tbH0R3AV7qM+sST2W0aKy4J+nCez9RmvJ8MjxGwXVoukIlj/+PG6HC4dZoohbtcrB0qArHlTuSjnYErMi66g= X-Received: by 10.107.174.102 with SMTP id x99mr9466514ioe.18.1521995530881; Sun, 25 Mar 2018 09:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Sun, 25 Mar 2018 09:32:10 -0700 (PDT) From: Ben Schwartz Date: Sun, 25 Mar 2018 12:32:10 -0400 Message-ID: To: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11449fe403319005683f3357" Archived-At: Subject: [Doh] Consensus confirmation 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, 25 Mar 2018 16:32:14 -0000 --001a11449fe403319005683f3357 Content-Type: multipart/alternative; boundary="001a11449fe4f840f405683f3233" --001a11449fe4f840f405683f3233 Content-Type: text/plain; charset="UTF-8" Hi DOH, At the meeting in London last week, we asked the room for opinions on two topics: 1. Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. 2. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus. --Ben --001a11449fe4f840f405683f3233 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi DOH,

At the meeting in London last w= eek, we asked the room for opinions on two topics:

1. Should we have a content-type that is Mandatory to Implement?

Several participants spoke in favor of making the default f= ormat (currently called "application/dns-udpwireformat") mandator= y, at least for servers.

2. Among the GET and POST= modes of operation, which, if any, should be mandatory to implement?
=

Among the participants, there was consensus in favor of= making both GET and POST mandatory to implement for servers.
If you would like to voice a dissenting opinion on either point= , please reply on this list.=C2=A0 Otherwise, the chairs will regard these = decisions as the group's consensus.

--Ben
--001a11449fe4f840f405683f3233-- --001a11449fe403319005683f3357 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDjEC14/uSOtr9tineMIHe8 M4Frdv/WMB0EpRxJS7IdbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMjUxNjMyMTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAakAgzHigMf2MgnY3ksZemX3/1toiHzvOcM6v8DSS OQGk2g9x7IF39vnhXzZsF38oKFFJLoUnlkYRNlGx1YjRuz6c37hvNz1MCXtWTv1A8b3X9s7v1kUW McGtqniTUcJVuI0fphYpB3PG8JoYfTmED4VAgaQhJ5gExFewhAJgMyAvEF8gq+IPpdoSnQko5hFb I+GwcOsE7hg22hIVAZ05ajDia0ju2ANFTniWONhNPeQB3SnsZRCwJRzqaeaxapQiIsuyWKPRpSOE xLXnJ1QYbnmyVIwKAy9wQho6RwZw0lPpwxot+VFbbdcTDbzQljmqelst2eXyhKby9KdWh/zLwQ== --001a11449fe403319005683f3357-- From nobody Sun Mar 25 13:18:44 2018 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 664D9129515 for ; Sun, 25 Mar 2018 13:18:43 -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 ERoLAMwcyUyF for ; Sun, 25 Mar 2018 13:18:41 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 6DB22128C0A for ; Sun, 25 Mar 2018 13:18:41 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id r30-v6so18489833otr.2 for ; Sun, 25 Mar 2018 13:18:41 -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=xoVawogxP6XgxZGpQoI0veIZ2wK1nG4+KN9rbxd+WFA=; b=RcAA1xFimHbFG+yjS5KSDTTRM15YYNZxEX2QRxDvDw+sQFBN35WxPsDJQ1cdALDDh+ 5lkSvpEh+OlPSC7tkp//JG+skGr1zG9YJyzjcYjJDsw6WjyRRk+Y9vjHf0Pl5MFhVjYW bVgqBHc6kO4mVAXItJ6BmRWTnhKdhiMRtEKsNVWdcJgC1v+BQ4NzhZo5yWq/ysm2Qz8s uTa3pkyC6ZCa36abMdk7FQUlTbSUj8f6WZIE6X1pcYFBMQKTIFjafxz/o+07QzIq+LVV rNgORdpuL0Uan+ahhpIXnRUgaPLxvoRniinYcs1IODmS42lKTEQwrLGbef51+HY3Kovr P7rQ== 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=xoVawogxP6XgxZGpQoI0veIZ2wK1nG4+KN9rbxd+WFA=; b=g1Ebw1CrLnic31x8CpyvfEgacgqCMY7PN3Z+5va4sQu+2omB0E9nvN6z/5mnuGSKYd PyaWMLMfCMJ2CNYgbqN0m2HKTATMuWSPJZhwkJjkZTI6MJQ9aUR3vAx/0rr0NWf6ed9z Av3UwaS7m4JuFMzAwMReuD0IhkxRttpX74xc2UmtnOUGtXPdxv78MAlaMl2iJIY5kFua fYYPV9nz125z+SUmbEudkUcHVY7TPfLSDL6lWU7YAjFnm4X7dWdGCjpV8etcuf9+pSUE FrwYd92qV/y2eDdFW6yfsiz4snvVWfmblcmFV0L5sbbbode7ZZn+LA+c3hgJsJ62X7iW K9Bw== X-Gm-Message-State: AElRT7H2pYObrCE8ZZwFt9Y2mOlVjFgC8Q5ET+Q8LQgOmhlpVoOO1fEP hLYRS9vpXJEW6+xHExYR9MMmfZuqfRTRsKiGKn4= X-Google-Smtp-Source: AIpwx4/0g3oIZNJjxPYyUM2729rZFKB9Lk9zQoRdMef+uBLqGY6bWdHnfhz2OUqgdYos6i3ESGFK7Bd7veUOz0pJOuA= X-Received: by 2002:a9d:57c4:: with SMTP id q4-v6mr3421434oti.47.1522009120847; Sun, 25 Mar 2018 13:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.155.70 with HTTP; Sun, 25 Mar 2018 13:18:40 -0700 (PDT) In-Reply-To: <715DB690-12D4-474C-8D60-FA03E6E9CA19@icann.org> References: <715DB690-12D4-474C-8D60-FA03E6E9CA19@icann.org> From: Alexander Mayrhofer Date: Sun, 25 Mar 2018 21:18:40 +0100 Message-ID: To: Paul Hoffman Cc: "doh@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] Review of draft-ietf-doh-dns-over-https-04 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, 25 Mar 2018 20:18:43 -0000 On Sun, Mar 25, 2018 at 5:30 PM, Paul Hoffman wrote: >> - Section 5, expiration: I think this should be reworded to be more >> concise, i do suggest the following text: >> >> The HTTP response freshness >> lifetime ([RFC7234] Section 4.2) should SHOULD be set to expire at >> the same time the first of the DNS resource record sets in the Answer section >> reach a 0 TTL, and MUST NOT be greater >> than that indicated by the DNS resource record set with the smallest TTL >> in the DNS response. >> >> (does the MUST NOT consider additional sections as well, or just the >> answer section - clarification needed..) > > Your proposed text talks about the first RRset in the Answer section. Why? If there are multiple RRsets with different TTLs, shouldn't the HTTP expiration be based on the shortest of them, not just the first? It was meant to be a temporal, not spatial "first" ("first .. to reach a 0 TTL") - so we mean the same thing (I believe "first" was already in the text, but there was a third clause in that sentence that confused me). Anyways - the gist is, it should be set so that the HTTP response freshness lifetime expires before any of the DNS RRsets expire. >> Same for the remaining freshness text - all sections, or just "answer" section? > > I used the Answer section because it is the one that is likely to be put into a cache. The data from the other sections might be used by the recursive, but are unlikely to be put in the cache because of the anti-poisoning rules. Understood! Alex From nobody Sun Mar 25 13:42:42 2018 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 1AB53126D85 for ; Sun, 25 Mar 2018 13:42:40 -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 A8yeyS6uBPyU for ; Sun, 25 Mar 2018 13:42:37 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 83F23126579 for ; Sun, 25 Mar 2018 13:42:37 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id d1so4875474wrj.13 for ; Sun, 25 Mar 2018 13:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3q2mhHehku9oZsOyTaRlcmJYgA83IbfnCdNaWuI1tlk=; b=R4BhvXTOUxjaeDoiZSX64WLEiStDIoTx/fnCwYDMrr8sBKLlN4AT2zAVvdgaK82wfP ZtDq338mba2KRmu/A3bvY9vIDoGcTy9i+z1/8Wr4MLViRIM0Mt91HIsCNgE3JPMkbOIT gtODtl+XIEIhE+WXAddog+aB/tctft5tqkABj8NvtNUuVvlQL8XF5hgU2kfBQoa5W4iY kfYKCggy77bgoJ+pOPH5CIoP8EIcwuGqfxI2IV09u5MA5eQUZaB63XWfFtaMj6lrVxPg zKcY380o4exVr69sF1L3VtQJ1bnUWvl4XNJ1EhbeHoMio2qwE+YwH5GUdGJJWgio2fZx TNwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3q2mhHehku9oZsOyTaRlcmJYgA83IbfnCdNaWuI1tlk=; b=r+fI7ofB8gcyer/a7hKrPh1AKOle3PaROAeKftrVkd8Kk1lJHPXlK2M5oLKlvaR/+t scEY1mwYj7vBzjqqqfyuznHx3tii8dLM2zmV3D25FLtFcDBiEZF6LpFafEhJI8983KKG zx4RPxB1q+t9Cf7zqK8NyxHRZUV1yiCzZDWZpQpayCzU/8qSNX2vF55gRoOpFOBaSqGj 831iLaqkvuvviwTZnlyK9pkuEeFMaIdCGATjWRwmNfQxl4v0fKcQ1ONtQ/nu3NA3gLPB 9WjsugxYgvOKskYtY0rGZUyIpDymKg4/ptTioWqKMTaye/a1PhcaWIEETqFM7w6Y7dPs DG5Q== X-Gm-Message-State: AElRT7HlffPWmOzWdB9V9HVST3KD0wzn34sXs11OOf5zEmke8n9W9o4V mBp4EcdLM+W9RTwsu5LxNGkzVw== X-Google-Smtp-Source: AG47ELvpoaekuMAoFS4MAucVWWXlyDul6UINsoSFdPAc3Tjt9W+B5cdtz+H75BwAn/u5NuYt4snIuw== X-Received: by 10.223.130.102 with SMTP id 93mr26777816wrb.97.1522010555505; Sun, 25 Mar 2018 13:42:35 -0700 (PDT) Received: from raspberrypi ([2a02:c7f:629:a400:350:885e:dce0:c58d]) by smtp.gmail.com with ESMTPSA id 140sm14401872wmy.38.2018.03.25.13.42.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 13:42:35 -0700 (PDT) Date: Sun, 25 Mar 2018 20:42:32 +0000 From: Thomas Peterson To: doh@ietf.org Message-ID: <20180325204158.GA6688@raspberrypi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Doh] Consensus confirmation 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, 25 Mar 2018 20:42:40 -0000 I vote that servers MUST implement GET, but MAY implement POST. Not all implementations will find implmenting multiple methods straightfoward. Regards On Sun, Mar 25, 2018 at 12:32:10PM -0400, Ben Schwartz wrote: > Hi DOH, > > At the meeting in London last week, we asked the room for opinions on two > topics: > > 1. Should we have a content-type that is Mandatory to Implement? > > Several participants spoke in favor of making the default format (currently > called "application/dns-udpwireformat") mandatory, at least for servers. > > 2. Among the GET and POST modes of operation, which, if any, should be > mandatory to implement? > > Among the participants, there was consensus in favor of making both GET and > POST mandatory to implement for servers. > > If you would like to voice a dissenting opinion on either point, please > reply on this list. Otherwise, the chairs will regard these decisions as > the group's consensus. > > --Ben > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Sun Mar 25 13:46:58 2018 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 B8BB2126D85 for ; Sun, 25 Mar 2018 13:46:56 -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 (1024-bit key) header.d=cloudflare.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 E8U6o-kB4o_T for ; Sun, 25 Mar 2018 13:46:54 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 64586126579 for ; Sun, 25 Mar 2018 13:46:54 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id r82so11949677wme.0 for ; Sun, 25 Mar 2018 13:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sIdwNCkgMShQ4tQVv62SlDXUW1TH9zvlxOS5LrjeFtg=; b=qomETDstNC8CwvYalteG5zUaaWRvmFcErLgXeotEcnMk5+nuhlOsRF2y/f8Db9Z2Xe Q4WQBzlSz/EcewLHcMPdhZIzjSkp4s8cdlEZxTa1Iiy+Ci60dz1is/lDpttfElJF4A90 zBVj94SlQ+gXzqZb9IzoVMbFNmgdsEwU6mWZ4= 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=sIdwNCkgMShQ4tQVv62SlDXUW1TH9zvlxOS5LrjeFtg=; b=quIAFOlaeNiERasFxevBVzWqyHQOcFOSDE16QplXDda7h4rlWwKHmUSad0jnISkFcC 34Ze6SgCgz7ed/+9NFG2WA2ucrkH0J2sMuH0ViNTctWwKs3pG3vTpagwzqABBJ6YocZ6 GKgpn6XmGPaGyvCponNhmCIS2Rms6KNFwDjksg8/WIUmd7RWf/NsG4mX0yoYbwKvW4kC FkOR9p4m6IHD0Wc9rIkPurGb/UFXiEaf8QsqzB77u/cHHs7B+T1C4IFiRX0KGrNbHhdk jnQJYATsug6Xr5rF7EdmZmeIAgL58J5wS/+lABSXGBrwOUmU9Lrm97grnKNzk3yNlVor /y3w== X-Gm-Message-State: AElRT7GJ+0iznh15L6ww/NnbhQ6v7hE53pN0iZvmCMdQ6kBctfZcr+zo GWn641oa6sHWUIh74cSGxnythRDOxwxhIGHy5W7UsA== X-Google-Smtp-Source: AG47ELvpHFI8fERPWdsSNpRgbjX0gVM33wD2s9ixwCGlA0VpE5EFnll2DlWzC7UFkHsfElFp72fOcqvvWNWN0p9U3pU= X-Received: by 10.28.109.88 with SMTP id i85mr13069734wmc.150.1522010812804; Sun, 25 Mar 2018 13:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.41 with HTTP; Sun, 25 Mar 2018 13:46:52 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Sun, 25 Mar 2018 21:46:52 +0100 Message-ID: To: Ben Schwartz Cc: DoH WG Content-Type: multipart/alternative; boundary="001a1147c456d78749056842c1c5" Archived-At: Subject: Re: [Doh] Consensus confirmation 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, 25 Mar 2018 20:46:57 -0000 --001a1147c456d78749056842c1c5 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 25, 2018 at 5:32 PM, Ben Schwartz wrote: > Hi DOH, > > At the meeting in London last week, we asked the room for opinions on two > topics: > > 1. Should we have a content-type that is Mandatory to Implement? > > Several participants spoke in favor of making the default format > (currently called "application/dns-udpwireformat") mandatory, at least > for servers. > My understanding was that the name was to be "application/dns-wireformat" and I support it to be mandatory. > > 2. Among the GET and POST modes of operation, which, if any, should be > mandatory to implement? > > Among the participants, there was consensus in favor of making both GET > and POST mandatory to implement for servers. > > If you would like to voice a dissenting opinion on either point, please > reply on this list. Otherwise, the chairs will regard these decisions as > the group's consensus. > Both is fine, but have slight preference for "POST is MUST and GET is SHOULD " Olafur > > --Ben > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --001a1147c456d78749056842c1c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 25, 2018 at 5:32 PM, Ben Schwartz <bemasc@google.com&g= t; wrote:
Hi DOH,=

At the meeting in London last week, we asked the room f= or opinions on two topics:

1. Should we have a con= tent-type that is Mandatory to Implement?

Several = participants spoke in favor of making the default format (currently called = "application/dns-udpwireformat") mandatory, at least for ser= vers.

My understanding was that= the name was to be "application/dns-wireformat"=C2=A0
= and I support it to be mandatory.=C2=A0=C2=A0

2. Among the GET and POST modes= of operation, which, if any, should be mandatory to implement?
<= br>
Among the participants, there was consensus in favor of makin= g both GET and POST mandatory to implement for servers.

If you would like to voice a dissenting opinion on either point, plea= se reply on this list.=C2=A0 Otherwise, the chairs will regard these decisi= ons as the group's consensus.

Both is fine, but have slight preference for "POST is MUST and GET = is SHOULD "

Olafur
=C2=A0
=

--Ben

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


--001a1147c456d78749056842c1c5-- From nobody Sun Mar 25 13:48:15 2018 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 8564C126D85 for ; Sun, 25 Mar 2018 13:48:13 -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 (1024-bit key) header.d=cloudflare.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 Jc9zsRfiG7_c for ; Sun, 25 Mar 2018 13:48:11 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 3D6A0126579 for ; Sun, 25 Mar 2018 13:48:11 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id u11so4599559wri.12 for ; Sun, 25 Mar 2018 13:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JPffiSTrL2C8UoT9zxLwt2bJ87gY47WBjEoFLoO9ZJs=; b=jqWls0rstV0ix3EfW8PjYCLlBp+Jn5xVgruuHRSUbNgtI7BXViwfd3lnFgN1jjNauU lr+DdL2HZa3++yrZqBClZnKJxQfp4BFe9SrUR8NhNuIRUiYZUxy3nTLV0NqkAWnm6Vlr thcGg/ZqHb2PdCyqwBQD0SiYJCdq1dvsjSHNU= 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=JPffiSTrL2C8UoT9zxLwt2bJ87gY47WBjEoFLoO9ZJs=; b=t1GnTwP6JBwYqFX6dyIMQh5NxwBQY4WYVVkTnwdBnWoDEvtggjYLutb5AVYbi/T8oK VjvpHIkL8Pcm4jeT6CKeNbSVsbZSY03wdk7Lzou5nf1DdS4s6iXUFtWvcdOQ4XG3EoOs z5p8z2hVQOby5h75VfVwxoM6js/50avOfprRj40LgCKmpfdNgS7thfgn5szSkUhLJFUX XE3vZAe2bpINIQJ/tRohrHx18uv9qdyyc8QvAwCBkzS3lrNjv7JQxh/BeSjvgw6vm0k7 FkGzoKoE886zwKN/c7AxvsKHDVccbNMdIDaJml8JMjpu7HVP75GDPh9H40C7lRQSMgPp gaUg== X-Gm-Message-State: AElRT7ECDXRPexfKq6cj8QVEqQ6MdFvTA6tkwGh5cXB7RUNOTsMsDvXN nXlZ3xIsyyHez3mmQ1Fi6RiciTuO+lKHuDcV2YGhvdpy X-Google-Smtp-Source: AG47ELtny0d9ofRAPqb8b4p4E3vKUuA4IfDOGp79nYeSn5OwbwYaUcfqEaHj3Soq5EaHR1jdeeGDwTnLwwkWC0WMStk= X-Received: by 10.223.154.47 with SMTP id z44mr25979677wrb.239.1522010889703; Sun, 25 Mar 2018 13:48:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.169.41 with HTTP; Sun, 25 Mar 2018 13:48:09 -0700 (PDT) In-Reply-To: <97DE40CC-7B70-42F7-9FF5-B78F17CB7818@icann.org> References: <97DE40CC-7B70-42F7-9FF5-B78F17CB7818@icann.org> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Sun, 25 Mar 2018 21:48:09 +0100 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="f403045f4c206ce97d056842c604" Archived-At: Subject: Re: [Doh] Proposed text for dealing with the old UDP 512-byte limitation and truncation 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, 25 Mar 2018 20:48:14 -0000 --f403045f4c206ce97d056842c604 Content-Type: text/plain; charset="UTF-8" text looks good On Sun, Mar 25, 2018 at 5:10 PM, Paul Hoffman wrote: > Please see > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/120/files > So that we don't get two threads of comments, please send them here to the > list. > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f403045f4c206ce97d056842c604 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
text looks good=C2=A0


On Sun, Mar 25, 2018 at 5:10 PM, = Paul Hoffman <paul.hoffman@icann.org> wrote:
Please see
=C2=A0 =C2=A0https://github.com= /dohwg/draft-ietf-doh-dns-over-https/pull/120/files
So that we don't get two threads of comments, please send them here to = the list.

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

--f403045f4c206ce97d056842c604-- From nobody Sun Mar 25 22:25:30 2018 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 2C61C1252BA for ; Sun, 25 Mar 2018 22:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 y_Xyg6CyF5Ii for ; Sun, 25 Mar 2018 22:25:28 -0700 (PDT) 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 31E33120047 for ; Sun, 25 Mar 2018 22:25:28 -0700 (PDT) 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, 25 Mar 2018 22:25:26 -0700 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, 25 Mar 2018 22:25:26 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: [Ext] [Doh] Consensus confirmation Thread-Index: AQHTxFbYsQ9E3J/CBUiMSvMzE1ngdKPiclkA Date: Mon, 26 Mar 2018 05:25:25 +0000 Message-ID: References: In-Reply-To: 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.47.234] Content-Type: multipart/signed; boundary="Apple-Mail=_B3DBCEA6-D385-44DD-8ECE-F1926A3E10FB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Consensus confirmation 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, 26 Mar 2018 05:25:29 -0000 --Apple-Mail=_B3DBCEA6-D385-44DD-8ECE-F1926A3E10FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 1. Should we have a content-type that is Mandatory to Implement? >=20 > Several participants spoke in favor of making the default format = (currently called "application/dns-udpwireformat") mandatory, at least = for servers. application/dns-udpwireformat needs to be mandatory to implement for us = to have maximum interoperability out of the box. > 2. Among the GET and POST modes of operation, which, if any, should be = mandatory to implement? >=20 > Among the participants, there was consensus in favor of making both = GET and POST mandatory to implement for servers. Both GET and POST need to be mandatory to implement for servers so that = we have maximum interoperability out of the box. --Paul HOffman --Apple-Mail=_B3DBCEA6-D385-44DD-8ECE-F1926A3E10FB 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----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlq4hEQACgkQsZnCoeEP RXsW2ggAqJZpKnp8rJmCR/oGbIyILsF601ZwRjpaD8tW3LMWv46FCJznuLxeWC/o MaFbLztX1/5C7BBqhjAkXsyHeiyc7pN8tX3JDVrpCxNJvFpwm2ix9PBftXbXm8Ki yCBD9uShhus7i7AyM+l1kQgQQhH2mwikf/CwhEEcdNUvhbt5KY1IcHWX0uiVFYVe riEzuMdCDQ5P3Ttsao+CH84NM1Y8QiHCAXTmmgDTRFsW6oDiWmQl7qMOgE9NUccn 6NwnfkbACVy5OuCgGh8bqj6fA1T4qPqHxy6EpHHdsYUvXLa+dJLvHU3ePIYxsPqV eXD2HqfB8Q1MFz5XCf6BTLxT1E9Dmw== =j1r+ -----END PGP SIGNATURE----- --Apple-Mail=_B3DBCEA6-D385-44DD-8ECE-F1926A3E10FB-- From nobody Sun Mar 25 22:48:27 2018 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 8A48D126BF6; Sun, 25 Mar 2018 22:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Jnmrf6uynRls; Sun, 25 Mar 2018 22:48:17 -0700 (PDT) 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 99E471252BA; Sun, 25 Mar 2018 22:48:17 -0700 (PDT) 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, 25 Mar 2018 22:48:15 -0700 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, 25 Mar 2018 22:48:15 -0700 From: Paul Hoffman To: DoH WG , dnsop Thread-Topic: Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http Thread-Index: AQHTxMYIRqZcpUF5Mk2GmIIpkmEjNg== Date: Mon, 26 Mar 2018 05:48:15 +0000 Message-ID: <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> In-Reply-To: <5AB3E3B7.3080607@redbarn.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.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <9303D6EC79B4A243B13982468DC6EA65@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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, 26 Mar 2018 05:48:19 -0000 Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new = media type seems like overkill, particularly given that it will be transpor= ting *the exact same* data as an existing media type. Instead, an optional = parameter could be added to the application/dns-udpwireformat registration = in the DOH document. Proposal: =3D=3D=3D=3D=3D In the media type definition, change "Optional parameters" to: Optional parameters: original_transport original_transport has two defined values, "udp" and "tcp". This is only expected to be used by servers. Also in the the DOH document, under Operational Considerations, we would ad= d: This protocol does not define any use for the original_transport optional parameter of the application/dns-udpwireformat media type.=20 =3D=3D=3D=3D=3D Then draft-ietf-dnsop-dns-wireformat-http could define the use of that opti= onal parameter as it sees fit. --Paul Hoffman From nobody Sun Mar 25 23:08:38 2018 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 0448C127058; Sun, 25 Mar 2018 23:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 lHoRJu_Rgvo8; Sun, 25 Mar 2018 23:08:34 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACBA126E01; Sun, 25 Mar 2018 23:08:34 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427] (unknown [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AB60C7594C; Mon, 26 Mar 2018 06:08:34 +0000 (UTC) Message-ID: <5AB88E60.5010007@redbarn.org> Date: Sun, 25 Mar 2018 23:08:32 -0700 From: Paul Vixie User-Agent: Postbox 5.0.24 (Windows/20180302) MIME-Version: 1.0 To: Paul Hoffman CC: DoH WG , dnsop References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> In-Reply-To: <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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, 26 Mar 2018 06:08:36 -0000 Paul Hoffman wrote: > Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining > a new media type seems like overkill, particularly given that it will > be transporting *the exact same* data as an existing media type. > Instead, an optional parameter could be added to the > application/dns-udpwireformat registration in the DOH document. > > Proposal: > > ===== > > In the media type definition, change "Optional parameters" to: > > Optional parameters: original_transport original_transport has two > defined values, "udp" and "tcp". This is only expected to be used by > servers. s/servers/proxies/ > Also in the the DOH document, under Operational Considerations, we > would add: > > This protocol does not define any use for the original_transport > optional parameter of the application/dns-udpwireformat media type. > > ===== > > Then draft-ietf-dnsop-dns-wireformat-http could define the use of > that optional parameter as it sees fit. so this would look like content-type: application/dns-udpwireformat; tcp ? -- P Vixie From nobody Sun Mar 25 23:53:16 2018 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 8E682126BF6 for ; Sun, 25 Mar 2018 23:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 axzuuZoYY6CD for ; Sun, 25 Mar 2018 23:53:14 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 316DC126B72 for ; Sun, 25 Mar 2018 23:53:14 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id n40-v6so2587909otd.3 for ; Sun, 25 Mar 2018 23:53:14 -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; bh=RgqBy3VeH6Hm7kZTR82nvJBvAubjM6IWj4cvZg2NmsQ=; b=Glg1EPebsP/M5EtkM4Z54rRzcYhPk4+9izcOnXNHbbrzsJ2Uh8yU/un4905OerLjV3 9P25Z9mq55+BjtAfPAuQnal2q0sphbAqzWifcUAphYyB7kyHXbPFMCOoYlS2TEnt28/I 66MUIQBanZ4XY7tx83tDSjktrvbAt1EN5YHOVoQGi3K9rbp+h7SfGtxs/qLF82DAakd1 PJlp81BbCxdECbKwRnLYZy0nuNQfuU88T45dWI0SHaIw5RhqJrcb8+PTXzS45z7jHAZn U/3y0n8PyvODdaIe97gZdxUJVAxeWbNFbq0QrkMOkCjsDAwulKsFBUd2zh9s/xAGgXxR XEzQ== 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=RgqBy3VeH6Hm7kZTR82nvJBvAubjM6IWj4cvZg2NmsQ=; b=KOZNnY814gRbF1MEH2mx/DFPsnWrv19uCdejCFJONO92E0hwnVnKlMX4I2MJ6IMxh6 58NeDK2H0zYvFnlxuq6xIr/zBX4SLbIK3R5pHu1JsRCDNDXzTopBuH+QGjbWEPuOU7xp g1gcZMxlC7oi1Asxwrv7MV9G08SW4xDJU2kdm9pa/ag5VpbF3DsOBxAFi/fGo+Pj+xEK swaQH2i6xJE9twt+TB60aTmzjHi/G+T6MPL7OmX67xYq6f9DnLf6jKSWfBoH4NVX3/Mj XGDO/E2hOZDXEJocYZmlszvIZV4vDJoArjyfxNN54ZGde5QimGYNi7Y/3gk5qwyhkP2y NpEA== X-Gm-Message-State: AElRT7GELyKAMd0bxeYvwREdsRSiqjTjOE5S0pN35e7aWL6qMKkDpyzf k0EHFC0V/J1IMgfyISJSfLRxZNfbaU9QbXjuPtY= X-Google-Smtp-Source: AIpwx49nloLQTdgzCaX1PaDyb3Vewx3AQl4etGsOY25Pw67poM+MXFknnuIxPuEvs/BvaHx9rX8YhpkePxIrVRqgOX0= X-Received: by 2002:a9d:70c7:: with SMTP id w7-v6mr11145205otj.183.1522047193389; Sun, 25 Mar 2018 23:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.155.70 with HTTP; Sun, 25 Mar 2018 23:53:13 -0700 (PDT) In-Reply-To: References: From: Alexander Mayrhofer Date: Mon, 26 Mar 2018 07:53:13 +0100 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Doh] Fwd: Consensus confirmation 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, 26 Mar 2018 06:53:16 -0000 FYI, sent that to Ben only.. ---------- Forwarded message ---------- From: Alexander Mayrhofer Date: Mon, Mar 26, 2018 at 7:52 AM Subject: Re: [Doh] Consensus confirmation To: Ben Schwartz On Sun, Mar 25, 2018 at 5:32 PM, Ben Schwartz wrote: > 1. Should we have a content-type that is Mandatory to Implement? Yes, the currently existing "application/dns-udpwireformat" should be the MTI format for both clients and servers. Other formats MAY be supported. > 2. Among the GET and POST modes of operation, which, if any, should be > mandatory to implement? Both GET and POST should be MTI for servers. For reason of interopability, clients hence MUST implement at least one of either GET or POST, even if potential future methods are defined. best, Alex From nobody Sun Mar 25 23:54:59 2018 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 2308A126BF6 for ; Sun, 25 Mar 2018 23:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHTs5Fjp0XXS for ; Sun, 25 Mar 2018 23:54:56 -0700 (PDT) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CA8126B72 for ; Sun, 25 Mar 2018 23:54:56 -0700 (PDT) Received: from [79.124.59.194] (helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1f0M2f-0002ve-NU for doh@ietf.org; Mon, 26 Mar 2018 06:55:41 +0000 To: doh@ietf.org References: From: Shane Kerr Message-ID: Date: Mon, 26 Mar 2018 06:54:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Consensus confirmation 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, 26 Mar 2018 06:54:58 -0000 All, Paul Hoffman: >> 1. Should we have a content-type that is Mandatory to Implement? >> >> Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. > > application/dns-udpwireformat needs to be mandatory to implement for us to have maximum interoperability out of the box. > >> 2. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? >> >> Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. > > Both GET and POST need to be mandatory to implement for servers so that we have maximum interoperability out of the box. I agree on both counts. Otherwise we are dooming every client ever written from now until the end of time to either: * Have a little dance trying to figure out server capabilities, or * Rely on the lowest-common denominator. Cheers, -- Shane From nobody Mon Mar 26 00:45:30 2018 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 A2BE71243F6 for ; Mon, 26 Mar 2018 00:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 1FmVbgGLau31 for ; Mon, 26 Mar 2018 00:45:22 -0700 (PDT) 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 AB3A21200C5 for ; Mon, 26 Mar 2018 00:45:22 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 5A2A9242147B; Mon, 26 Mar 2018 07:45:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Jim Reid In-Reply-To: Date: Mon, 26 Mar 2018 08:45:18 +0100 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Shane Kerr X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [Ext] Consensus confirmation 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, 26 Mar 2018 07:45:29 -0000 > On 26 Mar 2018, at 07:54, Shane Kerr = wrote: >=20 >> Both GET and POST need to be mandatory to implement for servers so = that we have maximum interoperability out of the box. >=20 > I agree on both counts. Otherwise we are dooming every client ever > written from now until the end of time to either: >=20 > * Have a little dance trying to figure out server capabilities, or > * Rely on the lowest-common denominator. Me too! From nobody Mon Mar 26 00:56:28 2018 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 9199A126DED for ; Mon, 26 Mar 2018 00:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] 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 g9e-VXumGVyq for ; Mon, 26 Mar 2018 00:56:20 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 E49BE1200C5 for ; Mon, 26 Mar 2018 00:56:19 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id p142-v6so26703325lfd.6 for ; Mon, 26 Mar 2018 00:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XSePwJdcCVHVgCydF8bcDSyqkYZhOKvMNgaJg/LArQY=; b=CtBpeb9/MDoXFisnD4NLSU09+OxAwukfsVdCqbHqkfXJTapmy32yRY00nBRSRiwWuy ViE3ar3Zqj+NCOIU7ONBUchtcCUesU/pLNHoTFVU09hJ7fXLV8GJAyirAGzaj9Eep6sX 4LZi82MGAJxv4rbZYNkOXTmtA8vfc2ucWJkpeVjszj+Qd6cZz6gryKP3/Hlabk2cO3uV FHSWUlPvJxtlqifUp0mlYj9du2hWZy2zTn60r3SFtDpK0IvZKiPqFScPSK/2TOwn1UIq 68jDDDGUIqHUw58jE2XvRNKP17MrI1hvOTjimTzSbk4ba5lknY+W57y7SsztjjAznw/e B1Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XSePwJdcCVHVgCydF8bcDSyqkYZhOKvMNgaJg/LArQY=; b=ftU7NWCuxdVrWJTFUYh74egAbEkSyw3hkn13X6iZC6rcKYhm8h3HxB2dqlSS38RhMN w3L2+QjYSltFk8jpX4GVRQv1GeZJ41fOKewobgJxhws0cA7osI0n3Q7+i7igGnkv1otF AicbjUhL3ZurEqONEkx8OGYPxZrzOZw6mG9GxUKAsT9cwdZOhXjmi0qwE4hr9/xVrY/e qhm3wr6h3qUpBjcjqRj6dTl9/Z7uYi5hbHYNTbv8PO0MPaquiDpbKjYg2OJksOjMEUNP pykgiTQIJRnvctOZBfG+x7ihYKP8oSCqqEEkM/2po6NLcmxs6r1xK5iTsDnuL9Cuym+8 yNSQ== X-Gm-Message-State: AElRT7FHdLsjLuF2awgRfqH+Yi2IDN4JJk/5W2tX0qHZtn1R/K3QBT6O YOMg6GLDafdLdE0ZN6SC98lxAXJWc0VnFb1+Uuc= X-Google-Smtp-Source: AG47ELto8wJz+irbXEc/xQnoJhXWOIUjmfqUjSMlOVryQjJdIakcqms/WJNno99YtTVhazuPAL8De+yzT20bJP2pu7E= X-Received: by 2002:a19:136a:: with SMTP id j103-v6mr24853982lfi.19.1522050978099; Mon, 26 Mar 2018 00:56:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: manu tman Date: Mon, 26 Mar 2018 07:56:07 +0000 Message-ID: To: Ben Schwartz Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000e137d805684c1be7" Archived-At: Subject: Re: [Doh] Consensus confirmation 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, 26 Mar 2018 07:56:22 -0000 --000000000000e137d805684c1be7 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 25, 2018 at 6:32 PM Ben Schwartz wrote: > Hi DOH, > > At the meeting in London last week, we asked the room for opinions on two > topics: > > 1. Should we have a content-type that is Mandatory to Implement? > > Several participants spoke in favor of making the default format > (currently called "application/dns-udpwireformat") mandatory, at least for > servers. > Server must implement application/dns-(udp)?wireformat and client will be able to choose whatever they want but can rely on wire format > > 2. Among the GET and POST modes of operation, which, if any, should be > mandatory to implement? > > Among the participants, there was consensus in favor of making both GET > and POST mandatory to implement for servers. > Yes, server must implement both and client is free to choose. Manu > > If you would like to voice a dissenting opinion on either point, please > reply on this list. Otherwise, the chairs will regard these decisions as > the group's consensus. > > --Ben > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000e137d805684c1be7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Mar 25, 2018 = at 6:32 PM Ben Schwartz <bemasc@goo= gle.com> wrote:
Hi DOH,=

At the meeting in London last week, we asked the room f= or opinions on two topics:

1. Should we have a con= tent-type that is Mandatory to Implement?

Several = participants spoke in favor of making the default format (currently called = "application/dns-udpwireformat") mandatory, at least for servers.=


=
Server must implement application/dns-(udp)?wirefor= mat and client will be able to choose whatever they want but can rely on wi= re format

2. Among the GET and POST modes of operation, which, if any, should = be mandatory to implement?

Among the participants,= there was consensus in favor of making both GET and POST mandatory to impl= ement for servers.

Yes, server must implement both and client is free to choose.=

Manu

If you would like to = voice a dissenting opinion on either point, please reply on this list.=C2= =A0 Otherwise, the chairs will regard these decisions as the group's co= nsensus.

--Ben
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000e137d805684c1be7-- From nobody Mon Mar 26 01:30:52 2018 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 0E59112D945 for ; Mon, 26 Mar 2018 01:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 t2uTUKuIcH38 for ; Mon, 26 Mar 2018 01:30:40 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 96DE71205F0 for ; Mon, 26 Mar 2018 01:30:33 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C3CD32801C2; Mon, 26 Mar 2018 10:30:31 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id BE145280291; Mon, 26 Mar 2018 10:30:31 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id B78152801C2; Mon, 26 Mar 2018 10:30:31 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B49BB6423521; Mon, 26 Mar 2018 10:30:31 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id AD3AA40FAD; Mon, 26 Mar 2018 10:30:31 +0200 (CEST) Date: Mon, 26 Mar 2018 10:30:31 +0200 From: Stephane Bortzmeyer To: Martin Thomson Cc: doh@ietf.org Message-ID: <20180326083031.2bco57z33vyty766@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.052913, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.26.82117 Archived-At: Subject: Re: [Doh] New query formats 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, 26 Mar 2018 08:30:47 -0000 On Thu, Mar 22, 2018 at 02:32:40PM +0000, Martin Thomson wrote a message of 45 lines which said: > 3. Specify that other parameters can be used to carry information > about queries. Servers that find unknown query parameters MUST ignore > them. > > 4. Define a new registry for header field parameters. (The URI > template would have covered this neatly, so you could avoid that.) Yes, RFC 6570 is the right way to specify these parameters. You can get some inspiration from my (old) DNS looking glass: http://www.bortzmeyer.org/dns-lg-usage.html From nobody Mon Mar 26 01:33:16 2018 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 559941205F0 for ; Mon, 26 Mar 2018 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 Q7CtJxIX2TRP for ; Mon, 26 Mar 2018 01:33:14 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 10C9B1204DA for ; Mon, 26 Mar 2018 01:33:14 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 93F4A280286; Mon, 26 Mar 2018 10:33:12 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 8DBF1280292; Mon, 26 Mar 2018 10:33:12 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 86FE2280286; Mon, 26 Mar 2018 10:33:12 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 841446423521; Mon, 26 Mar 2018 10:33:12 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 7C5CD40FAD; Mon, 26 Mar 2018 10:33:12 +0200 (CEST) Date: Mon, 26 Mar 2018 10:33:12 +0200 From: Stephane Bortzmeyer To: Paul Hoffman Cc: Alexander Mayrhofer , "doh@ietf.org" Message-ID: <20180326083312.6objbqfuzcc3rjyx@nic.fr> References: <715DB690-12D4-474C-8D60-FA03E6E9CA19@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <715DB690-12D4-474C-8D60-FA03E6E9CA19@icann.org> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.26.82117 Archived-At: Subject: Re: [Doh] [Ext] Review of draft-ietf-doh-dns-over-https-04 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, 26 Mar 2018 08:33:15 -0000 On Sun, Mar 25, 2018 at 04:30:27PM +0000, Paul Hoffman wrote a message of 38 lines which said: > > 204 shouldn't happen if the DNS API server provides a valid DNS > > response, and 205 gives me the crazy ID that this could be used to > > "update" a local DNS cache with updated information... > > The WG seemed hesitant to start listing speicfic types of response codes. I would say otherwise: some people in the WG want listing specific types of response codes, probably in a non-normative appendix, some people fear we risk to contradict HTTP RFCs when trying to restate them. AFAIK, no decision was taken yet. From nobody Mon Mar 26 01:45:31 2018 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 156171204DA for ; Mon, 26 Mar 2018 01:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 e-AT4HdpO8Jy for ; Mon, 26 Mar 2018 01:45:26 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 96B281243F6 for ; Mon, 26 Mar 2018 01:45:21 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 29079280287; Mon, 26 Mar 2018 10:45:20 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 22FFC280293; Mon, 26 Mar 2018 10:45:20 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 1C4C0280287; Mon, 26 Mar 2018 10:45:20 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 19BBF6423521; Mon, 26 Mar 2018 10:45:20 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 114DC40FAD; Mon, 26 Mar 2018 10:45:20 +0200 (CEST) Date: Mon, 26 Mar 2018 10:45:20 +0200 From: Stephane Bortzmeyer To: Ben Schwartz Cc: DoH WG Message-ID: <20180326084520.zwwfzzvvnh4vda5l@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.26.83916 Archived-At: Subject: Re: [Doh] Consensus confirmation 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, 26 Mar 2018 08:45:27 -0000 On Sun, Mar 25, 2018 at 12:32:10PM -0400, Ben Schwartz wrote a message of 158 lines which said: > 2. Among the GET and POST modes of operation, which, if any, should > be mandatory to implement? > > Among the participants, there was consensus in favor of making both > GET and POST mandatory to implement for servers. I agree with that but I note that Daniel Kahn Gillmor claimed that clients should (SHOULD?) implement both because a DoH server queried with POST may redirect you and GET be used. (301 and 302 allows that, unlike 307 and 308, RFC 7231, section 6.4.) From nobody Mon Mar 26 03:16:42 2018 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 3E0D41242F7; Mon, 26 Mar 2018 03:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ttlFjf6hpWTH; Mon, 26 Mar 2018 03:16:40 -0700 (PDT) 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 53492127077; Mon, 26 Mar 2018 03:16:40 -0700 (PDT) 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; Mon, 26 Mar 2018 03:16:38 -0700 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; Mon, 26 Mar 2018 03:16:38 -0700 From: Paul Hoffman To: Paul Vixie CC: dnsop , DoH WG Thread-Topic: [Ext] Re: [Doh] [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http Thread-Index: AQHTxMYJjiIeoO0puk2SlNzAM+KuJqPifYgAgABFTwA= Date: Mon, 26 Mar 2018 10:16:38 +0000 Message-ID: <9DBF114F-C361-475B-867E-B49DF3B4DB5A@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <5AB88E60.5010007@redbarn.org> In-Reply-To: <5AB88E60.5010007@redbarn.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.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F7481E926EDFB4CB9049A333FD55DE4@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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, 26 Mar 2018 10:16:41 -0000 On Mar 26, 2018, at 7:08 AM, Paul Vixie wrote: > Paul Hoffman wrote: >> Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining >> a new media type seems like overkill, particularly given that it will >> be transporting *the exact same* data as an existing media type. >> Instead, an optional parameter could be added to the >> application/dns-udpwireformat registration in the DOH document. >>=20 >> Proposal: >>=20 >> =3D=3D=3D=3D=3D >>=20 >> In the media type definition, change "Optional parameters" to: >>=20 >> Optional parameters: original_transport original_transport has two >> defined values, "udp" and "tcp". This is only expected to be used by >> servers. >=20 > s/servers/proxies/ Maybe? I can't tell from the current draft if a proxy client would need to = send a transport type. >> Also in the the DOH document, under Operational Considerations, we >> would add: >>=20 >> This protocol does not define any use for the original_transport >> optional parameter of the application/dns-udpwireformat media type. >>=20 >> =3D=3D=3D=3D=3D >>=20 >> Then draft-ietf-dnsop-dns-wireformat-http could define the use of >> that optional parameter as it sees fit. >=20 > so this would look like >=20 > content-type: application/dns-udpwireformat; tcp Not quite. content-type: application/dns-udpwireformat; original_transport=3Dtcp --Paul Hoffman= From nobody Mon Mar 26 06:07:35 2018 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 AAE44127137 for ; Mon, 26 Mar 2018 06:07:33 -0700 (PDT) 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 4mfWqtXmELKJ for ; Mon, 26 Mar 2018 06:07:32 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 246F21201FA for ; Mon, 26 Mar 2018 06:07:32 -0700 (PDT) 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]:38549) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f0RqU-000F8F-95 (Exim 4.89_2) for doh@ietf.org (return-path ); Mon, 26 Mar 2018 14:07:30 +0100 Date: Mon, 26 Mar 2018 14:07:30 +0100 From: Tony Finch To: DoH WG In-Reply-To: Message-ID: References: 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] [Ext] Consensus confirmation 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, 26 Mar 2018 13:07:34 -0000 Paul Hoffman wrote: > application/dns-udpwireformat needs to be mandatory to implement for us > to have maximum interoperability out of the box. > > Both GET and POST need to be mandatory to implement for servers so that > we have maximum interoperability out of the box. +1 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Faeroes, Southeast Iceland: Easterly or southeasterly 6 to gale 8. Moderate or rough, occasionally very rough. Occasional drizzle. Good, occasionally poor. From nobody Tue Mar 27 13:46:04 2018 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 1D46B12E8A8 for ; Tue, 27 Mar 2018 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 n5_JyieBI40m for ; Tue, 27 Mar 2018 13:45:55 -0700 (PDT) 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 16C2312E04D for ; Tue, 27 Mar 2018 13:45:55 -0700 (PDT) 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 w2RKjrwH071044 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 27 Mar 2018 15:45:54 -0500 (CDT) (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 From: Adam Roach To: "doh@ietf.org" Message-ID: <1a24d4e7-5465-975b-e3c6-3752fb57c779@nostrum.com> Date: Tue, 27 Mar 2018 15:45:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Doh] Clarification re: "Opportunistic 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: Tue, 27 Mar 2018 20:46:03 -0000 I'm posting this in my role as AD, to get information that might help us figure out next steps regarding the "Opportunistic DNS" [1] work that was discussed in London. Note that the "Opportunistic DNS" work remains out of scope for DOH: I'm posting here because this list has the correct community of interest. During last week's discussion in DOH regarding techniques for proactively pushing DNS records to endpoints [2], there were several comments at the microphone that make me think there are important and subtle issues that were not completely obvious. Specifically: while the slides and proponent were careful to talk about DNSSEC, TLS certificate validation, and "additional validation checks" for received information, there were at least two independent comments at the microphone that expressed concerns about cache poisoning. There were also multiple comments (one at the mic, one after the meeting) expressing concerns that DNSSEC doesn't provide the right kind of assurances necessary to validate records received from untrusted sources. If the DNS experts on this list could expand on the concerns about poisoning in the context of DNSSEC, it would be greatly appreciated. Feel free to reply directly to me, or on-list. Thanks! /a ___ [1] I'm carefully using quotation marks here to indicate what it was called in the meeting, with the explicit recognition that this name is considered problematic by some. [2] Presentation at https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-opportunistic-dns-00 From nobody Tue Mar 27 15:54:23 2018 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 38258126CB6 for ; Tue, 27 Mar 2018 15:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, T_RP_MATCHES_RCVD=-0.01, 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 xPq3GZRzF5K1 for ; Tue, 27 Mar 2018 15:54:19 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B998B1200C1 for ; Tue, 27 Mar 2018 15:54:19 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id y20-v6so1218909itc.5 for ; Tue, 27 Mar 2018 15:54:19 -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 :cc; bh=cLrXzfnZXeyuPf798qXqJ7fRiJlpLbSAd1sFSpX6W0Y=; b=Tmfb9dQpeviyK19fMPDQLQHNQuJsBlJKNSVROuIQXZZdT5FN4vUpxlsygHN8J7zceQ lTJViqTZc+RQa+QeWzCiw/NuaSOgbDWoLuXLgqD8GpqwoMA071+bvVG9nDSP7Nxc90jI OAkgK5WbQWpxW2g6iC+yN5Tpz/D2hMd3mXk8k/O2UMyvBbyckXAXAK0Z0Chpb1ryjm3P SZMAsSsvLW0g9kaXa1a+CcKyeE2v1ZA/OPTt8EZRwzasYLjDQlbwE6uzH9k3ZZlCA+uD 2IRroIk8fuLSFhihnkvxplYGh1czIgqrLqGtd67uxBd79eoSjfwb4TfOvCYInauP4vFO OngA== 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=cLrXzfnZXeyuPf798qXqJ7fRiJlpLbSAd1sFSpX6W0Y=; b=rlrvpgphyXcPu5qHjUP0ecGv5Y1gHFPqFyaJAz5BWPp0WRClIAXWS3fpNS5ZTA1yN/ 8KS7jhnakpY4YmQeYbUxguqTkLwBNj84KT99jdyZZO6LZs4jlq4gDrJAz9CmGfeuIONF c/m77No4cWYZpHEP0zz89Vv6vJCoNPAeeE/rDLcjSNPaxfZ6zJot0TG8kdT4Eyiwsm7o XeqsIwFi2hQCwE8E8j4KCrnp7zqzYz1lJGk+paGLmrnGouG/kCzYkOXWSrD4tp9J2P6L hxmwDTfRJqa54/Opzjxp74dkOkqLa5c3rM1By7CEdF6HStP45oNBri0JBEBgcFZUZZxs XgOg== X-Gm-Message-State: ALQs6tAgmCoJHy2FD50wfqG9R8osE6zVgZwQhdfYksROkGFzKirohl8b WZU9ADFmmS6W7YIf22sVav9vXwMDah62VrJX/Knsn8IV X-Google-Smtp-Source: AIpwx48JptgVfhwzQgBKfZw58Hmw512ydgvhWWZG+QPIGbwsw7tjImMTpLG/OA+FzKDOZ294Q4/C6Pn/vwTRxaIsBiA= X-Received: by 2002:a24:3715:: with SMTP id r21-v6mr1178602itr.110.1522191258649; Tue, 27 Mar 2018 15:54:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.168.210 with HTTP; Tue, 27 Mar 2018 15:54:18 -0700 (PDT) In-Reply-To: <1a24d4e7-5465-975b-e3c6-3752fb57c779@nostrum.com> References: <1a24d4e7-5465-975b-e3c6-3752fb57c779@nostrum.com> From: Ben Schwartz Date: Tue, 27 Mar 2018 18:54:18 -0400 Message-ID: To: Adam Roach Cc: "doh@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000004a5c1205686cc50f" Archived-At: Subject: Re: [Doh] Clarification re: "Opportunistic 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: Tue, 27 Mar 2018 22:54:22 -0000 --0000000000004a5c1205686cc50f Content-Type: multipart/alternative; boundary="000000000000411b2005686cc595" --000000000000411b2005686cc595 Content-Type: text/plain; charset="UTF-8" I'm not a DNS expert, but I've had a lot of time to think about this. To me, in the context of the web, the most interesting concerns are about scoping and lifetime. For example, as a web server operator, if I can populate a user's DNS cache with some distinctive (but valid, signed) DNS records, then perhaps I can follow that user across the web, effectively "marking" their traffic until the RRSIGs expire. I think we can remove this problem by scoping opportunistic records to the client IP address that received them, so their use doesn't link two client IP addresses. (This resembles QUIC's issues with connection IDs.) There's also a similar problem related to same-origin user tracking. I think that will require us to treat opportunistic DNS records like cookies, and to clear them in similar situations. Another concern is related to bad server selection. Could a rogue actor use an ad network to push suboptimal records to millions of users, breaking a target site's load balancing? I'm less concerned about this, especially thanks to redirection tools like Alt-Svc, but it is worth some careful attention. On Tue, Mar 27, 2018 at 4:45 PM, Adam Roach wrote: > I'm posting this in my role as AD, to get information that might help us > figure out next steps regarding the "Opportunistic DNS" [1] work that was > discussed in London. Note that the "Opportunistic DNS" work remains out of > scope for DOH: I'm posting here because this list has the correct community > of interest. > > During last week's discussion in DOH regarding techniques for proactively > pushing DNS records to endpoints [2], there were several comments at the > microphone that make me think there are important and subtle issues that > were not completely obvious. > > Specifically: while the slides and proponent were careful to talk about > DNSSEC, TLS certificate validation, and "additional validation checks" for > received information, there were at least two independent comments at the > microphone that expressed concerns about cache poisoning. There were also > multiple comments (one at the mic, one after the meeting) expressing > concerns that DNSSEC doesn't provide the right kind of assurances necessary > to validate records received from untrusted sources. > > If the DNS experts on this list could expand on the concerns about > poisoning in the context of DNSSEC, it would be greatly appreciated. Feel > free to reply directly to me, or on-list. > > Thanks! > > /a > > ___ > [1] I'm carefully using quotation marks here to indicate what it was > called in the meeting, with the explicit recognition that this name is > considered problematic by some. > > [2] Presentation at https://datatracker.ietf.org/m > eeting/101/materials/slides-101-doh-opportunistic-dns-00 > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000411b2005686cc595 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not a DNS expert, but I've had a lot of t= ime to think about this.

To me, in the context of the w= eb, the most interesting concerns are about scoping and lifetime.=C2=A0 For= example, as a web server operator, if I can populate a user's DNS cach= e with some distinctive (but valid, signed) DNS records, then perhaps I can= follow that user across the web, effectively "marking" their tra= ffic until the RRSIGs expire.=C2=A0 I think we can remove this problem by s= coping opportunistic records to the client IP address that received them, s= o their use doesn't link two client IP addresses.=C2=A0 (This resembles= QUIC's issues with connection IDs.)

There's als= o a similar problem related to same-origin user tracking.=C2=A0 I think tha= t will require us to treat opportunistic DNS records like cookies, and to c= lear them in similar situations.

Another concern i= s related to bad server selection.=C2=A0 Could a rogue actor use an ad netw= ork to push suboptimal records to millions of users, breaking a target site= 's load balancing?=C2=A0 I'm less concerned about this, especially = thanks to redirection tools like Alt-Svc, but it is worth some careful atte= ntion.


=
On Tue, Mar 27, 2018 at 4:45 PM, Adam Roach <ada= m@nostrum.com> wrote:
I'= ;m posting this in my role as AD, to get information that might help us fig= ure out next steps regarding the "Opportunistic DNS" [1] work tha= t was discussed in London. Note that the "Opportunistic DNS" work= remains out of scope for DOH: I'm posting here because this list has t= he correct community of interest.

During last week's discussion in DOH regarding techniques for proactive= ly pushing DNS records to endpoints [2], there were several comments at the= microphone that make me think there are important and subtle issues that w= ere not completely obvious.

Specifically: while the slides and proponent were careful to talk about DNS= SEC, TLS certificate validation, and "additional validation checks&quo= t; for received information, there were at least two independent comments a= t the microphone that expressed concerns about cache poisoning. There were = also multiple comments (one at the mic, one after the meeting) expressing c= oncerns that DNSSEC doesn't provide the right kind of assurances necess= ary to validate records received from untrusted sources.

If the DNS experts on this list could expand on the concerns about poisonin= g in the context of DNSSEC, it would be greatly appreciated. Feel free to r= eply directly to me, or on-list.

Thanks!

/a

___
[1] I'm carefully using quotation marks here to indicate what it was ca= lled in the meeting, with the explicit recognition that this name is consid= ered problematic by some.

[2] Presentation at https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-opportunistic-dns-00

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

--000000000000411b2005686cc595-- --0000000000004a5c1205686cc50f 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD26U3eVHK2FPC4C8MgQ3Qe CwnoO5iDuENdJZghi2eYKDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAzMjcyMjU0MTlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAEprszjHxYZ+GPNpIgSls1pMZlQB0+SsU5xqNCXfx IKhhQXe604XgXbKoKO//DhqbSbaN5g9x6er/Ban+rgJAVFFyf0kjZG+XG/OiETikYa2JJFpgwyF/ qEMKQGI5D20Oj8sOSNiR+3QEBT8sq94GHs44WAgDsg+rlAIWJDIHYm/DJfcAW6HGMQUYHvVEVcqS 7nac0/+omB4a8bV4fBq5jdLHvbvQMndR2TWpeS0R9SWePMQxOdBWJecnvnZMFNt03pBpakMIt9ru OQG8dMbCfwYRneRUxiNPfLNbKZos0ZsH4t+f3EbzG+MCyauHj+X9tIEXGHem28FQSH9rqTlOaQ== --0000000000004a5c1205686cc50f-- From nobody Tue Mar 27 20:03:50 2018 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 02B64126BF3 for ; Tue, 27 Mar 2018 20:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 6GYIL5EEFY8X for ; Tue, 27 Mar 2018 20:03:47 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 47BFD120724 for ; Tue, 27 Mar 2018 20:03:47 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w2S1jA8Y037299 for ; Tue, 27 Mar 2018 21:54:22 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2gyxn2jv2v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 27 Mar 2018 21:54:22 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w2S1sLZp014601 for ; Tue, 27 Mar 2018 21:54:21 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w2S1sIWP014583 for ; Tue, 27 Mar 2018 21:54:18 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id BB768400042E for ; Wed, 28 Mar 2018 01:54:18 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27129.vci.att.com (Service) with ESMTPS id ABAC040006A1 for ; Wed, 28 Mar 2018 01:54:18 +0000 (GMT) Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.209]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0361.001; Tue, 27 Mar 2018 21:54:18 -0400 From: "HANSEN, TONY L" To: "doh@ietf.org" Thread-Topic: subscribe Thread-Index: AQHTxjeu5BawjSLzT0yOKYfXbx9w6A== Date: Wed, 28 Mar 2018 01:54:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.5.18] Content-Type: multipart/alternative; boundary="_000_B79C10C1344A460C8C42F17AE19F67BBattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-27_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=373 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803280015 Archived-At: Subject: [Doh] subscribe 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, 28 Mar 2018 03:03:49 -0000 --_000_B79C10C1344A460C8C42F17AE19F67BBattcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo= --_000_B79C10C1344A460C8C42F17AE19F67BBattcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_B79C10C1344A460C8C42F17AE19F67BBattcom_-- From nobody Wed Mar 28 11:42:30 2018 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 0EAA81271DF for ; Wed, 28 Mar 2018 11:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 x4AiHKaE-Mql for ; Wed, 28 Mar 2018 11:42:27 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B311201F2 for ; Wed, 28 Mar 2018 11:42:26 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 41DB23A2BC; Wed, 28 Mar 2018 14:42:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23227.57872.252828.797452@gro.dd.org> Date: Wed, 28 Mar 2018 14:42:24 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <1a24d4e7-5465-975b-e3c6-3752fb57c779@nostrum.com> References: <1a24d4e7-5465-975b-e3c6-3752fb57c779@nostrum.com> Archived-At: Subject: [Doh] Clarification re: "Opportunistic 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: Wed, 28 Mar 2018 18:42:29 -0000 Adam Roach writes: > If the DNS experts on this list could expand on the concerns about > poisoning in the context of DNSSEC, it would be greatly appreciated. > Feel free to reply directly to me, or on-list. Honestly, I'm curious what the rationale *in the context of DNSSEC* is as well, since from my point of view, what DNSSEC is giving you is an indication that the records from the authority are authentic no matter which way you got them, whether through your own iteration or on a sheet of paper that that the RFC 2549 pigeon brought you. The Chain Query extension works under the very same principle: you configure a trust anchor as the starting point, and are provided all of the necessary chain-of-trust records necessary to validate the final answer -- records which almost certainly all came from different administrative authorities. From nobody Fri Mar 30 01:53:06 2018 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 7B5DC126C83; Fri, 30 Mar 2018 01:53:05 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 d5FOoSsiVuFY; Fri, 30 Mar 2018 01:53:03 -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 3594B1201F8; Fri, 30 Mar 2018 01:53:03 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id n64so1526512vkf.12; Fri, 30 Mar 2018 01:53: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=XIUoIjw2io0KVcgZiwE7VffnirPfgIRnXARG0fZwas8=; b=NRzoBpqicf6zUaO/kc1hdeexU4VRp7rIU7HYtmkwBFdm2Wm7R/YTan/f1NL9HBuVfI 2Lbv0V2oH9Y06FWVC34j9MlKt0q0d0YuWl+UazSsM4BZjG4ORKrBynIS5sxFSCUmeSK5 avfWWcLs8lOPnXV1jj7fOzT0yosI2Fmx6kKx0bdasJ/fPc23OAT5CejTGe5hLspwboaS f+18TCkNeDZ7oazytA3LQWdLJ/bZ41IGMUF3rbG7fldIp8WlQrdvWleTB0ubSgMyH1an OYSYpw7/JL7kTQw0Ol+OheiL5e3+msVth8CBo8DNsJNVXm4PTsZOMyKfg2RL1Et90AOH 88lg== 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=XIUoIjw2io0KVcgZiwE7VffnirPfgIRnXARG0fZwas8=; b=PEXBMg7XpEJkcgkpbsumawmLhV1oZY4KJQSqpTD6dubjrICyYJNfDawTKxhvaZ9aDx EnU47/ivlzZhafX+8sf9pbPNa0x91jQS0/nyynraeGweGR7cPlgyyFDLoLeEP9gTO/xX 6IBBb/mJv/f6ku8mXpEuugEBXe3T43XrEms1xh1NixQbRYFlvhXfji8BA0eckvTL7Xe+ 3/Y/4Awdc84aV4Zq7eJDCyffwAgC+EEqLpS0Jv3E1+ksHT1uT1FCwvPEMVzx3CgP6TCw l/EiEYK+z1Ltym5aG0dvTBnTr4Cg4KGX5yrqaujJejFD7E8tZV/YsI/q8INU9uA86iBe zeEg== X-Gm-Message-State: AElRT7HY/8Q4F1rBwwJ2S2XM+QQ/HRr7q8vfw2mkctDnTYrTWlFP7okF KBZp6HzZ06/vYtyLBDvUWFeXoDJv0mljkj1XW1g= X-Google-Smtp-Source: AIpwx49DhFktqHnK1+c83Y5Nn+G0fB+RO7xBuoyiYdD9tIXNb/+NfpDJsthdo9ceD7V2fZcELAwPxO5cwZTHOXuYYmM= X-Received: by 10.31.79.132 with SMTP id d126mr6632877vkb.174.1522399982245; Fri, 30 Mar 2018 01:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Fri, 30 Mar 2018 01:53:01 -0700 (PDT) In-Reply-To: <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> From: Davey Song Date: Fri, 30 Mar 2018 16:53:01 +0800 Message-ID: To: Paul Hoffman Cc: DoH WG , dnsop Content-Type: multipart/alternative; boundary="001a114dd4cc25dc9005689d5e74" Archived-At: Subject: Re: [Doh] [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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, 30 Mar 2018 08:53:05 -0000 --001a114dd4cc25dc9005689d5e74 Content-Type: text/plain; charset="UTF-8" Hi Paul, It sounds reasonable as we discussed before. Best regards, Davey On 26 March 2018 at 13:48, Paul Hoffman wrote: > Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a > new media type seems like overkill, particularly given that it will be > transporting *the exact same* data as an existing media type. Instead, an > optional parameter could be added to the application/dns-udpwireformat > registration in the DOH document. > > Proposal: > > ===== > > In the media type definition, change "Optional parameters" to: > > Optional parameters: original_transport > original_transport has two defined values, "udp" and "tcp". > This is only expected to be used by servers. > > Also in the the DOH document, under Operational Considerations, we would > add: > > This protocol does not define any use for the original_transport optional > parameter of the application/dns-udpwireformat media type. > > ===== > > Then draft-ietf-dnsop-dns-wireformat-http could define the use of that > optional parameter as it sees fit. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114dd4cc25dc9005689d5e74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,=C2=A0

It sounds reasonable as = we discussed before.

Best regards,
Davey=

On 26= March 2018 at 13:48, Paul Hoffman <paul.hoffman@icann.org> wrote:
Given the use case in draft-i= etf-dnsop-dns-wireformat-http, defining a new media type seems like ov= erkill, particularly given that it will be transporting *the exact same* da= ta as an existing media type. Instead, an optional parameter could be added= to the application/dns-udpwireformat registration in the DOH document.

Proposal:

=3D=3D=3D=3D=3D

In the media type definition, change "Optional parameters" to:
Optional parameters: original_transport
=C2=A0 =C2=A0original_transport has two defined values, "udp" and= "tcp".
=C2=A0 =C2=A0This is only expected to be used by servers.

Also in the the DOH document, under Operational Considerations, we would ad= d:

This protocol does not define any use for the original_transport optional parameter of the application/dns-udpwireformat media type.

=3D=3D=3D=3D=3D

Then draft-ietf-dnsop-dns-wireformat-http could define the use of that= optional parameter as it sees fit.

--Paul Hoffman

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a114dd4cc25dc9005689d5e74-- From nobody Fri Mar 30 01:54:00 2018 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 E28D3126C83; Fri, 30 Mar 2018 01:53:53 -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, 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 JMz8ioWsPCux; Fri, 30 Mar 2018 01:53:52 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 717BE126CD6; Fri, 30 Mar 2018 01:53:52 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n20so5079316ual.7; Fri, 30 Mar 2018 01:53:52 -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=jJE4BG3OMuNVrzs1Dkj31X64qNbXITR+ubbg/b4jgMM=; b=Xsf2rXElseA+XqxWHfIFAb81Oih/hvw1VYP4y8oRVxyWYi2Z00SfJ+/+wTfEa3gwe6 MvE/APESb66BLwZWHctxtOIOB0gP+QO2SAN4s/9axXw9PiijkOQRdv/zU6VtMiKhUKRW oP1ilfj37fDCS61aSmZBU991MOZyrrpVAljJbrLt57AM4QAkHZsIl/JV3x92iqN+fN/4 Gq1mmxA3opCvjJ7MbuCyd/McefP5zAl4iFRGaFsPV8C4SV4RKVmc8XnIFBGp6d6ogYjQ wLU2PRWokB4LDZHhAZFgVG7Fes/Dk/Odn0sYbhLV+ti0xG5npOjwUbPC0leSP79JGEuG cKsQ== 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=jJE4BG3OMuNVrzs1Dkj31X64qNbXITR+ubbg/b4jgMM=; b=EEtCUvFbIHfvGe6hwcmJJrFTihftUxK0+QLf/7I0MNaVyFvYF4pMjHmENxGzxr/lnD qEQjW2ZJyVsgjpI4MHmjTEIeHg7EZnpZPEAsgjJ7fvlwIyJqdWv9k0Kq5uFTwIaITmdf 1nNp4YBZ5lvtI3YvDQVKOJT24lf9iFVG2ln0QmDkljaOrf5JDn1prl9/PvrZnnyZyj92 ooMB3Clh55US1d+S9TjsUPn2rwdEZEPbJqef8Et+Ny8zsVx0kXxwfB4+iALdsslhwbpT W4FzelG87q5sTZWvvmZ3ob5CGe+uPqcEvOBDlcZuBiicJUjw7/bPLltXYjJEY8TC6rJH nBmg== X-Gm-Message-State: AElRT7Em+RFyKjp+0SlO6FObQIQ9nA7a4CFPgmtFni8tsZg0z09n02qk ayDhmEKAoftFLRRN3gg8II7wLLpabVIVaibmlvE= X-Google-Smtp-Source: AIpwx4826KVh3mVc4wHTuRKJtBE7pZwvjruW3+7OMMDo791v/C2ro6ECSPEJZpTA2b+wnWtG/p37I4Jt7cRMohc7XLs= X-Received: by 10.176.91.13 with SMTP id u13mr7580555uae.138.1522400031575; Fri, 30 Mar 2018 01:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.43.143 with HTTP; Fri, 30 Mar 2018 01:53:51 -0700 (PDT) In-Reply-To: <9DBF114F-C361-475B-867E-B49DF3B4DB5A@icann.org> References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <5AB88E60.5010007@redbarn.org> <9DBF114F-C361-475B-867E-B49DF3B4DB5A@icann.org> From: Davey Song Date: Fri, 30 Mar 2018 16:53:51 +0800 Message-ID: To: Paul Hoffman Cc: Paul Vixie , dnsop , DoH WG Content-Type: multipart/alternative; boundary="f403045f8a7a16925505689d6106" Archived-At: Subject: Re: [Doh] [Ext] Re: [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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, 30 Mar 2018 08:53:54 -0000 --f403045f8a7a16925505689d6106 Content-Type: text/plain; charset="UTF-8" > > > Not quite. > content-type: application/dns-udpwireformat; original_transport=tcp > Yes. That's right. I will give a example like that. --f403045f8a7a16925505689d6106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Not quite.
=C2=A0 =C2=A0content-type: application/dns-udpwireformat; original_transpor= t=3Dtcp

Yes. That's right. I will g= ive a example like that.=C2=A0
--f403045f8a7a16925505689d6106-- From nobody Fri Mar 30 18:13:38 2018 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 718571242F5; Fri, 30 Mar 2018 18:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YTBgawh4mwKC; Fri, 30 Mar 2018 18:13:30 -0700 (PDT) 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 BACC9124234; Fri, 30 Mar 2018 18:13:30 -0700 (PDT) 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; Fri, 30 Mar 2018 18:13:28 -0700 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; Fri, 30 Mar 2018 18:13:28 -0700 From: Paul Hoffman To: Davey Song CC: dnsop , DoH WG Thread-Topic: [Doh] [Ext] Re: [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http Thread-Index: AQHTyASoYay6p8uEhEaWN/RESrzjVKPqAEGA Date: Sat, 31 Mar 2018 01:13:28 +0000 Message-ID: References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <23219.33838.166003.614689@gro.dd.org> <23219.56569.2064.711002@gro.dd.org> <5AB3E3B7.3080607@redbarn.org> <69AA6C5D-D348-4956-8A31-FE1EC3A2042E@icann.org> <5AB88E60.5010007@redbarn.org> <9DBF114F-C361-475B-867E-B49DF3B4DB5A@icann.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] Re: [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http 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: Sat, 31 Mar 2018 01:13:32 -0000 I have opened a pull request for this change: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/127 --Paul Hoffman