30.6. Домэйн Нэрийн Систем (DNS)

30.6.6.1. /etc/namedb/named.conf

// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.

options {
	// All file and path names are relative to the chroot directory,
	// if any, and should be fully qualified.
	directory	"/etc/namedb/working";
	pid-file	"/var/run/named/pid";
	dump-file	"/var/dump/named_dump.db";
	statistics-file	"/var/stats/named.stats";

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
	listen-on	{ 127.0.0.1; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
//	listen-on-v6	{ ::1; };

// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
	disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
	disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
	disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
	forwarders {
		127.0.0.1;
	};
*/

// If the 'forwarders' clause is not empty the default is to 'forward first'
// which will fall back to sending a query from your local server if the name
// servers in 'forwarders' do not have the answer.  Alternatively you can
// force your name server to never initiate queries of its own by enabling the
// following line:
//	forward only;

// If you wish to have forwarding configured automatically based on
// the entries in /etc/resolv.conf, uncomment the following line and
// set named_auto_forward=yes in /etc/rc.conf.  You can also enable
// named_auto_forward_only (the effect of which is described above).
//	include "/etc/namedb/auto_forward.conf";

Тайлбар дээр хэлсэнчлэн дээд гарцын түр тогтоогчоос хүртэхийн тулд forwarders-г идэвхжүүлж болох юм. Энгийн үед, нэрийн сервер нь хариултыг олтлоо давталттай байдлаар хэд хэдэн нэрийн серверүүдээр дамжин асууна. Энэ тохируулгыг идэвхжүүлснээр, дээд гарцынхаа нэрийн серверээс (эсвэл зааж өгсөн нэрийн сервер) хамгийн түрүүнд асууж, энэ серверийн түр санах ойд байгаа мэдээллээс хүртэхийг эрмэлзэнэ. Хэрэв дээд гарцын нэрийн сервер нь олон асуулгад хариулдаг, хурдан үйлчилдэг сервер байвал дээрх тохируулгыг идэвхжүүлсний үр ашиг гарна.

	/*
	   Modern versions of BIND use a random UDP port for each outgoing
	   query by default in order to dramatically reduce the possibility
	   of cache poisoning.  All users are strongly encouraged to utilize
	   this feature, and to configure their firewalls to accommodate it.

	   AS A LAST RESORT in order to get around a restrictive firewall
	   policy you can try enabling the option below.  Use of this option
	   will significantly reduce your ability to withstand cache poisoning
	   attacks, and should be avoided if at all possible.

	   Replace NNNNN in the example with a number between 49160 and 65530.
	*/
	// query-source address * port NNNNN;
};

// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*	Slaving the following zones from the root name servers has some
	significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
	3. Greater resilience to any potential root server failure/DDoS

	On the other hand, this method requires more monitoring than the
	hints file to be sure that an unexpected failure mode has not
	incapacitated your server.  Name servers that are serving a lot
	of clients will benefit more from this approach than individual
	hosts.  Use with caution.

	To use this mechanism, uncomment the entries below, and comment
	the hint zone above.

	As documented at http://dns.icann.org/services/axfr/ these zones:
	"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
	are availble for AXFR from these servers on IPv4 and IPv6:
	xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
	type slave;
	file "/etc/namedb/slave/root.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
zone "arpa" {
	type slave;
	file "/etc/namedb/slave/arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
*/

/*	Serving the following zones locally will prevent any queries
	for these zones leaving your network and going to the root
	name servers.  This has two significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912 and 5735 (and BCP 32 for localhost)
zone "localhost"	{ type master; file "/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };

// "This" Network (RFCs 1912 and 5735)
zone "0.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// Private Use Networks (RFCs 1918 and 5735)
zone "10.in-addr.arpa"	   { type master; file "/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// Link-local/APIPA (RFCs 3927 and 5735)
zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IETF protocol assignments (RFCs 5735 and 5736)
zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737)
zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Range for Documentation (RFC 3849)
zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// Domain Names for Documentation and Testing (BCP 32)
zone "test" { type master; file "/etc/namedb/master/empty.db"; };
zone "example" { type master; file "/etc/namedb/master/empty.db"; };
zone "invalid" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.com" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.net" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.org" { type master; file "/etc/namedb/master/empty.db"; };

// Router Benchmark Testing (RFCs 2544 and 5735)
zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };

// IANA Reserved - Old Class E Space (RFC 5735)
zone "240.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "241.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "242.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "243.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "244.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "245.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "246.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "247.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "248.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "249.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "250.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "251.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "252.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "253.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "254.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "3.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "4.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "5.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "8.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "c.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "e.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "0.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "1.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "2.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "3.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "4.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "5.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "8.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "0.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "1.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "2.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "3.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "4.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "5.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "6.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "7.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "9.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "a.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "b.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "d.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "e.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "f.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int"		{ type master; file "/etc/namedb/master/empty.db"; };

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries.  It can be convenient to become
// a slave at least for the zone your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// master name server.
//
// Do not forget to include the reverse lookup zone!
// This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
//
// Before starting to set up a master zone, make sure you fully
// understand how DNS and BIND work.  There are sometimes
// non-obvious pitfalls.  Setting up a slave zone is usually simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.

/* An example dynamic zone
key "exampleorgkey" {
	algorithm hmac-md5;
	secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
	type master;
	allow-update {
		key "exampleorgkey";
	};
	file "/etc/namedb/dynamic/example.org";
};
*/

/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" {
	type slave;
	file "/etc/namedb/slave/1.168.192.in-addr.arpa";
	masters {
		192.168.1.1;
	};
};
*/

named.conf доторх эдгээр жишээнүүд нь ердийн болон урвуу бүсийн зарц бүртгэлүүд болно.

Шинэ бүс нэмэхдээ, named.conf файл дотор шинэ бүртгэл оруулах хэрэгтэй.

Жишээ нь, example.org домэйны хувьд хамгийн хялбар бүртгэл дараах байдалтай байна:

zone "example.org" {
	type master;
	file "master/example.org";
};

Энэ бүс нь эзэн бүс болохыг type илэрхийллээс харж болно. Мөн бүсийн мэдээллийг /etc/namedb/master/example.org файл дотор агуулж байгааг file илэрхийллээс харж болно.

zone "example.org" {
	type slave;
	file "slave/example.org";
};

Зарц бүсийн хувьд, тухайн бүсийн хувьд бүсийн мэдээлэл эзэн нэрийн серверээс зөөгдөж ирэх ба зааж өгсөн файлд хадгалагдана. Эзэн сервер унтарсан эсвэл холбоо тогтоох боломжгүй болбол, зарц нэрийн серверт бүсийн мэдээлэл байгаа тул асуулгуудад хариулах чадвартай байна.

30.6.6.2. Бүсийн Файлууд

example.org домэйны хувьд жишээ эзэн бүсийн файлыг дор үзүүлэв (/etc/namedb/master/example.org файл):

$TTL 3600        ; 1 hour default TTL
example.org.    IN      SOA      ns1.example.org. admin.example.org. (
                                2006051501      ; Serial
                                10800           ; Refresh
                                3600            ; Retry
                                604800          ; Expire
                                300             ; Negative Response TTL
                        )

; DNS Servers
                IN      NS      ns1.example.org.
                IN      NS      ns2.example.org.

; MX Records
                IN      MX 10   mx.example.org.
                IN      MX 20   mail.example.org.

                IN      A       192.168.1.1

; Machine Names
localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
mail            IN      A       192.168.1.5

; Aliases
www             IN      CNAME   example.org.

“.” тэмдэгтээр төгссөн хост нэрүүд нь жинхэнэ хост нэрүүд бөгөөд “.” тэмдэгтээр төгсөөгүй нэрүүдэд үүсэл залгагдахыг анхаарна уу. Жишээлбэл, ns1 нь ns1.example.org.-руу хөрвүүлэгдэх болно.

Бүсийн файл дараах хэлбэртэй байна:

recordname      IN recordtype   value

Хамгийн өргөн хэрэглэгддэг DNS бичлэгүүд:

example.org. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        300 )           ; Negative Response TTL

       IN NS           ns1.example.org.

