BIND 9 管理员参考手册 - Internet Systems Consortium

需积分: 10 134 浏览量更新于2024-07-31 收藏 712KB PDF 举报

“Bv9ARM.pdf”是一本关于BIND 9管理员参考手册的文档，主要涵盖了互联网系统联盟(ISC)的 BIND DNS服务器的管理和配置知识。 BIND 9是Internet Systems Consortium (ISC) 开发的一个开源DNS（域名系统）服务器软件，广泛用于互联网基础设施。这个手册是针对BIND 9管理员的，提供了详细的指南和参考资料，帮助管理员理解和操作BIND 9服务。手册的介绍部分提到，文档的范围包括了BIND 9的基本概念、组织结构以及文档中使用的约定。它还简要介绍了DNS系统的基础知识，如域名系统的工作原理、域名与域名名称的区别，以及DNS中的“区域”概念。 1.1 Scope of Document: 这个部分明确了文档覆盖的内容，可能包括BIND 9的安装、配置、日志管理、安全设置、性能优化以及故障排查等各个方面。 1.2 Organization of This Document: 手册的组织结构通常会按照逐步的方式进行，从基础概念到高级特性和配置，确保读者能循序渐进地学习。 1.3 Conventions Used in This Document: 这一部分会解释文档中使用的特殊符号、术语和格式，以便读者能准确理解指令和示例。 1.4 The Domain Name System (DNS): DNS是互联网的关键组件，负责将人类可读的域名转换为IP地址。这部分深入解释了DNS的基本原理，包括DNS查询和响应的过程、权威DNS服务器和缓存DNS服务器的角色。 1.4.1 DNS Fundamentals: 基础部分可能涉及DNS的工作流程、资源记录类型（如A记录、MX记录、CNAME记录等）、DNS解析过程等。 1.4.2 Domains and Domain Names: 这里可能会讨论域名的层次结构、顶级域(TLDs)、二级域和子域的概念，以及如何注册和管理域名。 1.4.3 Zones: 区域是DNS中的一个重要概念，每个区域对应DNS树的一部分，包含该部分的所有DNS记录。管理员需要理解如何创建、管理和更新这些区域文件，以保持DNS服务的正常运行。由于提供的内容有限，完整的手册将详细阐述BIND 9的配置选项、安全策略、动态DNS更新、DNSSEC（DNS安全扩展）、性能监控和故障排查等内容。对于DNS管理员或网络管理员来说，这是一份非常宝贵的参考资料。

3.3. NAME SERVER OPERATIONS CHAPTER 3. NAME SERVER CONFIGURATION

named-checkzone [-djqvD] [-c class] [-o output] [-t directory] [-w

directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] [-W

(ignore|warn)] zone [filename]

named-compilezone Similar to named-checkzone, but it always dumps the zone content to a speciﬁed

ﬁle (typically in a different format).

rndc The remote name daemon control (rndc) program allows the system administrator to control the

operation of a name server. Since BIND 9.2, rndc supports all the commands of the BIND 8 ndc

utility except ndc start and ndc restart, which were also not supported in ndc’s channel mode. If

you run rndc without any options it will display a usage message as follows:

Usage

rndc [-c config] [-s server] [-p port] [-y key] command [command...]

The command is one of the following:

reload Reload conﬁguration ﬁle and zones.

reload zone [class [view]] Reload the given zone.

refresh zone [class [view]] Schedule zone maintenance for the given zone.

retransfer zone [class [view]] Retransfer the given zone from the master.

freeze [zone [class [view]]] Suspend updates to a dynamic zone. If no zone is speci-

ﬁed, then all zones are suspended. This allows manual edits to be made to a zone normally

updated by dynamic update. It also causes changes in the journal ﬁle to be synced into the

master and the journal ﬁle to be removed. All dynamic update attempts will be refused while

the zone is frozen.

thaw [zone [class [view]]] Enable updates to a frozen dynamic zone. If no zone is spec-

iﬁed, then all frozen zones are enabled. This causes the server to reload the zone from disk,

and re-enables dynamic updates after the load has completed. After a zone is thawed, dy-

namic updates will no longer be refused.

notify zone [class [view]] Resend NOTIFY messages for the zone.

reconfig Reload the conﬁguration ﬁle and load new zones, but do not reload existing zone ﬁles

even if they have changed. This is faster than a full reload when there is a large number of

zones because it avoids the need to examine the modiﬁcation times of the zones ﬁles.

stats Write server statistics to the statistics ﬁle.

querylog Toggle query logging. Query logging can also be enabled by explicitly directing the

queries category to a channel in the logging section of named.conf or by specifying query-

log yes; in the options section of named.conf.

dumpdb [-all|-cache|-zone] [view ...] Dump the server’s caches (default) and/or zones

to the dump ﬁle for the speciﬁed views. If no view is speciﬁed, all views are dumped.

stop [-p] Stop the server, making sure any recent changes made through dynamic update or

IXFR are ﬁrst saved to the master ﬁles of the updated zones. If -p is speciﬁed named’s process

CHAPTER 3. NAME SERVER CONFIGURATION 3.3. NAME SERVER OPERATIONS

id is returned. This allows an external process to determine when named had completed

stopping.

halt [-p] Stop the server immediately. Recent changes made through dynamic update or IXFR

are not saved to the master ﬁles, but will be rolled forward from the journal ﬁles when the

server is restarted. If -p is speciﬁed named’s process id is returned. This allows an external

process to determine when named had completed halting.

trace Increment the servers debugging level by one.

trace level Sets the server’s debugging level to an explicit value.

notrace Sets the server’s debugging level to 0.

flush Flushes the server’s cache.

flushname name Flushes the given name from the server’s cache.

