From nobody Thu May 16 13:24:27 2019 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 92C751202E0 for ; Thu, 16 May 2019 13:24:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk 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 43WTrF6SaAzi for ; Thu, 16 May 2019 13:24:19 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDCF1202E1 for ; Thu, 16 May 2019 13:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T5bB6Ut7+tq2netUXrQ1Ql0BLPJY1T8jw6bSnIJ6a0Y=; b=VEW9YVd/Z4M8DgevfE0/I1tUL4W1gjMZaPF7qhVqjRqv6LujAEtsN870xzuMZvnDXB8DUmDY4MfP8c2beolcGJGgT5pgN6tVda5+OE1E9n1uwv+1O0gy6OTzk6eijOiMKR6Ds9IqO3MxCAPke0NcG7LVxAloghGXJXa2bcOTeus= Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com (10.168.51.153) by DB6PR0601MB2421.eurprd06.prod.outlook.com (10.169.215.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Thu, 16 May 2019 20:24:08 +0000 Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54]) by DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54%3]) with mapi id 15.20.1878.024; Thu, 16 May 2019 20:24:08 +0000 From: "Winfield, Alister" To: "doh@ietf.org" Thread-Topic: Googles Experimental DoH Endpoint. Thread-Index: AQHVDCVQeEeedLcigU6Yk5iVYmPLhA== Date: Thu, 16 May 2019 20:24:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [2a02:c7d:e2db:2400:a54d:161b:5775:e7a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33b036e0-0204-4555-12d2-08d6da3c733e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0601MB2421; x-ms-traffictypediagnostic: DB6PR0601MB2421: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0039C6E5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(346002)(376002)(366004)(189003)(199004)(53936002)(6116002)(99286004)(2616005)(476003)(5660300002)(46003)(8676002)(81166006)(81156014)(1730700003)(7736002)(72206003)(478600001)(8936002)(14454004)(25786009)(74482002)(2906002)(15974865002)(86362001)(2351001)(82746002)(36756003)(102836004)(14444005)(5024004)(33656002)(6436002)(5640700003)(256004)(64756008)(6506007)(73956011)(76116006)(68736007)(71190400001)(66946007)(91956017)(66556008)(6306002)(6486002)(6512007)(66446008)(58126008)(66476007)(83716004)(2501003)(71200400001)(54896002)(6916009)(486006)(316002)(186003)(3480700005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0601MB2421; H:DB6PR0601MB2184.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: v140PqROig+psbXiN/cSdEugOqLA/dem6+K5/x9aGoDHefEKU6N6i8wsmUVTgdascHO76QP/2leDeeuAL/AwVcyEEgNbqy6NHhdhq3C6uavuopUaWPxmc6iEBgxLO/+abeG39Ay39tS1dwTbd9YjH46DPkI4tTbNoS+ORFMZwQz744pGKEi5e6j6bbUKn24v6hX7n5fFj6v9cEbNNy5/eTNfMT1U5Jb+k51ez7df6mpv0xyTank/D/9Y+WGbS8o2XYGRntgMDUxTcV4V/c+YI5nnbypx1jeaU4CigGGknot1xEKtKaQyYXwrSRAYiSNI8Ee0SXTwszhcq6ZHnJQMmxpiNCL4blZ/sCQ3tCHorgLbId2fEOCWQj74QZK19mEgtd+dEAse+SpZ7KrJZF0pkaE5bDcYt9xEvZoAc9vBWSA= Content-Type: multipart/alternative; boundary="_000_BF0C7A3C17F54BD0AD7C25922B085D23skyuk_" MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 33b036e0-0204-4555-12d2-08d6da3c733e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 20:24:08.4123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2421 Archived-At: Subject: [Doh] Googles Experimental DoH Endpoint. X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 20:24:27 -0000 --_000_BF0C7A3C17F54BD0AD7C25922B085D23skyuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b2ggYnkgdGhlIHdheSBJIG5vdGljZWQgdGhpcyBhbmQgaXQgc2VlbXMgY291bnRlciB0byB0aGUg Y2xhaW0gb2YgRG9IIG9ubHkgcnVubmluZyBvbiA4LjguOC44Lg0KDQoNClRvIGtlZXAgaXQgc2hv cnQgSeKAmXZlIHJlbW92ZWQgdGhlIFNTTCBzZXR1cCBzdGVwIGZyb20gdGhlIGV4YW1wbGUuDQoN Cg0KDQokIG9wZW5zc2wgc19jbGllbnQgLWNvbm5lY3Qgc2VhcmNoLmdvb2dsZS5jb206NDQzIC1z ZXJ2ZXJuYW1lIHNlYXJjaC5nb29nbGUuY29tDQoNCuKApg0KDQotLS0NCg0KDQoNCkdFVCAvZXhw ZXJpbWVudGFsP2Rucz1BQUFCQUFBQkFBQUFBQUFBQTNkM2R3ZGxlR0Z0Y0d4bEEyTnZiUUFBQVFB QiBIVFRQLzEuMQ0KDQpob3N0OiBkbnMuZ29vZ2xlLmNvbQ0KDQoNCg0KSFRUUC8xLjEgMjAwIE9L DQoNClN0cmljdC1UcmFuc3BvcnQtU2VjdXJpdHk6IG1heC1hZ2U9MzE1MzYwMDA7IGluY2x1ZGVT dWJEb21haW5zOyBwcmVsb2FkDQoNCkFjY2Vzcy1Db250cm9sLUFsbG93LU9yaWdpbjogKg0KDQpE YXRlOiBUdWUsIDE0IE1heSAyMDE5IDEzOjQ5OjUzIEdNVA0KDQpFeHBpcmVzOiBUdWUsIDE0IE1h eSAyMDE5IDEzOjQ5OjUzIEdNVA0KDQpDYWNoZS1Db250cm9sOiBwcml2YXRlLCBtYXgtYWdlPTIw NTk1DQoNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vZG5zLW1lc3NhZ2UNCg0KU2VydmVyOiBI VFRQIHNlcnZlciAodW5rbm93bikNCg0KQ29udGVudC1MZW5ndGg6IDQ5DQoNClgtWFNTLVByb3Rl Y3Rpb246IDANCg0KWC1GcmFtZS1PcHRpb25zOiBTQU1FT1JJR0lODQoNCkFsdC1TdmM6IHF1aWM9 Ijo0NDMiOyBtYT0yNTkyMDAwOyB2PSI0Niw0NCw0MywzOSINCg0KDQoNCj8/d3d3ZXhhbXBsZWNv bT8NCg0KICAgICAgICAgICAgICAgIFBzXT8/Il5DDQoNCiQNCg0KDQpUcmllZCBhIGZldyBtb3Jl IGdtYWlsLmdvb2dsZS5jb20sIHd3dy55b3V0dWJlLmNvbSwgbmV3cy5nb29nbGUuY29tDQoNClNv IEkgZ3Vlc3MgaXTigJlzIHRoZWlyIGVudGlyZSB3ZWIgZXN0YXRlDQoNCi0tDQpBbGlzdGVyIFdp bmZpZWxkLg0KSW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1 c2l2ZWx5IGZvciB0aGUgYWRkcmVzc2VlLiBUaGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUg b2ZmaWNpYWwgcG9saWN5LCBidXQgdGhlIHBlcnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9y LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLiBZb3Ug c2hvdWxkIG5vdCByZXByb2R1Y2UsIGRpc3RyaWJ1dGUsIHN0b3JlLCByZXRyYW5zbWl0LCB1c2Ug b3IgZGlzY2xvc2UgaXRzIGNvbnRlbnRzIHRvIGFueW9uZS4gUGxlYXNlIG5vdGUgd2UgcmVzZXJ2 ZSB0aGUgcmlnaHQgdG8gbW9uaXRvciBhbGwgZS1tYWlsIGNvbW11bmljYXRpb24gdGhyb3VnaCBv dXIgaW50ZXJuYWwgYW5kIGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3Mg YXJlIHRyYWRlbWFya3Mgb2YgU2t5IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFu ZCBhcmUgdXNlZCB1bmRlciBsaWNlbmNlLg0KDQpTa3kgVUsgTGltaXRlZCAoUmVnaXN0cmF0aW9u IE5vLiAyOTA2OTkxKSwgU2t5LUluLUhvbWUgU2VydmljZSBMaW1pdGVkIChSZWdpc3RyYXRpb24g Tm8uIDIwNjcwNzUpLCBTa3kgU3Vic2NyaWJlcnMgU2VydmljZXMgTGltaXRlZCAoUmVnaXN0cmF0 aW9uIE5vLiAyMzQwMTUwKSBhbmQgU2t5IENQIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gOTUx MzI1OSkgYXJlIGRpcmVjdCBvciBpbmRpcmVjdCBzdWJzaWRpYXJpZXMgb2YgU2t5IExpbWl0ZWQg KFJlZ2lzdHJhdGlvbiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25l ZCBpbiB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVz IGFuZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3 b3J0aCwgTWlkZGxlc2V4IFRXNyA1UUQNCg== --_000_BF0C7A3C17F54BD0AD7C25922B085D23skyuk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4g R290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6TWVubG87DQoJcGFub3NlLTE6MiAxMSA2IDkgMyA4IDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1l OnAxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjVwdDsNCglmb250LWZhbWlseTpNZW5sbzsNCgljb2xvcjpibGFjazt9DQpwLnAyLCBsaS5wMiwg ZGl2LnAyDQoJe21zby1zdHlsZS1uYW1lOnAyOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250LWZhbWlseTpNZW5sbzsNCgljb2xv cjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b2ggYnkgdGhlIHdheSBJIG5vdGljZWQgdGhp cyBhbmQgaXQgc2VlbXMgY291bnRlciB0byB0aGUgY2xhaW0gb2YgRG9IIG9ubHkgcnVubmluZyBv biA4LjguOC44LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvIGtlZXAgaXQgc2hvcnQgSeKAmXZlIHJlbW92ZWQgdGhl IFNTTCBzZXR1cCBzdGVwIGZyb20gdGhlIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+JCBvcGVuc3NsIHNfY2xpZW50IC1jb25uZWN0IHNlYXJj aC5nb29nbGUuY29tOjQ0MyAtc2VydmVybmFtZSBzZWFyY2guZ29vZ2xlLmNvbTwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+4oCmPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJwMSI+PHNwYW4gY2xhc3M9InMxIj4tLS08L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3Bh biBjbGFzcz0iczEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+ PHNwYW4gY2xhc3M9InMxIj5HRVQgL2V4cGVyaW1lbnRhbD9kbnM9QUFBQkFBQUJBQUFBQUFBQUEz ZDNkd2RsZUdGdGNHeGxBMk52YlFBQUFRQUIgSFRUUC8xLjE8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 InAxIj48c3BhbiBjbGFzcz0iczEiPmhvc3Q6IGRucy5nb29nbGUuY29tPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJwMiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNs YXNzPSJzMSI+SFRUUC8xLjEgMjAwIE9LPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4g Y2xhc3M9InMxIj5TdHJpY3QtVHJhbnNwb3J0LVNlY3VyaXR5OiBtYXgtYWdlPTMxNTM2MDAwOyBp bmNsdWRlU3ViRG9tYWluczsgcHJlbG9hZDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFu IGNsYXNzPSJzMSI+QWNjZXNzLUNvbnRyb2wtQWxsb3ctT3JpZ2luOiAqPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj5EYXRlOiBUdWUsIDE0IE1heSAyMDE5IDEzOjQ5 OjUzIEdNVDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+RXhwaXJl czogVHVlLCAxNCBNYXkgMjAxOSAxMzo0OTo1MyBHTVQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAx Ij48c3BhbiBjbGFzcz0iczEiPkNhY2hlLUNvbnRyb2w6IHByaXZhdGUsIG1heC1hZ2U9MjA1OTU8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPkNvbnRlbnQtVHlwZTog YXBwbGljYXRpb24vZG5zLW1lc3NhZ2U8L3NwYW4+PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBj bGFzcz0iczEiPlNlcnZlcjogSFRUUCBzZXJ2ZXIgKHVua25vd24pPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj5Db250ZW50LUxlbmd0aDogNDk8L3NwYW4+PC9wPg0K PHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPlgtWFNTLVByb3RlY3Rpb246IDA8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPlgtRnJhbWUtT3B0aW9uczogU0FN RU9SSUdJTjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+QWx0LVN2 YzogcXVpYz0mcXVvdDs6NDQzJnF1b3Q7OyBtYT0yNTkyMDAwOyB2PSZxdW90OzQ2LDQ0LDQzLDM5 JnF1b3Q7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJzMSI+Pz93d3dleGFtcGxlY29tPzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0icDEiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFu PjxzcGFuIGNsYXNzPSJzMSI+UHNdPz8mcXVvdDteQzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0icDEi PjxzcGFuIGNsYXNzPSJzMSI+JDwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VHJpZWQgYSBmZXcgbW9yZSA8L3NwYW4+PHNwYW4gY2xhc3M9InMxIj5nbWFp bC5nb29nbGUuY29tLCB3d3cueW91dHViZS5jb20sIG5ld3MuZ29vZ2xlLmNvbTwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+U28gSSBndWVzcyBpdOKAmXMgdGhlaXIgZW50aXJlIHdlYiBlc3RhdGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFs aXN0ZXIgV2luZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQpJbmZvcm1hdGlv biBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5IGJlIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZSBhZGRy ZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lhbCBwb2xpY3ksIGJ1 dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2UNCiBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3VsZCBub3QgcmVwcm9k dWNlLCBkaXN0cmlidXRlLCBzdG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRpc2Nsb3NlIGl0cyBj b250ZW50cyB0byBhbnlvbmUuIFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhlIHJpZ2h0IHRvIG1v bml0b3IgYWxsIGUtbWFpbCBjb21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGludGVybmFsIGFuZA0K IGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mg b2YgU2t5IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRl ciBsaWNlbmNlLg0KPGJyPg0KPGJyPg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4g MjkwNjk5MSksIFNreS1Jbi1Ib21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAy MDY3MDc1KSwgU2t5IFN1YnNjcmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBO by4gMjM0MDE1MCkgYW5kIFNreSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDk1MTMyNTkp IGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBMaW1pdGVkIChSZWdp c3RyYXRpb24NCiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBp biB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFu ZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0 aCwgTWlkZGxlc2V4IFRXNyA1UUQNCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BF0C7A3C17F54BD0AD7C25922B085D23skyuk_-- From nobody Thu May 16 15:26:24 2019 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 A3187120324 for ; Thu, 16 May 2019 15:26:22 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=cHDNumfZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fISqyGU+ 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 iawXWSetY-rG for ; Thu, 16 May 2019 15:26:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ADC1200C7 for ; Thu, 16 May 2019 15:26:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DF3942517B; Thu, 16 May 2019 18:26:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 16 May 2019 18:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=C v+X5pWmlEsW0sENXyLMFxUs2vW1G5vsFrQrvGf0Gu4=; b=cHDNumfZMiHu8Bt7A 0HtDQgMp7It5Kgpu2dUgSoDQ9qJ6bTBgv35UNGV+kbBAGl/mi80Hb0s925Mm44UT pICtJgSvBgwQJY3CpMj6UMqshJd4bQg4SzApvacqNDmkrKE9t1hyqVKj/BZGm1gY al4m3UrvaEyYCVquCqp/J2gyt23/+GdQ0FF833Rf9o/Zs5N3iOL027An4q5mPccb ReJvmz5Z52Z2DpmjnlYyMhSXhwQE2OO2qugc66uNHbPexgvdDk7VC2ZGQtdcnbIG +RtUg65AExy22NSkcyIoGqlwhgArUZcLiA9wcgu6p9bmKlX8xXoFpKWTkV+fgM8+ 3tuug== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Cv+X5pWmlEsW0sENXyLMFxUs2vW1G5vsFrQrvGf0G u4=; b=fISqyGU+nbUjnvOYeBdFGv5POrc8EvX76ZRauJPpUMGNXVFi1ij8gvzNO HW4CtI5Alo7erJRe1ho4G4JxQYKOdh8eGGfVQJOY35GJxI+dbBLYnal/Z8dJRaBp C5PBjBDTjldqwgsaiSd9icfiGghFKQszh6TlkVPVS9e6b5KX04bT9NS02YiAawSY 5tptWNGHOhZgH9g/NkQ81+6giCtfUJivklHHryDlCZ2qZ9YnP+yLu8oEqQJj+g1n TAkzY0pgdj1ez4fqGvH8tfHfjx3/h8UpQMt0NkfxD0R9bRs0COMgrGTRJzfRzdfS 4QSRksnDTYg+RjfJ85xK1KBUoRoDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddtuddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtpdduhhhoshhtughnshdrghhoohhglhgvnecukfhppedvudefrddu jeeirddugeegrdduudehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnoh htrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [10.254.236.149] (unknown [213.176.144.115]) by mail.messagingengine.com (Postfix) with ESMTPA id 40EAD8005B; Thu, 16 May 2019 18:26:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mark Nottingham In-Reply-To: Date: Thu, 16 May 2019 22:26:08 +0000 Cc: "doh@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Winfield, Alister" X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Doh] Googles Experimental DoH Endpoint. X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 22:26:23 -0000 So, you're effectively doing domain fronting here; i.e., routing to one = server name with SNI, while using a different host header. Firefox (for example) doesn't support doing this with its DoH = implementation, AFAICT; you'd have to write a custom client (or = intermediary). > On 16 May 2019, at 8:24 pm, Winfield, Alister = wrote: >=20 > $ openssl s_client -connect search.google.com:443 -servername = search.google.com > =E2=80=A6 > --- > =20 > GET /experimental?dns=3DAAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB = HTTP/1.1 > host: dns.google.com -- Mark Nottingham https://www.mnot.net/ From nobody Fri May 17 03:07:23 2019 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 254D7120147 for ; Fri, 17 May 2019 03:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk 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 DgdpWcyHOjNT for ; Fri, 17 May 2019 03:07:20 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20085.outbound.protection.outlook.com [40.107.2.85]) (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 00FD8120047 for ; Fri, 17 May 2019 03:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BxpXDl95blDKcpMvpye3nlE5HUYIrkzakPrRCS3LBt8=; b=eqUMNKObcqo5RfuvRl9p3AvZOVtxatwQbmmFmtack062r7uChlyLCAzo6LQT5JyabEPbTpiMozpDfJFvCUOsodGoQquZJJ2E2BynifUccIUprB9BmtTYJpVR/0ig4ZZFH/HUjetwihikanwj8/VhlyjQHUvJlArlVsbADBdjcR8= Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com (10.168.51.153) by DB6PR0601MB2215.eurprd06.prod.outlook.com (10.168.53.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 10:07:17 +0000 Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54]) by DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54%3]) with mapi id 15.20.1878.024; Fri, 17 May 2019 10:07:17 +0000 From: "Winfield, Alister" To: Mark Nottingham CC: "doh@ietf.org" Thread-Topic: [EXTERNAL] Re: [Doh] Googles Experimental DoH Endpoint. Thread-Index: AQHVDCVQeEeedLcigU6Yk5iVYmPLhKZuVGwAgADUoIA= Date: Fri, 17 May 2019 10:07:16 +0000 Message-ID: <758C0ED4-7136-4427-992B-038966DCDB94@sky.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [78.86.37.208] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0d6c612-bf38-4e4c-d934-08d6daaf712d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0601MB2215; x-ms-traffictypediagnostic: DB6PR0601MB2215: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(86362001)(6916009)(83716004)(68736007)(4326008)(71190400001)(66066001)(91956017)(6116002)(66574012)(45080400002)(73956011)(82746002)(25786009)(102836004)(66946007)(72206003)(6512007)(966005)(6306002)(66556008)(66476007)(71200400001)(316002)(7736002)(76116006)(305945005)(58126008)(3846002)(64756008)(66446008)(33656002)(229853002)(446003)(476003)(76176011)(478600001)(81166006)(11346002)(81156014)(2616005)(53936002)(14444005)(5024004)(486006)(256004)(8676002)(5660300002)(2906002)(8936002)(6506007)(74482002)(186003)(6486002)(26005)(99286004)(36756003)(14454004)(6246003)(6436002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0601MB2215; H:DB6PR0601MB2184.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pKJpkkGUm4N5ab3VwvpVJ9B9rwQAi9PhCC7scB/zkcw54l5cznSzIWwaKD/yhLGc7ZI0HrBsglWQ/MB88FM3NIEG4ddoJQKo4TG1CBn1cqar5IhMbK1gnRC1PUmJMhpqdnkyZHKeLiU/+t0oiuczogssd1o86RN+K5rEJDdMuSjpE/Z2p8dQ5+TjGQQHp1c9KmHna4z7GKFAsNcLT3/AgXZTmoXJPWUvebRUMS7Q8K7xVdAeJn9aeoHS/VP7ENORz4VN3XlCs35XOwkcjwLd3QVkVo3Xeo7W96RUjPAFXLjfb+ygiPioFb0C+KV0ewj43tbi6ozHsGukRMCDQfq5piKDhBXRy8IeusCztGYC1evy0mrOlWc0nIEv6rDYNa2tq9L20TB0ngy2MnOOJLwcYLcBIrJskcgMvOiUM0nViu8= Content-Type: text/plain; charset="utf-8" Content-ID: <368F531E7F76814AB54A13B14ED7B2A6@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: f0d6c612-bf38-4e4c-d934-08d6daaf712d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 10:07:16.9033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2215 Archived-At: Subject: Re: [Doh] [EXTERNAL] Re: Googles Experimental DoH Endpoint. X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 10:07:22 -0000 ICA+IE9uIDE2LzA1LzIwMTksIDIzOjI2LCAiTWFyayBOb3R0aW5naGFtIiA8bW5vdEBtbm90Lm5l dD4gd3JvdGU6DQogID4NCiAgPiAgICBTbywgeW91J3JlIGVmZmVjdGl2ZWx5IGRvaW5nIGRvbWFp biBmcm9udGluZyBoZXJlOyBpLmUuLCByb3V0aW5nIHRvIG9uZSBzZXJ2ZXIgbmFtZSB3aXRoIFNO SSwgd2hpbGUgdXNpbmcgYSBkaWZmZXJlbnQgaG9zdCBoZWFkZXIuDQogID4NCiAgPiAgICBGaXJl Zm94IChmb3IgZXhhbXBsZSkgZG9lc24ndCBzdXBwb3J0IGRvaW5nIHRoaXMgd2l0aCBpdHMgRG9I IGltcGxlbWVudGF0aW9uLCBBRkFJQ1Q7IHlvdSdkIGhhdmUgdG8gd3JpdGUgYSBjdXN0b20gY2xp ZW50IChvcg0KICA+LiAgIGludGVybWVkaWFyeSkuDQoNCg0KVGhhdCBtYXkgYmUgdHJ1ZSwgYnV0 IHRoZSBjaGFuZ2UgdG8gYWxsb3cgaXQgaW4gYSBtYWluc3RyZWFtIGNsaWVudCB3aWxsLCBpbiBt b3N0IGNhc2VzLCBiZSB0cml2aWFsIGFuZCBtYWx3YXJlIHdyaXRlcnMgcmVhbGx5IGRvbid0IGNh cmUuDQrvu78NCg0KDQogICAgPiBPbiAxNiBNYXkgMjAxOSwgYXQgODoyNCBwbSwgV2luZmllbGQs IEFsaXN0ZXIgPEFsaXN0ZXIuV2luZmllbGQ9NDBza3kudWtAZG1hcmMuaWV0Zi5vcmc+IHdyb3Rl Og0KICAgID4NCiAgICA+ICQgb3BlbnNzbCBzX2NsaWVudCAtY29ubmVjdCBzZWFyY2guZ29vZ2xl LmNvbTo0NDMgLXNlcnZlcm5hbWUgc2VhcmNoLmdvb2dsZS5jb20NCiAgICA+IOKApg0KICAgID4g LS0tDQogICAgPg0KICAgID4gR0VUIC9leHBlcmltZW50YWw/ZG5zPUFBQUJBQUFCQUFBQUFBQUFB M2QzZHdkbGVHRnRjR3hsQTJOdmJRQUFBUUFCIEhUVFAvMS4xDQogICAgPiBob3N0OiBkbnMuZ29v Z2xlLmNvbQ0KDQogICAgLS0NCiAgICBNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5v dC5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q0FsaXN0ZXIuV2luZmllbGQlNDBza3kudWslN0Mx ZDM3ZmFiNjcxZDA0Zjc2OWQwYjA4ZDZkYTRkODgyNCU3QzY4Yjg2NWQ1Y2YxODRiMmI4MmE0YTRl ZGRiOWM1MjM3JTdDMCU3QzElN0M2MzY5MzY0MjM4ODE1NjU3NTUmYW1wO3NkYXRhPVUxbWJkJTJG WVc4R3lMJTJCZnlxJTJCQWpvelQ0c2UydkUwU2k4R0c1ciUyRjBMT2olMkZVJTNEJmFtcDtyZXNl cnZlZD0wDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRl cm5hbCBzb3VyY2UuIFBsZWFzZSBkbyBub3Qgb3BlbiBhdHRhY2htZW50cyBvciBjbGljayBsaW5r cyBmcm9tIGFuIHVua25vd24gb3Igc3VzcGljaW91cyBvcmlnaW4uIFBoaXNoaW5nIGF0dGVtcHRz IGNhbiBiZSByZXBvcnRlZCBieSBzZW5kaW5nIHRoZW0gdG8gcGhpc2hpbmdAc2t5LnVrIGFzIGF0 dGFjaG1lbnRzLiBUaGFuayB5b3UNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KSW5mb3JtYXRpb24g aW4gdGhpcyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgYWRkcmVz c2VlLiBUaGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUgb2ZmaWNpYWwgcG9saWN5LCBidXQg dGhlIHBlcnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9yLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwg YW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG5vdCByZXByb2R1Y2Us IGRpc3RyaWJ1dGUsIHN0b3JlLCByZXRyYW5zbWl0LCB1c2Ugb3IgZGlzY2xvc2UgaXRzIGNvbnRl bnRzIHRvIGFueW9uZS4gUGxlYXNlIG5vdGUgd2UgcmVzZXJ2ZSB0aGUgcmlnaHQgdG8gbW9uaXRv ciBhbGwgZS1tYWlsIGNvbW11bmljYXRpb24gdGhyb3VnaCBvdXIgaW50ZXJuYWwgYW5kIGV4dGVy bmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mgb2YgU2t5 IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRlciBsaWNl bmNlLg0KDQpTa3kgVUsgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyOTA2OTkxKSwgU2t5LUlu LUhvbWUgU2VydmljZSBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIwNjcwNzUpLCBTa3kgU3Vi c2NyaWJlcnMgU2VydmljZXMgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMzQwMTUwKSBhbmQg U2t5IENQIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gOTUxMzI1OSkgYXJlIGRpcmVjdCBvciBp bmRpcmVjdCBzdWJzaWRpYXJpZXMgb2YgU2t5IExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjI0 NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFwaCBh cmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2FtZSBy ZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRXNyA1 UUQNCg== From nobody Fri May 17 03:10:35 2019 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 97242120177 for ; Fri, 17 May 2019 03:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk 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 fMptKMc8jNV2 for ; Fri, 17 May 2019 03:10:31 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::615]) (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 1FA84120131 for ; Fri, 17 May 2019 03:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C7FTyWRl7/0teV13S6W7P2vxF6tqmxwO2m1woH6Yo7o=; b=Ul+DGHYYRXACZ/eRtb5IbUtDofHb4UZr6RyUbP7dceofF+SDPnhrkErIVDmOh2MzPertbxcIU9bnwQmUuZRtRFffWsAGGZXx5WpgOkCUuFks/NqMxgb2vyAysU/n11kK1z50oHdMUWFehRoIkZZEp4ZLV8039Agj4khlF4uHq64= Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com (10.168.51.153) by DB6PR0601MB2215.eurprd06.prod.outlook.com (10.168.53.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 10:10:28 +0000 Received: from DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54]) by DB6PR0601MB2184.eurprd06.prod.outlook.com ([fe80::883b:b573:ea6d:2d54%3]) with mapi id 15.20.1878.024; Fri, 17 May 2019 10:10:28 +0000 From: "Winfield, Alister" To: Mark Nottingham CC: "doh@ietf.org" Thread-Topic: [EXTERNAL] Re: [Doh] Googles Experimental DoH Endpoint. Thread-Index: AQHVDCVQeEeedLcigU6Yk5iVYmPLhKZuVGwAgADVjIA= Date: Fri, 17 May 2019 10:10:28 +0000 Message-ID: <0F7DFD3D-18E7-4B2F-B8ED-429444FEBE78@sky.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [78.86.37.208] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c443344-007e-4993-5764-08d6daafe319 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6PR0601MB2215; x-ms-traffictypediagnostic: DB6PR0601MB2215: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(86362001)(6916009)(83716004)(68736007)(4326008)(71190400001)(66066001)(91956017)(6116002)(45080400002)(73956011)(82746002)(25786009)(102836004)(66946007)(72206003)(6512007)(966005)(6306002)(66556008)(66476007)(71200400001)(316002)(7736002)(76116006)(305945005)(58126008)(3846002)(64756008)(66446008)(33656002)(229853002)(446003)(476003)(76176011)(478600001)(81166006)(11346002)(81156014)(2616005)(53936002)(14444005)(5024004)(486006)(256004)(8676002)(5660300002)(2906002)(8936002)(6506007)(74482002)(186003)(6486002)(26005)(99286004)(36756003)(14454004)(6246003)(6436002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0601MB2215; H:DB6PR0601MB2184.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EltY2THjbFefG9lFsm1ZdmEWP45XyhipTUOTsVy76pkLa/pB7uKNAFWSd9OHsQyrh3QN1S/Qe4VyvJwFyVwgsw71AuTNX60vxx07BQ4s+n86FG9MIkivqfy7pfFa+CRmIXH+qu7Fl3k7d80HJxJT9NkDhWkriKg4VdonuMKQZmhdHfYTwrdNncmuqt2/fpGI2g5qHnlEak+aJIh/Rrdl3GMFVVKu1BO3+cB0lI05H0Qx3zbPAf30hyOf5WQlyPFpZu2tqBM3HfwfaXruTOj93lB53N8hY9yMgKMAfdR9ujTYecAvQAoSJrAmeowqPRytL4V3zDVxzO8lskT+0cBCy4DlnrjNPyqYCO3oxwpraRhf6U1y+vZWqYBKsGNI5btoRaWm/1I7EX9CSBQ7N4fQjdC5OMo5irw212Qt1zAaRII= Content-Type: text/plain; charset="utf-8" Content-ID: <18EC08ABDCFC774D9B120A75FA9A1E62@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 5c443344-007e-4993-5764-08d6daafe319 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 10:10:28.2843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2215 Archived-At: Subject: Re: [Doh] [EXTERNAL] Re: Googles Experimental DoH Endpoint. X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 10:10:33 -0000 DQoNCu+7vyAgID4gT24gMTYvMDUvMjAxOSwgMjM6MjYsICJNYXJrIE5vdHRpbmdoYW0iIDxtbm90 QG1ub3QubmV0PiB3cm90ZToNCiAgID4NCiAgID4gU28sIHlvdSdyZSBlZmZlY3RpdmVseSBkb2lu ZyBkb21haW4gZnJvbnRpbmcgaGVyZTsgaS5lLiwgcm91dGluZyB0byBvbmUgc2VydmVyIG5hbWUg d2l0aCBTTkksIHdoaWxlIHVzaW5nIGEgZGlmZmVyZW50IGhvc3QgaGVhZGVyLg0KICAgPg0KICAg PiBGaXJlZm94IChmb3IgZXhhbXBsZSkgZG9lc24ndCBzdXBwb3J0IGRvaW5nIHRoaXMgd2l0aCBp dHMgRG9IIGltcGxlbWVudGF0aW9uLCBBRkFJQ1Q7IHlvdSdkIGhhdmUgdG8gd3JpdGUgYSBjdXN0 b20gY2xpZW50IChvcg0KICAgPiBpbnRlcm1lZGlhcnkpLg0KDQogICAgT2ggYW5kIG9idmlvdXNs eSBpdCdzIHN0aWxsIHRoZSBjYXNlIHRoZSBHb29nbGUgYXJlIHN0YXRpbmcgb25lIGZhY3QsIHJl cGVhdGluZyBpdCBhdCBldmVyeSBvcHBvcnR1bml0eSB3aGlsc3QgKEkgaG9wZSBieSBhY2NpZGVu dCkgZG9pbmcgY29tcGxldGVseSB0aGUgb3Bwb3NpdGUgaW4gcmVhbGl0eS4NCg0KDQogICAgPiBP biAxNiBNYXkgMjAxOSwgYXQgODoyNCBwbSwgV2luZmllbGQsIEFsaXN0ZXIgPEFsaXN0ZXIuV2lu ZmllbGQ9NDBza3kudWtAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+ICQgb3Bl bnNzbCBzX2NsaWVudCAtY29ubmVjdCBzZWFyY2guZ29vZ2xlLmNvbTo0NDMgLXNlcnZlcm5hbWUg c2VhcmNoLmdvb2dsZS5jb20NCiAgICA+IOKApg0KICAgID4gLS0tDQogICAgPg0KICAgID4gR0VU IC9leHBlcmltZW50YWw/ZG5zPUFBQUJBQUFCQUFBQUFBQUFBM2QzZHdkbGVHRnRjR3hsQTJOdmJR QUFBUUFCIEhUVFAvMS4xDQogICAgPiBob3N0OiBkbnMuZ29vZ2xlLmNvbQ0KDQogICAgLS0NCiAg ICBNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cubW5vdC5uZXQlMkYmYW1wO2RhdGE9MDIl N0MwMSU3Q0FsaXN0ZXIuV2luZmllbGQlNDBza3kudWslN0MxZDM3ZmFiNjcxZDA0Zjc2OWQwYjA4 ZDZkYTRkODgyNCU3QzY4Yjg2NWQ1Y2YxODRiMmI4MmE0YTRlZGRiOWM1MjM3JTdDMCU3QzElN0M2 MzY5MzY0MjM4ODE1NjU3NTUmYW1wO3NkYXRhPVUxbWJkJTJGWVc4R3lMJTJCZnlxJTJCQWpvelQ0 c2UydkUwU2k4R0c1ciUyRjBMT2olMkZVJTNEJmFtcDtyZXNlcnZlZD0wDQoNCiAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIFRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRlcm5hbCBzb3VyY2UuIFBsZWFzZSBk byBub3Qgb3BlbiBhdHRhY2htZW50cyBvciBjbGljayBsaW5rcyBmcm9tIGFuIHVua25vd24gb3Ig c3VzcGljaW91cyBvcmlnaW4uIFBoaXNoaW5nIGF0dGVtcHRzIGNhbiBiZSByZXBvcnRlZCBieSBz ZW5kaW5nIHRoZW0gdG8gcGhpc2hpbmdAc2t5LnVrIGFzIGF0dGFjaG1lbnRzLiBUaGFuayB5b3UN CiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KSW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kIGlz IGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgYWRkcmVzc2VlLiBUaGUgdmlld3MgZXhwcmVz c2VkIG1heSBub3QgYmUgb2ZmaWNpYWwgcG9saWN5LCBidXQgdGhlIHBlcnNvbmFsIHZpZXdzIG9m IHRoZSBvcmlnaW5hdG9yLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG5vdCByZXByb2R1Y2UsIGRpc3RyaWJ1dGUsIHN0b3JlLCBy ZXRyYW5zbWl0LCB1c2Ugb3IgZGlzY2xvc2UgaXRzIGNvbnRlbnRzIHRvIGFueW9uZS4gUGxlYXNl IG5vdGUgd2UgcmVzZXJ2ZSB0aGUgcmlnaHQgdG8gbW9uaXRvciBhbGwgZS1tYWlsIGNvbW11bmlj YXRpb24gdGhyb3VnaCBvdXIgaW50ZXJuYWwgYW5kIGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5k IHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mgb2YgU2t5IExpbWl0ZWQgYW5kIFNreSBJbnRl cm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRlciBsaWNlbmNlLg0KDQpTa3kgVUsgTGltaXRl ZCAoUmVnaXN0cmF0aW9uIE5vLiAyOTA2OTkxKSwgU2t5LUluLUhvbWUgU2VydmljZSBMaW1pdGVk IChSZWdpc3RyYXRpb24gTm8uIDIwNjcwNzUpLCBTa3kgU3Vic2NyaWJlcnMgU2VydmljZXMgTGlt aXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMzQwMTUwKSBhbmQgU2t5IENQIExpbWl0ZWQgKFJlZ2lz dHJhdGlvbiBOby4gOTUxMzI1OSkgYXJlIGRpcmVjdCBvciBpbmRpcmVjdCBzdWJzaWRpYXJpZXMg b2YgU2t5IExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29t cGFuaWVzIG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVu Z2xhbmQgYW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBH cmFudCBXYXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRXNyA1UUQNCg== From nobody Sat May 18 16:38:27 2019 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 432B3120072 for ; Sat, 18 May 2019 16:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st 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 fxTwzwqq7Uhi for ; Sat, 18 May 2019 16:38:23 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3512004F for ; Sat, 18 May 2019 16:38:22 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id BDD573AFF7; Sun, 19 May 2019 09:38:15 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558222695; bh=FKOyS3NqjDeGvYZC7jRlxWd8w3o=; h=Comments:Received:Date:Message-ID:From:Cc:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=OjKk+nHNSzJmkfn+hqxtlneCCuFw4eDfOur4QyrEZ4vp/Du0+/XAO+wiYCXGmkNBH uwKSAKZFu6LyILm/qdP4X7rTAA6XD97zZaETj7+tzPTajyXs3p1nWKNP1gWFJARJJL z1cJkhbxLKFjH+q1bLxoXIOFeQ4TBpP9Y77TvbLs=TvbLs= Comments: QMDA 0.3a Received: (qmail 44250 invoked by uid 1001); 18 May 2019 23:38:15 -0000 Date: 18 May 2019 23:38:15 +0000 Message-ID: <20190518233815.44249.qmail@f3-external.bushwire.net> From: "Mark Delany" Cc: doh@ietf.org References: <20190418071238.68406.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190418071238.68406.qmail@f3-external.bushwire.net> Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2019 23:38:25 -0000 On 18Apr19, Mark Delany allegedly wrote: > I'm working on a proxy/server DoH implementation designed to install on CPE > The questions: I have another. ## Truncated response In the scenario where a DoH server is implemented as a HTTPS server that relays the query onto a cache, say by using nginx/ATS as HTTPS front-ends, RFC848 is silent on the matter of a truncated response coming back from the cache and passing thru the DoH server. Presumably the DoH server should simply pass the response back to the DoH client with the TC bit intact. However relegating TC handling to the DoH client can't work as the DoH client has no way to re-issue the query with an "ask the DoH server to use TCP" signal. I also worry that a dumb stub/DoH client combo could easily get in a loop as it sees the TC bit and re-issues the query gets another TC bit and re-issues the query - rinse and repeat. One solution is to have the DoH server detect TC and directly re-issue the query via TCP on behalf of the DoH client but that seems to go against the implicit design whereby a DoH server is mostly just a dumb relay rather than an intelligent intermediary. It's also unlikely to be a viable solution when using most of the off-the-shelf HTTPS front-ends. Another solution might be to have one of the DoH components arbitrarily zero the TC bit to protect agsinst dumb stubs but that doesn't seem right or resilient in terms of applications consuming the results. It seems to me that a TC response from a DoH server can never be handled correctly which probably excludes otherwise legitimate implementations which want to use off-the-shelf HTTPS front-ends. Alternatively, if TC is never allowed as a return from a DoH server it needs to be explicitly stated in the RFC or if it is allowed, provide a mechanism for the client to signal the need for a TCP re-query. For the curious, this whole question came about because I observed a TC response and a subsequent TCP re-query from a "stub" in my lab. Specifically from a macOS platform - which admittedly has an interesting relationship with client-side DNS. Nonetheless, the problem seems real enough to warrant trying to find a solution. Mark. From nobody Sat May 18 19:27:45 2019 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 8981C1200F1 for ; Sat, 18 May 2019 19:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 v9hn2S83uch6 for ; Sat, 18 May 2019 19:27:40 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 8EC3C1200E9 for ; Sat, 18 May 2019 19:27:40 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id u4so4143754uau.10 for ; Sat, 18 May 2019 19:27:40 -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=fFUEiOUEHJ+SI4w0L8h6UdRki28Dx2VD710mkmErcpQ=; b=uM/jWuj53hcAZnsmdU1z1TxSsdvoyDNOI6p4i9k++Jsih1mkiuk9BCQhaAzBeT4TS+ c2IxAMNjILZnp7Dqej/WnrzGGtAFDVta8t8tOmTyFUFhVNMmvN+6X/Y1J2MZGeAv1TOE ViHbF49BQBWXmD16GLrD63Wc+/EBxOrU7rSOohdnpD6TLMvfyu0ca2udsD2wOG5D2dN/ TYRySZro7auEkKvJUv7OpuvmdZSPNzQ8ZiwUZS/YyFANXZVO92Tg5OOglp1Gl1cpR1HZ hkSIK4sov+edSuWtyx6wQgGBghp9bsuPeqVtxmYCEPDDjOM1Qf/fABsJdysVNW0zxFoZ M+aA== 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=fFUEiOUEHJ+SI4w0L8h6UdRki28Dx2VD710mkmErcpQ=; b=F7jFsyzsM8rMGLTtM2if02HzVc5UWLo2MofEMmXj24sWI6ozK58xNuubcSO2TjntXF cHkRjtPlO97zGJp52rPaJ24jod08sPGv7zFEC3WT1AU0N2eJAGF9UMNTAsApzg8ipX8b ngQ8dsvj6SrDe665otmPOfc0vbTDql2Yyz/l6iktAIlq4wzfk3xfCpONDlk8eLOpL9x9 RfNoxOACZOA5dbuoLln+YdsO2tmG6yR9iQN/UzZywRG4D8DL2FGUcrKIHu8xOZSNhs+h XID8Pif/mZxtEu5W03iAp7cQUnPk6Qw7JnSqhf7FGiSWXBO+p/rWov00hXKemNGQdGRm Dg4g== X-Gm-Message-State: APjAAAW+V+zAotJx1zalun9hw7WrFUdgpTtjxXBwgbKjtcgPbGVDyqb4 2uptFQYjq5A2mOWiJWO5kRq4+jXvMbzoMcBgftoqf4oOfvQyTw== X-Google-Smtp-Source: APXvYqxNhlhW2FY6wq08k+V6L8BmBZB+H6NrUvO0npzolk7EAYPxCCovg0VhTekY29z9qO4vD00lqR/GCS7YwhWyZQs= X-Received: by 2002:ab0:7298:: with SMTP id w24mr8210896uao.119.1558232859235; Sat, 18 May 2019 19:27:39 -0700 (PDT) MIME-Version: 1.0 References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> In-Reply-To: <20190518233815.44249.qmail@f3-external.bushwire.net> From: Ben Schwartz Date: Sat, 18 May 2019 22:27:26 -0400 Message-ID: To: Mark Delany Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000015d9e80589345c72" Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 02:27:43 -0000 --00000000000015d9e80589345c72 Content-Type: multipart/alternative; boundary="0000000000000dc5690589345cc7" --0000000000000dc5690589345cc7 Content-Type: text/plain; charset="UTF-8" *From: *Mark Delany *Date: *Sat, May 18, 2019 at 7:38 PM *Cc: * On 18Apr19, Mark Delany allegedly wrote: > > I'm working on a proxy/server DoH implementation designed to install on > CPE > > > The questions: > > I have another. > > ## Truncated response > > In the scenario where a DoH server is implemented as a HTTPS server > that relays the query onto a cache, say by using nginx/ATS as HTTPS > front-ends, RFC848 is silent on the matter of a truncated response > coming back from the cache and passing thru the DoH server. > > Presumably the DoH server should simply pass the response back to the > DoH client with the TC bit intact. > > However relegating TC handling to the DoH client can't work as the DoH > client has no way to re-issue the query with an "ask the DoH server to > use TCP" signal. > Correct. I also worry that a dumb stub/DoH client combo could easily get in a > loop as it sees the TC bit and re-issues the query gets another TC bit > and re-issues the query - rinse and repeat. > > One solution is to have the DoH server detect TC and directly re-issue > the query via TCP on behalf of the DoH client but that seems to go > against the implicit design whereby a DoH server is mostly just a dumb > relay rather than an intelligent intermediary. I don't think the implication you describe is intended. This sort of reissuance is the expected implementation in the architecture you're describing. > It's also unlikely to > be a viable solution when using most of the off-the-shelf HTTPS > front-ends. > In practice all the various DoH implementations do not seem to have encountered a problem with this. That might be because the easiest DoH implementation is simply a wrapper around a traditional stub or recursive resolver core, which already has to handle query reissuance. Another solution might be to have one of the DoH components > arbitrarily zero the TC bit to protect agsinst dumb stubs but that > doesn't seem right or resilient in terms of applications consuming the > results. > > It seems to me that a TC response from a DoH server can never be > handled correctly which probably excludes otherwise legitimate > implementations which want to use off-the-shelf HTTPS front-ends. > > Alternatively, if TC is never allowed as a return from a DoH server it > needs to be explicitly stated in the RFC or if it is allowed, provide > a mechanism for the client to signal the need for a TCP re-query. > DoH servers are permitted to return TC responses. Clients can do whatever they like with their truncated response, which may or may not be of any use to them. Certainly a DoH server that returns TC frequently is not likely to be very useful. As RFC 8484 notes, when truncation cannot be avoided, a DoH server could use an HTTP error instead of a non-error response that has the TC bit set. For the curious, this whole question came about because I observed a > TC response and a subsequent TCP re-query from a "stub" in my > lab. Specifically from a macOS platform - which admittedly has an > interesting relationship with client-side DNS. Nonetheless, the > problem seems real enough to warrant trying to find a solution. > > > Mark. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000000dc5690589345cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
From: Mark Delany <d5e@xray.emu.st&= gt;
Date: Sat, May 18, 2019 at 7:38 PM
Cc: <doh@ietf.org>
On 18Apr19, Ma= rk Delany allegedly wrote:
> I'm working on a proxy/server DoH implementation designed to insta= ll on CPE

> The questions:

I have another.

## Truncated response

In the scenario where a DoH server is implemented as a HTTPS server
that relays the query onto a cache, say by using nginx/ATS as HTTPS
front-ends, RFC848 is silent on the matter of a truncated response
coming back from the cache and passing thru the DoH server.

Presumably the DoH server should simply pass the response back to the
DoH client with the TC bit intact.

However relegating TC handling to the DoH client can't work as the DoH<= br> client has no way to re-issue the query with an "ask the DoH server to=
use TCP" signal.

Correct.

I also worry that a dumb stub/DoH client combo could easily get in a
loop as it sees the TC bit and re-issues the query gets another TC bit
and re-issues the query - rinse and repeat.

One solution is to have the DoH server detect TC and directly re-issue
the query via TCP on behalf of the DoH client but that seems to go
against the implicit design whereby a DoH server is mostly just a dumb
relay rather than an intelligent intermediary.

<= div>I don't think the implication you describe is intended.=C2=A0 This = sort of reissuance is the expected implementation in the architecture you&#= 39;re describing.
=C2=A0
It's also unlikely to
be a viable solution when using most of the off-the-shelf HTTPS
front-ends.

In practice all the various= DoH implementations do not seem to have encountered a problem with this.= =C2=A0 That might be because the easiest DoH implementation is simply a wra= pper around a traditional stub or recursive resolver core, which already ha= s to handle query reissuance.

Another solution might be to have one of the DoH components
arbitrarily zero the TC bit to protect agsinst dumb stubs but that
doesn't seem right or resilient in terms of applications consuming the<= br> results.

It seems to me that a TC response from a DoH server can never be
handled correctly which probably excludes otherwise legitimate
implementations which want to use off-the-shelf HTTPS front-ends.

Alternatively, if TC is never allowed as a return from a DoH server it
needs to be explicitly stated in the RFC or if it is allowed, provide
a mechanism for the client to signal the need for a TCP re-query.

DoH servers are permitted to return TC responses= .=C2=A0 Clients can do whatever they like with their truncated response, wh= ich may or may not be of any use to them.=C2=A0 Certainly a DoH server that= returns TC frequently is not likely to be very useful.=C2=A0 As RFC 8484 n= otes, when truncation cannot be avoided,

   a DoH server could use an HTT=
P error instead of a non-error
   response that has the TC bit set.

For the curious, this whole question came about because I observed a
TC response and a subsequent TCP re-query from a "stub" in my
lab. Specifically from a macOS platform - which admittedly has an
interesting relationship with client-side DNS. Nonetheless, the
problem seems real enough to warrant trying to find a solution.


Mark.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000000dc5690589345cc7-- --00000000000015d9e80589345c72 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAmpUavJX8ZIxhfDwTmKUSB NkbeCjeFqiGx2VOw6YwgUjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA1MTkwMjI3MzlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAUlZa42MEefJ36gEBu4/IePJEVpt23gPCVbZ0bWqd ACLZXdoVIrXAr5zFZ6BN73NA3g3rso/QlNQsgL+G+FGdaQmx0r7Od96duqkQuAEvyZ6N4TKYj71C fLJEJlurEEMCE45VcEM5l7giWsnBelR3ozNB00uzc+6sag4XZxXtAVB/XG9H9U6+IgnXKlW+c8L1 nO3LGI8tvJRxVIyjFF/c6Y8ueXxzq/bW6vFic8wkD5U7TuejGJ++yqkTQIwo46cIq6FzD4Z1G5qO bjQz1Cq5SRe+PGN0mYWT31RLL7f4UgsuAC6VnN77FkiDGCDmTAEKVUTZPe4TJ9SKfryjFcPZFQ== --00000000000015d9e80589345c72-- From nobody Sat May 18 22:53:07 2019 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 9D06D1200E9 for ; Sat, 18 May 2019 22:53:05 -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=emu.st 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 W6dmst5bldax for ; Sat, 18 May 2019 22:53:04 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id CC87A1200B2 for ; Sat, 18 May 2019 22:53:03 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 041F83AFF7; Sun, 19 May 2019 15:52:56 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558245176; bh=UyoGbNs8FbHbgKHLZdUdZbV24hg=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=ar2/+/cPX7yx5NANosRfcl9eR4gOGsIW7clLg1lBJWk4ZSQFhKUTDIObiPqxNj46j wDx6tt8dzXc90kT4PYd47H8tl+2uAGPWE8TVieCRnF3wulkAeePSfx2D2UDE0hdQ5L cS/Vf9DbVnykwnH2rU6k7qg0+kiJ41DmUZ1o0k94=o0k94= Comments: QMDA 0.3a Received: (qmail 45718 invoked by uid 1001); 19 May 2019 05:52:55 -0000 Date: 19 May 2019 05:52:55 +0000 Message-ID: <20190519055255.45717.qmail@f3-external.bushwire.net> From: "Mark Delany" To: "DoH WG" References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 05:53:06 -0000 On 18May19, Ben Schwartz allegedly wrote: > I don't think the implication you describe is intended. This sort of > reissuance is the expected implementation in the architecture you're > describing. Thanks. I think you're right that I've been thinking of a DoH server as being a dumber component than perhaps intended. But having to glean this model from potentially unintended consequences - such as a forced outcome for sensibly dealing with TC - is a bit disconcerting. If you infer from RFC8484 that a DoH Client is a simple call to an HTTPS library embedded in an application you get quite a different architectural perspective than if you infer a DoH client as being a service on your home/office gateway or portable wifi AP. In the former there is only one resolver library in the path, in the latter there are two (per your "easiest implementation" comment). How you divvy up roles and responsibilities in each of these models substantially differs. In the former model most, if not all, of the stub resolver smarts live in the DoH server. That could include nameserver timeouts, TC retries, ECS settings and more. That agrees with the inference you suggest. In the latter model the division of labor is much more ambiguous as in effect you have one stub resolver calling another with both having local configurations and both assuming they have sole responsibility for client-side errors, retries and feature management. Put another way, in the former model a DoH server most closely performs the role of a stub resolver in the latter model a DoH server most closely performs the role of a recursive resolver but it has no clue as to which one it is being used as. It's a pity the second model didn't get much attention because if DoH becomes pervasive, it's hard to believe it will be as a dumb HTTPS client embedded in a bazillion applications. Not much to be done about all of that now I supposed. The main conclusion I've drawn thus far is that the first model is relatively straightforward, but the second model could benefit from both specification guidance as well as possible protocol support to negotiate overlapping roles and responsibilities. Mark. From nobody Sun May 19 09:09:26 2019 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 24E161201D4 for ; Sun, 19 May 2019 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 baBo3t_F4jBT for ; Sun, 19 May 2019 09:09:20 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 9BADC1201FA for ; Sun, 19 May 2019 08:41:43 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id m1so7512085vsr.6 for ; Sun, 19 May 2019 08: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=0lHyH4zPN5BJ2NBy2BWiylLsSOZ050gr2xexcj+tU5k=; b=pmKT01JD5Ko0hBCwWlCkEu+ohSegbr3MyJXv/via4eeFSfoyvbstJDKse5R+9poiFu Xwk/L3l4oavu3SWILu3vT3h52DUyR27z4OkldjUeiEwxY1qyNy/GUq3K9NKhc5k3fV7/ RyblghoCfLrbRGLKTTtZyHwjqCEimp50PbIcYEWiaDid508Vi50FM0ssQV3kriKueiNc DmFVgz7RQerdg0VZdbCXiDCk9orpADU7rVIWzcdiAnSDEMDlidnYYPkCNoPQapTnSecQ d/dMyc7jA9ahAuUkhxUehqmhgVej6zGW8ooo53gT8g9jI6uDJsnCs0PpO25ZATMzPl3k dLVw== 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=0lHyH4zPN5BJ2NBy2BWiylLsSOZ050gr2xexcj+tU5k=; b=UvqRCMQMff5Fhve9+rMLVIaSTMxTApIJZC+T5H8OpMPvNI3MrEn2eMzUwDiGJFakpH tj2WgLU5J/pAMvE9RayFHmC4Ezd177FC3HDIEUgLlpIVj5lPK4dB/YhZghiC3vGe5Tkz E8rPG3BtEdw+jCd7/D/4llCWddDpFJxxRWEscFY1g12EVI3zvejAUo0vjwMDHtDUjm6B 1NREQ4EdrpL0eZ+6cckeVnQzQFYTUZDu8pJA8UsHt2Z9eW8k3dAmKYUjwynkxo8ydvN5 CL+05mpQXUbszRN7nv2bIktoLX44HoshLoVT7pM9P9Hib2VoTrzE5cPAMtkxBviFvKr8 yhPw== X-Gm-Message-State: APjAAAV5sFTRdP3nXgfbEGr5+G9slpH6sD3M9OFTS/VhRZoTVcN+drQG tNA9SyMnwjWmYdq4X184FzANZisCmxpF3XxodoCjyG+HwIstyA== X-Google-Smtp-Source: APXvYqxHh92y7R9UjlFs7ref8SSwVm3Es6i9VO/X/kTot1mitKW1QTI6Co3da0WVLZTzez1MHUQqHq19SxGweIYrpAU= X-Received: by 2002:a67:1e47:: with SMTP id e68mr33408847vse.1.1558280502238; Sun, 19 May 2019 08:41:42 -0700 (PDT) MIME-Version: 1.0 References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> In-Reply-To: <20190519055255.45717.qmail@f3-external.bushwire.net> From: Ben Schwartz Date: Sun, 19 May 2019 11:41:28 -0400 Message-ID: To: Mark Delany Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d4cbdf05893f73f8" Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2019 16:09:24 -0000 --000000000000d4cbdf05893f73f8 Content-Type: multipart/alternative; boundary="000000000000ccb39405893f7335" --000000000000ccb39405893f7335 Content-Type: text/plain; charset="UTF-8" *From: *Mark Delany *Date: *Sun, May 19, 2019 at 1:53 AM *To: *DoH WG On 18May19, Ben Schwartz allegedly wrote: > > > I don't think the implication you describe is intended. This sort of > > reissuance is the expected implementation in the architecture you're > > describing. > > Thanks. I think you're right that I've been thinking of a DoH server > as being a dumber component than perhaps intended. > > But having to glean this model from potentially unintended > consequences - such as a forced outcome for sensibly dealing with TC - > is a bit disconcerting. > Given the large number of potential deployment scenarios (including the two you've noted), the authors felt that it was best to focus on specification, and avoid attempting to enumerate the expected patterns of usage in each scenario. > If you infer from RFC8484 that a DoH Client is a simple call to an > HTTPS library embedded in an application you get quite a different > architectural perspective than if you infer a DoH client as being a > service on your home/office gateway or portable wifi AP. > > In the former there is only one resolver library in the path, in the > latter there are two (per your "easiest implementation" comment). How > you divvy up roles and responsibilities in each of these models > substantially differs. > > In the former model most, if not all, of the stub resolver smarts live > in the DoH server. That could include nameserver timeouts, TC retries, > ECS settings and more. That agrees with the inference you suggest. > > In the latter model the division of labor is much more ambiguous as in > effect you have one stub resolver calling another with both having > local configurations and both assuming they have sole responsibility > for client-side errors, retries and feature management. > > Put another way, in the former model a DoH server most closely > performs the role of a stub resolver in the latter model a DoH server > most closely performs the role of a recursive resolver but it has no > clue as to which one it is being used as. > The classic DNS protocol doesn't have any such role indications either. Thus, when I send a query to my network's advertised DNS server, I have no idea whether it is acting as a recursive, forwarding my query to a recursive (e.g. dnsmasq), or something in-between. This is transparent and generally does not cause problems. DoH is a transport for DNS. Since DNS has no protocol-level indication of these responsibilities, neither does DoH. It's a pity the second model didn't get much attention because if DoH > becomes pervasive, it's hard to believe it will be as a dumb HTTPS > client embedded in a bazillion applications. > > Not much to be done about all of that now I supposed. The main > conclusion I've drawn thus far is that the first model is relatively > straightforward, but the second model could benefit from both > specification guidance as well as possible protocol support to > negotiate overlapping roles and responsibilities. > In practice, none of this seems to be a problem. DoH servers simply do their best to fully answer the query, securely and in a timely fashion. The details of that are left to the implementor, as it is with classic DNS servers, whose detailed behavior varies widely according to the preferences of the operator. > Mark. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000ccb39405893f7335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
From: Mark Delany <d5e@xray.emu.st&= gt;
Date: Sun, May 19, 2019 at 1:53 AM
To: DoH WG

On 18May19, Ben Schwartz allegedly wrote:

> I don't think the implication you describe is intended.=C2=A0 This= sort of
> reissuance is the expected implementation in the architecture you'= re
> describing.

Thanks. I think you're right that I've been thinking of a DoH serve= r
as being a dumber component than perhaps intended.

But having to glean this model from potentially unintended
consequences - such as a forced outcome for sensibly dealing with TC -
is a bit disconcerting.

Given the large= number of potential deployment scenarios (including the two you've not= ed), the authors felt that it was best to focus on specification, and avoid= attempting to enumerate the expected patterns of usage in each scenario.
=C2=A0
If you infer from RFC8484 that a DoH Client is a simple call to an
HTTPS library embedded in an application you get quite a different
architectural perspective than if you infer a DoH client as being a
service on your home/office gateway or portable wifi AP.

In the former there is only one resolver library in the path, in the
latter there are two (per your "easiest implementation" comment).= How
you divvy up roles and responsibilities in each of these models
substantially differs.

In the former model most, if not all, of the stub resolver smarts live
in the DoH server. That could include nameserver timeouts, TC retries,
ECS settings and more. That agrees with the inference you suggest.

In the latter model the division of labor is much more ambiguous as in
effect you have one stub resolver calling another with both having
local configurations and both assuming they have sole responsibility
for client-side errors, retries and feature management.

Put another way, in the former model a DoH server most closely
performs the role of a stub resolver in the latter model a DoH server
most closely performs the role of a recursive resolver but it has no
clue as to which one it is being used as.

The classic DNS protocol doesn't have any such role indications= either.=C2=A0 Thus, when I send a query to my network's advertised DNS= server, I have no idea whether it is acting as a recursive, forwarding my = query to a recursive (e.g. dnsmasq), or something in-between.=C2=A0 This is= transparent and generally does not cause problems.
<= div>
DoH is a transport for DNS.=C2=A0 Since DNS has no proto= col-level indication of these responsibilities, neither does DoH.=C2=A0

It's a pity the second model didn't get much attention because if D= oH
becomes pervasive, it's hard to believe it will be as a dumb HTTPS
client embedded in a bazillion applications.

Not much to be done about all of that now I supposed. The main
conclusion I've drawn thus far is that the first model is relatively straightforward, but the second model could benefit from both
specification guidance as well as possible protocol support to
negotiate overlapping roles and responsibilities.

=
In practice, none of this seems to be a problem.=C2=A0 DoH serve= rs simply do their best to fully answer the query, securely and in a timely= fashion.=C2=A0 The details of that are left to the implementor, as it is w= ith classic DNS servers, whose detailed behavior varies widely according to= the preferences of the operator.
=C2=A0
Mark.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000ccb39405893f7335-- --000000000000d4cbdf05893f73f8 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDC901IEni9FkQxCflzS72n khiCYRBDrXDn/4Itx35sATAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA1MTkxNTQxNDJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcUgODAh4/AT3vh+W/F7d1aybTsVl55yXPlSxT5wg +Xdn1dIgE+EH51oNGpCUUP4FYPUQmzqYiw17pGJFvq8adlllLwCCgE/ncrtY1BOlCTo30+cVA4Hj VK//2Imi6s305oNd3uuwf7spDljy3z3LMKW7YdIpIyUTySekIcCPlYFSWC+gLZLL834XuU7pka6a 9nazppWkmI9U2ZFMHeqTmVKny4Y/QEWdTC1zSlDbby2DrelB4MUXNKnDwwboMgCuyHTGxpvV6+HQ ZDsnQN3ASP0iHq1Eev7D4Oyqs8+tJeEml0XyqV5Kk/zrFJDrLQf5mHZd0AYP1qy98itqxziyWg== --000000000000d4cbdf05893f73f8-- From nobody Mon May 20 01:12:18 2019 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 4C4D012012D for ; Mon, 20 May 2019 01:12:16 -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=portfast.net 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 K4JM0YfEwj7Y for ; Mon, 20 May 2019 01:12:14 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 254F4120077 for ; Mon, 20 May 2019 01:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=O756vT44kfeKVt6RVVPqCzERYZTNV/cug/8QD1dv9oo=; b=QSKkVHt/uF3q7uttkIzepTUkkG /ZTdeCX29+9Y3YSWTXBVEgpGBcpvKg60OfyDRHDckgLE7E9BYmPwTlgWzOtfsGiaUiPe2QyGujX1I CIPIawVu6wQmRwu+54Tx7XYqnyMC81lnr2V8KoKsfSa/4qlQZco1HgzpygnwGgASNJ78=; Received: from [88.212.170.147] (port=49482 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hSdP1-0003bi-7g (Exim 4.89) for doh@ietf.org (return-path ); Mon, 20 May 2019 08:12:11 +0000 To: doh@ietf.org References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> From: Ray Bellis Message-ID: Date: Mon, 20 May 2019 09:12:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 08:12:16 -0000 On 19/05/2019 16:41, Ben Schwartz wrote: > The classic DNS protocol doesn't have any such role indications either. > Thus, when I send a query to my network's advertised DNS server, I have > no idea whether it is acting as a recursive, forwarding my query to a > recursive (e.g. dnsmasq), or something in-between.  This is transparent > and generally does not cause problems. Not so - see RFC 5625 and SSAC035. Ray From nobody Mon May 20 21:48:57 2019 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 6291A120123 for ; Mon, 20 May 2019 21:48:55 -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=emu.st 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 2gmS0DreSRXE for ; Mon, 20 May 2019 21:48:53 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id B31F712009C for ; Mon, 20 May 2019 21:48:53 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 50B8D3B05A; Tue, 21 May 2019 14:48:50 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558414130; bh=0H3racZnYPJn8LpwyWt8C55nQXI=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=LRpP3hO1GH+MZeAk8ZwIHz8KdXq/7KWCgGEf4vX7YnvayyuwIGfrDgZoZ1OPQ+EW3 TfKds1PJN/WvGEFsdjgT4iY9EEFb5urwMDQoUgjaYDd7OXssLedZhl8M23y0Ia8Vwe jiEwzqUcW9fVTnyX1+CxF3q01t1WKy6aRAbpGkbQ=pGkbQ= Comments: QMDA 0.3a Received: (qmail 11544 invoked by uid 1001); 21 May 2019 04:48:50 -0000 Date: 21 May 2019 04:48:50 +0000 Message-ID: <20190521044850.11543.qmail@f3-external.bushwire.net> From: "Mark Delany" To: "DoH WG" References: <20190418071238.68406.qmail@f3-external.bushwire.net> <20190518233815.44249.qmail@f3-external.bushwire.net> <20190519055255.45717.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 04:48:55 -0000 On 19May19, Ben Schwartz allegedly wrote: > This is transparent and generally does not cause problems. > In practice, none of this seems to be a problem. I'm interested to know how you came to those conclusions. When you say "generally" and "seems" that sounds more anecdotal than empirical. (Was there ever a bake-off for DoH? Three independent implementations and all that jazz?) Having said that I accept the reality that as long as at least one IP address gets returned in a response, then everything else that the DNS community has layered on top of a DNS query/response is mostly icing on the cake. IOWs the lowest common denominator is all that most clients rely on so all my hand-wringing around TC and ECS and roles is so much esotericism. Sad for me but hardly important. As just one example of how indifferent clients are; as you observe, many DoH servers re-query TC responses locally thus insulating clients. Contrast this with dnsmasq which appears to arbitrarily clear TC and return the truncated response to client as if it were whole. That the Internet functions with these two completely opposing outcomes is impressive. I'm not sure how that guides a DoH implementor to a robust solution but it does seem to perpetuate the notion that any solution is legit as long as it generally "seems" to work. > DoH is a transport for DNS. That misapprehension on my part is what initiated this thread in the first place. I initially saw DoH as a port 53 tunnel, but it is anything but that if you include client and server behavior. At the very least the DoH server is content-aware and responds to TC=1 and server timeouts and who knows what else based on what local resolver it is using. In addition the DoH client is specified to be aware of TTLs and HTTP "Age" headers and modify the response accordingly. We also saw earlier in this thread some discussion around DoH components participating in ECS settings. To my mind that makes DoH more akin to an RPC interface created by slicing thru a stub resolver. Enough ranting. You provided useful feedback that I can act on, so thanks for that. Mark. From nobody Mon May 20 23:11:28 2019 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 9A19212012F for ; Mon, 20 May 2019 23:11:26 -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=emu.st 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 tC0pb8BzWUhe for ; Mon, 20 May 2019 23:11:25 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA1120118 for ; Mon, 20 May 2019 23:11:24 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 863333B05A; Tue, 21 May 2019 16:11:22 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1558419082; bh=Fbg/bJBS2XrOpNNEaBmJhJeO8h0=; h=Comments:Received:Date:Message-ID:From:To:Subject:MIME-Version: Content-Type:Content-Disposition; b=qLC6V0QzZjYel0/Qbw1gmdUs50tE7ZHiRr1sITTEEjj4PcBbYQiGVtHGKexRseFeQ tcKO3WHlmSctT2wwXhvCVQDBDYvDCqXlWSdPVsv+Z6hKSDUuVHNm5SXxgTGJ498lNz A1g6psMW//AXDqnHeVmRs03DqSfQXcjIUbowbnFo=wbnFo= Comments: QMDA 0.3a Received: (qmail 11759 invoked by uid 1001); 21 May 2019 06:11:22 -0000 Date: 21 May 2019 06:11:22 +0000 Message-ID: <20190521061122.11758.qmail@f3-external.bushwire.net> From: "Mark Delany" To: "DoH WG" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Archived-At: Subject: [Doh] TSIG, Padding and "Age:" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 06:11:26 -0000 Sorry. More hand-wringing. Section 9 of RFC8484 (DoH) says "servers can also add DNS padding [RFC7830] if the DoH client requests it in the DNS query". However section 3.4 of RFC2845 (TSIG) says that essentially the whole message is protected by the hash calculation (bar a few irrelevant odds and sods) which means that a DoH server adding padding will break the TSIG message digest. Therefore is it correct to say that a DoH server cannot add padding if the DNS message contains a TSIG RR? I see no mention of this constraint in either RFC8484 or RFC7830 so it might be easy to miss unless you dig deep. If my reading is correct, would a proviso in Section 9 be helpful for implementors? If TSIG is in play - and I don't really know until someone here confirms it - does the TSIG constraint on message modification also conflict with Section 5.1 of RFC8484 which states: "DoH clients MUST account for the Age response header field's value" ... and modify TTLs? Would that section similarly benefit from the proviso of "MUST account for the Age ... unless TSIG is present" or perhaps more generally "no modifications if the message is cryptographically protected"? Dunno how you do that with unknowable future crptographic protections, but oh well. I tell ya. Once you step into the waters of modifying in-flight DNS messages it seems like crocodiles all the way down. Mark. From nobody Wed May 22 01:36:08 2019 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 F2D30120094 for ; Wed, 22 May 2019 01:36:07 -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=portfast.net 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 bTv97EKNv-xY for ; Wed, 22 May 2019 01:36:06 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 C3CD0120092 for ; Wed, 22 May 2019 01:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q02MxXPa1T2ub2ROCKbKpKujyDTEO+UMJVg9L6+PFRE=; b=o4YXqoN9RWiak7aJeWxstHQ+L1 trE5wsA50giX2IYXcS/XwDTz3parQ2Cpg3BECLwUmf86Tzj0UBTMh7zbZ7gT+XqKvgLff9ini16Ce nPMZpTXBSCYKJhCGInrY0Yk+GGa8GgKwfY9eGMh8ZX/rOrJ1lvpwqTh+KfVD7JCqX+Ho=; Received: from [88.212.170.147] (port=56607 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hTMjB-0001MS-UI (Exim 4.89) for doh@ietf.org (return-path ); Wed, 22 May 2019 08:36:02 +0000 To: doh@ietf.org References: <20190521061122.11758.qmail@f3-external.bushwire.net> From: Ray Bellis Message-ID: <1b07c20e-efd3-ce95-10ad-1133caa6433a@bellis.me.uk> Date: Wed, 22 May 2019 09:36:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190521061122.11758.qmail@f3-external.bushwire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] TSIG, Padding and "Age:" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 08:36:08 -0000 On 21/05/2019 07:11, Mark Delany wrote: > Section 9 of RFC8484 (DoH) says "servers can also add DNS padding [RFC7830] if > the DoH client requests it in the DNS query". > > However section 3.4 of RFC2845 (TSIG) says that essentially the whole message is > protected by the hash calculation (bar a few irrelevant odds and sods) which > means that a DoH server adding padding will break the TSIG message digest. > > Therefore is it correct to say that a DoH server cannot add padding if the DNS > message contains a TSIG RR? That's correct. > If TSIG is in play - and I don't really know until someone here confirms it - > does the TSIG constraint on message modification also conflict with Section 5.1 > of RFC8484 which states: "DoH clients MUST account for the Age response header > field's value" ... and modify TTLs? Also correct. > I tell ya. Once you step into the waters of modifying in-flight DNS messages it > seems like crocodiles all the way down. This is not news :( Ray From nobody Wed May 22 07:09:12 2019 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 570841201A1 for ; Wed, 22 May 2019 07:09:07 -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, 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=comcast.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 Z7wbYYgeYP2G for ; Wed, 22 May 2019 07:09:04 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 EB4FB120142 for ; Wed, 22 May 2019 07:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1558534131; x=2422447731; 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=DXKG72YhOzbzhIXbahGqxZHV8IogkabgMQgJhOwogys=; b=o1B4nbB6y/4e28tcQuGHR4R4u4fEsjHE5nm/CoylMJTmSPuO0YkBG17OXKGhYxGY tW+ca7Yj/2DTSukPC7VtlEeSe1Rtmc3haJrTYt/jgj6chtrsRzyw9fniinjiWtoW 2B3vzJFnwv0IXZ5G7VuIGEIqFAFsEvq33Ht+Nwb6maoCwp4BSqmwex3/ppPNegdc 6RDCdaj3oTMKXjdXKtGO5kffcdNC0awavPsruVjztzJwuzX26h/qmGvt/brDEzYG S6OpzCWwLJd87m/JavGO6PtDr++WkbH9tMNUvGCppyWe1OEcsRlhemLmOKx4rXR+ 6wrdyu/jJXhtYGysEEvG3Q==; X-AuditID: a2962c47-cebff70000021564-7f-5ce557ee2756 Received: from COPDCEXC35.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 5A.67.05476.EE755EC5; Wed, 22 May 2019 08:08:46 -0600 (MDT) Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC35.cable.comcast.com (147.191.125.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 22 May 2019 10:08:53 -0400 Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Wed, 22 May 2019 10:08:53 -0400 From: "Livingood, Jason" To: DoH WG Thread-Topic: [FYI] How Comcast Handles DNS Information Thread-Index: AQHVEKfjeVSP5/NgUk6KgkVLHxwQZA== Date: Wed, 22 May 2019 14:08:53 +0000 Message-ID: <87D8BAF1-9EF5-4DF4-9F67-571201F8D906@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [96.115.73.253] Content-Type: multipart/alternative; boundary="_000_87D8BAF19EF54DF49F67571201F8D906cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNIsWRmVeSWpSXmKPExsWSUDRnsu678KcxBvd2S1tcu3uRzYHRY8mS n0wBjFHhNkWpxaVJuZklCsWpRWWZyam2SsmJxUp2XAoYAKg0JzWxONUxuSQzP69YH0ONjT7M MLuE8Iw/P+eyFKxxqOi7/JGlgfGgXRcjJ4eEgIlE3/7bLF2MXBxCAkeYJJb8b2WDcFqYJM61 fIHKnGaUWNR8nR2khU3ATOLuwivMILaIgKTExanvWEBsYaBRs7+dZIKIW0pM3vwAqkZPYm/T BsYuRg4OFgFViTcfVEHCvAIuEv8nzAIbySggJvH91BqwVmYBcYlbT+YzQVwnILFkz3lmCFtU 4uXjf6wgtqiAvsSP7TfZIOKKEvs+rGCG6E2X2DNlKQvEfEGJkzOfsEDUiEscPrKDdQKjyCwk K2YhaZmFpGUW0KXMApoS63fpQ5QoSkzpfsgOYWtItM6ZC2VbSXT862NCVrOAkWMVI6+hmZGe oamBnomJnrnhJkZglC+apuO+g/HD+dhDjAIcjEo8vNuB0S/EmlhWXJl7iFGCg1lJhPf0qUcx QrwpiZVVqUX58UWlOanFhxilOViUxHmNNG/HCAmkJ5akZqemFqQWwWSZODilGhgZ2n8GPm1i mn7evpetdqIit1ar2fmG+t5+oW3sp/i/Fvg+fszvuyI1o1he/sqh5NKIoKaAvFfTlXZVTQ/2 +l+RLner/CObYLjmhZkN9pxLzC/4vFu+tsBI/3NzJt/CzrZv20O6X3/+3/l+tu33k193F6t/ yth8ea1m0f2rEZYPHSeeEJlXcUKJpTgj0VCLuag4EQAUm9q97gIAAA== Archived-At: Subject: [Doh] [FYI] How Comcast Handles DNS Information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 14:09:12 -0000 --_000_87D8BAF19EF54DF49F67571201F8D906cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgdGhlIHJlY2VudCBEb0ggbWVldGluZyBhdCBJRVRGLTEwNCwgYW5kIGFsc28gaW4gdGhlIHNp ZGUgbWVldGluZyB0aGF0IFN0w6lwaGFuZSBvcmdhbml6ZWQsIHRoZXJlIHdhcyBtdWNoIGRpc2N1 c3Npb24gYWJvdXQgaG93IGEgcHJpbWFyeSBtb3RpdmF0aW9uIGZvciBjZW50cmFsaXplZCBEb0gg d2FzIElTUCBETlMgcHJhY3RpY2VzOiBzcGVjaWZpY2FsbHksIE5YRE9NQUlOIHJlZGlyZWN0aW9u IGFuZCBETlMgZGF0YSBjb2xsZWN0aW9uIGFuZCBwcml2YWN5Lg0KDQpJIHRob3VnaHQgSeKAmWQg dGFrZSBhIG1vbWVudCBoZXJlIHRvIGNvbmZpcm0gQ29tY2FzdOKAmXMgcG9zaXRpb24gb24gdGhl c2UgaXNzdWVzLiBGaXJzdCwgd2UgZG9u4oCZdCBkbyBOWERPTUFJTiByZWRpcmVjdGlvbiAoc2Vl IGh0dHBzOi8vY29ycG9yYXRlLmNvbWNhc3QuY29tL2NvbWNhc3Qtdm9pY2VzL2NvbWNhc3QtZG9t YWluLWhlbHBlci1zaHV0cy1kb3duKS4gIFNlY29uZCwgb3VyIGxvbmdzdGFuZGluZyBwb2xpY3kg cmVnYXJkaW5nIGN1c3RvbWVyIEROUyBxdWVyaWVzIGlzIHNpbXBsZTogd2UgZG8gbm90IHRyYWNr IGN1c3RvbWVyc+KAmSBETlMgZGF0YSwgc2VsbCBpdCwgb3IgdXNlIGl0IGZvciBhZHZlcnRpc2lu ZyBvciBtYXJrZXRpbmcuICBBbmQgZXZlbiB0aG91Z2ggQ29tY2FzdCBwcm9jZXNzZXMgbW9yZSB0 aGFuIDU1MCBiaWxsaW9uIHJlY3Vyc2l2ZSBETlMgcXVlcmllcyBwZXIgZGF5LCBpdCBpcyBvdXIg c3RhbmRhcmQgcG9saWN5IHRvIGRlbGV0ZSBhbGwgRE5TIHF1ZXJpZXMgZnJvbSBvdXIgc3lzdGVt c+KAmSBsb2dzIGV2ZXJ5IDI0IGhvdXJzLCB1bmxlc3Mgd2UgbmVlZCB0byByZXNlYXJjaCBhbmQg cmVzb2x2ZSBzcGVjaWZpYyBzZWN1cml0eSBvciBuZXR3b3JrIHBlcmZvcm1hbmNlIGlzc3Vlcy4N Cg0KV2UgdGFrZSBETlMgc2VjdXJpdHkgdmVyeSBzZXJpb3VzbHkgYW5kIHdlIHdlcmUgdGhlIGZp cnN0IGxhcmdlIElTUCBpbiB0aGUgVW5pdGVkIFN0YXRlcyB0byBmdWxseSBpbXBsZW1lbnQgRE5T U0VDIHZhbGlkYXRpb24gKHNlZSBodHRwczovL2NvcnBvcmF0ZS5jb21jYXN0LmNvbS9jb21jYXN0 LXZvaWNlcy9jb21jYXN0LWNvbXBsZXRlcy1kbnNzZWMtZGVwbG95bWVudCkuIFdoZXRoZXIgaXQg aXMgRE5TU0VDIG9yIG91ciBlYXJseSBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2LCB3ZeKAmXJlIGFs d2F5cyBpbnRlcmVzdGVkIGluIGRlcGxveWluZyB2YWx1YWJsZSBuZXcgc3RhbmRhcmRzIGFuZCwg anVzdCBhcyBtYW55IG90aGVyIElTUHMgYXJlIG5vdyBkb2luZywgd2UgY29udGludWUgdG8gc3R1 ZHkgaG93IGFuZCB3aGVuIHRvIGRlcGxveSBEb0ggYW5kIERvVCBpbiBhIG1hbm5lciB0aGF0IHdp bGwgbWluaW1pemUgY29uc3VtZXIgZGlzcnVwdGlvbnMgd2hpbGUgZW5zdXJpbmcgY29udGludWVk IGNvbnN1bWVyIHByaXZhY3kgJiBzZWN1cml0eS4NCg0KUmVnYXJkcywNCkphc29uIExpdmluZ29v ZA0KVmljZSBQcmVzaWRlbnQg4oCTIFRlY2hub2xvZ3kgUG9saWN5ICYgU3RhbmRhcmRzDQpDb21j YXN0DQoNCg== --_000_87D8BAF19EF54DF49F67571201F8D906cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <084A53F8C33C3B4E9675938CA2088A8F@comcast.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBD U1wpIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B dCB0aGUgcmVjZW50IERvSCBtZWV0aW5nIGF0IElFVEYtMTA0LCBhbmQgYWxzbyBpbiB0aGUgc2lk ZSBtZWV0aW5nIHRoYXQNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5TdMOpcGhhbmUm bmJzcDtvcmdhbml6ZWQsIHRoZXJlIHdhcyBtdWNoIGRpc2N1c3Npb24gYWJvdXQgaG93IGEgcHJp bWFyeSBtb3RpdmF0aW9uIGZvciBjZW50cmFsaXplZCBEb0ggd2FzIElTUCBETlMgcHJhY3RpY2Vz OiBzcGVjaWZpY2FsbHksIE5YRE9NQUlOIHJlZGlyZWN0aW9uIGFuZCBETlMgZGF0YSBjb2xsZWN0 aW9uIGFuZCBwcml2YWN5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5JIHRob3VnaHQgSeKAmWQgdGFrZSBhIG1vbWVudCBoZXJlIHRvIGNvbmZpcm0gQ29tY2Fz dOKAmXMgcG9zaXRpb24gb24gdGhlc2UgaXNzdWVzLiBGaXJzdCwgd2UgZG9u4oCZdCBkbyBOWERP TUFJTiByZWRpcmVjdGlvbiAoc2VlDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9jb3Jwb3JhdGUu Y29tY2FzdC5jb20vY29tY2FzdC12b2ljZXMvY29tY2FzdC1kb21haW4taGVscGVyLXNodXRzLWRv d24iPmh0dHBzOi8vY29ycG9yYXRlLmNvbWNhc3QuY29tL2NvbWNhc3Qtdm9pY2VzL2NvbWNhc3Qt ZG9tYWluLWhlbHBlci1zaHV0cy1kb3duPC9hPikuJm5ic3A7IFNlY29uZCwgb3VyIGxvbmdzdGFu ZGluZyBwb2xpY3kgcmVnYXJkaW5nIGN1c3RvbWVyIEROUyBxdWVyaWVzIGlzIHNpbXBsZTogd2UN CiBkbyBub3QgdHJhY2sgY3VzdG9tZXJz4oCZIEROUyBkYXRhLCBzZWxsIGl0LCBvciB1c2UgaXQg Zm9yIGFkdmVydGlzaW5nIG9yIG1hcmtldGluZy4mbmJzcDsgQW5kIGV2ZW4gdGhvdWdoIENvbWNh c3QgcHJvY2Vzc2VzIG1vcmUgdGhhbiA1NTAgYmlsbGlvbiByZWN1cnNpdmUgRE5TIHF1ZXJpZXMg cGVyIGRheSwgaXQgaXMgb3VyIHN0YW5kYXJkIHBvbGljeSB0byBkZWxldGUgYWxsIEROUyBxdWVy aWVzIGZyb20gb3VyIHN5c3RlbXPigJkgbG9ncyBldmVyeSAyNCBob3VycywNCiB1bmxlc3Mgd2Ug bmVlZCB0byByZXNlYXJjaCBhbmQgcmVzb2x2ZSBzcGVjaWZpYyBzZWN1cml0eSBvciBuZXR3b3Jr IHBlcmZvcm1hbmNlIGlzc3Vlcy48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHRha2UgRE5TIHNlY3VyaXR5IHZl cnkgc2VyaW91c2x5IGFuZCB3ZSB3ZXJlIHRoZSBmaXJzdCBsYXJnZSBJU1AgaW4gdGhlIFVuaXRl ZCBTdGF0ZXMgdG8gZnVsbHkgaW1wbGVtZW50IEROU1NFQyB2YWxpZGF0aW9uIChzZWUNCjxhIGhy ZWY9Imh0dHBzOi8vY29ycG9yYXRlLmNvbWNhc3QuY29tL2NvbWNhc3Qtdm9pY2VzL2NvbWNhc3Qt Y29tcGxldGVzLWRuc3NlYy1kZXBsb3ltZW50Ij4NCmh0dHBzOi8vY29ycG9yYXRlLmNvbWNhc3Qu Y29tL2NvbWNhc3Qtdm9pY2VzL2NvbWNhc3QtY29tcGxldGVzLWRuc3NlYy1kZXBsb3ltZW50PC9h PikuIFdoZXRoZXIgaXQgaXMgRE5TU0VDIG9yIG91ciBlYXJseSBpbXBsZW1lbnRhdGlvbiBvZiBJ UHY2LCB3ZeKAmXJlIGFsd2F5cyBpbnRlcmVzdGVkIGluIGRlcGxveWluZyB2YWx1YWJsZSBuZXcg c3RhbmRhcmRzIGFuZCwganVzdCBhcyBtYW55IG90aGVyIElTUHMgYXJlIG5vdyBkb2luZywgd2Ug Y29udGludWUNCiB0byBzdHVkeSBob3cgYW5kIHdoZW4gdG8gZGVwbG95IERvSCBhbmQgRG9UIGlu IGEgbWFubmVyIHRoYXQgd2lsbCBtaW5pbWl6ZSBjb25zdW1lciBkaXNydXB0aW9ucyB3aGlsZSBl bnN1cmluZyBjb250aW51ZWQgY29uc3VtZXIgcHJpdmFjeSAmYW1wOyBzZWN1cml0eS48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFzb24gTGl2aW5nb29k PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmljZSBQcmVzaWRlbnQg4oCTIFRlY2hub2xvZ3kg UG9saWN5ICZhbXA7IFN0YW5kYXJkczwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbWNhc3Q8 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_87D8BAF19EF54DF49F67571201F8D906cablecomcastcom_-- From nobody Wed May 22 15:49:50 2019 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 E99B41200B7 for ; Wed, 22 May 2019 15:49:48 -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 kxrv-McUffxi for ; Wed, 22 May 2019 15:49:47 -0700 (PDT) Received: from mail.icann.org (out.west.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 D0FB0120088 for ; Wed, 22 May 2019 15:49:47 -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.1367.3; Wed, 22 May 2019 15:49:46 -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.1367.000; Wed, 22 May 2019 15:49:46 -0700 From: Paul Hoffman To: doh WG Thread-Topic: Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information Thread-Index: AQHVEPCmpYtbMN8MwEyatKtOZMXDNA== Date: Wed, 22 May 2019 22:49:45 +0000 Message-ID: <21EA7A61-2E10-431E-871F-CCE89728836F@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: <6776AC099CEB7B4CAC706A404744243A@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 22:49:49 -0000 Greetings again. For those in the DOH WG who are not also in the DNSOP WG, = you may not have seen that Puneet Sood, Roy Arends and I have new drafts th= at would replace draft-ietf-doh-resolver-associated-doh. During IETF 104, a= nd on this list, people asked why the mechanisms in draft-ietf-doh-resolver= -associated-doh were only for DoH. In response, we created draft-sah-resolv= er-information and draft-sah-resinfo-doh. The former is a general way of as= king resolvers for information about them; the latter is the definition of = the DoH-related information. We've used the DNSOP WG mailing list to get input on the drafts, with the h= ope that the DNSOP WG will adopt the drafts soon so we can move the work fr= om draft-ietf-doh-resolver-associated-doh to the more general solution. We = have not yet asked for WG adoption, but will likely do so after people see = these new drafts. Both Google and Mozilla have said here that they look forward to a way to f= ind the DoH server associated with a user's resolver, so we hope that the w= ork can move forward at a reasonable pace. However, if people in this WG th= ink we're doing it wrong by having a general mechanism for querying resolve= rs, please speak up here. --Paul Hoffman= From nobody Thu May 23 02:24:18 2019 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 3D2CD1200F8 for ; Thu, 23 May 2019 02:24:16 -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 o3B70MErxQIU for ; Thu, 23 May 2019 02:24:14 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 30BDD12008B for ; Thu, 23 May 2019 02:24:14 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id g24so1557054iti.5 for ; Thu, 23 May 2019 02:24:14 -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=AD40ayrchvSbBam7ASnr12gXAghZyMstmhXUea5zN8M=; b=reyECCWAdY/MxOSid6L+6DiUjJTZPUlgBcH85/khH8FvAS/sM7H9dC7byIqBowGuRE 6xESJ8CFGiFbKVYS/j5aU+++nLaU4SzQk+C1Au4GltOYBm0b1ZWRBCyziANRHY0mBCWL Kcli1jO2QHUidV8zabaGFe+u+aQJfCpgo9PWPD9pQIXzhVXbsmXgLM2eImxDb0pNVrNb n+jRbBlHWczbiu2q9GeKcMtTtM394OVNFijgzMNwTaljn1Pf5JtSxgKCGcOOs4/iYt01 JIEl7bOGDZNR6Jpi6MFpIWWSLnl1p6Mf5Nimow15q1n3a6qy6gL0VWNpCipDpI0E3dfU ZcbA== 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=AD40ayrchvSbBam7ASnr12gXAghZyMstmhXUea5zN8M=; b=cF1qt0p2zh7amke3LzDY5m3GJWw02/K7iHUazcP9BW5IPY2NyPHsrWaKGZyLyaj/47 56jEpkEh9xuaYdOuFZjLsGMzSF/1h9HTLAx3jUEwt7O5ZaKe09f8lRncFaqLja99QZCH 1w/DLXeroEP37DxoetJWvMtHSO86lPUAzy/CHkpHO8//LeJVnGNuytOCCWKlXHExeB37 i3HkyeBDkU8uKovip4oWBI4o2aAM5movDB1P4pqcoLREwqFIeBPV0nt0uKlxkIrXgvgk iyOCk82U1N+hGUJmVIY8hpindaIkbhG60vLyQaNxbqRw3LqcNxqL5KlK363/o/ot9pOC mnwQ== X-Gm-Message-State: APjAAAW8XjjTlkiQ/fL9aruadWXKertIrTFm1xT3o1kpp6UnoAMv+oDL D2jDOj+qKL7qpQOuFxNhXaRI5x8dsqJ+nXDGv8A= X-Google-Smtp-Source: APXvYqxVXpee0Wp7IhbPnZcz9hhb96Dky8IjTNtoE2URB3PLuHgluXJ+QljthSQbOh2PMi/wdJ/8NZDIxs/2igX2pvA= X-Received: by 2002:a24:1d8f:: with SMTP id 137mr12494020itj.66.1558603452039; Thu, 23 May 2019 02:24:12 -0700 (PDT) MIME-Version: 1.0 References: <21EA7A61-2E10-431E-871F-CCE89728836F@icann.org> In-Reply-To: <21EA7A61-2E10-431E-871F-CCE89728836F@icann.org> From: tirumal reddy Date: Thu, 23 May 2019 14:54:00 +0530 Message-ID: To: Paul Hoffman Cc: doh WG Content-Type: multipart/alternative; boundary="0000000000001ac73705898aa51b" Archived-At: Subject: Re: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 09:24:16 -0000 --0000000000001ac73705898aa51b Content-Type: text/plain; charset="UTF-8" Hi Paul, If DOH is supported by the DNS server, why can't the DNS client query for the URI resource record type [RFC7553] ? -Tiru On Thu, 23 May 2019 at 04:19, Paul Hoffman wrote: > Greetings again. For those in the DOH WG who are not also in the DNSOP WG, > you may not have seen that Puneet Sood, Roy Arends and I have new drafts > that would replace draft-ietf-doh-resolver-associated-doh. During IETF 104, > and on this list, people asked why the mechanisms in > draft-ietf-doh-resolver-associated-doh were only for DoH. In response, we > created draft-sah-resolver-information and draft-sah-resinfo-doh. The > former is a general way of asking resolvers for information about them; the > latter is the definition of the DoH-related information. > > We've used the DNSOP WG mailing list to get input on the drafts, with the > hope that the DNSOP WG will adopt the drafts soon so we can move the work > from draft-ietf-doh-resolver-associated-doh to the more general solution. > We have not yet asked for WG adoption, but will likely do so after people > see these new drafts. > > Both Google and Mozilla have said here that they look forward to a way to > find the DoH server associated with a user's resolver, so we hope that the > work can move forward at a reasonable pace. However, if people in this WG > think we're doing it wrong by having a general mechanism for querying > resolvers, please speak up here. > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000001ac73705898aa51b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

If DOH is supported by the DNS server= , why can't the DNS client query for the URI resource record type [RFC7= 553] ?

-Tiru

On Thu, 23 May 2019 at 04:19, Paul Hoffman <paul.hoffman@icann.org> wrote:<= br>
Greetings again.= For those in the DOH WG who are not also in the DNSOP WG, you may not have= seen that Puneet Sood, Roy Arends and I have new drafts that would replace= draft-ietf-doh-resolver-associated-doh. During IETF 104, and on this list,= people asked why the mechanisms in draft-ietf-doh-resolver-associated-doh = were only for DoH. In response, we created draft-sah-resolver-information a= nd draft-sah-resinfo-doh. The former is a general way of asking resolvers f= or information about them; the latter is the definition of the DoH-related = information.

We've used the DNSOP WG mailing list to get input on the drafts, with t= he hope that the DNSOP WG will adopt the drafts soon so we can move the wor= k from draft-ietf-doh-resolver-associated-doh to the more general solution.= We have not yet asked for WG adoption, but will likely do so after people = see these new drafts.

Both Google and Mozilla have said here that they look forward to a way to f= ind the DoH server associated with a user's resolver, so we hope that t= he work can move forward at a reasonable pace. However, if people in this W= G think we're doing it wrong by having a general mechanism for querying= resolvers, please speak up here.

--Paul Hoffman
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000001ac73705898aa51b-- From nobody Thu May 23 08:23:51 2019 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 35EB31201D9 for ; Thu, 23 May 2019 08:23:39 -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 YSJiQ-HyW_Ru for ; Thu, 23 May 2019 08:23:33 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9B926120179 for ; Thu, 23 May 2019 08:23:32 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id D7F47270895; Thu, 23 May 2019 15:23:29 +0000 (UTC) Date: Thu, 23 May 2019 15:23:29 +0000 From: dagon To: Paul Hoffman Cc: doh WG Message-ID: <20190523152329.GB16799@sudo.sh> References: <21EA7A61-2E10-431E-871F-CCE89728836F@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21EA7A61-2E10-431E-871F-CCE89728836F@icann.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 15:23:49 -0000 On Wed, May 22, 2019 at 10:49:45PM +0000, Paul Hoffman wrote: > Greetings again. For those in the DOH WG who are not also in the > DNSOP WG, you may not have seen that Puneet Sood, Roy Arends and I > have new drafts that would replace > draft-ietf-doh-resolver-associated-doh. During IETF 104, and on this > list, people asked why the mechanisms in > draft-ietf-doh-resolver-associated-doh were only for DoH. In > response, we created draft-sah-resolver-information and > draft-sah-resinfo-doh. The former is a general way of asking > resolvers for information about them; the latter is the definition > of the DoH-related information. One comment on draft-sah-resinfo-doh: Compare the use of a new RRType, ${SUDN}.arpa/IN/RESINFO, which yields a structured set of I-JSON fields, to a simple ${SUDN}.arpa/IN/A approach, with merely returns a record pointing to an appropriate server with resolver policy statements, perhaps on a web site or yaml ("This recursive blocks malware and ads, and per corporate policy all resolution must be local. Resolve elsewhere at your professional peril. This is an M&A audit requirement."), and/or other meta data useful to the stub's DNS path choices. There are many advantages to RESINFO beyond well structured data, including identifying/addressing stray ${SUDN}.arpa queries seen just above-the-recursive by local operators (REFUSED, etc?). And the networks who wish to block DOH will likely trigger on ${SUDN}.arpa/IN/RESINFO? queries, for captive portal education, whereas triggering on SUDN IN/A? for DOH identification would have too many false positives induced by DNS prefetching. (Aside: This was yet another global DNS accommodation for browsers, btw.) Although IN/RESINFO is the correct approach, compared to IN/A, I've been recently alerted to one potential draw back to a new RRType: some of the meta data one hopes to expose (e.g., filtration policy) might be easier to add or edit out-of-zone. That is, the simple ${SUDN}.arpa/IN/A approach points to a web site, which any summer intern in the legal department can edit (after the DNS operators add their rrset and close the ticket). In contrast, ${SUDN}.arpa/IN/RESINFO seems to inhere more extensive, or ongoing +w access to a recursive config, with potentially significant impacts for DOH users in the case of accidents. This is fine for just DOH URI fields, which don't change often. But other data, not generated by the DNS operator teams, will prove less agile. Without existing appliance support for editing (and not merely rfc3597 sane passing) of a novel RRType, adoption might be slow, since the DNS operators in organizations become entrained in the output of other groups. Many organizations affected by DOH (e.g., banks, mid-sized and larger corps, ISPs) already have clear delineations in groups around security, DNS, network operations, customer care, policy and public statements. Since draft-sah-resolver-information is designed to have more than just DOH URIs (and potentially could include policy details relevant to DOH pathing decisions), this seems important. Had I realized this years ago, IN/RESINFO still would be the obvious choice compared to IN/A, since well structured fields encourage app developers to poll ${SUDN}.arpa for discrete information. But the existing DOH deployment suggests speeding RESINFO uptake/adoption. Perhaps also supporting IN/A discovery of DNS filtration policy data could be useful. DNS appliance vendors would support IN/RESINFO of course, some quickly, some eventually. But IN/A could be done today on existing installs. Perhaps a billion+ people have DOH available (currently off), and some are using it to start small office fires. Exposing LAN policy to the apps quickly would help. And it would discipline the anti-malware DNS filtration industry around transparency-to-the-stub. (We can expect other DNS-abusive censors to continue to provide few or misleading details, which the browsers might well ignore as likely L8 imposed firewalls.) > Both Google and Mozilla have said here that they look forward to a > way to find the DoH server associated with a user's resolver, so we > hope that the work can move forward at a reasonable pace. However, > if people in this WG think we're doing it wrong by having a general > mechanism for querying resolvers, please speak up here. Since users are already turning on DOH, there's urgency in exposing network policy information to apps. Not just the DOH URI, but the imperative some networks see in DNS anti-malware filtering, as they now shop for PACs/TLS interception solutions, post-DOH. If you're revising draft-sah-resolver-information, could it support both A and RESINFO? (The former for rapid uptake/captive portal use and avoiding portal triggering, the latter for standardized app integration, once DNS appliances support federated editing.) Or anything just short of overloading TXT records once again? Cf. https://www.cafepress.com/nxdomain/8592477 Or have I missed something making IN/RESINFO the exclusive solution and not merely superior to IN/A? I do like the general compass direction of draft-sah-resolver-information: telling users about recursive DNS settings and policy is wonderful. This informs user consent and alternative resolution path choices. My thanks to the authors for drafting their solution. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Thu May 23 08:54:27 2019 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 D796B120072 for ; Thu, 23 May 2019 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 gnk0ysC846Wc for ; Thu, 23 May 2019 08:54:21 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 2CA7D120125 for ; Thu, 23 May 2019 08:54:20 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id k187so3871150vsk.12 for ; Thu, 23 May 2019 08:54:20 -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=naM1gEnodMcta8VlSvN+hueE5c88J8lPyOuG7sZ09Es=; b=Ir22rgpwR+Dsp9hCSt08lO8pbNWjxZRnR0eNG835vTAsLmc7/OjdiQpAk2b4IKLu/u 94ofqT8uAEXjicUAYgCNsmrglDHcTs95t67yjo6DPLSWdibvJY9Hw3rD2W5/G28n5K4w Bo90+fkR8RLZQ/ZJZ5jn6K+uy+Hjyxgd0ZjGspg5qLLvn3uiQAcLg2WaA9fZT5nfZ8mU mHqjzAEv3Gkjwu1dCifubEa0iH+fY8Hxx6iIykdZcgsW8oVDrPNEYB66ugmYQD99EZt8 DeliCAkROTkbWeEEu22kI8Z3+kOOci5OjJl6pa7zMwAkoRRRDF9sv2anYhwjdLqn2L4k xFng== 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=naM1gEnodMcta8VlSvN+hueE5c88J8lPyOuG7sZ09Es=; b=c6RxRTYkH9g8xFiJUvbWDzTeArvUOo+GdFMY6bqoHvtw4NWQuuDSJPiZqnTC9dfzCe nMD2x8CtdwLkXuM45FjGDeHIyAjyF2T0F4M5SZmNqNWRPEl0CvE6ZaDlUlNr7ISxmDZg N1LTRPO8lh6URTBiH7XFQD2DrbKSGslMoS4zCC8OZDSeKmySS7pc9aYvZyf/BdnwR5z0 rKNA8pYxOe2Vs9FUnpTxUQI0lpW+78DzCQzCSEBTTOwBGnhnxzhzHNrQxRGs5pCUmm5O WFXSE9yGfth4wVtJGxmN+WPPm3V9+tS38+w2ffioRtk3cr6GWkp/Db7piU2C13GcCcZ9 jbyA== X-Gm-Message-State: APjAAAVhBjOHqWxhtNAKRTi/WQGfBftznzC/0cW9XPK+pBALOHIFQtBS 4HWJqb4m2pe3Zkogap6ZeKMaOuQ7KOYA2ki+DjzWVQ== X-Google-Smtp-Source: APXvYqxsXAfp5Y0LY7qxLKadZxbjPp8hvnBMKuYgx6hVmx2nn51paCP4u1qye1tFZHur05tiQcr/2tgkub2pTXsXfSk= X-Received: by 2002:a67:ca9a:: with SMTP id a26mr19401685vsl.92.1558626858816; Thu, 23 May 2019 08:54:18 -0700 (PDT) MIME-Version: 1.0 References: <21EA7A61-2E10-431E-871F-CCE89728836F@icann.org> <20190523152329.GB16799@sudo.sh> In-Reply-To: <20190523152329.GB16799@sudo.sh> From: Ben Schwartz Date: Thu, 23 May 2019 11:54:07 -0400 Message-ID: To: dagon Cc: Paul Hoffman , doh WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000049e8fb0589901869" Archived-At: Subject: Re: [Doh] Maybe moving draft-ietf-doh-resolver-associated-doh to draft-sah-resolver-information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 15:54:25 -0000 --00000000000049e8fb0589901869 Content-Type: multipart/alternative; boundary="000000000000425882058990184c" --000000000000425882058990184c Content-Type: text/plain; charset="UTF-8" On Thu, May 23, 2019 at 11:24 AM dagon wrote: > On Wed, May 22, 2019 at 10:49:45PM +0000, Paul Hoffman wrote: > > > Greetings again. For those in the DOH WG who are not also in the > > DNSOP WG, you may not have seen that Puneet Sood, Roy Arends and I > > have new drafts that would replace > > draft-ietf-doh-resolver-associated-doh. During IETF 104, and on this > > list, people asked why the mechanisms in > > draft-ietf-doh-resolver-associated-doh were only for DoH. In > > response, we created draft-sah-resolver-information and > > draft-sah-resinfo-doh. The former is a general way of asking > > resolvers for information about them; the latter is the definition > > of the DoH-related information. > > One comment on draft-sah-resinfo-doh: > > Compare the use of a new RRType, ${SUDN}.arpa/IN/RESINFO, which yields > a structured set of I-JSON fields, to a simple ${SUDN}.arpa/IN/A > approach, with merely returns a record pointing to an appropriate > server with resolver policy statements, perhaps on a web site or yaml > ("This recursive blocks malware and ads, and per corporate policy all > resolution must be local. Resolve elsewhere at your professional > peril. This is an M&A audit requirement."), and/or other meta data > useful to the stub's DNS path choices. > > There are many advantages to RESINFO beyond well structured data, > including identifying/addressing stray ${SUDN}.arpa queries seen just > above-the-recursive by local operators (REFUSED, etc?). And the > networks who wish to block DOH will likely trigger on > ${SUDN}.arpa/IN/RESINFO? queries, for captive portal education, > whereas triggering on SUDN IN/A? for DOH identification would have too > many false positives induced by DNS prefetching. (Aside: This was yet > another global DNS accommodation for browsers, btw.) > > Although IN/RESINFO is the correct approach, compared to IN/A, I've > been recently alerted to one potential draw back to a new RRType: some > of the meta data one hopes to expose (e.g., filtration policy) might > be easier to add or edit out-of-zone. > > That is, the simple ${SUDN}.arpa/IN/A approach points to a web site, > which any summer intern in the legal department can edit (after the > DNS operators add their rrset and close the ticket). In contrast, > ${SUDN}.arpa/IN/RESINFO seems to inhere more extensive, or ongoing +w > access to a recursive config, with potentially significant impacts for > DOH users in the case of accidents. This is fine for just DOH URI > fields, which don't change often. But other data, not generated by > the DNS operator teams, will prove less agile. > > Without existing appliance support for editing (and not merely rfc3597 > sane passing) of a novel RRType, adoption might be slow, since the DNS > operators in organizations become entrained in the output of other > groups. Many organizations affected by DOH (e.g., banks, mid-sized > and larger corps, ISPs) already have clear delineations in groups > around security, DNS, network operations, customer care, policy and > public statements. Since draft-sah-resolver-information is designed > to have more than just DOH URIs (and potentially could include policy > details relevant to DOH pathing decisions), this seems important. > It seems like any such policy information could be referenced by URL in a RESINFO RR, to support easy editing and separation of access controls. Would a design of that sort address your concerns? Had I realized this years ago, IN/RESINFO still would be the obvious > choice compared to IN/A, since well structured fields encourage app > developers to poll ${SUDN}.arpa for discrete information. But the > existing DOH deployment suggests speeding RESINFO uptake/adoption. > Perhaps also supporting IN/A discovery of DNS filtration policy data > could be useful. > > DNS appliance vendors would support IN/RESINFO of course, some quickly, > some eventually. But IN/A could be done today on existing installs. > Perhaps a billion+ people have DOH available (currently off), and some > are using it to start small office fires. Exposing LAN policy to the > apps quickly would help. And it would discipline the anti-malware DNS > filtration industry around transparency-to-the-stub. (We can expect > other DNS-abusive censors to continue to provide few or misleading > details, which the browsers might well ignore as likely L8 imposed > firewalls.) > > > Both Google and Mozilla have said here that they look forward to a > > way to find the DoH server associated with a user's resolver, so we > > hope that the work can move forward at a reasonable pace. However, > > if people in this WG think we're doing it wrong by having a general > > mechanism for querying resolvers, please speak up here. > > Since users are already turning on DOH, there's urgency in exposing > network policy information to apps. Not just the DOH URI, but the > imperative some networks see in DNS anti-malware filtering, as they > now shop for PACs/TLS interception solutions, post-DOH. > > If you're revising draft-sah-resolver-information, could it support > both A and RESINFO? (The former for rapid uptake/captive portal use > and avoiding portal triggering, the latter for standardized app > integration, once DNS appliances support federated editing.) Or > anything just short of overloading TXT records once again? > Cf. https://www.cafepress.com/nxdomain/8592477 > > Or have I missed something making IN/RESINFO the exclusive solution > and not merely superior to IN/A? > > I do like the general compass direction of > draft-sah-resolver-information: telling users about recursive DNS > settings and policy is wonderful. This informs user consent and > alternative resolution path choices. My thanks to the authors > for drafting their solution. > > -- > David Dagon > dagon@sudo.sh > D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000425882058990184c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 23, 2019 at 11:24 AM dago= n <dagon@sudo.sh> wrote:
On Wed, May 22, 2019 at 10:49:45PM +0000, Paul Hoffman wrote= :

> Greetings again. For those in the DOH WG who are not also in the
> DNSOP WG, you may not have seen that Puneet Sood, Roy Arends and I
> have new drafts that would replace
> draft-ietf-doh-resolver-associated-doh. During IETF 104, and on this > list, people asked why the mechanisms in
> draft-ietf-doh-resolver-associated-doh were only for DoH. In
> response, we created draft-sah-resolver-information and
> draft-sah-resinfo-doh. The former is a general way of asking
> resolvers for information about them; the latter is the definition
> of the DoH-related information.

One comment on draft-sah-resinfo-doh:

Compare the use of a new RRType, ${SUDN}.arpa/IN/RESINFO, which yields
a structured set of I-JSON fields, to a simple ${SUDN}.arpa/IN/A
approach, with merely returns a record pointing to an appropriate
server with resolver policy statements, perhaps on a web site or yaml
("This recursive blocks malware and ads, and per corporate policy all<= br> resolution must be local. Resolve elsewhere at your professional
peril.=C2=A0 This is an M&A audit requirement."), and/or other met= a data
useful to the stub's DNS path choices.

There are many advantages to RESINFO beyond well structured data,
including identifying/addressing stray ${SUDN}.arpa queries seen just
above-the-recursive by local operators (REFUSED, etc?).=C2=A0 And the
networks who wish to block DOH will likely trigger on
${SUDN}.arpa/IN/RESINFO?=C2=A0 queries, for captive portal education,
whereas triggering on SUDN IN/A? for DOH identification would have too
many false positives induced by DNS prefetching.=C2=A0 (Aside: This was yet=
another global DNS accommodation for browsers, btw.)

Although IN/RESINFO is the correct approach, compared to IN/A, I've
been recently alerted to one potential draw back to a new RRType: some
of the meta data one hopes to expose (e.g., filtration policy) might
be easier to add or edit out-of-zone.

That is, the simple ${SUDN}.arpa/IN/A approach points to a web site,
which any summer intern in the legal department can edit (after the
DNS operators add their rrset and close the ticket).=C2=A0 In contrast,
${SUDN}.arpa/IN/RESINFO seems to inhere more extensive, or ongoing +w
access to a recursive config, with potentially significant impacts for
DOH users in the case of accidents.=C2=A0 This is fine for just DOH URI
fields, which don't change often.=C2=A0 But other data, not generated b= y
the DNS operator teams, will prove less agile.

Without existing appliance support for editing (and not merely rfc3597
sane passing) of a novel RRType, adoption might be slow, since the DNS
operators in organizations become entrained in the output of other
groups.=C2=A0 Many organizations affected by DOH (e.g., banks, mid-sized and larger corps, ISPs) already have clear delineations in groups
around security, DNS, network operations, customer care, policy and
public statements.=C2=A0 Since draft-sah-resolver-information is designed to have more than just DOH URIs (and potentially could include policy
details relevant to DOH pathing decisions), this seems important.

It seems like any such policy information could = be referenced by URL in a RESINFO RR, to support easy editing and separatio= n of access controls.=C2=A0 Would a design of that sort address your concer= ns?

Had I realized this years ago, IN/RESINFO still would be the obvious
choice compared to IN/A, since well structured fields encourage app
developers to poll ${SUDN}.arpa for discrete information.=C2=A0 But the
existing DOH deployment suggests speeding RESINFO uptake/adoption.
Perhaps also supporting IN/A discovery of DNS filtration policy data
could be useful.

DNS appliance vendors would support IN/RESINFO of course, some quickly,
some eventually.=C2=A0 But IN/A could be done today on existing installs. Perhaps a billion+ people have DOH available (currently off), and some
are using it to start small office fires.=C2=A0 Exposing LAN policy to the<= br> apps quickly would help.=C2=A0 And it would discipline the anti-malware DNS=
filtration industry around transparency-to-the-stub.=C2=A0 (We can expect other DNS-abusive censors to continue to provide few or misleading
details, which the browsers might well ignore as likely L8 imposed
firewalls.)

>=C2=A0 Both Google and Mozilla have said here that they look forward to= a
> way to find the DoH server associated with a user's resolver, so w= e
> hope that the work can move forward at a reasonable pace. However,
> if people in this WG think we're doing it wrong by having a genera= l
> mechanism for querying resolvers, please speak up here.

Since users are already turning on DOH, there's urgency in exposing
network policy information to apps.=C2=A0 Not just the DOH URI, but the
imperative some networks see in DNS anti-malware filtering, as they
now shop for PACs/TLS interception solutions, post-DOH.

If you're revising draft-sah-resolver-information, could it support
both A and RESINFO?=C2=A0 (The former for rapid uptake/captive portal use and avoiding portal triggering, the latter for standardized app
integration, once DNS appliances support federated editing.)=C2=A0 Or
anything just short of overloading TXT records once again?
Cf. https://www.cafepress.com/nxdomain/8592477

Or have I missed something making IN/RESINFO the exclusive solution
and not merely superior to IN/A?

I do like the general compass direction of
draft-sah-resolver-information: telling users about recursive DNS
settings and policy is wonderful.=C2=A0 This informs user consent and
alternative resolution path choices.=C2=A0 My thanks to the authors
for drafting their solution.

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

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000425882058990184c-- --00000000000049e8fb0589901869 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCa2gkRjGlZ1pj4I0xRtKoa NMcQ688k3NSugB5x++qYVjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA1MjMxNTU0MTlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAq+BJ+GEZDq/CrmdKBoKKHfLAhV13OIcFDiVwiLYF uOo2N1LAvf3aV9MqSM6/2BzzMwhTIfDVjwxf9CFtV0HYuFI4ASGwsmKiP4Ix2qk1QlPMQbHMNqFl 8KuSkZxwXqwEso3+vPTDFGzDcYM1nVlZflFgk1gS1h4np4NcngYmRiwaMpVlfMv9ej945C6y4rOw 1RwXF2qiVTPqRKcUlUHFs4qfT1vIb6AIKu96k6r3Ab17pl7BSKRRtF2TRcxWeQumFsJ0NPjiNhgE n8GwmUh4ebZLJS0qDdNIJm44ZZ/XugkPvK4hCH2ooL8dsXU0HKQKDTMix9c+CDcpKpC+0UF4ag== --00000000000049e8fb0589901869--