非官方中文译本声明：本页为 IETF RFC 7858《Specification for DNS over Transport Layer Security (TLS)》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7858。

RFC 7858《DNS over TLS（DoT）规范》中文译本

IETF · RFC 7858 · 标准跟踪（Standards Track）· 2016 年 5 月

摘要

本文档描述如何使用传输层安全（Transport Layer Security，TLS）来为 DNS 提供隐私保护。TLS 所提供的加密消除了在网络中窃听 DNS 查询、以及在路径上（on-path）篡改 DNS 查询的机会，例如 RFC 7626 中所讨论的那些情形。此外，本文档为 DNS over TLS 规定了两种使用剖面（usage profile），并就性能考量给出建议，以尽量减小在 DNS 中使用 TCP 与 TLS 所带来的开销。

按照 DPRIVE 工作组的章程，本文档聚焦于保护存根（stub）到递归（recursive）之间的流量。这并不妨碍该协议未来被应用于递归到权威（authoritative）之间的流量。

1. 引言

今天，几乎所有的 DNS 查询 [RFC1034] [RFC1035] 都是以未加密的方式发送的，这使得它们容易被能够接触到网络信道的攻击者窃听，从而降低了查询发起方的隐私性。近来的新闻报道加剧了这些担忧，而 IETF 近期的工作也已对 DNS 的隐私考量作出了专门说明 [RFC7626]。

此前的工作已经解决了 DNS 安全的某些方面，但直到最近，围绕 DNS 客户端与服务器之间隐私的工作仍然很少。DNS 安全扩展（DNSSEC）[RFC4033] 通过定义对区（zone）进行密码学签名的机制来提供响应完整性，使最终用户（或其第一跳解析器）能够验证应答是否正确。DNSSEC 在设计意图上并不保护请求与响应的隐私。传统上，要么隐私未被视为 DNS 流量的一项需求，要么就是假定网络流量已足够私密；然而，由于近期发生的一些事件 [RFC7258]，这些认知正在发生变化。

其他有潜力在 DNS 客户端与服务器之间实现加密的工作包括 DNSCurve [DNSCurve]、DNSCrypt [DNSCRYPT-WEBSITE]、Confidential DNS [CONFIDENTIAL-DNS] 以及 IPSECA [IPSECA]。除本规范之外，DPRIVE 工作组还采纳了一项关于 DNS over 数据报传输层安全（DTLS）的提案 [DNSoD]。

本文档描述在一个熟知端口（well-known port）上使用 DNS over TLS，同时就性能考量给出建议，以尽量减小在 DNS 中使用 TCP 与 TLS 所带来的开销。

DNS over TLS 的发起过程非常直接。通过在一个熟知端口上建立连接，客户端与服务器即预期并同意协商一个 TLS 会话来保护该信道。部署将是渐进的。并非所有服务器都会支持 DNS over TLS，而该熟知端口也可能被某些防火墙阻断。客户端应当持续记录哪些服务器支持 TLS、哪些不支持。客户端与服务器都将遵循 [BCP195] 的 TLS 实现建议与安全考量。

此处描述的协议适用于存根客户端（stub client）与递归服务器之间的查询与响应。它在递归客户端与权威服务器之间也可能同样奏效，但按照 DNS 私密交换（DNS PRIVate Exchange，DPRIVE）工作组当前的章程，该协议的这一应用不在其范围之内。

本文档在第 4 节描述了两种提供不同隐私保障级别的剖面：机会式隐私剖面（opportunistic privacy profile）与带外密钥固定隐私剖面（out-of-band key-pinned privacy profile）。预计未来会有一份基于 [TLS-DTLS-PROFILES] 的文档，进一步描述适用于 DNS over TLS 与 DNS over DTLS 的其他隐私剖面。

本文档较早的草案版本曾描述过一种将 DNS-over-TCP 连接升级为 DNS-over-TLS 会话的技术，本质上就是「DNS 版的 STARTTLS」。为简化协议，本文档现在仅使用一个熟知端口来指明 TLS 的使用，略去了升级式做法。升级式做法不再出现在本文档中，本文档现在专注于使用熟知端口来承载 DNS over TLS。

