[Doh] DNS Resolver Identification and Use (DRIU) BoF.
Warren Kumari <email@example.com> Tue, 08 May 2018 12:17 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AF12DB6F for <firstname.lastname@example.org>; Tue, 8 May 2018 05:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbXTG9BMjxGq for <email@example.com>; Tue, 8 May 2018 05:17:20 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8248812DB6D for <firstname.lastname@example.org>; Tue, 8 May 2018 05:17:20 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id o4-v6so32058959wrm.0 for <email@example.com>; Tue, 08 May 2018 05:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=z1bXUmAhxGOpW7sv9Lnfkp08wGMMWj11ScW7hSMDvEY=; b=d6O8t38owHKEfpKejBgLyY5lhi3eQIPARnbALSixeG6hzBOvLHfV87WMaNPMhw1aLY jNhHKcY6xWwe56rC6KzJZnWBXHdt63T2SIsIcRqmcAoo5+3nFA4rs9DBJAzfZqGI9c49 fgUMm/5od9LPl4wlGxYIbDGdfWZtk/q6mvtOQFmFmeOSXXSXizdpnG3XMIfQSdnWiAoy QsAHNIgWBX3QxvTP6v9eSBFd/nCub7ve9x/9Xj2SEVZSg+5AL3N6izcGqeG6R0bfBHfs ULgCmWi1ttbDbSSBnYJn6Uf4b+Vf4ictoxOrJsCH95Zpo81sKfZrqtpYeiRsf/Aknfv3 Rg4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z1bXUmAhxGOpW7sv9Lnfkp08wGMMWj11ScW7hSMDvEY=; b=Dp/IxDRd3rNpd1N7bQPuY/RPGHU9ik82G784ROUyiYU7EwPw53s3FWICBRj1oVpsy1 qBFFrEHkwsSp4pzs6xr31YZ+DpU5MTGNuLwX8LZmb90jkN5TIYX2XzxevoGx0FPg6SIT FJuX2SNk3Qad24+p7PM7ftKLJLwz4IUUeBPm2Y0jlhMWB4GwBhdOyz1YPuET4TOP7kTr w/CUoGvNAa7CXO2xPZGbjemK4vBu/hAoL7z7xcmGA/NYN+IR+nyYPa//fGC2DWhAH4Zr c+Eq259RZflibdE7j7mQ8rOEGENa/B1h3+QqxvpCw90newvgXYL5mXjl9JtfHWtTxfh6 nRWw==
X-Gm-Message-State: ALQs6tDdoLgQaG17cbRSs/pvzrmi8Yc7KedqdArp5aP6Yya8MRSJZNou sdhIDOp+eiQxSOan9Lz2KXwYXwMsPUgmMa+qL6bdHViB74s=
X-Received: by 2002:adf:e1ce:: with SMTP id l14-v6mr32320100wri.148.1525781838473; Tue, 08 May 2018 05:17:18 -0700 (PDT)
From: Warren Kumari <firstname.lastname@example.org>
Date: Tue, 08 May 2018 12:16:42 +0000
Content-Type: text/plain; charset="UTF-8"
Subject: [Doh] DNS Resolver Identification and Use (DRIU) BoF.
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2018 12:17:23 -0000
[ Apparently first version of this mail didn't arrive, resending. ] Hi all, I wanted to mention a proposed (non-WG forming) BoF -- DNS Resolver Identification and Use (DRIU). The description is below, and the mailing list is: https://www.ietf.org/mailman/listinfo/driu I think that this will be of interest to many... -------- The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties. This BoF is not intended to form a Working Group. Instead, it is meant to bring together authors of various WG and individual drafts to prevent overlap and to garner interest in particular topics. Because many people are thinking of writing documents covering various related topics, it would be good to have a mailing list and a BoF to help cross-pollinate the ideas. Some of the topics that would be on-topic would be: * How to identify DNS-over-different-transport in protocols such as DHCP, and in user-accessible configuration * Security properties of the various flavors of transport-secured DNS * TLS authentication when the identifier is an IP address (which is most common for identifying DNS resolvers) * How resolvers can express their capabilities to clients who might care (such as "this resolver does DNSSEC validation" or "this resolver passes client subnet information to authoritative servers") * Identifying a resolver in the "dns:" URI scheme in RFC 4501. A related question is whether there should be a "dnss:" URI scheme whose semantics mean "Look up this name, but only use a secure DNS server", where "secure" would need to be defined. * There are likely additional related topics that the BoF and mailing list might delve into. ----- W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
- [Doh] DNS Resolver Identification and Use (DRIU) … Warren Kumari