status Display status of the server. Note that the number of zones includes the internal bind/CH

zone and the default ./IN hint zone if there is not an explicit root zone conﬁgured.

recursing Dump the list of queries named is currently recursing on.

A conﬁguration ﬁle is required, since all communication with the server is authenticated with

digital signatures that rely on a shared secret, and there is no way to provide that secret other than

with a conﬁguration ﬁle. The default location for the rndc conﬁguration ﬁle is /etc/rndc.conf,

but an alternate location can be speciﬁed with the -c option. If the conﬁguration ﬁle is not found,

rndc will also look in /etc/rndc.key (or whatever sysconfdir was deﬁned when the BIND

build was conﬁgured). The rndc.key ﬁle is generated by running rndc-confgen -a as described

in Section 6.2.4.

The format of the conﬁguration ﬁle is similar to that of named.conf, but limited to only four

statements, the options, key, server and include statements. These statements are what associate

the secret keys to the servers with which they are meant to be shared. The order of statements is

not signiﬁcant.

The options statement has three clauses: default-server, default-key, and default-port. default-

server takes a host name or address argument and represents the server that will be contacted if no

-s option is provided on the command line. default-key takes the name of a key as its argument,

as deﬁned by a key statement. default-port speciﬁes the port to which rndc should connect if no

port is given on the command line or in a server statement.

The key statement deﬁnes a key to be used by rndc when authenticating with named. Its syntax

is identical to the key statement in named.conf. The keyword key is followed by a key name,

which must be a valid domain name, though it need not actually be hierarchical; thus, a string like

”rndc key” is a valid name. The key statement has two clauses: algorithm and secret. While the

conﬁguration parser will accept any string as the argument to algorithm, currently only the string

”hmac-md5” has any meaning. The secret is a base-64 encoded string as speciﬁed in RFC 3548.

The server statement associates a key deﬁned using the key statement with a server. The keyword

server is followed by a host name or address. The server statement has two clauses: key and

port. The key clause speciﬁes the name of the key to be used when communicating with this

server, and the port clause can be used to specify the port rndc should connect to on the server.

A sample minimal conﬁguration ﬁle is as follows:

key rndc_key {

4.3. INCREMENTAL ZONE TRANSFERS (IXFR) CHAPTER 4. ADVANCED DNS FEATURES

large zone is updated frequently. Instead, the dump is delayed by up to 15 minutes, allowing additional

updates to take place.

When a server is restarted after a shutdown or crash, it will replay the journal ﬁle to incorporate into the

zone any updates that took place after the last zone dump.

Changes that result from incoming incremental zone transfers are also journalled in a similar way.

The zone ﬁles of dynamic zones cannot normally be edited by hand because they are not guaranteed to

contain the most recent dynamic changes — those are only in the journal ﬁle. The only way to ensure

that the zone ﬁle of a dynamic zone is up to date is to run rndc stop.

If you have to make changes to a dynamic zone manually, the following procedure will work: Disable

dynamic updates to the zone using rndc freeze zone. This will also remove the zone’s .jnl ﬁle and

update the master ﬁle. Edit the zone ﬁle. Run rndc thaw zone to reload the changed zone and re-enable

dynamic updates.

4.3 Incremental Zone Transfers (IXFR)

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data,

instead of having to transfer the entire zone. The IXFR protocol is speciﬁed in RFC 1995. See [Proposed

Standards].

When acting as a master, BIND 9 supports IXFR for those zones where the necessary change history

information is available. These include master zones maintained by dynamic update and slave zones

whose data was obtained by IXFR. For manually maintained master zones, and for slave zones obtained

by performing a full zone transfer (AXFR), IXFR is supported only if the option ixfr-from-differences is

set to yes.

When acting as a slave, BIND 9 will attempt to use IXFR unless it is explicitly disabled. For more

information about disabling IXFR, see the description of the request-ixfr clause of the server statement.

4.4 Split DNS

Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually

referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS

this way.

One common reason for setting up a DNS system this way is to hide ”internal” DNS information from

”external” clients on the Internet. There is some debate as to whether or not this is actually useful.

Internal DNS information leaks out in many ways (via email headers, for example) and most savvy

”attackers” can ﬁnd the information they need using other means. However, since listing addresses

of internal servers that external clients cannot possibly reach can result in connection delays and other

annoyances, an organization may choose to use a Split DNS to present a consistent view of itself to the

outside world.

Another common reason for setting up a Split DNS system is to allow internal networks that are behind

ﬁlters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the

Internet. Split DNS can also be used to allow mail from outside back in to the internal network.

4.4.1 Example split DNS setup

Let’s say a company named Example, Inc. (example.com) has several corporate sites that have an

internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ),

or ”outside” section of a network, that is available to the public.

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail

with people on the outside. The company also wants its internal resolvers to have access to certain

internal-only zones that are not available at all outside of the internal network.

剩余119页未读，继续阅读

shuerbuzuo

粉丝: 0
资源: 1

BIND 9 管理员参考手册 - Internet Systems Consortium

BV转AV

电子-CF7670BV2pcb.PDF

汽车编程-TASKING VX-toolset for ARM User Guide.pdf

基于ARM的智能家居语音控制系统设计.pdf

基于赛元ARM内核MCU的智能温度控制系统的设计.pdf

三相电表RN8302BV2.0硬件资料

UTV210BV04评估板友坚官网资料（Cortex-A8 S5PV210）

嵌入式软件设计--大连理工大学--赖晓晨.zip 内含全部PPT及源码

TASKING VX-toolset for ARM 用户指南-汽车编程解析

【java毕业设计】应急救援物资管理系统源码（springboot+vue+mysql+说明文档）.zip

最新资源