2. 关键词

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 RFC 2119 [RFC2119] 中的描述进行解释。

3. DNS-over-TLS 会话的建立与管理

3.1. 会话发起

在默认情况下，支持 DNS over TLS 的 DNS 服务器必须（MUST）在 853 端口上监听并接受 TCP 连接，除非它与其客户端之间另有约定，使用 853 之外的端口来承载 DNS over TLS。若要使用 853 以外的端口，客户端与服务器双方的软件都需要提供相应的配置项。

在默认情况下，希望从某台特定服务器获得 DNS over TLS 隐私保护的 DNS 客户端必须（MUST）向该服务器的 853 端口建立 TCP 连接，除非它与其服务器之间另有约定，使用 853 之外的端口来承载 DNS over TLS。这样的另一端口不得（MUST NOT）为 53 端口，但可以（MAY）取自「先到先得」（first-come, first-served）端口范围。之所以建议不将 53 端口用于 DNS over TLS，是为了避免在选择使用或不使用 TLS 时产生复杂性，并降低降级攻击的风险。此 TCP 连接上的首次数据交换必须（MUST）是客户端与服务器按照 [RFC5246] 中描述的过程发起 TLS 握手。

DNS 客户端与服务器不得（MUST NOT）使用 853 端口传输明文 DNS 报文。在任何用于 DNS over TLS 的端口上（例如，包括 TLS 握手失败之后），DNS 客户端不得（MUST NOT）发送明文 DNS 报文，DNS 服务器也不得（MUST NOT）对明文 DNS 报文作出响应。将受保护数据与不受保护数据混用会带来重大的安全问题，正因如此，某台服务器为 DNS over TLS 所指定端口上的 TCP 连接，被纯粹保留用于加密通信。

DNS 客户端应当（SHOULD）记住那些不支持 DNS over TLS 的服务器 IP 地址，包括出现超时、连接被拒绝以及 TLS 握手失败的情形，并在一段合理的时间内（例如每台服务器一小时）不再向它们请求 DNS over TLS。遵循带外密钥固定隐私剖面（第 4.2 节）的 DNS 客户端可以（MAY）在重试 DNS-over-TLS 连接失败时更为积极。

3.2. TLS 握手与认证

一旦 DNS 客户端成功地通过 TCP 连接到 DNS over TLS 的熟知端口，它便按照 [BCP195] 中规定的最佳实践继续进行 TLS 握手 [RFC5246]。

随后，客户端将在需要时对服务器进行认证。本文档并不提出新的认证思路。取决于所使用的隐私剖面（第 4 节），DNS 客户端可以选择不要求对服务器进行认证，也可以选择使用一组受信任的主体公钥信息（Subject Public Key Info，SPKI）指纹固定集（pin set）。

TLS 协商完成后，该连接即被加密，从此受到保护而不会被窃听。

3.3. 报文的发送与接收

在已建立的 TLS 会话中，所有报文（请求与响应）必须（MUST）使用 [RFC1035] 第 4.2.2 节所描述的双字节长度字段。出于效率方面的原因，DNS 客户端与服务器应当（SHOULD）把双字节长度字段与该长度字段所描述的报文同时传递给 TCP 层（例如，在一次 "write" 系统调用中），以提高全部数据在单个 TCP 分段中被发送出去的可能性（[RFC7766] 第 8 节）。

为尽量降低时延，客户端应当（SHOULD）在一个 TLS 会话上流水线化（pipeline）地发送多个查询。当 DNS 客户端向服务器发送多个查询时，它不应在发送下一个查询之前等待尚未返回的应答（[RFC7766] 第 6.2.1.1 节）。

由于流水线化的响应可能乱序到达，客户端必须（MUST）使用报文 ID（Message ID）把响应与同一 TLS 连接上尚未完成的查询相匹配。如果响应中包含问题节（Question Section），客户端必须（MUST）匹配 QNAME、QCLASS 与 QTYPE 字段。客户端若未能正确地将响应与未完成的查询相匹配，可能对互操作性造成严重后果（[RFC7766] 第 7 节）。

3.4. 连接复用、关闭与重建