Энэ бол NS бичлэг. Тухайн бүсийн хувьд бүрэн эрхт хариултыг өгч чадах сервер бүрийн хувьд энэ бичлэг байх ёстой.

localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
mail            IN      A       192.168.1.5

A бичлэг нь машины нэрийг заана. Дээр үзүүлсэнчлэн, ns1.example.org нь 192.168.1.2-руу буулгагдана.

                IN      A       192.168.1.1

Энэ мөр нь 192.168.1.1 гэсэн IP хаягийг үүсэлд оноож байна, бидний жишээн дээр example.org.

www             IN CNAME        @

Хүлээн зөвшөөрөгдсөн нэрийн бичлэг нь машинд хуурамч дүр өгөхөд хэрэглэгдэнэ. Энэ жишээн дээр, www нь example.org (192.168.1.1) гэсэн домэйн нэртэй “master” машины хуурамч дүрийн нэр юм. CNAME-г тухайн хостын нэрийн хувьд өөр төрлийн бичлэгтэй хэзээ ч цуг хэрэглэж болохгүй.

               IN MX   10      mail.example.org.

MX бичлэг нь аль захидлын серверүүд тухайн бүсийн захидлыг хүлээж авах үүрэгтэй болохыг зааж өгнө. mail.example.org нь захидлын серверийн хост нэр бөгөөд 10 нь энэ захидлын серверийн зэрэглэлийг зааж байна.

