30.6. Домэйн Нэрийн Систем (DNS)
Өмнөх | Бүлэг 30. Сүлжээний орчны Серверүүд | Дараах

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

Хувь нэмрээ оруулсан Шерн Лий, Том Родес ба Даниэл Гэрзо.
Орчуулсан Лодойсамбын Баянзул.

### 30.6.1. Удиртгал

FreeBSD анхдагч байдлаар DNS протоколын хамгийн өргөн хэрэглэгддэг хэрэгжүүлэлт болох BIND (Berkeley Internet Name Domain)-н аль нэг хувилбарыг агуулсан байдаг. DNS нь нэрүүдийг IP хаягууд руу, мөн эсрэгээр нь буулгахад хэрэглэгддэг протокол юм. Жишээ нь, `www.FreeBSD.org`-г асуусан DNS асуулга явуулахад, хариуд нь FreeBSD Төсөлийн вэб серверийн IP хаяг ирэх бол, `ftp.FreeBSD.org`-н хувьд асуулга явуулахад, хариуд нь харгалзах FTP машины IP хаяг ирэх болно. Яг үүнтэй адилаар эсрэгээр нь хийж болно. Ямар нэг IP-р асуулга явуулахад түүний хост нэрийг олж болно. DNS хайлт хийхийн тулд тухайн системд домэйн нэрийн сервер ажиллаж байх ёстой.

FreeBSD нь одоо BIND9 DNS сервер програмын хамт ирдэг болсон. Бидний суулгац нь файл системийн шинэчилсэн зохион байгуулалт, автомат chroot(8) тохиргоо зэрэг аюулгүй байдлыг дээд зэргээр хангах функцүүдтэй ирдэг.

DNS бол Интернэт дээр тулгуурласан, бүрэн эрхт root буюу эх сервер, Top Level Domain буюу Дээд Түвшний Домэйн (TLD) сервер, болон домэйн тус бүрийн мэдээллийг агуулж байдаг бусад жижиг нэрийн серверүүдээс бүтсэн нарийн төвөгтэй систем юм.

BIND одоо Internet Systems Consortium http://www.isc.org/-н мэдэлд байдаг.

### 30.6.2. Нэр Томъёо

Энэ баримтыг ойлгохын тулд, DNS-тэй холбоотой зарим нэр томъёог ойлгосон байх шаардлагатай.

Нэр | Тайлбар
--- | ---
Forward буюу Ердийн DNS | Хост нэрийг IP хаяг руу буулгана.
Origin буюу Үүсэл | Тухайн бүсийн файлд хамрагдаж байгаа домэйныг заана.
named, BIND | FreeBSD-н BIND нэрийн серверийг нэрлэх түгээмэл нэршил.
Resolver буюу Тайлагч | Машин, бүсийн мэдээллийн талаар нэрийн серверээс асуулга явуулахын тулд ашигладаг системийн процесс.
Reverse буюу Урвуу DNS | IP хаягийг хост нэр рүү буулгана.
Root zone буюу Эх бүс | Интернэт бүсийн шатлалын эхлэл. Файл системийн бүх файлууд эх санд харъяалагддаг шиг, бүх бүсүүд эх бүсэд харъяалагдана.
Zone буюу Бүс | Нэг бүрэн эрхт газраар удирдуулж байгаа домэйн, дэд домэйн, эсвэл DNS-н нэг хэсэг.

Бүсүүдийн жишээ:

- `.` нь баримтад ихэвчлэн эх бүс гэж заагддаг.

- `org.` бол эх бүсийн доорх Top Level Domain буюу Дээд Түвшний Домэйн (TLD).

- `example.org.` бол `org.` TLD-н доорх бүс.

- `1.168.192.in-addr.arpa` бол `192.168.1.*` IP хаягийн хүрээнд багтаж байгаа бүх IP хаягуудыг агуулсан бүс.

Хост нэр зүүн тал руугаа явах тусам илүү тодорхой болж байгааг та бүхэн анзаарсан байх. Жишээлбэл, `example.org.` нь `org.`-с илүү тодорхой, харин `org.` нь эх бүсээс илүү тодорхой байна. Хост нэрийн зохион байгуулалт нь файл системийнхтэй төстэй: `/dev` директор нь эх директорт харъяалагдана, гэх мэт.

### 30.6.3. Нэрийн Сервер ажиллуулах Шалтгаанууд

Нэрийн Серверүүд ерөнхийдөө хоёр янз байна: authoritative буюу бүрэн эрхт нэрийн сервер, ба caching буюу түр тогтоогч нэрийн сервер.

Бүрэн эрхт нэрийн сервер нь дараах тохиолдлуудад хэрэгтэй:

- DNS мэдээллийг өөртөө агуулж, энэ мэдээллийг нийтэд зарлан, ирсэн асуулгуудад бүрэн эрхтэйгээр хариулах хүсэлтэй үед.

- Бүртгэлтэй домэйны хувьд, жишээлбэл `example.org`, түүний дор орших хост нэрүүдэд IP хаяг оноож өгөх хэрэгтэй үед.

- Бүлэг IP хаягуудад урвуу DNS мэдээлэл хэрэгтэй үед (IP-с хост нэр рүү).

- Нөөц эсвэл хоёрдогч нэрийн сервер, зарц гэж нэрлэнэ, асуулгуудад хариулуулах шаардлагатай үед.

Түр тогтоогч нэрийн сервер дараах тохиолдлуудад хэрэгтэй:

- Дотоод DNS сервер нь асуулгын хариуг түр тогтоосноор гадаад нэрийн серверээс илүү хурдан хариу өгч байгаа үед.

`www.FreeBSD.org`-р асуулга явуулсан үед, тайлагч ихэвчлэн үйлчилгээ авдаг ISP-нхаа нэрийн серверээс асуугаад хариуг олж авна. Дотоод, түр тогтоогч DNS сервер ажиллуулснаар, асуулгыг гадаад интернэтээс зөвхөн ганц удаа явуулах бөгөөд, хариуг тогтоож авна. Нэмэлт асуулгуудад түр тогтоогч нэрийн сервер хариулах ба гадагшаа дахин асуулга явуулах шаардлага байхгүй.

### 30.6.4. Хэрхэн ажилладаг вэ?

FreeBSD-д BIND дэмонг named гэж нэрлэнэ.

Файл | Тайлбар
--- | ---
named(8) | BIND дэмон.
rndc(8) | Нэрийн серверийг хянах хэрэгсэл.
`/etc/namedb` | BIND-н бүсийн мэдээлэл хадгалагдаж байгаа сан.
`/etc/namedb/named.conf` | дэмоны тохиргооны файл.

Тухайн бүс сервер дээр хэрхэн тохируулагдсанаас хамаарч энэ бүстэй хамааралтай файлууд `/etc/namedb` директорын `master`, `slave`, эсвэл `dynamic` гэсэн дэд сангуудад байрлана. Эдгээр файлуудад гадны асуулгад хариу болгон өгөх DNS мэдээллүүд байрлана.

### 30.6.5. BIND-г ажиллуулах нь

BIND нь анхдагч байдлаар суучихсан ирдэг тул тохируулахад хялбар байдаг.

named-н анхдагч тохиргоо нь chroot(8) орчинд ажиллах, тайлагч нэрийн сервер байдлаар хийгдсэн байдаг бөгөөд локал IPv4 loopback хаяг (127.0.0.1) дээр ажиллахаар хязгаарлагдсан байдаг. Энэ тохиргоогоор серверийг ажиллуулахын тулд дараах тушаалыг өгөх хэрэгтэй:

`#` `service named onestart`

named дэмонг систем ачаалах үед ажиллуулдаг болгохын тулд `/etc/rc.conf` дотор дараах мөрүүдийг нэмэх хэрэгтэй:

named_enable="YES"

Мэдээж `/etc/namedb/named.conf` файл дотор өөр олон тохируулгууд байгаа боловч энэ баримтын мэдлээс халих тул энд дурдсангүй. Хэрэв FreeBSD дээрх named-н эхлэл тохируулгуудын талаар сонирхож байгаа бол `/etc/defaults/rc.conf` дотор байгаа `named_`*`` тугуудыг нэг ороод үзээрэй. Мөн rc.conf(5) заавар хуудаснаас тусламж авч болно. Хэсэг 12.7, «FreeBSD дээр rc(8) ашиглах нь» хэсгийг уншихад илүүдэхгүй.

### 30.6.6. Тохиргооны файлууд

named-н тохиргооны файлууд нь `/etc/namedb` директор дотор байрлах ба хэрэв хялбар тайлагчаас өөр түвшинд ажиллах хэрэгтэй бол ажиллуулахаасаа өмнө тохиргооны файлд засвар хийх хэрэгтэй. Ихэнх тохиргоог энэ сан дотор гүйцэтгэнэ.

#### 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`-г идэвхжүүлж болох юм. Энгийн үед, нэрийн сервер нь хариултыг олтлоо давталттай байдлаар хэд хэдэн нэрийн серверүүдээр дамжин асууна. Энэ тохируулгыг идэвхжүүлснээр, дээд гарцынхаа нэрийн серверээс (эсвэл зааж өгсөн нэрийн сервер) хамгийн түрүүнд асууж, энэ серверийн түр санах ойд байгаа мэдээллээс хүртэхийг эрмэлзэнэ. Хэрэв дээд гарцын нэрийн сервер нь олон асуулгад хариулдаг, хурдан үйлчилдэг сервер байвал дээрх тохируулгыг идэвхжүүлсний үр ашиг гарна.

