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/-н мэдэлд байдаг.
Энэ баримтыг ойлгохын тулд, 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
директор нь
эх директорт харъяалагдана, гэх мэт.
Нэрийн Серверүүд ерөнхийдөө хоёр янз байна: authoritative буюу бүрэн эрхт нэрийн сервер, ба caching буюу түр тогтоогч нэрийн сервер.
Бүрэн эрхт нэрийн сервер нь дараах тохиолдлуудад хэрэгтэй:
DNS мэдээллийг өөртөө агуулж, энэ мэдээллийг нийтэд зарлан, ирсэн асуулгуудад бүрэн эрхтэйгээр хариулах хүсэлтэй үед.
Бүртгэлтэй домэйны хувьд, жишээлбэл example.org
,
түүний дор орших хост нэрүүдэд IP хаяг оноож өгөх хэрэгтэй үед.
Бүлэг IP хаягуудад урвуу DNS мэдээлэл хэрэгтэй үед (IP-с хост нэр рүү).
Нөөц эсвэл хоёрдогч нэрийн сервер, зарц гэж нэрлэнэ, асуулгуудад хариулуулах шаардлагатай үед.
Түр тогтоогч нэрийн сервер дараах тохиолдлуудад хэрэгтэй:
Дотоод DNS сервер нь асуулгын хариуг түр тогтоосноор гадаад нэрийн серверээс илүү хурдан хариу өгч байгаа үед.
www.FreeBSD.org
-р асуулга явуулсан үед, тайлагч ихэвчлэн
үйлчилгээ авдаг ISP-нхаа нэрийн серверээс асуугаад хариуг олж авна.
Дотоод, түр тогтоогч DNS сервер ажиллуулснаар,
асуулгыг гадаад интернэтээс зөвхөн ганц удаа явуулах бөгөөд,
хариуг тогтоож авна. Нэмэлт асуулгуудад түр тогтоогч нэрийн сервер
хариулах ба гадагшаа дахин асуулга явуулах шаардлага байхгүй.
FreeBSD-д BIND дэмонг named гэж нэрлэнэ.
Файл | Тайлбар |
---|---|
named(8) | BIND дэмон. |
rndc(8) | Нэрийн серверийг хянах хэрэгсэл. |
/etc/namedb | BIND-н бүсийн мэдээлэл хадгалагдаж байгаа сан. |
/etc/namedb/named.conf | дэмоны тохиргооны файл. |
Тухайн бүс сервер дээр хэрхэн тохируулагдсанаас хамаарч
энэ бүстэй хамааралтай файлууд /etc/namedb
директорын master
,
slave
, эсвэл dynamic
гэсэн дэд сангуудад байрлана. Эдгээр файлуудад
гадны асуулгад хариу болгон өгөх DNS мэдээллүүд
байрлана.
BIND нь анхдагч байдлаар суучихсан ирдэг тул тохируулахад хялбар байдаг.
named-н анхдагч тохиргоо нь chroot(8) орчинд ажиллах, тайлагч нэрийн сервер байдлаар хийгдсэн байдаг бөгөөд локал IPv4 loopback хаяг (127.0.0.1) дээр ажиллахаар хязгаарлагдсан байдаг. Энэ тохиргоогоор серверийг ажиллуулахын тулд дараах тушаалыг өгөх хэрэгтэй:
#
service named onestart
named дэмонг систем ачаалах үед
ажиллуулдаг болгохын тулд /etc/rc.conf
дотор дараах мөрүүдийг нэмэх
хэрэгтэй:
Мэдээж /etc/namedb/named.conf
файл дотор
өөр олон тохируулгууд байгаа боловч энэ баримтын мэдлээс халих
тул энд дурдсангүй. Хэрэв FreeBSD дээрх named-н эхлэл
тохируулгуудын талаар сонирхож байгаа бол /etc/defaults/rc.conf
дотор байгаа named_
тугуудыг нэг ороод үзээрэй.
Мөн rc.conf(5) заавар хуудаснаас тусламж авч болно. Хэсэг 12.7, «FreeBSD дээр rc(8) ашиглах нь»
хэсгийг уншихад илүүдэхгүй.*
named-н тохиргооны файлууд нь
/etc/namedb
директор дотор байрлах ба
хэрэв хялбар тайлагчаас өөр түвшинд ажиллах хэрэгтэй бол
ажиллуулахаасаа өмнө тохиргооны файлд засвар хийх хэрэгтэй.
Ихэнх тохиргоог энэ сан дотор гүйцэтгэнэ.
Тайлбар дээр хэлсэнчлэн
дээд гарцын түр тогтоогчоос хүртэхийн тулд
forwarders
-г идэвхжүүлж болох юм.
Энгийн үед, нэрийн сервер нь хариултыг олтлоо давталттай байдлаар
хэд хэдэн нэрийн серверүүдээр дамжин асууна.
Энэ тохируулгыг идэвхжүүлснээр, дээд гарцынхаа нэрийн серверээс
(эсвэл зааж өгсөн нэрийн сервер) хамгийн түрүүнд асууж, энэ серверийн
түр санах ойд байгаа мэдээллээс хүртэхийг эрмэлзэнэ.
Хэрэв дээд гарцын нэрийн сервер нь олон асуулгад хариулдаг, хурдан үйлчилдэг
сервер байвал дээрх тохируулгыг идэвхжүүлсний үр ашиг гарна.
127.0.0.1
энд ажиллахгүй. Энэ
IP хаягийг өөрийн дээд гарцын нэрийн серверээр сольж бичнэ үү.
named.conf
доторх эдгээр жишээнүүд нь
ердийн болон урвуу бүсийн зарц бүртгэлүүд болно.
Шинэ бүс нэмэхдээ, named.conf
файл дотор шинэ бүртгэл
оруулах хэрэгтэй.
Жишээ нь, example.org
домэйны хувьд
хамгийн хялбар бүртгэл дараах байдалтай байна:
Энэ бүс нь эзэн бүс болохыг type
илэрхийллээс харж болно.
Мөн бүсийн мэдээллийг /etc/namedb/master/example.org
файл дотор агуулж байгааг
file
илэрхийллээс харж болно.
Зарц бүсийн хувьд, тухайн бүсийн хувьд бүсийн мэдээлэл эзэн нэрийн серверээс зөөгдөж ирэх ба зааж өгсөн файлд хадгалагдана. Эзэн сервер унтарсан эсвэл холбоо тогтоох боломжгүй болбол, зарц нэрийн серверт бүсийн мэдээлэл байгаа тул асуулгуудад хариулах чадвартай байна.
example.org
домэйны хувьд жишээ эзэн бүсийн файлыг
дор үзүүлэв (/etc/namedb/master/example.org
файл):
«.» тэмдэгтээр төгссөн хост нэрүүд нь жинхэнэ хост нэрүүд бөгөөд
«.» тэмдэгтээр төгсөөгүй нэрүүдэд үүсэл залгагдахыг анхаарна уу.
Жишээлбэл, ns1
нь ns1.
-руу
хөрвүүлэгдэх болно.example.org.
Бүсийн файл дараах хэлбэртэй байна:
Хамгийн өргөн хэрэглэгддэг DNS бичлэгүүд:
start of zone authority буюу бүсийн бүрэн эрхт мэдээллийн эхлэл
бүрэн эрхт нэрийн сервер
хостын хаяг
хуурамч дүрд өгөх хүлээн зөвшөөрөгдсөн нэр
захидал солилцогч
домэйн нэрийг заагч (урвуу DNS-д хэрэглэнэ)
example.org.
домэйн нэр, мөн энэ бүсийн файлын хувьд үүсэл болно.
ns1.example.org.
энэ бүсийн гол/бүрэн эрхт нэрийн сервер.
admin.example.org.
энэ бүсийг хариуцагч хүн, «@» тэмдэгтийг нь
орлуулсан цахим захидлын хаяг.
(<admin@example.org>
нь admin.example.org
болно)
2006051501
Файлын сериал дугаар. Бүсийн файлд өөрчлөлт оруулах болгонд
энэ дугаарыг нэмэгдүүлэх шаардлагатай. Одоо цагт ихэнх админууд энэ сериал дугаарыг
yyyymmddrr
хэлбэрээр хэрэглэх болсон. 2006051501
гэдэг нь
хамгийн сүүлд 05/15/2006-нд засвар хийсэн, хамгийн сүүлийн 01
гэдэг нь
энэ өдөр хийгдсэн хамгийн анхны засвар гэдгийг илтгэнэ. Энэ сериал дугаар
нь зарц серверүүдэд бүсийн мэдээлэл өөрчлөгдсөн талаар мэдээлэл өгдөг тул их чухал зүйл
байгаа юм.
Энэ бол NS бичлэг. Тухайн бүсийн хувьд бүрэн эрхт хариултыг өгч чадах сервер бүрийн хувьд энэ бичлэг байх ёстой.
A бичлэг нь машины нэрийг заана. Дээр үзүүлсэнчлэн,
ns1.example.org
нь 192.168.1.2
-руу буулгагдана.
Энэ мөр нь 192.168.1.1
гэсэн IP хаягийг
үүсэлд оноож байна, бидний жишээн дээр example.org
.
Хүлээн зөвшөөрөгдсөн нэрийн бичлэг нь машинд хуурамч дүр
өгөхөд хэрэглэгдэнэ. Энэ жишээн дээр, www
нь
example.org
(192.168.1.1
) гэсэн домэйн нэртэй
«master» машины хуурамч дүрийн нэр юм. CNAME-г тухайн хостын нэрийн хувьд
өөр төрлийн бичлэгтэй хэзээ ч цуг хэрэглэж болохгүй.
MX бичлэг нь аль захидлын серверүүд тухайн бүсийн захидлыг
хүлээж авах үүрэгтэй болохыг зааж өгнө. mail.example.org
нь захидлын серверийн хост нэр бөгөөд 10 нь энэ захидлын серверийн
зэрэглэлийг зааж байна.
Нэг бүсэд 10, 20 гэх мэт ялгаатай зэрэглэлтэй
хэд хэдэн захидлын сервер байж болно. example.org
домэйн руу захидал явуулах гэж байгаа сервер эхлээд
хамгийн өндөр зэрэглэлтэй MX сервертэй (хамгийн бага зэрэглэлийн дугаартай), дараа нь дараагийн хамгийн өндөр зэрэглэлтэй
сервертэй гэх мэтчилэн захидлыг явуулж чадтал дарааллаар нь холбоо тогтооно.
in-addr.arpa бүсийн файл (урвуу DNS) нь ижил хэлбэртэй байна. Ганцхан ялгаа нь A болон CNAME бичлэгийн оронд PTR бичлэгийг хэрэглэнэ.
Энэ файлд дээрх домэйны IP-с хост нэр рүү буулгасан зохих шаардлагатай буулгалтуудыг үзүүлсэн байна.
PTR бичлэгийн баруун талын бүх нэрс төгссөн байх ёстой (өөрөөр хэлбэл «.»-ээр төгссөн байна).
Түр тогтоогч нэрийн сервер гэдэг нь рекурсив хүсэлтэд хариу өгөх гол үүрэгтэй нэрийн серверийг хэлнэ. Ийм төрлийн сервер нь зөвхөн асуулга явуулах бөгөөд хариултыг дараа хэрэглэхээр тогтоож авдаг.
Домэйн Нэрийн Системийн Аюулгүй байдлын Өргөтгөлүүд, товчоор 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 болон түүнээс хойшхи хувилбаруудын хооронд тохиргооны зөрүү байвал харуулах болно.
Рекурсив DNS серверийн гүйцэтгэсэн хүсэлтүүдийн
DNSSEC шалгалтыг идэвхжүүлэхийн тулд
named.conf
файлд цөөн өөрчлөлтийг хийх хэрэгтэй.
Эдгээр өөрчлөлтүүдийг хийхээс өмнө эх бүсийн түлхүүр эсвэл итгэлцлийн
анкорыг (anchor) авсан байх шаардлагатай. Одоогоор эх бүсийн түлхүүр нь
BIND ойлгох файлын форматаар байдаггүй бөгөөд
зөв хэлбэр рүү гараар хувиргах ёстой байдаг. Түлхүүрийг
dig ашиглан эх бүсээс асууж авч болдог.
Ингэхийн тулд
%
dig +multi +noall +answer DNSKEY . > root.dnskey
гэж ажиллуулна. Түлхүүр root.dnskey
файлд байх болно.
Доторх нь иймэрхүү байдалтай харагдана:
Олж авсан түлхүүрүүд энэ жишээн дээрхээс өөр байвал сандрах хэрэггүй. Тэдгээр нь энэ зааврыг бичсэнээс хойш өөрчлөгдсөн байж болох юм. Энэ гаралт нь хоёр түлхүүрийг агуулдаг. 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-г ашигладаг.
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-ийн хувьд формат доорхтой адил
хэлбэрийн байна:
For 9.7 the format will instead be:
Эх түлхүүрийг named.conf
файл
руу шууд эсвэл түлхүүр бүхий файлыг оруулан нэмж өгч болно.
Эдгээр алхмуудын дараа BIND-г хүсэлтүүд
дээр DNSSEC шалгалтыг хийдэг болгохын тулд
named.conf
файлыг засварлан
дараах мөрийг options
хэсэгт нэмж
тохиргоог хийнэ:
Ажиллаж байгааг шалгахын тулд дөнгөж тохируулсан тайлагчийг
ашиглан гарын үсгээр баталгаажсан бүсийг асуусан хүсэлтийг
dig ашиглан явуулна. Амжилттай
хариулт AD
тэмдэглэгээтэй байх бөгөөд
энэ нь өгөгдлийг таньж зөвшөөрсөн гэсэн үг юм. Доорх
хүсэлттэй адил хүсэлтийг ажиллуулбал
%
dig @resolver
+dnssec se ds
.se
бүсийн хувьд DS RR-г
буцаах ёстой. flags:
хэсэг дээр
AD
флаг тохируулагдсан байх ёстой бөгөөд доорх
байдлаар харагдана:
Тайлагч одоо 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
ашиглан
бүсийн файлд оруулж болно. Иймэрхүү байдалтай харагдана:
Төгсгөлд нь бүсийг баталгаажуулж 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 хаягаас үзнэ үү.
BIND 9.7 хувилбараас эхлээд
Smart Signing буюу ухаалгаар баталгаажуулах
боломж шинээр нэмэгдсэн. Энэ боломж нь түлхүүрийг удирдах болон
баталгаажуулах процессын зарим хэсгийг автоматжуулснаар хялбар
болгохыг зорьдог. key repository
санд түлхүүрүүдийг байршуулж auto-dnssec
гэсэн
шинэ тохиргоог ашиглан шаардлагатай тохиолдолд дахин баталгаажуулагддаг
динамик бүсийг үүсгэх боломжтой байдаг. Энэ бүсийг шинэчлэхийн
тулд nsupdate-г шинэ -l
аргументтай хэрэглэнэ. rndc бас
түлхүүр байрлах сан дахь түлхүүрүүдээр бүсүүдийг sign
гэсэн
тохиргоо ашиглан баталгаажуулах боломжтой болсон. example.com
-н хувьд энэ автоматаар хийх баталгаажуулалт
болон бүсийг шинэчлэх боломжийг BIND-д зааж өгөхийн тулд
дараахийг named.conf
файлд нэмж өгөх хэрэгтэй:
Эдгээр өөрчлөлтүүдийг хийсний дараа Хэсэг 30.6.8.2, «Бүрэн эрхт DNS серверийн тохиргоо»-д
тайлбарласны дагуу бүсийн хувьд түлхүүрүүдийг үүсгэж өгнө. Ингэхийн
тулд тэр түлхүүрүүдийг түлхүүр байрлах санд хийж бүсийн
тохиргооны key-directory
гэдэгт уг санг өгөх
бөгөөд ингэснээр бүс автоматаар баталгаажуулагдах болно. Ийм замаар
тохируулсан бүсэд хийх шинэчлэлтийг nsupdate
ашиглан хийх ёстой бөгөөд энэ нь бүсэд шинэ өгөгдөл нэмэн дахин
баталгаажуулах ажлыг хийдэг байна. Илүү дэлгэрэнгүйг Хэсэг 30.6.10, «Гүнзгийрүүлэн унших»
болон BIND-н баримтаас үзнэ үү.
Хэдийгээр BIND нь хамгийн өргөн хэрэглэгддэг DNS сервер боловч, аюулгүй байдалтай холбоотой асуудлууд байнга тулгардаг. Гадны халдлагад өртөж болзошгүй аюулгүй байдлын цоорхой заримдаа олддог.
Хэдийгээр FreeBSD named-г автоматаар chroot(8) орчинд оруулдаг боловч; DNS халдлагад ашиглаж болохуйц хэд хэдэн механизмууд байсаар байна.
CERT-с гаргадаг аюулгүй байдлын санамжуудыг уншихыг зөвлөж байна. Мөн FreeBSD аюулгүй байдлын мэдэгдлүүд захидлын жагсаалт-д бүртгүүлж, шинээр гарч байгаа Интернэт болон FreeBSD-н аюулгүй байдлын асуудлуудын талаар мэдээлэлтэй байхыг зөвлөе.
Хэрэв ямар нэгэн асуудал тулгарвал эхийг байнга шинэчилж, named-г шинээр бүтээх нь тусалж болох юм.
BIND/named заавар хуудсууд: rndc(8) named(8) named.conf(5)nsupdate(1) dnssec-signzone(8) dnssec-keygen(8)
DNSSECЭх бүсэд зориулсан итгэмжит анкор зарлалт (Trust Anchor Publication for the Root Zone)
RFC4034 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан Resource Records буюу Нөөцийн Бичлэгүүд
RFC4035 - DNS-н аюулгүй байдлын өргөтгөлүүдэд зориулсан протоколын өөрчлөлтүүд
RFC 5011 - DNS-н аюулгүй байдлын автомат шинэчлэлтүүд (DNSSEC Trust Anchors
Энэ болон бусад баримтуудыг ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ хаягаас татаж авч болно.
FreeBSD-ийн талаар
<questions@FreeBSD.org>
хаягтай холбоо барихаасаа өмнө
баримтыг уншина уу.
Энэ бичиг баримттай холбоотой асуулт байвал
<doc@FreeBSD.org>
хаягаар цахим захидал явуулна уу.
Энэ бичиг баримтын орчуулгатай холбоотой асуулт байвал
<admin@mnbsd.org>
хаягаар цахим захидал явуулна уу.