Нэг бүсэд 10, 20 гэх мэт ялгаатай зэрэглэлтэй хэд хэдэн захидлын сервер байж болно. example.org домэйн руу захидал явуулах гэж байгаа сервер эхлээд хамгийн өндөр зэрэглэлтэй MX сервертэй (хамгийн бага зэрэглэлийн дугаартай), дараа нь дараагийн хамгийн өндөр зэрэглэлтэй сервертэй гэх мэтчилэн захидлыг явуулж чадтал дарааллаар нь холбоо тогтооно.

in-addr.arpa бүсийн файл (урвуу DNS) нь ижил хэлбэртэй байна. Ганцхан ялгаа нь A болон CNAME бичлэгийн оронд PTR бичлэгийг хэрэглэнэ.

$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        300 )           ; Negative Response TTL

        IN      NS      ns1.example.org.
        IN      NS      ns2.example.org.

1       IN      PTR     example.org.
2       IN      PTR     ns1.example.org.
3       IN      PTR     ns2.example.org.
4       IN      PTR     mx.example.org.
5       IN      PTR     mail.example.org.

Энэ файлд дээрх домэйны IP-с хост нэр рүү буулгасан зохих шаардлагатай буулгалтуудыг үзүүлсэн байна.

PTR бичлэгийн баруун талын бүх нэрс төгссөн байх ёстой (өөрөөр хэлбэл “.”-ээр төгссөн байна).

30.6.8.1. Рекурсив DNS серверийн тохиргоо

Рекурсив DNS серверийн гүйцэтгэсэн хүсэлтүүдийн DNSSEC шалгалтыг идэвхжүүлэхийн тулд named.conf файлд цөөн өөрчлөлтийг хийх хэрэгтэй. Эдгээр өөрчлөлтүүдийг хийхээс өмнө эх бүсийн түлхүүр эсвэл итгэлцлийн анкорыг (anchor) авсан байх шаардлагатай. Одоогоор эх бүсийн түлхүүр нь BIND ойлгох файлын форматаар байдаггүй бөгөөд зөв хэлбэр рүү гараар хувиргах ёстой байдаг. Түлхүүрийг dig ашиглан эх бүсээс асууж авч болдог. Ингэхийн тулд

% dig +multi +noall +answer DNSKEY . > root.dnskey

гэж ажиллуулна. Түлхүүр root.dnskey файлд байх болно. Доторх нь иймэрхүү байдалтай харагдана:

. 93910 IN DNSKEY 257 3 8 (
	AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
	bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
	/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
	JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
	oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
	LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
	Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
	LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
	) ; key id = 19036
. 93910 IN DNSKEY 256 3 8 (
	AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
	UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
	g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
	EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
) ; key id = 34525

Олж авсан түлхүүрүүд энэ жишээн дээрхээс өөр байвал сандрах хэрэггүй. Тэдгээр нь энэ зааврыг бичсэнээс хойш өөрчлөгдсөн байж болох юм. Энэ гаралт нь хоёр түлхүүрийг агуулдаг. DNSKEY бичлэгийн төрлийн дараах 257 гэсэн утга бүхий жагсаалтад байгаа эхний түлхүүр нь хэрэгтэй нь юм. Энэ утга нь Аюулгүй Орох Цэг (SEP), түлхүүрийг гарын үсгээр баталгаажуулах түлхүүр гэгддэг (KSK) гэдгийг илэрхийлдэг. 256 гэсэн хоёр дахь түлхүүр нь захирагдагч түлхүүр бөгөөд Бүсийг гарын үсгээр баталгаажуулах түлхүүр (ZSK) гэгддэг. Эдгээр өөр түлхүүрийн төрлүүдийн талаар Хэсэг 30.6.8.2 хэсэгт дэлгэрэнгүй байгаа.