对于使用诸如 "getaddrinfo()" 和 "gethostbyname()" 等库函数的 DNS 客户端，已知目前的实现会为每一次 DNS 查询打开并关闭一条 TCP 连接。为避免出现过多、每条仅承载单个查询的 TCP 连接，客户端应当（SHOULD）复用一条通往递归解析器的 TCP 连接。作为替代方案，它们也可以选择通过 UDP 访问同一台机器上启用了 DNS over TLS 的缓存解析器，再由该解析器使用一条系统级的 TCP 连接连往递归解析器。

为摊薄 TCP 与 TLS 的连接建立成本，客户端与服务器不应（SHOULD NOT）在每次响应之后立即关闭连接。相反，只要资源充足，客户端与服务器应当（SHOULD）为后续查询复用已有连接。在某些情况下，这意味着客户端与服务器可能需要将空闲连接保持打开一段时间。

妥善管理已建立的连接与空闲连接，对 DNS 服务器的健康运行至关重要。DNS over TLS 的实现者应当（SHOULD）遵循 [RFC7766] 所描述的 DNS over TCP 最佳实践。未能做到这一点，可能导致资源耗尽与拒绝服务。

鉴于 [RFC1035] 时代的客户端与服务器实现在 TCP 连接管理方面表现不佳，本文档规定：TLS 的成功协商即表明双方愿意保持空闲的 DNS 连接处于打开状态，这与不使用 TLS 的 DNS over TCP 的超时设置或其他建议无关。换言之，实现本协议的软件被假定支持空闲的持久连接，并已准备好管理多条、可能长期存活的 TCP 连接。

本文档不对空闲连接的超时取值给出具体建议。客户端与服务器应根据可用资源的水平来复用和/或关闭连接。在活动量低的时段，超时可以更长；在活动量高的时段，超时可以更短。该领域当前正在开展的工作也可能有助于 DNS-over-TLS 客户端与服务器选取合适的超时值 [RFC7828] [TDNS]。

保持空闲连接打开的客户端与服务器必须（MUST）能够稳健地应对任何一方终止空闲连接的情况。与当前的 DNS over TCP 一样，DNS 服务器可以（MAY）在任何时刻关闭连接（或许是出于资源受限的原因）。同样与当前的 DNS over TCP 一样，客户端必须（MUST）处理突然关闭的情况，并做好重建连接和/或重试查询的准备。

在重建一条已被终止的 DNS-over-TCP 连接时，正如 [RFC7766] 中所讨论的，TCP 快速打开（TCP Fast Open）[RFC7413] 是有益的。再次强调在 DNS-over-TLS 端口上只能发送加密 DNS 数据这一要求（第 3.2 节）：使用 TCP 快速打开时，客户端与服务器必须（MUST）立即发起或恢复一次 TLS 握手（不得（MUST NOT）交换明文 DNS）。DNS 服务器应当（SHOULD）启用快速 TLS 会话恢复 [RFC5077]，并且在重建连接时应当（SHOULD）使用它。

在关闭连接时，DNS 服务器应当（SHOULD）使用 TLS 的 close-notify 请求，以把 TCP 的 TIME-WAIT 状态转移给客户端。关于优化 DNS over TCP 的其他要求与指导，可参见 [RFC7766]。

4. 使用剖面

本协议提供了灵活性，以适配若干不同的使用场景。本文档定义了两种使用剖面：（1）机会式隐私；（2）带外密钥固定认证——若客户端与某台支持 TLS 的 DNS 服务器之间存在受信任的关系，后者可用于获得更强的隐私保证。更多的认证方法将在一份即将发布的文档 [TLS-DTLS-PROFILES] 中予以定义。

4.1. 机会式隐私剖面

对于机会式隐私，其思路类似于 SMTP 的机会式安全 [RFC7435]：并不强制要求隐私，但在可能的情况下希望获得隐私。

在机会式隐私下，客户端可能从一个不受信任的来源获知某台启用了 TLS 的递归 DNS 解析器。一种可能的流程是：客户端使用 DHCP 的 DNS 服务器选项 [RFC3646] 发现某台启用 TLS 的递归解析器的 IP 地址，然后在 853 端口上尝试 DNS over TLS。对于这样一台被发现的 DNS 服务器，客户端可能会、也可能不会对该解析器进行校验。这些选择最大化了可用性与性能，但也使客户端易受破坏隐私的路径上（on-path）攻击。