### Сануулга:

`127.0.0.1` энд ажиллахгүй. Энэ IP хаягийг өөрийн дээд гарцын нэрийн серверээр сольж бичнэ үү.

/* 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 бичлэгүүд:

SOA

  start of zone authority буюу бүсийн бүрэн эрхт мэдээллийн эхлэл

NS

  бүрэн эрхт нэрийн сервер

A

  хостын хаяг

CNAME

  хуурамч дүрд өгөх хүлээн зөвшөөрөгдсөн нэр

MX

  захидал солилцогч

PTR

  домэйн нэрийг заагч (урвуу 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

`example.org.`

  домэйн нэр, мөн энэ бүсийн файлын хувьд үүсэл болно.

`ns1.example.org.`

  энэ бүсийн гол/бүрэн эрхт нэрийн сервер.

`admin.example.org.`

  энэ бүсийг хариуцагч хүн, «@» тэмдэгтийг нь орлуулсан цахим захидлын хаяг. (`<admin@example.org>` нь `admin.example.org` болно)

`2006051501`

  Файлын сериал дугаар. Бүсийн файлд өөрчлөлт оруулах болгонд энэ дугаарыг нэмэгдүүлэх шаардлагатай. Одоо цагт ихэнх админууд энэ сериал дугаарыг `yyyymmddrr` хэлбэрээр хэрэглэх болсон. `2006051501` гэдэг нь хамгийн сүүлд 05/15/2006-нд засвар хийсэн, хамгийн сүүлийн `01` гэдэг нь энэ өдөр хийгдсэн хамгийн анхны засвар гэдгийг илтгэнэ. Энэ сериал дугаар нь зарц серверүүдэд бүсийн мэдээлэл өөрчлөгдсөн талаар мэдээлэл өгдөг тул их чухал зүйл байгаа юм.

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.7. Түр тогтоогч Нэрийн Сервер (Caching Name Server)

Түр тогтоогч нэрийн сервер гэдэг нь рекурсив хүсэлтэд хариу өгөх гол үүрэгтэй нэрийн серверийг хэлнэ. Ийм төрлийн сервер нь зөвхөн асуулга явуулах бөгөөд хариултыг дараа хэрэглэхээр тогтоож авдаг.

### 30.6.8. DNSSEC

Домэйн Нэрийн Системийн Аюулгүй байдлын Өргөтгөлүүд, товчоор DNSSEC, бол нэр тайлагч серверүүдийг залилуулсан DNS бичлэг гэх мэт хуурамч DNS өгөгдлөөс хамгаалах заавруудын иж бүрдэл юм. Электрон гарын үсгийн тусламжтай нэр тайлагч нь бичлэгийн бүрэн бүтэн байдлыг магадлах боломжтой. DNSSEC нь зөвхөн Боломжит Бичлэгүүд дээр (RRs) электрон гарын үсэг зурах замаар өгөгдлийн бүрэн бүтэн байдлыг хангадаг болохыг тэмдэглэн хэлье. Нууцлалыг хангаж, эцсийн хэрэглэгчийн буруу үйлдлээс хамгаалж чадахгүй. Өөрөөр хэлбэл хүмүүсийг `example.com`-н оронд `example.net`-руу орохыг болиулж чадахгүй гэсэн үг юм. DNSSEC-н хийж чадах ганц зүйл бол өгөгдөл замдаа хувиралгүйгээр очсоныг магадлан тогтоох юм. DNS-н аюулгүй байдал бол Интернэтийн аюулгүй байдлыг хангахад чухал алхам болдог. DNSSEC хэрхэн ажилладаг талаар дэлгэрэнгүй мэдээллийг тухайн RFC-үүдээс аваарай. Хэсэг 30.6.10, «Гүнзгийрүүлэн унших»-д байгаа жагсаалтыг үзнэ үү.

Дараах бүлгүүдэд BIND 9 ажиллаж байгаа бүрэн эрхт DNS сервер болон рекурсив (эсвэл түр тогтоогч) DNS сервер дээр DNSSEC-г хэрхэн идэвхжүүлэхийг үзүүлэх болно. BIND 9-н бүх хувилбарууд DNSSEC-г дэмжих боловч, DNS асуулгуудын хүчинтэй эсэхийг шалгахад гарын үсэгтэй эх бүсийг ашиглахын тулд хамгийн багадаа 9.6.2 хувилбарыг суулгах шаардлагатай. Яагаад гэвэл өмнөх хувилбаруудад эх (root) бүсийн түлхүүрийг ашиглах шалгалтыг идэвхжүүлэхэд шаардлагатай алгоритмууд байдаггүй. Эх түлхүүрт зориулж автоматаар түлхүүрийг шинэчлэх боломж болон автоматаар бүсүүдийг гарын үсгээр баталгаажуулж гарын үсгүүдийг байнга шинэ байлгахын тулд BIND-ийн хамгийн сүүлийн хувилбар 9.7 юм уу эсвэл түүний дараагийн хувилбарыг ашиглахыг шаарддаг. 9.6.2 болон 9.7 болон түүнээс хойшхи хувилбаруудын хооронд тохиргооны зөрүү байвал харуулах болно.

#### 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, «Бүрэн эрхт DNS серверийн тохиргоо» хэсэгт дэлгэрэнгүй байгаа.

Одоо түлхүүрийг шалгаж 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, «Бүрэн эрхт DNS серверийн тохиргоо»-д тайлбарласны дагуу бүсийн хувьд түлхүүрүүдийг үүсгэж өгнө. Ингэхийн тулд тэр түлхүүрүүдийг түлхүүр байрлах санд хийж бүсийн тохиргооны `key-directory` гэдэгт уг санг өгөх бөгөөд ингэснээр бүс автоматаар баталгаажуулагдах болно. Ийм замаар тохируулсан бүсэд хийх шинэчлэлтийг nsupdate ашиглан хийх ёстой бөгөөд энэ нь бүсэд шинэ өгөгдөл нэмэн дахин баталгаажуулах ажлыг хийдэг байна. Илүү дэлгэрэнгүйг Хэсэг 30.6.10, «Гүнзгийрүүлэн унших» болон BIND-н баримтаас үзнэ үү.

### 30.6.9. Аюулгүй байдал

Хэдийгээр BIND нь хамгийн өргөн хэрэглэгддэг DNS сервер боловч, аюулгүй байдалтай холбоотой асуудлууд байнга тулгардаг. Гадны халдлагад өртөж болзошгүй аюулгүй байдлын цоорхой заримдаа олддог.

Хэдийгээр FreeBSD named-г автоматаар chroot(8) орчинд оруулдаг боловч; DNS халдлагад ашиглаж болохуйц хэд хэдэн механизмууд байсаар байна.

CERT-с гаргадаг аюулгүй байдлын санамжуудыг уншихыг зөвлөж байна. Мөн FreeBSD аюулгүй байдлын мэдэгдлүүд захидлын жагсаалт-д бүртгүүлж, шинээр гарч байгаа Интернэт болон FreeBSD-н аюулгүй байдлын асуудлуудын талаар мэдээлэлтэй байхыг зөвлөе.

### Зөвлөгөө:

Хэрэв ямар нэгэн асуудал тулгарвал эхийг байнга шинэчилж, named-г шинээр бүтээх нь тусалж болох юм.

### 30.6.10. Гүнзгийрүүлэн унших

BIND/named заавар хуудсууд: rndc(8) named(8) named.conf(5)nsupdate(1) dnssec-signzone(8) dnssec-keygen(8)

- ISC BIND-н Албан ёсны Хуудас

- ISC BIND-н Албан ёсны Хэлэлцүүлэг

- Root DNSSEC

- O'Reilly "DNS ба BIND" 5 дахь Хэвлэлт

- DNSSECЭх бүсэд зориулсан итгэмжит анкор зарлалт (Trust Anchor Publication for the Root Zone)

- RFC1034 - Домэйн Нэрүүд - Зарчмууд болон Боломжууд

- RFC1035 - Домэйн Нэрүүд - Хэрэгжүүлэлт болон Үзүүлэлтүүд

- RFC4033 - DNS-н аюулгүй байдлын танилцуулга ба шаардлагууд

- RFC4034 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан Resource Records буюу Нөөцийн Бичлэгүүд

- RFC4035 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан протоколын өөрчлөлтүүд

- RFC4641 - DNSSEC ажиллуулах практикууд

- RFC 5011 - DNS-н аюулгүй байдлын автомат шинэчлэлтүүд (DNSSEC Trust Anchors

Өмнөх | Дээш | Дараах
30.5. Автомат Сүлжээний Тохиргоо (DHCP) | Эхлэл | 30.7. Apache HTTP Сервер

Энэ болон бусад баримтуудыг ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ хаягаас татаж авч болно.

FreeBSD-ийн талаар <questions@FreeBSD.org> хаягтай холбоо барихаасаа өмнө баримтыг уншина уу.
Энэ бичиг баримттай холбоотой асуулт байвал <doc@FreeBSD.org> хаягаар цахим захидал явуулна уу.
Энэ бичиг баримтын орчуулгатай холбоотой асуулт байвал <admin@mnbsd.org> хаягаар цахим захидал явуулна уу.