Одоо түлхүүрийг шалгаж BIND ашиглаж болох хэлбэрт оруулах ёстой. Түлхүүрийг баталгаажуулахын тулд DS RR-г үүсгэнэ. Эдгээр RR-уудыг агуулсан файлыг дараах тушаалаар үүсгэнэ

% dnssec-dsfromkey -f root-dnskey . > root.ds

Эдгээр бичлэгүүд нь SHA-1 болон SHA-256-г ашигладаг бөгөөд дараах жишээтэй төстэй харагдах ёстой. Урт нь SHA-256-г ашигладаг.

. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

SHA-256 RR-г https://data.iana.org/root-anchors/root-anchors.xml дээр байгаа дайжесттай харьцуулж болно. Түлхүүрийг XML файлын өгөгдлөөр өөрчлөгдөөгүйг жинхэнэ утгаар мэдэхийн тулд https://data.iana.org/root-anchors/root-anchors.asc дахь PGP гарын үсгийг ашиглан шалгаж болно.

Дараа нь түлхүүрийг зөв хэлбэрт оруулсан байх ёстой. Энэ нь BIND 9.6.2 болон 9.7 түүнээс хойшхи хувилбаруудын хооронд жаахан ялгаатай байдаг. 9.7 хувилбарт түлхүүрт хийгдэх өөрчлөлтийг автоматаар хянаж шаардлагатай бол шинэчилдэг дэмжлэг нэмэгдсэн байдаг. Үүнийг доорх жишээн дээр үзүүлсэн шиг managed-keys ашиглан хийдэг. Хуучин хувилбар ашиглаж байгаа тохиолдолд түлхүүрийг trusted-keys гэдгийг ашиглан нэмдэг бөгөөд шинэчлэлтүүдийг гараар хийх ёстой байдаг. BIND 9.6.2-ийн хувьд формат доорхтой адил хэлбэрийн байна:

trusted-keys {
	"." 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
	QxA+Uk1ihz0=";
};

For 9.7 the format will instead be:

managed-keys {
	"." initial-key 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
	QxA+Uk1ihz0=";
};

Эх түлхүүрийг named.conf файл руу шууд эсвэл түлхүүр бүхий файлыг оруулан нэмж өгч болно. Эдгээр алхмуудын дараа BIND-г хүсэлтүүд дээр DNSSEC шалгалтыг хийдэг болгохын тулд named.conf файлыг засварлан дараах мөрийг options хэсэгт нэмж тохиргоог хийнэ:

dnssec-enable yes;
dnssec-validation yes;

Ажиллаж байгааг шалгахын тулд дөнгөж тохируулсан тайлагчийг ашиглан гарын үсгээр баталгаажсан бүсийг асуусан хүсэлтийг dig ашиглан явуулна. Амжилттай хариулт AD тэмдэглэгээтэй байх бөгөөд энэ нь өгөгдлийг таньж зөвшөөрсөн гэсэн үг юм. Доорх хүсэлттэй адил хүсэлтийг ажиллуулбал

% dig @resolver +dnssec se ds

.se бүсийн хувьд DS RR-г буцаах ёстой. flags: хэсэг дээр AD флаг тохируулагдсан байх ёстой бөгөөд доорх байдлаар харагдана:

...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
...

Тайлагч одоо DNS хүсэлтүүдийг шалгаж таних чадвартай боллоо.

30.6.8.2. Бүрэн эрхт DNS серверийн тохиргоо