机会式隐私可被任何现有客户端采用，但它只有在不存在路径上主动攻击者时才提供隐私。

4.2. 带外密钥固定隐私剖面

带外密钥固定隐私剖面可用于 DNS 客户端与服务器之间已经存在既定信任关系的环境（例如企业网络中的存根到递归、处于有效维护中的合同服务关系，或客户端使用某个公共 DNS 解析器的情形）。该剖面的效果是：客户端仅连接到它能够认证的服务器，从而对其 DNS 数据的隐私性获得强有力的保证。在该剖面下，DNS-over-TLS 服务的运营者应提供针对被固定服务本身的固定值（pin），即直接属于终端实体（end entity）的公钥，或属于某个服务专用私有证书颁发机构（CA）的公钥，而不是某个通用公共 CA 的公钥。

在该剖面中，客户端通过匹配一组 SPKI 指纹来认证服务器，其方式类似于 [RFC7469] 中所描述的做法。在这种带外密钥固定隐私剖面下，出于 [RFC7469] 中所解释的原因，客户端管理员应当（SHOULD）在部署主固定值的同时部署一个备用固定值。备用固定值在密钥轮换（key rollover）时尤其有用，这样服务器运营者就不必与其所有客户端同时协调密钥的切换。在服务器更换密钥之后，应当（SHOULD）以某种安全方式向所有客户端分发更新后的固定集，为未来的密钥轮换做好准备。带外更新固定集的机制不在本文档范围之内。

这样的客户端将只使用那些已经为其提供了 SPKI 指纹固定集的 DNS 服务器。持有一份受信任的、预先部署好的固定集，使客户端能够检测并阻止中间人（person-in-the-middle）攻击与降级攻击。

然而，在配置网络时，已配置的 DNS 服务器可能会暂时不可用。例如，对于处在需要通过网页登录进行认证的网络中的客户端，此类认证可能依赖于对 DNS 的拦截与伪造。在网络配置期间，可以（MAY）使用类似 DNSSEC-trigger [DNSSEC-TRIGGER] 所采用的技术，并意在完成认证后切换到指定的 DNS 提供方。在这种引导（bootstrap）过程中，只要有可能，就必须（MUST）提醒用户此时的 DNS 并不具备隐私性。

在 TLS 连接与握手成功之后，客户端为在已校验的服务器证书链中找到的公钥计算 SPKI 指纹（如果服务器提供的是原始公钥，则针对该原始公钥计算）。如果某个计算出的指纹与所配置的固定值之一完全匹配，客户端便照常继续该连接。否则，客户端必须（MUST）将该 SPKI 校验失败视为不可恢复的错误。附录 A 给出了在实践中如何执行此项认证的详细示例。

本隐私剖面的实现必须（MUST）支持这样一种指纹计算方式：对 X.509 证书 SPKI 的 DER 编码 ASN.1 表示取 SHA-256 [RFC6234] 散列。实现必须（MUST）支持将 SHA-256 指纹表示为 base64 编码的字符串 [RFC4648]。此外还可以（MAY）支持其他指纹类型。

5. 性能考量

DNS over TLS 在会话启动时会带来额外的时延。它同时还需要额外的状态（内存）与更多的处理开销（CPU）。

完整的性能评估不在本规范范围之内。关于 DNS over TLS（以及 DNS over TCP）性能影响的更详细分析，可参见 [TDNS] 与 [RFC7766]。

6. IANA 考虑

IANA 已在「服务名称与传输协议端口号注册表」（Service Name and Transport Protocol Port Number Registry）的系统范围（System Range）中添加了下述取值。该范围的注册表要求经过 IETF 审阅或 IESG 批准 [RFC6335]，本文档中这一熟知 TCP 端口的相关审阅已通过早期分配流程 [RFC7120] 提出申请。

IANA 已为拟议中的 DNS-over-DTLS 协议 [DNSoD] 在 UDP 上保留了相同的端口号。

