Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference - نسخه متنی

Richard L. Petersen

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








Dynamic Update: DHCP and Journal Files


There are situations where you will need to have zones updated dynamically. Instead of your manually editing a zone file to make changes in a zone, an outside process updates the zone, making changes and saving the file automatically. Dynamic updates are carried out both by master zones updating slave zones and by DHCP servers providing IP addresses they generated for hosts to the DNS server.

A journal file is maintained recording all the changes made to a zone, having a .jnl extension. Should a system crash occur, this file is read to implement the most current changes. Should you want to manually update a dynamically updated zone, you will need to erase its journal file first; otherwise, your changes would be overwritten by the journal file entries.

You allow a zone to be automatically updated by specifying the allow-update option. This option indicates the host that can perform the update.

allow-update {turtle.mytrek.com;};

Alternatively, for master zones, you can create a more refined set of access rules using the update-policy statement. With the update-policy statement, you can list several grant and deny rules for different hosts and types of hosts.


TSIG Signatures and Updates


With BIND 9.x, TSIG signature names can be used instead of host names or IP addresses for both allow-update and update-policy statements (see the following sections on TSIG). Use of TSIG signatures implements an authentication of a host performing a dynamic update, providing a much greater level of security. For example, to allow a DHCP server to update a zone file, you would place an allow-update entry in the zone statement listed in the named.conf file.

The TSIG key is defined in a key statement, naming the key previously created by the dnssec-keygen command. The algorithm is HMAC-MD5, and the secret is the encryption key listed in .private file generated by dnssec-keygen.

key mydhcpserver {
algorithm HMAC-MD5;
secret "ONQAfbBLnvWU9H8hRqq/WA==";
};

The key name can then be used in an allow-update or allow-policy statement to specify a TSIG key.

allow-update { key mydhcpserver;};


Manual Updates: nsupdate


You can use the update procedure to perform any kind of update you want. You can perform updates manually or automatically using a script. For DHCP updates, the DHCP server is designed to perform dynamic updates of the DNS server. You will need to configure the DHCP server appropriately, specifying the TSIG key to use and the zones to update.

You can manually perform an update using the

nsupdate command, specifying the file holding the key with the

-k option.

nsupdate -k myserver.private

At the prompt, you can use

nsupdate commands to implement changes. You match on a record using its full or partial entry. To update a record, you would first delete the old one and then add the changed version, as shown here:

update delete rabbit.mytrek.com. A 192.168.0.2
update add rabbit.mytrek.com. A 192.168.0.44


/ 328