DNSSEC-р баталгаажсан бүсэд үйлчлэх бүрэн эрхт нэрийн сервертэй болохын тулд бага зэргийн зүйлс хийх шаардлагатай. Бүсийг криптограф түлхүүрүүд ашиглан баталгаажуулах ёстой бөгөөд түлхүүрүүдийг үүсгэх ёстой. Энэ зорилгоор зөвхөн нэг түлхүүр ашиглаж болно. Гэхдээ зөвлөдөг арга бол байнга өөрчлөгдөөд байдаггүй, хүчтэй, маш сайн хамгаалагдсан Түлхүүрийг гарын үсгээр баталгаажуулах Түлхүүр (KSK) болон байнга өөрчлөгддөг Бүсийг гарын үсгээр баталгаажуулах Түлхүүртэй (ZSK) байх явдал юм. Үйл ажиллагааны хувьд зөвлөсөн практикуудын талаарх мэдээллийг RFC 4641: DNSSEC үйл ажиллагааны практикууд хаягаас авч болно. Эх бүсийн талаарх практикуудыг Эх бүсийн KSKоператорт зориулсан DNSSEC практик болон Эх бүсийн ZSKоператорт зориулсан DNSSEC практик хаягуудаас олж болно. KSK нь дараалсан бүрэн эрхийг шалгагдах шаардлагатай байгаа өгөгдөлд өгөхөд хэрэглэгддэг бөгөөд бас Secure Entry Point буюу Аюулгүй Орох Цэг (SEP) түлхүүр гэгддэг. Энэ түлхүүрийн зурвасын дайжестийг Delegation Signer буюу Төлөөлөн баталгаажуулагч(DS) бичлэг гэгддэг бөгөөд итгэлцлийн дарааллыг бий болгохын тулд эцэг бүсэд бичигдсэн байх ёстой. Үүнийг хэрхэн хийх нь эцэг бүсийг эзэмшигчээс хамаардаг. ZSK нь бүсийг баталгаажуулахад хэрэглэгддэг бөгөөд тэндээ бичигдсэн байх ёстой байдаг.

Өмнөх жишээн дээр харуулсан example.com бүсийн хувьд DNSSEC-г идэвхжүүлэхийн тулд эхний алхам нь KSK болон ZSK түлхүүрийн хослолыг үүсгэх dnssec-keygen-г ашиглах явдал юм. Энэ түлхүүрийн хослол нь өөр өөр криптограф алгоритмуудыг хэрэглэж болно. Түлхүүрүүдийн хувьд RSA/SHA256-г ашиглахыг зөвлөдөг бөгөөд 2048 битийн түлхүүрийн урт хангалттай. example.com-н хувьд KSK-г үүсгэхийн тулд дараахийг ажиллуулна

% dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com

ZSK-г үүсгэхийн тулд

% dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

dnssec-keygen хоёр файлыг гаргах бөгөөд нийтийн болон хувийн түлхүүрүүд нь Kexample.com.+005+nnnnn.key (нийтийн) болон Kexample.com.+005+nnnnn.private (хувийн) гэсэн файлуудтай төстэй нэртэйгээр байна. Файлын нэрийн nnnnn хэсэг нь таван оронтой түлхүүрийн ID юм. Аль түлхүүрийн ID аль түлхүүрт харгалзаж байгааг хянаж байх хэрэгтэй. Энэ нь ялангуяа бүсэд нэгээс илүү түлхүүр ашиглаж байгаа үед чухал юм. Түлхүүрүүдийн нэрийг бас өөрчилж болно. KSK файл бүрийн хувьд дараахийг ажиллуулна:

% mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key
% mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private

ZSK файлуудын хувьд KSK-г ZSK-р солиорой. Одоо файлуудыг $include ашиглан бүсийн файлд оруулж болно. Иймэрхүү байдалтай харагдана:

$include Kexample.com.+005+nnnnn.KSK.key    ; KSK
$include Kexample.com.+005+nnnnn.ZSK.key    ; ZSK

Төгсгөлд нь бүсийг баталгаажуулж BIND-д баталгаажуулсан бүсийн файлыг ашиглахыг зааж өгнө. Бүсийг баталгаажуулахын тулд dnssec-signzone-г ашиглана. example.com.db-д байрлах example.com бүсийг баталгаажуулах тушаал иймэрхүү байна

% dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key