Service Namedomain-s
Port Number853
Transport Protocol(s)TCP/UDP
AssigneeIESG
ContactIETF Chair
DescriptionDNS query-response protocol run over TLS/DTLS
ReferenceThis document

7. 设计演进

本文档较早的草案版本曾提出一种基于升级的方式来建立 TLS 会话。客户端通过在 DNS 扩展机制（EDNS(0)）的标志字段中设置一个 "TLS OK" 位来表明其对 TLS 的意向。服务器则通过在响应中同样设置该 TLS OK 位来表明接受。

由于我们假定客户端不希望在信道被保护之前泄露任何信息，我们曾提出使用一种「哑查询」（dummy query），供客户端为此目的发送。所提议的查询名为 STARTTLS，查询类型为 TXT，查询类为 CH。

TLS OK 信令方式既有优点也有缺点。一项重要优点是客户端与服务器可以协商 TLS。如果服务器过于繁忙，或不愿向某个特定客户端提供 TLS 服务，它可以对 TLS 探测作出否定响应。一项附带的好处是，服务器可以在实现与部署之前，就（通过查询中的 TLS OK 位）收集 DNS over TLS 的采用情况信息。另一项被寄予期望的优点是 DNS over TLS 有望在 53 端口上工作，也就是说，无需「浪费」另一个端口，也无需在中间盒上部署新的防火墙规则。

然而与此同时，鉴于 EDNS0 标志字段多年来未曾变动，中间盒是否会放行 TLS OK 位并不确定。另一个缺点在于，TLS OK 位可能使降级攻击变得容易，且与中间盒故障难以区分。从性能角度看，基于升级的方式还有一个缺点：哑查询需要额外 1 个 RTT 的时延。

在该提案之后，DNS over DTLS 被单独提出。DNS over DTLS 声称它可以在 53 端口上工作，但这只是因为非 DTLS 服务器会把 DNS-over-DTLS 查询解读为一个响应，也就是说，非 DTLS 服务器观察到 QR 标志被置为 1。虽然这在技术上可行，但似乎并不理想，甚至可能并不可取。

DNS over TLS 与 DNS over DTLS 都可以从单一的熟知端口中获益，从而避免额外的时延以及查询被误解为响应的问题。

8. 安全考虑

使用 DNS over TLS 旨在应对因 DNS 报文可被窃听而产生的隐私风险。它并不解决 DNS 中的其他安全问题，并且存在若干残余风险，可能影响其保护隐私的成效：

  1. 存在针对 TLS 的已知攻击，例如中间人攻击与协议降级攻击。这些是针对 TLS 的通用攻击，并非 DNS over TLS 所特有；关于这些安全问题的讨论请参阅 TLS 系列 RFC。客户端与服务器必须（MUST）遵循 [BCP195] 的 TLS 实现建议与安全考量。DNS 客户端持续记录已知支持 TLS 的服务器，可使客户端能够检测降级攻击。对于没有连接历史、且看不出支持 TLS 的服务器，客户端可以根据其隐私剖面与隐私需求选择：(a) 在有其他服务器可用时改试另一台服务器，(b) 在不使用 TLS 的情况下继续，或 (c) 拒绝转发该查询。
  2. 某些网络中存在中间盒（middlebox）[RFC3234]，且已知它们会干扰正常的 DNS 解析。为 DNS over TLS 使用一个专用端口应能避免此类干扰。总体而言，尝试 TLS 但失败的客户端可以根据其隐私剖面与隐私需求，或者回退到未加密的 DNS，或者等待并稍后重试。
  3. 任何以明文进行的 DNS 协议交互都可能被中间人攻击者修改。例如，未加密的查询与响应可能在客户端与服务器之间经由 53 端口发生。出于这一原因，客户端可以（MAY）丢弃以明文通告的、关于服务器能力的缓存信息。
  4. 本文档本身并未规定抵御已知流量分析或旁路泄露的思路。即便报文已被加密，位置有利的一方仍可能通过分析报文的时序与大小获知某些细节。客户端与服务器可以考虑使用某种填充（padding）方法，以应对因报文大小造成的隐私泄露 [RFC7830]。由于流量分析可以基于多种模式与多种分类器，仅靠简单的填充方案可能不足以缓解此类攻击。不过，填充将成为未来可能逐步发展出的、针对流量分析攻击的更复杂缓解措施的一部分。在填充使用方式上能够提供灵活性的实现者，或许更有条件让此类缓解措施在未来得以部署。

