Основен главен DNS за LAN на Debian 6.0 (V) и окончателен

Тези, които следват 1-ви, 2da, 3-ви y 4ta част от тази статия и консултациите, направени до тяхната BIND, върнаха задоволителни резултати, те вече са експерти по въпроса. :-) И без повече шум нека да влезем в последната част:

• Създаване на файл „Основна основна зона“ тип „Inverse“ 10.168.192.in-addr.arpa
• отстраняване на неизправности
• Обобщение

Създаване на файл „Основна основна зона“ тип „Inverse“ 10.168.192.in-addr.arpa

Името на района ги носи на вас, нали? И това е, че обратните зони са задължителни, за да имат правилна резолюция на имената според Интернет стандартите. Нямаме друг избор, освен да създадем този, съответстващ на нашия домейн. За това използваме като шаблон файла /etc/bind/db.127:

cp /etc/bind/db.127 /var/cache/bind/192.168.10.rev

Редактираме файла /var/cache/bind/192.168.10.rev и го оставяме така:

; /var/cache/bind/192.168.10.rev; ; Файл с обратни данни BIND за основната зона 10.168.192.in-addr.arpa; Файлове с данни BIND за Master Zone (Reverse) 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800); Отрицателен кеш TTL; @ IN NS ns. 10 В PTR ns.amigos.cu. 1 В PTR gandalf.amigos.cu. 9 В PTR mail.amigos.cu. 20 В PTR web.amigos.cu. 100 В PTR fedex.amigos.cu. ; можем да напишем и пълния IP адрес. Пример :; 192.168.10.1 В PTR gandalf.amigos.cu.

• Наблюдавайте как в този случай оставяме времената в секунди, тъй като се създават по подразбиране, когато свързване9. Той работи по същия начин. Те са същите времена като посочените във файла приятели.cu.host. Когато се съмнявате, проверете.
• Също така имайте предвид, че декларираме само обратните записи на хостовете, които имат присвоен или „реален“ IP в нашата локална мрежа и това го идентифицира уникално.
• Не забравяйте да актуализирате файла Reverse Zone с ВСИЧКИ правилни IP адреси, декларирани в Direct Zone.
• Не забравяйте да увеличите Зонален сериен номер всеки път, когато те модифицират файла и преди да рестартират BIND.

Нека проверим новосъздадената зона:

named-checkzone 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev

Проверяваме конфигурацията:

named-checkconf -z named-checkconf -p

Ако всичко е наред, рестартираме услугата:

рестартиране на услугата bind9

Отсега нататък всеки път, когато модифицираме зоновите файлове, просто трябва да изпълним:

rndc презареждане

За това декларираме ключа в /etc/bind/named.conf.options, не?

отстраняване на неизправности

Много важно е правилното съдържание на файла / И т.н. / resolv.conf както видяхме в предишната глава. Не забравяйте да посочите в него поне следното:

търсене amigos.cu сървър за имена 192.168.10.20

команда копаят от пакета dnsutils. На конзола въведете командите, предшествани от #:

# dig -x 127.0.0.1 ..... ;; ОТГОВОР СЕКЦИЯ: 1.0.0.127.in-addr.arpa. 604800 В PTR локален хост. .... # dig -x 192.168.10.9 .... ;; СЕКЦИЯ ОТГОВОР: 9.10.168.192.in-addr.arpa. 604800 В PTR mail.amigos.cu. .... # хост gandalf gandalf.amigos.cu има адрес 192.168.10.1 # хост gandalf.amigos.cu gandalf.amigos.cu има адрес 192.168.10.1 # dig gandalf; << >> DiG 9.7.2-P3 << >> gandalf ;; глобални опции: + cmd ;; връзката изтече; няма достъп до сървъри # dig gandalf.amigos.cu .... ;; СЕКЦИЯ ОТГОВОР: gandalf.amigos.cu. 604800 В 192.168.10.1 .... Ако имат достъп до кубинския или глобалния интернет и препращачите са правилно декларирани, опитайте: # dig debian.org .... ;; ВЪПРОСЕН РАЗДЕЛ :; debian.org. В ;; ОТГОВОР СЕКЦИЯ: debian.org. 3600 В 86.59.118.148 debian.org. 3600 В 128.31.0.51 .... # хост bohemia.cu bohemia.cu има адрес 190.6.81.130 # хост yahoo.es yahoo.es има адрес 77.238.178.122 yahoo.es има адрес 87.248.120.148 yahoo.es пощата се обработва от 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; СЕКЦИЯ ОТГОВОР: 122.178.238.77.in-addr.arpa. 429 В PTR w2.rc.vip.ird.yahoo.com.

... И като цяло с други домейни извън нашата LAN. Консултирайте се и разберете за интересни неща в интернет.

Един от най-добрите начини за проверка на производителността на сървър свързване9, и като цяло за всяка друга инсталирана услуга, е четене на изхода на Съобщения в системния дневник с помощта на командата опашката -f / var / log / syslog стартирайте като потребителкорен.

Много е интересно да видим резултата от тази команда, когато зададем на нашия локален BIND въпрос за външен домейн или хост. В този случай могат да бъдат представени няколко сценария:

• Ако нямаме достъп до интернет, заявката ни ще се провали.
• Ако имаме достъп до интернет и НЕ сме декларирали спедитори, най-вероятно няма да получим отговор.
• Ако имаме достъп до интернет и сме декларирали спедиторите, ще получим отговор, тъй като те ще отговарят за консултацията с DNS сървъра или сървърите, които са необходими.

Ако работим по a LAN затворен при които е невъзможно по никакъв начин да отидем в чужбина и нямаме спедитори от какъвто и да е вид, можем да премахнем съобщенията за търсене на Рут сървъри „Изпразване“ на файла /etc/bind/db.root. За целта първо записваме файла с друго име и след това изтриваме цялото му съдържание. След това проверяваме конфигурацията и рестартираме услугата:

cp /etc/bind/db.root /etc/bind/db.root.original cp / dev / null /etc/bind/db.root named-checkconf -z named-checkconf -p service bind9 рестартиране

Обобщение

Засега, хора, малко въведение в DNS услугата. Това, което сме направили до момента, може да ни послужи перфектно за нашия малък бизнес. Също така за къщата, ако създаваме виртуални машини с различни операционни системи и различни IP адреси и не искаме да се позоваваме на тях по IP, а по име. Винаги инсталирам BIND на моя домашен хост, за да инсталирам, конфигурирам и тествам услуги, които зависят силно от DNS услугата. Използвам широко настолни компютри и виртуални сървъри и не обичам да пазя файл / Etc / hosts във всяка от машините. Прекалено много греша.

Ако никога не сте инсталирали и конфигурирали BIND, моля, не се отлагайте, ако нещо се обърка при първия опит и трябва да започнете отначало. Винаги препоръчваме в тези случаи да започнете с чиста инсталация. Струва си да опитате!

За тези, които се нуждаят от висока наличност в услугата за разрешаване на имена, което може да бъде постигнато чрез конфигуриране на вторичен главен сървър, препоръчваме да продължите с нас при следващото приключение: Вторичен главен DNS за LAN.

Поздравления за тези, които проследиха всички статии и получиха очакваните резултати!