6. Support Services (支持服务)
6. 支撑服务 (SUPPORT SERVICES)
6.1 域名翻译 (DOMAIN NAME TRANSLATION)
6.1.1 引言 (INTRODUCTION)
每台主机必须实现 (MUST) 一个域名系统 (DNS) 解析器, 并且必须实现 (MUST) 一种使用该 DNS 解析器把主机名转换为 IP 地址以及反向转换的机制 [DNS:1, DNS:2].
除 DNS 之外, 主机还可以 (MAY) 实现一种搜索本地互联网主机表的主机名翻译机制. 关于这一选项的更多信息见第 6.1.3.8 节.
讨论 (DISCUSSION):
互联网主机名翻译最初通过搜索一张包含所有主机的表的本地副本来完成. 这张表变得过于庞大, 无法及时更新与分发, 也大到装不进许多主机, 因此发明了 DNS.
DNS 创建了一个分布式数据库, 主要用于主机名与主机地址之间的转换. 必须实现 DNS 软件. DNS 由两个逻辑上不同的部分组成: 域名服务器与解析器 (尽管实现出于效率考虑常把这两个逻辑部分合在一起) [DNS:2].
域名服务器存储数据库某些区域的权威数据并回答关于这些数据的查询. 域解析器代表用户进程向域名服务器查询数据. 因此每台主机都需要一个 DNS 解析器; 某些主机还需要运行域名服务器. 由于没有任何一台域名服务器拥有完整信息, 一般来说解析一个查询需要从多台域名服务器获取信息.
6.1.2 协议逐步分析 (PROTOCOL WALK-THROUGH)
实现者必须仔细研读参考文献 [DNS:1] 与 [DNS:2]. 它们全面描述了域名系统的理论, 协议与实现, 并凝结了多年的经验.
6.1.2.1 零 TTL 的资源记录 (Resource Records with Zero TTL): RFC-1035 第 3.2.1 节
所有 DNS 域名服务器与解析器必须正确处理 (MUST) TTL 为零的 RR: 把 RR 返回给客户端但不缓存它.
讨论 (DISCUSSION):
零 TTL 值被解释为: 该 RR 只能用于正在进行的事务, 不应被缓存; 它们适用于极易变化的数据.
6.1.2.2 QCLASS 值 (QCLASS Values): RFC-1035 第 3.2.5 节
除非请求者要从多个类中获取数据, 否则不应当 (SHOULD NOT) 使用 "QCLASS=*" 的查询. 特别是, 如果请求者只关心互联网数据类型, 必须使用 (MUST) QCLASS=IN.
6.1.2.3 未使用的字段 (Unused Fields): RFC-1035 第 4.1.1 节
查询或响应消息中未使用的字段必须为 (MUST) 零.
6.1.2.4 压缩 (Compression): RFC-1035 第 4.1.4 节
域名服务器必须在响应中使用 (MUST) 压缩.
讨论 (DISCUSSION):
压缩对于避免 UDP 数据报溢出至关重要; 见第 6.1.3.2 节.
6.1.2.5 滥用配置信息 (Misusing Configuration Info): RFC-1035 第 6.1.2 节
递归域名服务器与全服务解析器通常有一些配置信息, 其中包含关于根域名服务器或本地域名服务器位置的提示 (hint). 实现禁止 (MUST NOT) 在响应中包含任何这些提示.
讨论 (DISCUSSION):
许多实现者发现把这些提示当作缓存数据来存储很方便, 但一些人忽略了确保这种 "缓存数据" 不被包含进响应. 当这些提示过时或错误时, 曾在互联网上造成严重问题.
6.1.3.1 解析器实现 (Resolver Implementation)
如果主机支持并发进程, 域名解析器应当 (SHOULD) 能够多路复用并发请求.
实现 DNS 解析器时, 可以 (MAY) 选择两种不同模型之一: 全服务解析器 (full-service resolver) 或存根解析器 (stub resolver).
(A) 全服务解析器 (Full-Service Resolver)
全服务解析器是解析器服务的完整实现, 能够应对通信故障, 单个域名服务器的故障, 为给定名称找到恰当域名服务器等问题. 它必须满足以下要求:
-
解析器必须实现 (MUST) 本地缓存功能, 以避免对相同请求的重复远程访问, 并且必须对缓存中的信息设置 (MUST) 超时.
-
解析器应当可配置 (SHOULD) 启动信息, 指向多个根域名服务器以及本地域的多个域名服务器. 这确保解析器在正常情况下能够访问整个名称空间, 并且在本地网络与互联网其余部分断开时仍能访问本地域信息.
(B) 存根解析器 (Stub Resolver)
"存根解析器" 依赖所连接网络或 "邻近" 网络上的递归域名服务器的服务. 这一方案让主机把解析器功能的负担转交给另一台主机上的域名服务器. 该模型对于能力较弱的主机 (例如 PC) 往往是必需的; 当主机是本地网络上若干工作站之一时也推荐使用, 因为它让所有工作站共享递归域名服务器的缓存, 从而减少本地网络导出的域名请求数量.
至少, 存根解析器必须 (MUST) 能够把它的请求定向到冗余的递归域名服务器. 注意, 递归域名服务器被允许限制其将受理的请求来源, 因此主机管理员必须核实该服务确实会提供. 存根解析器可以选择 (MAY) 实现缓存, 但如果实现, 就必须对缓存信息设置 (MUST) 超时.
6.1.3.2 传输协议 (Transport Protocols)
DNS 解析器与递归服务器必须支持 (MUST) UDP, 并应当支持 (SHOULD) TCP, 用于发送 (非区传送) 查询. 具体而言, 发送非区传送查询的 DNS 解析器或服务器必须 (MUST) 先发送 UDP 查询. 如果响应的 Answer 节被截断且请求方支持 TCP, 它应当 (SHOULD) 用 TCP 再次尝试该查询.
DNS 服务器必须能够 (MUST) 服务 UDP 查询, 并应当能够 (SHOULD) 服务 TCP 查询. 域名服务器可以 (MAY) 限制它投入 TCP 查询的资源, 但不应当 (SHOULD NOT) 仅仅因为某个 TCP 查询用 UDP 本可以成功就拒绝服务该 TCP 查询.
被截断的响应禁止 (MUST NOT) 被保存 (缓存) 后再使用, 使得其被截断的事实丢失.
讨论 (DISCUSSION):
查询优先使用 UDP 而非 TCP, 因为 UDP 查询的开销低得多, 无论是在分组数量上还是在连接状态上. 对于重负载服务器 (尤其是根服务器), UDP 的使用至关重要. UDP 还提供了额外的健壮性: 解析器可以用一次 TCP 查询的代价尝试向不同服务器发起多次 UDP 查询.
DNS 响应可能被截断, 尽管在当前的互联网 DNS 中这种情况非常罕见. 实际上, 截断无法预测, 因为它取决于数据. 相关因素包括答案中 RR 的数量, 每个 RR 的大小, 以及名称压缩算法节省的空间. 根据经验, 对于包含 15 个或更少 RR 的答案, NS 与 MX 列表不应发生截断.
能否使用被截断的答案取决于应用. mailer 禁止使用被截断的 MX 响应, 因为这可能导致邮件环路.
负责任的实践可以让 UDP 在绝大多数情形下足够. 域名服务器必须在响应中使用压缩. 解析器必须区分响应 Additional 节的截断 (只损失额外信息) 与 Answer 节的截断 (对 MX 记录而言, 这会使响应无法被 mailer 使用). 数据库管理员应当在域名服务器列表, MX 备选等列表中只列出合理数量的主名称.
然而, 同样清楚的是: 未来定义的某些新 DNS 记录类型所含信息将超出适用于 UDP 的 512 字节限制, 因而需要 TCP. 因此, 解析器与域名服务器应当把 TCP 服务作为 UDP 的备份实现, 并知道将来会需要这项 TCP 服务.
经私下约定, 域名服务器与解析器可以 (MAY) 约定在它们之间的所有流量上使用 TCP. 区传送 (zone transfer) 必须使用 (MUST) TCP.
DNS 服务器必须 (MUST) 具备足够的内部并发性, 使得它在等待响应或在已打开的 TCP 连接上执行区传送的同时, 能够继续处理 UDP 查询 [DNS:2].
服务器可以 (MAY) 支持通过 IP 广播或组播地址投递的 UDP 查询. 但是, 组播的查询禁止设置 (MUST NOT) Recursion Desired 位, 并且域名服务器对经广播或组播地址收到的查询必须忽略该位 (MUST). 发送广播或组播 DNS 查询的主机应当 (SHOULD) 只把它们作为偶发的探测发送, 缓存从响应中获得的 IP 地址, 以便正常情况下发送单播查询.
讨论 (DISCUSSION):
广播或 (尤其是) IP 组播可以提供一种在不知道其 IP 地址的情况下找到邻近域名服务器的途径. 然而, 递归查询的普遍广播会给网络和服务器造成过度且不必要的负载.
6.1.3.3 高效的资源使用 (Efficient Resource Usage)
以下对服务器与解析器的要求对整个互联网的健康非常重要, 尤其当 DNS 服务被更高层的自动化服务器 (例如 mailer) 反复调用时.
(1) 解析器必须实现 (MUST) 重传控制, 以确保不浪费通信带宽, 并且必须对响应单个请求所消耗的资源施加 (MUST) 有限上限. 具体建议见 [DNS:2] 第 43-44 页.
(2) 在一个查询被重传若干次仍无响应之后, 实现必须放弃 (MUST) 并向应用返回一个软错误.
(3) 所有 DNS 域名服务器与解析器应当 (SHOULD) 缓存临时故障, 超时周期为分钟量级.
讨论 (DISCUSSION):
这可以防止立即重试软失败的应用 (违反本文档第 2.2 节) 产生过多的 DNS 流量.
(4) 所有 DNS 域名服务器与解析器应当 (SHOULD) 缓存指示指定名称或指定类型数据不存在的否定响应, 如 [DNS:2] 所述.
(5) 当 DNS 服务器或解析器重试 UDP 查询时, 重试间隔应当 (SHOULD) 受指数退避算法约束, 并且应当 (SHOULD) 有上下界.
实现 (IMPLEMENTATION):
应当使用实测的 RTT 与方差 (如果有) 来计算初始重传间隔. 如果没有该信息, 应使用不小于 5 秒的默认值. 实现可以限制重传间隔, 但该限制必须超过互联网最大段寿命的两倍加上域名服务器的服务延迟.
(6) 当解析器或服务器对它发出的查询收到 Source Quench 时, 它应当 (SHOULD) 采取措施降低近期对该服务器的查询速率. 服务器可以 (MAY) 忽略因发送响应数据报而收到的 Source Quench.
实现 (IMPLEMENTATION):
一种推荐的降低速率的动作是: 如果有可用备选, 把下一次查询尝试发给备选服务器. 另一种是对同一服务器退避重试间隔.
6.1.3.4 多宿主主机 (Multihomed Hosts)
当主机名到地址的功能遇到拥有多个地址的主机时, 它应当 (SHOULD) 利用对直连网络号的知识以及任何其他适用的性能或历史信息, 对地址进行排序.
讨论 (DISCUSSION):
多宿主主机的不同地址一般意味着不同的互联网路径, 而某些路径在性能, 可靠性或管理限制方面可能优于其他路径. 域名系统没有一般性的方法来确定最佳路径. 一个
一种推荐的方法是把这个决策建立在由系统管理员设置的本地配置信息之上.
实现 (IMPLEMENTATION):
以下方案已被成功使用:
(a) 在主机配置数据中纳入一个网络偏好列表 (Network-Preference List), 即一个按偏好排序的网络列表. 如果没有偏好, 该列表可以为空.
(b) 当一个主机名被映射为一列 IP 地址时, 这些地址应当按网络号排序, 排成与网络偏好列表中对应网络相同的顺序. 其网络未出现在网络偏好列表中的 IP 地址应放在列表末尾.
6.1.3.5 可扩展性 (Extensibility)
DNS 软件必须支持 (MUST) 所有众所周知的, 与类无关的格式 [DNS:2], 并且应当编写得 (SHOULD) 能把引入新的众所周知类型以及用非标准类型做本地试验所带来的创伤降到最小.
讨论 (DISCUSSION):
DNS 使用的数据类型与类是可扩展的, 因此会有新类型加入, 旧类型被删除或重定义. 新数据类型的引入应当只依赖于 DNS 消息内部域名压缩的规则, 以及资源记录 (RR) 的可打印 (即主文件) 格式与内部格式之间的转换.
压缩依赖对特定 RR 内部数据格式的了解. 因此压缩只能用于众所周知的, 与类无关的 RR 的内容, 绝不能用于类特定的 RR 或非众所周知类型的 RR. RR 的所有者名称总是可以压缩.
域名服务器可能经由区传送获得一些它不知道如何转换为可打印格式的 RR. 解析器也可能通过查询收到类似信息. 为了正确运作, 这些数据必须被保留, 由此可以推知: DNS 软件不能用文本格式做内部存储.
DNS 对域名语法的定义非常宽泛 -- 一串标签, 每个标签最多 63 个 8 位八位组, 以点分隔, 总计最多 255 个八位组. DNS 的特定应用被允许进一步约束其所用域名的语法, 尽管 DNS 的部署已导致一些应用允许更一般的名称. 特别是, 本文档第 2.1 节略微放宽了 RFC-952 [DNS:4] 定义的合法互联网主机名语法.
6.1.3.6 RR 类型的状态 (Status of RR Types)
域名服务器必须能够 (MUST) 从配置文件加载除 MD 与 MF 之外的所有 RR 类型. MD 与 MF 类型已过时, 禁止实现 (MUST NOT); 特别是, 域名服务器禁止 (MUST NOT) 从配置文件加载这些类型.
讨论 (DISCUSSION):
RR 类型 MB, MG, MR, NULL, MINFO 与 RP 被视为实验性的, 使用 DNS 的应用不能指望大多数域都支持这些 RR 类型. 此外, 这些类型可能被重定义.
TXT 与 WKS RR 类型未被互联网站点广泛使用; 因此, 应用不能指望在大多数域中存在 TXT 或 WKS RR.
6.1.3.7 健壮性 (Robustness)
DNS 软件可能需要在根服务器或其他服务器因网络连通性或其他问题而不可用的环境中运行. 在这种情况下, DNS 域名服务器与解析器必须 (MUST) 继续为名称空间的可达部分提供服务, 对其余部分则给出临时失败.
讨论 (DISCUSSION):
尽管 DNS 主要设计用于互连的互联网, 但它也应当可以在与互联网不相连的网络中使用. 因此, 实现不得在为本地名称提供服务之前依赖对根服务器的访问.
6.1.3.8 本地主机表 (Local Host Table)
讨论 (DISCUSSION):
主机可以把本地主机表用作 DNS 的备份或补充. 这就产生了一个问题: DNS 与主机表哪个优先; 最灵活的做法是把它做成一个配置选项.
通常, 这类补充主机表的内容由站点本地决定. 不过, DDN 网络信息中心 (DDN NIC) 维护着一份公开可得的互联网主机表, 其格式记录在 [DNS:4] 中. 该表可以用 [DNS:5] 描述的协议从 DDN NIC 获取. 必须指出, 该表只包含全部互联网主机的一小部分. 使用该协议获取 DDN NIC 主机表的主机, 在用 ALL 命令请求整张表之前, 应当先用 VERSION 命令检查表是否已变化. VERSION 标识符应当被当作任意字符串处理, 只做相等性测试; 不得假定任何数值顺序.
DDN NIC 主机表包含一些主机运行所不需要, 因而目前未纳入 DNS 数据库的管理信息; 例如网络与网关条目. 然而, 这些附加信息中的很大一部分未来会加入 DNS. 反过来, DNS 提供了一些 DDN NIC 主机表无法提供的基本服务 (特别是 MX 记录).
6.1.4 DNS 用户接口 (DNS USER INTERFACE)
6.1.4.1 DNS 管理 (DNS Administration)
本文档关注的是主机软件的设计与实现问题, 而非管理或运营问题. 然而, 管理问题在 DNS 中尤为重要, 因为这个大型分布式数据库特定片段中的错误可能导致许多站点的性能不佳或错误. 这些问题在 [DNS:6] 与 [DNS:7] 中讨论.
6.1.4.2 DNS 用户接口 (DNS User Interface)
主机必须 (MUST) 为运行于其上的所有应用程序提供一个 DNS 接口. 该接口通常把请求导向一个执行解析器功能的系统进程 [DNS:1, 6.1:2].
至少, 基本接口必须支持 (MUST) 对与特定名称相关联的特定类型与类的全部信息的请求, 并且必须返回 (MUST) 以下三者之一: 全部所请求信息, 一个硬错误码, 或一个软错误指示. 无错误时, 基本接口不加修改, 删除或排序地返回完整的响应信息, 从而基本接口无需为容纳新数据类型而改动.
讨论 (DISCUSSION):
软错误指示是接口的一个必要组成部分, 因为并不总是能够从 DNS 访问特定信息; 见第 6.1.3.3 节.
主机可以 (MAY) 提供针对特定功能定制的其他 DNS 接口, 把原始域数据变换为更适合这些功能的格式. 特别是, 主机必须 (MUST) 提供一个便于在主机地址与主机名之间转换的 DNS 接口.
6.1.4.3 接口缩写设施 (Interface Abbreviation Facilities)
用户接口可以 (MAY) 提供让用户输入常用名称缩写的方法. 尽管这类方法的定义不在 DNS 规范的范围之内, 为确保这些方法能访问整个 DNS 名称空间并防止对互联网资源的过度使用, 需要某些规则.
如果提供了缩写方法, 那么:
(a) 必须有 (MUST) 某种约定来表示一个名称已经完整, 从而抑制缩写方法. 尾点是常用的方法.
(b) 缩写展开必须 (MUST) 恰好进行一次, 并且必须 (MUST) 在名称被输入的上下文中进行.
讨论 (DISCUSSION):
例如, 如果邮件程序对一个目的地使用了缩写, 该缩写应当被展开为完整的域名并连同 "已完整" 的指示一起存入排队消息. 否则, 该缩写可能被邮件系统的搜索列表 (而非用户的搜索列表) 展开, 或者由于反复的规范化尝试与通配符交互, 名称可能不断变长.
两种最常见的缩写方法是:
(1) 接口级别名 (Interface-level aliases)
接口级别名在概念上实现为一个别名/域名对的列表. 该列表可以是每用户的或每主机的, 并且可以为不同功能关联不同的列表, 例如一个列表用于主机名到地址的翻译, 另一个列表用于邮件域. 当用户输入一个名称时, 接口尝试把该名称与列表条目的别名部分匹配; 如果找到匹配条目, 该名称就被替换为条目中的域名.
注意, 接口级别名与 CNAME 是完全不同的机制; 接口级别名是本地事务, 而 CNAME 是一种全互联网范围的别名机制, 是任何 DNS 实现都必备的组成部分.
(2) 搜索列表 (Search Lists)
搜索列表在概念上实现为一个有序的域名列表. 当用户输入一个名称时, 搜索列表中的域名被逐一用作用户所供名称的后缀, 直到找到带有期望关联数据的域名, 或搜索列表耗尽. 搜索列表通常包含本地主机的父域或其他祖先域的名称. 搜索列表通常是每用户的或每进程的.
应当 (SHOULD) 允许管理员停用 DNS 搜索列表设施. 在某些情况下, 为防止 DNS 被滥用, 管理上的拒绝是有理由的.
存在这样的风险: 搜索列表机制在测试用户输入是否为完整域名 (缺少标记其完整的尾点) 时, 会向根服务器发出过多查询. 搜索列表机制必须 (MUST) 具备以下两条措施之一, 并且应当 (SHOULD) 两者兼备, 以防止这种情况:
(a) 本地解析器/域名服务器可以实现否定响应的缓存 (见第 6.1.3.3 节).
(b) 搜索列表展开器可以要求生成的域名至少含有两个内部点, 才尝试把该名称用于向非本地域服务器 (例如根) 的查询.
讨论 (DISCUSSION):
这一要求的意图是: 避免在搜索列表被逐一测试时给用户带来过多延迟, 更重要的是防止向根及其他高层服务器发送过多流量. 例如, 如果用户提供的名称为 "X" 而搜索列表把根作为其组成部分, 那么在尝试下一个搜索列表备选项之前, 就必须先查询一台根服务器. 根服务器及其附近网关承受的负载将乘以互联网中的主机数量.
否定缓存方案把影响限制在名称首次使用时. 内部点规则实现更简单, 但可能妨碍某些顶级域名的便利使用.
6.1.5 域名系统要求摘要 (DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY)
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
GENERAL ISSUES | | | | | | |
| | | | | | |
Implement DNS name-to-address conversion |6.1.1 |x| | | | |
Implement DNS address-to-name conversion |6.1.1 |x| | | | |
Support conversions using host table |6.1.1 | | |x| | |
Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
Unused fields zero |6.1.2.3 |x| | | | |
Use compression in responses |6.1.2.4 |x| | | | |
| | | | | | |
Include config info in responses |6.1.2.5 | | | | |x|
Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
Easily expand type list |6.1.3.5 | |x| | | |
Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
Load MD or MF type |6.1.3.6 | | | | |x|
Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOLVER ISSUES: | | | | | | |
| | | | | | |
Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
Full-service resolver: |6.1.3.1 | | |x| | |
Local caching |6.1.3.1 |x| | | | |
Information in local cache times out |6.1.3.1 |x| | | | |
Configurable with starting info |6.1.3.1 | |x| | | |
Stub resolver: |6.1.3.1 | | |x| | |
Use redundant recursive name servers |6.1.3.1 |x| | | | |
Local caching |6.1.3.1 | | |x| | |
Information in local cache times out |6.1.3.1 |x| | | | |
Support for remote multi-homed hosts: | | | | | | |
Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
| | | | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
TRANSPORT PROTOCOLS: | | | | | | |
| | | | | | |
Support UDP queries |6.1.3.2 |x| | | | |
Support TCP queries |6.1.3.2 | |x| | | |
Send query using UDP first |6.1.3.2 |x| | | | |1
Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
Name server limit TCP query resources |6.1.3.2 | | |x| | |
Punish unnecessary TCP query |6.1.3.2 | | | |x| |
Use truncated data as if it were not |6.1.3.2 | | | | |x|
Private agreement to use only TCP |6.1.3.2 | | |x| | |
Use TCP for zone transfers |6.1.3.2 |x| | | | |
TCP usage not block UDP queries |6.1.3.2 |x| | | | |
Support broadcast or multicast queries |6.1.3.2 | | |x| | |
RD bit set in query |6.1.3.2 | | | | |x|
RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOURCE USAGE: | | | | | | |
| | | | | | |
Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
Finite bounds per request |6.1.3.3 |x| | | | |
Failure after retries => soft error |6.1.3.3 |x| | | | |
Cache temporary failures |6.1.3.3 | |x| | | |
Cache negative responses |6.1.3.3 | |x| | | |
Retries use exponential backoff |6.1.3.3 | |x| | | |
Upper, lower bounds |6.1.3.3 | |x| | | |
Client handle Source Quench |6.1.3.3 | |x| | | |
Server ignore Source Quench |6.1.3.3 | | |x| | |
-----------------------------------------------|-----------|-|-|-|-|-|--
USER INTERFACE: | | | | | | |
| | | | | | |
All programs have access to DNS interface |6.1.4.2 |x| | | | |
Able to request all info for given name |6.1.4.2 |x| | | | |
Returns complete info or error |6.1.4.2 |x| | | | |
Special interfaces |6.1.4.2 | | |x| | |
Name<->Address translation |6.1.4.2 |x| | | | |
| | | | | | |
Abbreviation Facilities: |6.1.4.3 | | |x| | |
Convention for complete names |6.1.4.3 |x| | | | |
Conversion exactly once |6.1.4.3 |x| | | | |
Conversion in proper context |6.1.4.3 |x| | | | |
Search list: |6.1.4.3 | | |x| | |
Administrator can disable |6.1.4.3 | |x| | | |
Prevention of excessive root queries |6.1.4.3 |x| | | | |
Both methods |6.1.4.3 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
-----------------------------------------------|-----------|-|-|-|-|-|--
1. Unless there is private agreement between particular resolver and
particular server.
注: 以上要求摘要表为英文原文原样保留 (列含义: MUST / SHOULD / MAY / SHOULD NOT / MUST NOT / FOOTNOTE).
6.2 主机初始化 (HOST INITIALIZATION)
6.2.1 引言 (INTRODUCTION)
本节讨论跨越互连网络, 或者更一般地跨越一条互联网路径的主机软件初始化. 这对无盘主机是必需的, 对带磁盘驱动器的主机则可选用. 对无盘主机而言, 初始化过程称为 "网络引导" (network booting), 由位于引导 ROM 中的引导程序控制.
要跨越网络初始化一台无盘主机, 有两个不同的阶段:
(1) 配置 IP 层.
无盘机器往往没有可用于存储网络配置信息的永久存储, 因此必须动态获取足够的配置信息, 以支持随后的加载阶段. 这些信息至少必须包括主机与引导服务器的 IP 地址. 为支持跨越网关的引导, 还需要地址掩码与默认网关列表.
(2) 加载主机系统代码.
在加载阶段, 使用一种合适的文件传输协议把系统代码复制过来.
带磁盘的主机也可以执行第一步, 即动态配置. 这对微型计算机很重要: 它们的软盘可能使网络配置信息被错误地复制到多台主机上. 此外, 如果新主机自动从中央服务器获取其配置信息, 安装新主机会简单得多, 既节省管理员时间, 又降低出错概率.
6.2.2 要求 (REQUIREMENTS)
6.2.2.1 动态配置 (Dynamic Configuration)
已经为动态配置制定了若干协议条款.
-
ICMP Information Request/Reply 消息
这对已过时的消息对被设计用来让主机找出自己所在网络的网络号. 遗憾的是, 它只有在主机已经知道自己 IP 地址的主机号部分时才有用, 而需要动态配置的主机恰恰很少有这一信息.
-
反向地址解析协议 (RARP) [BOOT:4]
RARP 是用于广播介质的链路层协议, 让主机在给定其链路层地址的情况下找到自己的 IP 地址. 遗憾的是, RARP 无法跨越 IP 网关工作, 因此要求每个网络上都有一台 RARP 服务器. 此外, RARP 不提供任何其他配置信息.
-
ICMP Address Mask Request/Reply 消息
这些 ICMP 消息让主机能够得知特定网络接口的地址掩码.
-
BOOTP 协议 [BOOT:2]
该协议让主机确定本地主机与引导服务器的 IP 地址, 合适引导文件的名称, 以及可选的地址掩码与默认网关列表. 为找到 BOOTP 服务器, 主机用 UDP 广播一个 BOOTP 请求. 曾使用特别的网关扩展把 BOOTP 广播穿越网关传输; 将来, IP 组播设施将为这一目的提供标准机制.
动态配置的建议方案是: 使用带 "BOOTP Vendor Information Extensions" RFC-1084 [BOOT:3] 所定义扩展的 BOOTP 协议. RFC-1084 定义了一些重要的通用 (非厂商特定) 扩展. 特别是, 这些扩展允许在 BOOTP 中提供地址掩码; 我们建议 (RECOMMEND) 以这种方式提供地址掩码.
讨论 (DISCUSSION):
历史上, 子网划分是在 IP 之后很久才定义的, 因此设计了一个单独的机制 (ICMP Address Mask 消息) 来向主机提供地址掩码. 然而, IP 地址掩码与对应的 IP 地址在概念上构成一对; 出于运营简化的考虑, 它们应当在同一时间由同一机制定义, 无论是配置文件还是像 BOOTP 这样的动态机制.
注意, BOOTP 不够通用, 无法规定多宿主主机所有接口的配置. 多宿主主机必须么对每个接口分别使用 BOOTP, 要么用 BOOTP 配置一个接口来执行加载, 然后在加载完成后再从文件执行完整的初始化.
应用层配置信息预期在系统代码加载之后从文件获取.
6.2.2.2 加载阶段 (Loading Phase)
加载阶段的建议方案是: 在由 BOOTP 确立的 IP 地址之间使用 TFTP [BOOT:1].
不应当 (SHOULD NOT) 向广播地址做 TFTP, 原因见第 4.2.3.4 节.
6.3 远程管理 (REMOTE MANAGEMENT)
6.3.1 引言 (INTRODUCTION)
互联网社区最近在网络管理协议的开发上投入了相当大的努力. 结果是双管齐下的方案 [MGT:1, MGT:6]: 简单网络管理协议 (SNMP) [MGT:4] 与基于 TCP 的公共管理信息协议 (CMOT) [MGT:5].
要使用 SNMP 或 CMOT 进行管理, 主机需要实现适当的管理代理. 互联网主机应当 (SHOULD) 包含 SNMP 或 CMOT 之一的代理.
SNMP 与 CMOT 都在一个定义了管理值集合的管理信息库 (MIB) 上运作. 通过读取和设置这些值, 远程应用可以查询并改变被管理系统的状态.
已定义了一个供两种管理协议使用的标准 MIB [MGT:3], 其数据类型由 [MGT:2] 定义的管理信息结构 (SMI) 规定. 可以在 MIB 命名空间的 "enterprises" 与 "experimental" 子树下引入其他 MIB 变量 [MGT:2].
主机中的每个协议模块都应当 (SHOULD) 实现相关的 MIB 变量. 主机应当 (SHOULD) 实现最新标准 MIB 中定义的 MIB 变量, 并可以在恰当且有用时实现 (MAY) 其他 MIB 变量.
6.3.2 协议逐步分析 (PROTOCOL WALK-THROUGH)
MIB 旨在同时覆盖主机与网关, 尽管在这两种情形下 MIB 的应用可能存在细节差异. 本节给出 MIB 在主机上的恰当解释. MIB 的后续版本可能会为主机管理纳入更多条目.
被管理的主机必须实现以下各组 MIB 对象定义: System, Interfaces, Address Translation, IP, ICMP, TCP 与 UDP.
以下具体解释适用于主机:
-
ipInHdrErrors
注意, "time-to-live exceeded" 错误只有在主机转发源路由数据报时才可能在主机上发生.
-
ipOutNoRoutes
该对象统计因找不到路由而被丢弃的数据报. 如果主机配置中的所有默认网关都宕机, 主机上可能发生这种情况.
-
ipFragOKs, ipFragFails, ipFragCreates
不实现有意分片的主机 (见 [INTRO:1] 的 "Fragmentation" 一节) 必须 (MUST) 为这三个对象返回值零.
-
icmpOutRedirects
对主机而言, 该对象必须总是 (MUST) 为零, 因为主机不发送 Redirect.
-
icmpOutAddrMaskReps
对主机而言, 该对象必须总是 (MUST) 为零, 除非该主机是地址掩码信息的权威来源.
-
ipAddrTable
对主机而言, "IP Address Table" 对象实际上是一张逻辑接口表.
-
ipRoutingTable
对主机而言, "IP Routing Table" 对象实际上是主机的路由缓存与 [INTRO:1] "Routing Outbound Datagrams" 一节所述静态路由表的组合.
在每个 ipRouteEntry 中, ipRouteMetric1...4 通常对主机没有意义, 应当总是 (SHOULD) 为 -1, 而 ipRouteType 通常取值 "remote".
如果直连网络上的目的地不出现在路由缓存中 (见 [INTRO:1] "Routing Outbound Datagrams" 一节), 就不会有 ipRouteType 为 "direct" 的条目.
讨论 (DISCUSSION):
当前 MIB 未在 ipRouteEntry 中包含 Type-of-Service, 但预期未来的修订会加入.
我们还预期 MIB 会扩展以支持对应用的远程管理 (例如部分重新配置邮件系统的能力). 因此, 诸如邮件系统之类的网络服务应用在编写时就应当带上供远程管理使用的 "钩子".
6.3.3 管理要求摘要 (MANAGEMENT REQUIREMENTS SUMMARY)
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
Support SNMP or CMOT agent |6.3.1 | |x| | | |
Implement specified objects in standard MIB |6.3.1 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
注: 以上要求摘要表为英文原文原样保留 (列含义: MUST / SHOULD / MAY / SHOULD NOT / MUST NOT / FOOTNOTE).