附录 A. 附录

目录

A.1. 感谢

A.2. 历史上的DNS信息

A.3. 通用DNS参考信息

A.4. 参考书和推荐阅读

感谢

和有关历史的的类

Hesiod  赫西奥德(公元前8世纪,希腊诗人)

 [hesiod] 类是一个由MIT 项目Athena开发的信息服务，它用来分享不同系统的数据库信息，例如users, groups, printers 等等。

Chaos 历史(上)的, 有关历史的

chaos 类用于指定区域数据是MIT开发的CHAOSnet，它是1970年代中期的局域网协议。

通用地址 (A6)

IPv6 地址是128-bit 的二进制数，它是接口或一组接口，它在DNS中介绍，用来简化网络路由。有三种类型的地址： 单播, 一个接口的单个地址; 任意播, 一组接口的标识; 和多播, 一组接口的标识。这里介绍全局单播地址，更多信息参见RFC 2374。

全局单播地址格式如下：

3	13	8	24	16	64 bits
FP	TLA ID	RES	NLA ID	SLA ID	Interface ID
<------ Public Topology ------>
				<-Site Topology->
					<------ Interface Identifier ------>

Where

FP	=	Format Prefix (001)前缀
TLA ID	=	Top-Level 最高级的合成标识
RES	=	保留
NLA ID	=	Next-Level 下一级组合标识
SLA ID	=	Site-Level 站点级组合标识
INTERFACE ID	=	Interface Identifier接口标识

公众拓扑信息（Public Topology ）由ISP提供， (大概) 对应IPv4网络地址范围。站点拓扑信息（Site Topology ）是你划分你的子网，很像在把IPv4 /16 网络划成 /24 子网，接口标识（ Interface Identifier ）是在指定的网络上一个独立的接口。(在IPv6中，地址是属于接口的而不是主机的。)

在IPv6 中划分子网比IPv4中更灵活：子网划分可以把位作为边界，和Classless InterDomain Routing (CIDR)一样。

A6全局单播地址的公共拓扑信息的内部结构：

3	13	8	24
FP	TLA ID	RES	NLA ID

一个3 位长的FP (前缀的格式定义) 值是001说明这个是一个全局单播地址，对于其它类型的FP的长度可能不一样。

13位长的 TLA (Top Level Aggregator，最高级集合) 是最高级IP骨干携带器的前缀（bits give the prefix of your top-level IP backbone carrier.）。

8 位保留

NLA ID：24 位是次一级集合（Next Level Aggregators），这允许使用TLA来分发客户组织的部分IP地址空间，这样客户就可以通过加入更多的NLA位来继续划分他们的网络，或者给客户分发Ipv6前缀，等等。

没有位置拓扑（Site topology）段的组成结构，可以用需要的所有方法来分配这些位。

在Ipv6网络中界面标识必须是唯一的。在以太网中，一个确认的方法是设置硬件地址的前三个字节为"FFFE"，然后是最后三个字节，一个数从它的第一个不是零的位开始，地址被写成32位一组，并用冒号分开，每一组数前面的0都被省略，例如：

2001:db8:201:9:a00:20ff:fe81:2b32

IPv6 地址定义中经常有一串0，可以使用连续两个冒号来尽最大可能代表这些0，每个地址只能出现一个双冒号。

Specification documents for the Internet protocol suite, including the (where xxx is the number of the RFC). RFCs are also available via the Web at .

[RFC974] C. Partridge, Mail Routing and the Domain System, January 1986.

[RFC1034] P.V. Mockapetris, Domain Names — Concepts and Facilities, November 1987.

[RFC1035] P. V. Mockapetris, Domain Names — Implementation and Specification, November 1987.

[RFC2181] R., R. Bush Elz, Clarifications to the [RFC2308] M. Andrews, Negative Caching of [RFC1995] M. Ohta, Incremental Zone Transfer in [RFC1996] P. Vixie, A Mechanism for Prompt Notification of Zone Changes, August 1996.

[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, Dynamic Updates in the Domain Name System, April 1997.

[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington, Secret Key Transaction Authentication for

[RFC1886] S. Thomson and C. Huitema, [RFC2065] D. Eastlake, 3rd and C. Kaufman, Domain Name System Security Extensions, January 1997.

[RFC2137] D. Eastlake, 3rd, Secure Domain Name System Dynamic Update, April 1997.

[RFC1535] E. Gavron, A Security Problem and Proposed Correction With Widely Deployed [RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller, Common [RFC1982] R. Elz and R. Bush, Serial Number Arithmetic, August 1996.

[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, New [RFC1706] B. Manning and R. Colella, [RFC2168] R. Daniel and M. Mealling, Resolution of Uniform Resource Identifiers using the Domain Name System, June 1997.

[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson, A Means for Expressing Location Information in the Domain Name System, January 1996.

[RFC2052] A. Gulbrandsen and P. Vixie, A [RFC2163] A. Allocchio, Using the Internet [RFC2230] R. Atkinson, Key Exchange Delegation Record for the

[RFC1101] P. V. Mockapetris, [RFC1123] Braden, Requirements for Internet Hosts - Application and Support, October 1989.

[RFC1591] J. Postel, Domain Name System Structure and Delegation, March 1994.

[RFC2317] H. Eidnes, G. de Groot, and P. Vixie, Classless IN-ADDR.ARPA Delegation, March 1998.

[RFC1537] P. Beertema, Common [RFC1912] D. Barr, Common [RFC1912] D. Barr, Common [RFC2010] B. Manning and P. Vixie, Operational Criteria for Root Name Servers., October 1996.

[RFC2219] M. Hamilton and R. Wright, Use of

[RFC1464] R. Rosenbaum, Using the Domain Name System To Store Arbitrary String Attributes, May 1993.

[RFC1713] A. Romao, Tools for [RFC1794] T. Brisco, [RFC2240] O. Vaughan, A Legal Basis for Domain Name Allocation, November 1997.

[RFC2345] J. Klensin, T. Wolf, and G. Oglesby, Domain Names and Company Name Retrieval, May 1998.

[RFC2352] O. Vaughan, A Convention For Using Legal Names as Domain Names, May 1998.

[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni,

Internet Drafts (IDs) are rough-draft working documents of the Internet Engineering Task Force. They are, in essence, RFCs in the preliminary stages of development. Implementors are cautioned not to regard IDs as archival, and they should not be quoted or cited in any formal documents unless accompanied by the disclaimer that they are "works in progress." IDs have a lifespan of six months after which they are deleted unless updated by their authors.

A.4.3. Other Documents About BIND

Paul Albitz and Cricket Liu, DNS and BIND, 1998.