-k аргументад өгөгдсөн түлхүүр нь KSK ба нөгөө нэг түлхүүрийн файл нь ZSK бөгөөд баталгаажуулахад хэрэглэгдэх ёстой. Нэгээс илүү KSK болон ZSK өгч болох бөгөөд ингэсэн тохиолдолд бүс бүх өгөгдсөн түлхүүрээр баталгаажна. Энэ нь бүсийн өгөгдлийг нэгээс илүү алгоритмаар баталгаажуулахын тулд хэрэгтэй байж болно. dnssec-signzone-ий гаралт нь бүх RR нь баталгаажсан бүсийн файл байна. Энэ гаралт нь example.com.db.signed мэтийн .signed гэсэн өргөтгөлтэй файлд байх болно. DS бичлэгүүд нь бас тусдаа dsset-example.com файлд бичигддэг. Энэ баталгаажсан бүсийг ашиглахын тулд named.conf файлын бүсийн хэсэгт example.com.db.signed-г ашиглахаар болгож өөрчлөх хэрэгтэй. Анхдагчаар гарын үсгүүд нь 30 хоног хүчинтэй байдаг бөгөөд хүчингүй гарын үсгүүд бүхий бичлэгүүдийг нэр тайлагчдаар хадгалуулахгүй байлгахын тулд бүсийг ядаж ойролцоогоор 15 хоногийн дараа дахин баталгаажуулах хэрэгтэй гэсэн үг юм. Үүнийг хийхийн тулд скрипт бичээд cron-д ажиллуулахаар тохируулж болно. Дэлгэрэнгүйг холбогдох гарын авлагуудаас харна уу.

Бүх криптограф түлхүүрүүдийн адил хувийн түлхүүрүүдийг нууцлан хадгалахыг санаарай. Түлхүүрийг солихдоо шинэ түлхүүрийг бүсэд оруулан хуучнаар эхлээд баталгаажуулах нь зүйтэй бөгөөд дараа нь шинэ түлхүүрийг ашиглан баталгаажуулах хэрэгтэй. Эдгээр алхмуудыг хийсний дараа хуучин түлхүүрийг бүсээс арилгаж болно. Ингэж хийхгүй бол шинэ түлхүүр DNS-н шатлалаар түгээгдэн зарлагдтал DNS-н өгөгдөл нь хүртээмжгүй байх нөхцөлд хүргэж болно. Түлхүүр солих мэдээлэл болон DNSSEC-г ажиллуулахтай холбоотой асуудлуудын талаар дэлгэрэнгүйг RFC 4641: DNSSEC Operational practices хаягаас үзнэ үү.

30.6.8.3. BIND 9.7 болон түүнээс хойшхи хувилбаруудыг ашиглан автоматжуулах

BIND 9.7 хувилбараас эхлээд Smart Signing буюу ухаалгаар баталгаажуулах боломж шинээр нэмэгдсэн. Энэ боломж нь түлхүүрийг удирдах болон баталгаажуулах процессын зарим хэсгийг автоматжуулснаар хялбар болгохыг зорьдог. key repository санд түлхүүрүүдийг байршуулж auto-dnssec гэсэн шинэ тохиргоог ашиглан шаардлагатай тохиолдолд дахин баталгаажуулагддаг динамик бүсийг үүсгэх боломжтой байдаг. Энэ бүсийг шинэчлэхийн тулд nsupdate-г шинэ -l аргументтай хэрэглэнэ. rndc бас түлхүүр байрлах сан дахь түлхүүрүүдээр бүсүүдийг sign гэсэн тохиргоо ашиглан баталгаажуулах боломжтой болсон. example.com-н хувьд энэ автоматаар хийх баталгаажуулалт болон бүсийг шинэчлэх боломжийг BIND-д зааж өгөхийн тулд дараахийг named.conf файлд нэмж өгөх хэрэгтэй:

zone example.com {
	type master;
	key-directory "/etc/named/keys";
	update-policy local;
	auto-dnssec maintain;
	file "/etc/named/dynamic/example.com.zone";
};

Эдгээр өөрчлөлтүүдийг хийсний дараа Хэсэг 30.6.8.2-д тайлбарласны дагуу бүсийн хувьд түлхүүрүүдийг үүсгэж өгнө. Ингэхийн тулд тэр түлхүүрүүдийг түлхүүр байрлах санд хийж бүсийн тохиргооны key-directory гэдэгт уг санг өгөх бөгөөд ингэснээр бүс автоматаар баталгаажуулагдах болно. Ийм замаар тохируулсан бүсэд хийх шинэчлэлтийг nsupdate ашиглан хийх ёстой бөгөөд энэ нь бүсэд шинэ өгөгдөл нэмэн дахин баталгаажуулах ажлыг хийдэг байна. Илүү дэлгэрэнгүйг Хэсэг 30.6.10 болон BIND-н баримтаас үзнэ үү.