Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 04 May 2021 12:29 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0219A3A327D for <dns-privacy@ietfa.amsl.com>; Tue, 4 May 2021 05:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=verisign.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 QReeFrj9E4rw for <dns-privacy@ietfa.amsl.com>; Tue, 4 May 2021 05:28:55 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 AAA693A327C for <dns-privacy@ietf.org>; Tue, 4 May 2021 05:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11734; q=dns/txt; s=VRSN; t=1620131335; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Dow2OEuDA5KfSrcZpd1xRx9l+AKEfoJmRbGqClRmTkw=; b=JChZIMFI+iTzQt4I76+KDKUK1prvyB2GvV9lYdAi427i9eS7r4tajV4a hA9eRSqsyeXKByHVeTKkjzJnLkEqWArLS52MZ/vlIdSqFKSFdfUmaZiSn Uto7Swih9vFHBsEUK5NpFZNEl0NPjBuvABjtTI/JenP3VRHRChGRqaNHH HGQ0htJ24OmNycYQkfcLtsrdYFFrSm04Uamt+snc3GVfWOQRSZgGJMVTe Ibhyhr0C9L9y3IbwO5s3QgcubQy1GlTL0YXAMQUo+QjoO9hii4xQyMcmS ezFoqYEbJ8X8vJyyg1XBHpo/gzb+HbE8wYZ2MeyTjds0M680JlIuW3Gyp w==;
IronPort-SDR: MURUl5IZVZx2/RZ59rgO/UX/oo5cadR1mJ2NzbAWcLD/N3omiXioUJAjWdA8+L517UiOLdyCuS pzG73xFDzJRU1+Yj5DyIKd3retuP9ysfobtmwxvh5XKsZyLSzwVWHCL86N8NtgadWuGy7Dj6fz DFGfAinU5AYMK4ReMdi4ZpJpTFzsVch269A8MkXm5HfZE8hmgvC1nMI3x6iwXvkE4Yal34V7jn g3AN625xHGYVw8o9N1YkdT/JV32DpIFKNQ50FAR3iO+do57C2yMzz/C79jSYjp1NIvtg/7SrGI bnI=
IronPort-HdrOrdr: A9a23:C8ASl6iXZH/qmiTuF2zYSD3rNXBQX0Zw3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+YsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmuZ tIW5NVTOf9BV0St6vHySGzGdo43Z2j+Kenme/Rwx5WPHhXQotn6Bp0DRveN0VwShVPC5ZRLu vl2uNsoT28dXMLKvmqH3VtZZmJm/TnnI/rCCR2YCIPxxKJiVqTiILSNzi98lMgXyhUwbEkmF K12TDRwqm4qfm0xlv9+gbonvJrseDswNdCG8CA4/J9Ql6H5GeVTb9sRqGYu3QNqPyvgWxa1O XkmQsqPMh49hrqDwOIiCbtwAXp3XIP7HLv2Daj8B/eiPH5Xz4zBo59g5tYeHLimi8dlex7uZ g7vF6xht5yN1ftjS7979/HW1VBjUyvu0cvluYVkjh2TZYeQKU5l/1TwGplVLM7WA7q4oEuF+ djSOvG4uxNTF+cZ3fF+kFy3d2XWGgpFBvueDlPhuWllxxt2FxpxUoRw8IS2l0a8ogmdpVC7+ PYdoNlia9JVc1TSa5mHu8OTY+WBwX2MF3xGVPXBW6iOLAMOnrLpZKyyq4y/vuWdJsBy4Z3l4 /GVF9eqG4ua0PjAcCDx/Rwg1HwaVT4eQ6o5tBV5pB/tLG5bqHsKze/RFcnlNblo/h3OLyaZ9 +DfLZtR9PzJ2rnHohEmyfkXYNJFHUYWMoJ/tIyW1eEpNPXOpTn39arM8r7Ff7IK3IJS2n/Cn wMUHzYP8Nb9H2mXXf+nVzWQHPiekv2+JpqC6jE9+0PyIwAX7c8/DQ9uBCc3IWmODdCuqs5cA 9VO7X8iJ62omGw4CLV9WlzIwFcCUxU+b3kVHtPqWYxQgHJWIdGn+/aVXFZ3XOBKBM6ctjfFx RHoU9rvYitKYaL+CwkA9W7E26TgncJvkiWR5MElqDr37ahRroISrIdHI14D0HiCgF8kwcCkh Y5VCY0AmvkUg7IpYrgppoOH+3bf8R7m26QULRpgEOak16dq8EpTmYcRBi0X6es8EETbjJJm1 x89LIeirKcmTCpbXAymvg8LUckUhXqPJtWSAuCf4lagbbtZUV5SnqLnyWTj1UpdnPt7Fh6vB 2WEQSEPfXKCEFaoHZWz+Lj9051bHyUeytLGwRHmJw4EWTNoXBo1+CXIqK1zmuKc1MHhuUQKi vMbzdXIgRgwbmMpWmosSfHEXUt3ZM1OOPBSLwlbrHIw3uobJSSirtuJY4mwL91cNT19uMbW+ OWfAGYaDv+FuMywgSQ4nIoIjN9pnUome7hsSeVpVSQzTo6G77fMV5mT7YUL5WH42/oS+2B3Z 95gdg21NHAR1nZe5qD0+XafjRDIhTcrSqqVOkus4lTpr93u71pHZXXOAG4nE1vzVE7NoPzm0 wfSqggv+yENY9rYsAIeyVWulAuj8+CKUM3sgrwRu8yFGtd/kPzLpeM+f7Pr7FqH0iK4A33Ml Ob+zdG//jEUzCYvIRqeZ4YMCBTcgwk9H9m/OmebIXeBwWhavFb8DOBQwGAWa4YTLLABK4ZoR l76cyZhuObdyL33wbLoDtwS5g+g1qPUIe1GwKDGelB7ty8NxCNm8KRkbGOpSayUCC8YUgDn4 FJflwMYsBbjzEsnOQMo1WPdpA=
X-IronPort-AV: E=Sophos;i="5.82,272,1613451600"; d="scan'208,217";a="7026414"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Tue, 4 May 2021 08:28:53 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2242.008; Tue, 4 May 2021 08:28:53 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "bemasc=40google.com@dmarc.ietf.org" <bemasc=40google.com@dmarc.ietf.org>, "peter.van.dijk@powerdns.com" <peter.van.dijk@powerdns.com>
CC: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS
Thread-Index: AQHXQGBI2VIKpybQzEebEBhp0snOO6rTQNSw
Date: Tue, 4 May 2021 12:28:52 +0000
Message-ID: <830b24c9efe3489098a5ad8cb25282c6@verisign.com>
References: <161997426960.11261.17005541940248978884@ietfa.amsl.com> <4490d7382c7efb10bf5689f655bf890d7b76bed8.camel@powerdns.com> <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_830b24c9efe3489098a5ad8cb25282c6verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/GzoXStg83hZdll9DSxOwrgoVAs8>
Subject: Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 12:29:01 -0000