如前所述，DNSSEC 与 DNS over TLS 是相互独立且完全兼容的协议，各自解决不同的问题。使用其中之一并不会削弱对另一者的需要，也不会削弱另一者的用处。

9. 参考文献

9.1. 规范性参考文献

9.2. 资料性参考文献

附录 A. 带外密钥固定隐私剖面示例

本节基于一个最小固定集（两个固定值）给出一个示例，说明带外密钥固定隐私剖面在实践中可以如何运作。

某个 DNS 客户端系统被配置了来自某网络服务的带外密钥固定隐私剖面，所使用的固定集包含两个固定值。以 HTTP 公钥固定（HPKP）[RFC7469] 的风格表示，这两个固定值为：

pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="

该客户端还配置了它所期望的 DNS 服务器的 IP 地址：例如 192.0.2.3 与 2001:db8::2:4。

客户端连接到其中一个地址的 TCP 853 端口并开始 TLS 握手：协商使用带 Diffie-Hellman 密钥交换的 TLS 1.2。服务器发送一条包含三张证书（A、B 和 C）列表的证书报文，并用证书 A 中的公钥正确地对 ServerKeyExchange 报文进行签名。

此时客户端取证书 A 中 SPKI 的 SHA-256 摘要，并将其与固定集中的两个固定值逐一比较。只要有任一固定值匹配，校验即告成功；客户端继续该 TLS 连接，并可以发出它的第一个 DNS 查询。

如果两个固定值都不匹配证书 A 的 SPKI，客户端便验证证书 A 是否确实由证书 B 签发。如果是，则取证书 B 中 SPKI 的 SHA-256 摘要，并与固定集中的两个固定值逐一比较。只要有任一固定值匹配，校验即告成功。否则，客户端再验证 B 是否由 C 签发，然后将各固定值与 C 的 SPKI 摘要进行比较。

如果在密码学上有效的证书链中，没有任何一个 SPKI 与固定集中的任何固定值相匹配，客户端就以错误方式关闭该连接，并将该 IP 地址标记为失败。

致谢（Acknowledgments）

作者们谨此感谢 Stephane Bortzmeyer、John Dickinson、Brian Haberman、Christian Huitema、Shumon Huque、Simon Joseffson、Kim-Minh Kaplan、Simon Kelley、Warren Kumari、John Levine、Ilari Liusvaara、Bill Manning、George Michaelson、Eric Osterweil、Jinmei Tatuya、Tim Wicinski 与 Glen Wiley 对本规范的审阅。他们还要感谢 Nikita Somaiya 在这一构想上所做的早期工作。

Zi Hu、Liang Zhu 与 John Heidemann 在本文档上的工作，部分由美国国土安全部（DHS）科学技术司下属的国土安全先进研究计划局（HSARPA）网络安全处 BAA 11-01-RIKA 资助，以及由空军研究实验室信息处依协议编号 FA8750-12-2-0344 与合同编号 D08PC75599 资助。

贡献者（Contributors）

以下人士对本文档作出了重要贡献：

Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
United Kingdom

Email: sara@sinodun.com
URI: http://sinodun.com

Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
United States

作者地址（Authors' Addresses）

Zi Hu
USC/Information Sciences Institute
4676 Admiralty Way, Suite 1133
Marina del Rey, CA 90292
United States

Phone: +1-213-587-1057
Email: zihu@outlook.com

Liang Zhu
USC/Information Sciences Institute
4676 Admiralty Way, Suite 1133
Marina del Rey, CA 90292
United States

Phone: +1-310-448-8323
Email: liangzhu@usc.edu

John Heidemann
USC/Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
United States

Phone: +1-310-822-1511
Email: johnh@isi.edu

Allison Mankin
Independent

Phone: +1-301-728-7198
Email: Allison.mankin@gmail.com

Duane Wessels
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States

Phone: +1-703-948-3200
Email: dwessels@verisign.com

Paul Hoffman
ICANN

Email: paul.hoffman@icann.org