Information Center, NIC)维护,所有主机通过文件传输协议(File Transfer Protocol,
FTP)获得该文件[RFC-952、RFC-953]。按此方法分发新版本消耗的总网络带宽
正比于该网络中主机数的平方,即使当使用多层FTP时,在 NIC主机上的出境FTP
负载也是相当可观的。
主机数量的爆炸性增长预计将来也不会停止。
- 网络数量也在相应改变。构成原始ARPANET的分时主机正在被本地工作站网络
替代。本地组织正在管理他们自己的名称和地址,但是必须等待NIC改变
HOSTS.TXT,以便在互联网上普遍可以看到这些改变。组织们也希望在名称空
间上实现某种本地结构。
- 在互联网上的应用正在变得更加复杂,正在产生对通用目的名称服务的需求。
结果产生几种有关名称空间和对它们进行管理的思路[IEN-116、RFC-799、RFC-819、
RFC-830]。这些建议各不相同,但是共同的主线是等级名称空间思想,采用粗略对应组织
结构的等级,使用由“.”作为标记等级层次间边界的记号的名称。使用分布式数据库和广
义资源的设计在[RFC-882、RFC-883]中介绍。根据几方面实践的经验,系统最终演进为本
备忘录中介绍的方案。
术语“域(domain)”或“域名(domain name)”在许多场景中使用,使用范围超出这里介
绍的DNS。更一般情况,术语域名用于指具有由圆点表示的结构的名称,但是与DNS没有关
系。在邮件寻址[Quarterman 86]中尤其是这样。
2-2 DNS设计目标
DNS的设计目标影响它的结构。这些目标是:
- 主要目标是一致性名称空间,这一名称空间用于指资源。为了避免特别是由编码
引起的问题,名称应当不要求包括网络标识符、地址、路由,或作为该名称一部
分的类似信息。
- 规模庞大和频繁更新要求数据库必须采用分布式方式维护,使用本地缓存改善性
能。企图收集整个数据库的一致性复本的方法将变得越来越昂贵和困难,并且因
此应当避免。同样的道理也适用于名称空间结构,以及尤其是生成和删除名称的
机制;这些也应当是分布式的。
- 凡是需要在获得数据成本、更新速率和缓存精度间进行折中时,数据源应当控制
此折中。
- 实现成本(诸如便利性)要求DNS通常普遍可用,不被限制在单一应用。我们应当
能够使用名称来检索主机地址、邮箱数据和其他尚未确定的信息。所有与名称关
联的数据用类型(type)标记,并且可以将查询限制在单一类型。
- 因为我们希望名称空间可用于不同的网络和应用,我们提供由不同协议族或管理
使用相同 名称空间的能力。例如,尽管所有协议都有地址概念,协议间主机地
址格式不同。DNS用类以及类型标记所有数据,因此我们可以允许并行使用不同
格式类型地址的数据。
- 我们希望名称服务器业务独立于携带这些业务的通信系统。一些系统可能希望使
用数据报进行查询和响应,并且仅为强调可靠性的业务(例如,数据库更新,长
业务)建立虚拟电路;其他系统将排他性地使用虚拟电路。
- 系统应当能够适应广泛的主机能力。个人计算机和大型分时主机都应当能够使用
此系统,尽管可能采用不同方法。
2-3 有关应用的假设
评论15
最新资源