rfc6762 中文翻译第一部分

原文地址：

https://tools.ietf.org/html/rfc6762

Abstract-摘要

由于网络设备变得更小、更便捷、更普遍，操作较少配置的基础设备的能力变得越来越重要。特别的，在缺少传统的DNS服务器时，查找DNS资源记录数据类型（包括但不限于，主机名）的能力是十分有用的。

多播DNS 提供了这种在没有传统单播DNS服务器时，能在本地链路执行类似DNS操作的能力。此外，多播DNS指定一部分的DNS域名可供本地免费使用，而不需要支付任何年

费，并且无需设立委托方或配置传统DNS服务器来解析这些域名。

多播DNS主要的优点是：1.它们只需要很少的或者零管理零配置来启动；2.它们可以在没有基础DNS服务器设施时工作；3.它们在基础设施故障时仍然能工作；

Status of This Memo-本文档的状态

这是一篇互联网标准文档。

这篇文档由IETF产出，它代表了IETF团体的认可。它受到了公众审查并且获得了IESG的批准发布。关于互联网标准的更多信息请看https://tools.ietf.org/html/rfc5741#section-2

Copyright Notice-版权声明

所有版权归IETF 和文档作者所有。

本文件从出版文件生效日期起，便受BCP 78和IETF的法律约束（http://trustee.ietf.org/license-info）。请仔细查看这些文档，因为里面描述了你的权利和限制。从本文档中提取的代码组件必须包括简化BSD许可文本，如第4.e节所述

法律规定，并且如在简化BSD许可证中描述的是没有保证。

本文档可能包含IETF文档或IETF的材料或者在2008年11月10日之前发布或公开的文稿.一些材料中控制版权的人可能没有授予IETF 在IETF标准过程之外修改此类材料的权利。没有获得足够的许可，本文档不得在IETF标准程序之外修改，并且其衍生作品可能也不能在IETF标准过程之外创建，除了作为RFC出版需要格式化或将其翻译成其他语言。

1. Introduction-介绍

多播DNS 和伴随其出现的 DNS-Based Service Discovery RFC6763 技术是为IP网络更容易使用和做到零配置而产生，众所周知的AppleTalk RFC6760也是如此；读该文档时，了解zeroconf和自动本地链路寻址（RFC3927 RFC4862 )是十分有帮助的。

多播DNS大量借用了已经存在的DNS协议 [RFC1034] [RFC1035] [RFC6195]；使用已经存在的DNS消息结构，命名语法，和资源记录类型。本文不指定新的操作代码和响应代码。本文描述了客户端如何通过IP 多播发送类似DNS的请求，以及主机群如何配合

共同的使用有效的方式去应答。

2. Conventions and Terminology Used in This Document-本文档中使用的约定和术语

关键词“必须”，“不得”，“要求”，“即将”，“不即将”“应该”，“不应该”，“建议”，“可能”和“可选”应被解释成“在RFC中使用的表示需求级别的关键字“[ RFC2119 ]。

本文档使用术语“组播DNS”时，其意思是：“客户端通过在IP上发送类DNS的UDP查询和组播到UDP端口5353发送响应信息，对类似DNS的资源执行类似DNS的查询记录“。为什么选择UDP端口5353在附录A中讨论。

本文档使用术语“主机名”在严格意义上来表示具有IPv4或IPv6地址记录的完全合格域名。它不使用术语“主机名”像通常使用似的，不正确的只指主机合格域名的第一个DNS标签。

DNS（或mDNS）包包含了IP协议头中的IP生存时间（TTL），是个有效的包跳数计数限制，其为了防止路由环路。每个资源记录还包含一个TTL，这是资源记录可以缓存的秒数。本文档使用术语“IP TTL”来指代IP报头TTL（跳跃限制），术语“RR TTL”或仅仅是“TTL”指资源记录TTL（缓存生存期）。

DNS格式的消息包含一个头，一个问题部分，然后是答案，权限和其他记录部分。答案、权限和附加记录部分保存了同样格式的资源记录。本文档描述的问题同样适用于这三个部分，它使用术语“资源记录”来统称这三个部分。

本文档使用术语“共享”和“唯一”当提及资源记录集[ RFC1034 ]时：

“共享”资源记录集是指多个多播DNS的响应者可能具有相同name，rrtype和rrclass的记录, 并且多个响应者可以响应同一查询。