From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Ben Schwartz
Sent: Monday, May 3, 2021 5:07 PM
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Subject: [EXTERNAL] Re: [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS



Thanks for this draft; I think it's clear and could be a helpful introduction.



>    If the cache has no positive or negative answers for any DNS SVCB

   record for any of a zone's authoritative servers, the resolver needs
   to send queries for the DNS SVCB records for some or all of the
   zone's authoritative servers.



I think it would be worth rephrasing the words "needs to" here.  To me, this sounds like a normative requirement to perform these queries, but I suspect that's not what you mean.



>    Because some authoritative servers or middleboxes are misconfigured,
   requests for unknown RRtypes might be ignored by them.  Resolvers
   should be ready to deal with timeouts or other bad responses to their
   SVCB queries.



This sounds a bit pessimistic.  Ralf Weber recently published some figures showing a ~0.03% failure rate.  For security (in the authenticated case), any mitigations here are very delicate, and I'm a bit concerned about the brief treatment here.  (The SVCB draft has an extensive discussion: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1<https://secure-web.cisco.com/1KnxioJRTsf2uU1VW48qiLA_fHonJvyIlr7lqXBxF6-KQR8Euua8L4CgmpRZkuoe3cS_yTHaQPg9FD3nkj_RHY-7yCOcDuoR0vc6wkDa4uosV1tNCYOe3JcJGQw4KVsb_RRkzvTdQzxZbbHaeKPNC-UoXqfqMnCJOBub4XxG4JGbTo9MgdOEOKuLYS5gLGHiTqG9dVKWxkkqoBQ-9y8O0rUmFU45Xz9IAIBDvgTzxMUs3l2voDFu2pMpIcyVBnHF2/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-svcb-https%23section-3.1>.1>.)



>    DNS SVCB records act as advisory information for resolvers about the

   encrypted protocols that are supported.  They can be thought of as
   similar to NS records on the parent side of a zone cut: advisory
   enough to act on, but not authoritative.  Given this, authoritative
   servers that know the DNS SCVB records associated with NS records for
   any child zones MAY include those DNS SCVB records in the Additional
   section of responses to queries to a parent authoritative server.



This sounds like a restatement of the definition of "glue".  Can we simply declare that these records are "glue"?



[SAH] …and does this imply that we need to extend EPP to populate these records?



Scott