“唯一”资源记录集是指所有具有该name，rrtype和rrclass的纪录在概念上只被一个响应者所有，并且期望最多一个响应者响应该记录。声明拥有唯一资源记录集之前，响应者必须探测以验证是否其他响应者已经声明该集合的所有权，如在第8.1节“探测”中所述。（用于容错等原因，有时允许有多个响应者回答特定的“唯一”资源记录集，但这种合作响应者必须给出相同rdata的纪录。如果他们不给出相同的rdata，则探测步骤将拒绝因为与已经公布的记录内容不一致）；

严格地说，术语“共享”和“唯一”适用于资源记录集，而不是单个资源记录。但是，为了有时方便谈“共享资源记录”和“唯一”资源记录“。当使用这种方式时，单个资源记录应该理解为其指作为“共享”或“唯一”资源记录集的一员。

3.Multicast DNS Names-组播DNS名称

对于某个组织或个人的主机，需要拥有部分DNS命名空间的可以分配一个全局的唯一名称，例如，“cheshire.example.com”。然而，大多数家用计算机用户不可以方便地访问任何全局DNS命名空间去创建名称。这让大多数家用电脑为实际上是匿名使用。

为了解决这个问题，本文档允许任何计算机用户选择向其计算机提供链路本地多播DNS主机名，形式为：“single-dns-label.local”。例如，笔记本电脑可以回答名称“MyComputer.local”。任何计算机用户有权限以这种方式命名他们的计算机，但前提是所选主机名尚未在该链路上使用。以这种方式命名他们的计算机时，用户有权继续使用该名称，直到名称冲突发生并在用户的帮助下没有解决时。如果发生这种情况，

计算机（或其用户）必须停止使用该名称，并应该尝试分配新的唯一名称以在该链路上使用。这些预期冲突对于选择合理想象名字的人来说是相对罕见的，但拥有一个机制以便在发生时处理它们也是很重要的。

本文档规定了DNS顶级域“.local.”是一个具有特殊语义的特殊域，即任何以“.local”结尾的完全合格名称，都是本地链路的，并且包含该域的名称仅在它们来源的链路上有意义。这类似于169.254/16前缀的IPv4地址或FE80::/10前缀的IPv6地址，就是本地链路并仅在它们来源的链路上有意义。

任何名称以“.local.”结尾的DNS查询必须发送到mDNS IPv4链路本地组播地址224.0.0.251（或其等效的IPv6地址 FF02::FB）。使用固定的多播地址而不是从多播的范围中使用散列函数来选择在附录B中讨论。实现者可以选择通过其他方式同时查找这些名称（例如，单播DNS），并将结果合并。实现者选择这样做应该意识到

当给定名称由于外部网络条件（例如，但不是限于，其名称查找机制响应更快）产生不同结果时，用户可能混淆。

名称是否以“.local.”结尾是不重要的，因为它可能是用户明确键入了完全合格的以“.local.”结尾的域名，或者用户输入了不合格域名但主机软件附加了后缀“.local.”因为这个后缀在用户搜索列表中出现。“.local.”后缀在用户搜索列表中出现是因为用户手动配置过它，或者因为它是通过DHCP [ RFC2132 ]接收的或者通过任何其他配置DNS搜索列表的机制。关于“.local.”后缀的域,与任何可能出现在DNS搜索列表中的搜索域没有不同。

如果没有其他传统DNS服务器可用，不以“.local”结尾的名称的DNS查询可能被发送到mDNS多播地址。这可以允许同一链路上的主机继续在使用彼此的全局唯一DNS名称进行通信即使网络中断，外网不通。当通过本地组播来解析全局名称时，使用DNS安全扩展（DNSSEC）[ RFC4033 ]或其他安全机制以确保响应是可信的尤其重要。通过本地组播解析全局名称是一个有争议的问题，并且本文不做进一步讨论，本文关注的是使用发送给组播地址的DNS消息来解析本地名称的问题。

本文档建议为主机名使用单个水平命名空间，（例如，DNS“A”和“AAAA”记录的名称，会映射到IPv4和IPv6地址），但其他DNS记录类型（如基于DNS的服务发现[ RFC6763 ] 使用的那些）可能包含适合于所需使用的许多标签，直到最大值255字节，在结束处加上一个终止零字节。名称长度

问题在附录C中进一步讨论。

强制主机名的唯一性通常是很有必要的，但本文件不做强制要求。它是允许合作的主机集合维护多个具有相同名称的DNS地址记录，可能用于负载均衡或容错原因。本文档对这种方式不予评论。支持两种操作模式是很重要的。组播DNS协议允许主机验证和维护唯一的名称资源记录，并且它也允许主机使用单个共享名来维护多个资源记录。这种考虑适用于所有资源记录，而不仅仅是地址记录（主机名）。综上所述：需要协议具有检测和处理名称冲突的能力，但不要求用于每条记录。