Ние създаваме наш собствен локален DNS (PDNSD), с блекджек и по-бърз от Google Public DNS. Конфигуриране на кеширащ DNS сървър (BIND) за локална мрежа Пълни или частични трансфери на данни от DNS зона

03.05.2023

Всяка година скоростта на интернет - както последната миля, така и основните канали - става все по-висока. Само едно нещо е постоянно - латентността вече е достигнала физически граници: скоростта на светлината в оптичното влакно е около 200 хиляди километра в секунда и съответно, по-бързо от ~150ms, отговор от сървър отвъд Атлантическия океан не може да бъде получен в обозримо бъдеще (въпреки че, разбира се, има изкушения, като оптично влакно с въздушна сърцевина или радиорелейна комуникация, но това едва ли е достъпно за обикновените смъртни).

Когато се опитаме например от Русия да отворим уебсайт, намиращ се в САЩ (нейните NS сървъри вероятно са там), а домейнът не бъде намерен в DNS кеша на вашия доставчик, ще трябва да чакаме дълго дори на гигабитов интернет, може би дори цяла секунда: докато отвъд океана ще получаваме имената на NS сървърите на домейна, докато разрешаваме IP-то им, докато изпращаме и получаваме самата DNS заявка...

Преди няколко години Google пусна своя публичен DNS сървъри, и за да насърчат преминаването към тях, те разработиха помощна програма, наречена NameBench, която изпълнява DNS тестове на вашата история на сърфиране и показва колко по-бърз е Google DNS от DNS сървъра на вашия интернет доставчик.

Но успях да направя свой собствен DNS сървър, който работи по-бързо от Google Public DNS и в тази кратка бележка искам да споделя резултатите.

ПДНСД

pdnsd- кеширане на DNS прокси. В допълнение към баналното кеширане на DNS заявки (с възможност за стриктно задаване на минималния TTL - това може да е необходимо при много слаб интернет), той може да изпрати заявка едновременно до няколко „родителски“ DNS сървъра и да даде на клиента първия върнат отговор.

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

Инсталиран в Ubuntu с помощта на банален apt-get.

Няколко точки в конфигурацията

global ( perm_cache=10240; //Максимален размер на кеша в килобайти. //По подразбиране беше 1024, всичките ми записи не пасват. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // Минимално време за съхраняване на запис в кеша // Дори ако TTL пристигне за по-малко от 60 минути, то ще бъде 60 минути max_ttl=1w; // Максимално време за съхраняване на запис в кеша. Време за кеширане на отрицателни отговори (т.е. ако домейнът не е намерен) [..] par_queries=3; //Брой едновременно заявени „родителски“ DNS сървъри ( label = „main“; ip = 85.21.192.5 // Там са 4 сървъра, ако първите 3 не отговорят, тогава ще бъде изпратена заявка до 4-тия, 213.234.192.7 //Първите 2 сървъра са сървърът на вашия доставчик и някой съседен, 8.8.4.4 //Това е Google Public DNS - те кешират всичко рядко и се разрешават бързо, 8.8.8.8 [.. ] )

По принцип кеширането може да се направи по-малко агресивно (min_ttl=1m например), но в течение на една година работа не са възникнали особени проблеми. В случай на проблеми можете по избор да изтриете един запис от кеша:
sudo pdnsd-ctl запис 3.14.by изтриване или всички наведнъж:
sudo pdnsd-ctl празен кеш

Резултати от тестове в NameBench

Виждаме, че за 50% от заявките получаваме отговор за по-малко от 10ms, за 85% Google Public DNS е по-бърз и след това резултатите естествено съвпадат с Google.

Въз основа на резултатите от теста, NameBench с радост ни съобщава:

8.8.8.8 По-бавна реплика на SYS-192.167.0.98 8.8.4.4 По-бавна реплика на SYS-192.167.0.98

По този начин интелигентно кеширане на DNS прокси с паралелни заявки ви позволява да ускорите дори 100-мегабитов интернет. А за бавни (радио) връзки с висока латентност и загуба на пакети разликата може да е като небето и земята.
Автор: Пол Кобаут
Дата на публикуване: 24 май 2015 г
Превод: А. Панин
Дата на превод: 11 юли 2015 г

Глава 4: Въведение в DNS сървърите

4.3. Кеширане на DNS сървъри

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

Има два вида DNS кеширащи сървъри. Това са DNS сървъри, които използват препращащи DNS сървъри, както и DNS сървъри, които използват главни DNS сървъри.

4.3.1. Кеширащ DNS сървър, който не използва препращач

Кеширащ DNS сървър, който не използва препращач, трябва да получава информация от някъде другаде. Когато се получи заявка от клиент, той се свързва с един от основните сървъри. Главният сървър предава информация за сървъра, обслужващ целевия домейн от първо ниво, към кеширащия сървър, който от своя страна ще го насочи към друг DNS сървър. Последният сървър може или да има информацията, за да отговори на заявката, или може да предаде информация за друг DNS сървър, който може да има тази информация. В крайна сметка нашият DNS сървър ще получи необходимата информация, за да отговори на заявката и да изпрати отговор на клиента.

Илюстрацията по-долу показва процеса на клиент, изпращащ заявка за информация за IP адрес за името на домейна linux-training.be. Нашият сървър за кеширане ще се свърже с основния сървър и ще бъде пренасочен към сървъра, обслужващ домейна от първо ниво .be. След това ще се свърже със сървъра, обслужващ домейна от първо ниво .be, и ще бъде пренасочен към един от сървърите за имена на организацията Openminds. Един от тези сървъри за имена (в този случай nsq.openminds.be) ще отговори на заявката с IP адреса на сървъра с име на домейн linux-training.be. След като нашият сървър за кеширане изпрати тази информацияклиент, клиентът ще може да се свърже с въпросния уебсайт.

Когато използвате снифера tcpdump за разрешаване на дадено име на домейн, можете да получите следния изход (първите 20 знака от всеки ред са премахнати).

192.168.1.103.41251 > M.ROOT-SERVERS.NET.домейн: 37279% A? linux-tr\ aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: 38555% A? linux-обучение.\be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 60888% A? linux-train\ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)

4.3.2. Кеширане на DNS сървър с помощта на препращащ сървър

Кеширащият DNS сървър, който използва препращач, е DNS сървър, който получава цялата необходима информация от пренасочващия. Например DNS сървърът на доставчик на интернет услуги може да действа като пренасочващ DNS сървър.

Илюстрацията по-горе показва DNS сървъра в локална мрежакомпания, която използва предоставен от ISP DNS сървър като пренасочващ DNS сървър. Ако IP адресът на DNS сървъра, предоставен от интернет доставчика, е 212.71.8.10, следните редове трябва да присъстват в конфигурационния файл named.conf на DNS сървъра на компанията:

Спедитори ( 212.71.8.10; );

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

Зона "someotherdomain.local" ( въведете препращане; само препращане; препращащи устройства ( 10.104.42.1; ); );

4.3.3. Итеративна или рекурсивна заявка

Рекурсивната заявка е DNS заявка, след изпращането на която клиентът очаква да получи окончателен отговор от DNS сървъра (на илюстрацията по-горе е изобразен с удебелена червена стрелка, насочена от MacBook към DNS сървъра). Итеративна заявка е DNS заявка, след изпращането на която клиентът не очаква да получи окончателен отговор от DNS сървъра (на горната илюстрация е изобразен с три черни стрелки, насочени от DNS сървъра). Итеративните заявки най-често се извършват между сървъри за имена. Основните сървъри за имена не отговарят на рекурсивни заявки.

DNS сървърът, който управлява DNS зона, се нарича доверен DNS сървър за тази зона. Не забравяйте, че DNS зоната е просто колекция от записи на ресурси.

Първият авторитетен DNS сървър за DNS зона се нарича основен DNS сървър. Този сървър ще работи с копие на базата данни на зоната на DNS, която може да се чете и записва. Ако трябва да увеличите сигурността на данните в случай на повреди, да подобрите производителността на сървъра или балансирането на натоварването, можете да възложите друг DNS сървър, който също ще управлява тази DNS зона. Този сървър ще се нарича вторичен DNS сървър.

Вторичният сървър получава копие на базата данни на DNS зоната от основния сървър по време на процеса на прехвърляне на DNS зона. Заявките за прехвърляне на данни в DNS зона се изпращат от вторични сървъри на определени интервали от време. Продължителността на тези времеви интервали е зададена в рамките на SOA ресурсния запис.

Можете да принудите опресняване на данните за DNS зона с помощта на помощната програма rndc. Примерът по-долу инициира прехвърляне на данни за DNS зоната fred.local и отпечатва съответната част от syslog файла /var/log/syslog.

root@debian7:/etc/bind# rndc опресни fred.local root@debian7:/etc/bind# grep fred /var/log/syslog | опашка -7 | рязане -c38-зона fred.local/IN: изпращане на известия (сериен 1) получена команда за контролен канал "refresh fred.local" зона fred.local/IN: Прехвърлянето е започнало. прехвърляне на "fred.local/IN" от 10.104.109.1#53: свързан чрез 10.104.33.30#57367 зона fred.local/IN: прехвърлен сериен 2 трансфер на "fred.local/IN" от 10.104.109.1#53: Прехвърляне завършено: 1 съобщения, 10 записа, 264 байта, 0,001 секунди (264000 байта/сек) зона fred.local/IN: изпращане на известия (сериен 2) root@debian7:/etc/bind#

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

Най-често основният DNS сървър е главният сървър, който комуникира с всички подчинени сървъри. Понякога подчинен сървър може също да бъде главен сървър за подчинени сървъри на следващото ниво. На илюстрацията по-долу сървърът с име ns1 е основният сървър, а сървърите с име ns2, ns3 и ns4 са вторичните сървъри. Въпреки че главният сървър за сървъри с имена ns2 и ns3 е ns1, главният сървър за ns4 е ns2.

Ресурсният запис на SOA съдържа стойност на скоростта на опресняване на данните за DNS зона, наречена обновяване. Ако тази стойност е зададена на 30 минути, подчиненият сървър ще изпраща заявки за прехвърляне на копие от данните на DNS зоната на всеки 30 минути. Също този записсъдържа стойност за продължителност на изчакване, наречена повторен опит. Тази стойностизползва се, когато главният сървър не отговори на последната заявка за трансфер на данни в DNS зона. Стойност, наречена време на изтичане, задава периода от време, през който подчиненият сървър може да отговори на заявки от клиенти, без да актуализира данните за DNS зоната.

По-долу е даден пример за използване на помощната програма nslookup за четене на данните за SOA ресурсен запис на DNS зона (linux-training.be).

Root@debian6:~# nslookup > задайте тип=SOA > сървър ns1.openminds.be > linux-training.beСървър: ns1.openminds.be Адрес: 195.47.215.14#53 linux-training.be origin = ns1.openminds.be mail addr = hostmaster.openminds.be serial = 2321001133 refresh = 14400 retry = 3600 expire = 604800 minimum = 3600

Прехвърлянето на данни в DNS зона се извършва само когато данните в базите данни на DNS зоната се променят (т.е. когато се добавят, изтриват или модифицират един или повече главни записи на ресурси от страна на сървъра). Подчиненият сървър сравнява номера на версията на собственото си копие на SOA ресурсния запис с номера на версията на SOA ресурсния запис на съответния главен сървър. Ако номерата на версиите съвпадат, не е необходима актуализация на данните (тъй като не са добавени, премахнати или променени други записи на ресурси). В същия случай, ако номерът на версията на SOA ресурсния запис от страната на подчинения сървър е по-малък от номера на версията на същия запис от страната на съответния главен сървър, ще бъде направена заявка за трансфер на данни в DNS зона.

По-долу е моментна снимка на прозореца на снифера на Wireshark с данни, прихванати по време на прехвърлянето на данни в DNS зоната.

4.9. Пълни или частични трансфери на данни от DNS зона

Прехвърлянето на данни за DNS зона може да бъде пълно или частично. Решението за използване на един или друг режим зависи от количеството данни, към които трябва да се прехвърлят пълна актуализация DNS зона база данни на подчинения сървър. Частичното прехвърляне на зонови данни е за предпочитане, когато общото количество променени данни е по-малко от размера на цялата база данни. Пълните трансфери на данни в DNS зона се извършват с помощта на протокола AXFR, а частичните трансфери на данни в DNS зони се извършват с помощта на протокола IXFR.

Добър ден, читатели. Продължава теоретичен материало, в настоящата статия искам да разгледам един практически пример инсталации и настройкиразличен Конфигурации на BIND сървър.В статията ще опиша настройване на DNS кеши пълен DNS главен сървър. Ще започна описанието с общи понятия и необходимите стъпки за организиране на всякакви DNS сървъри.

Главна информация

На имее демон, който е част от пакет bind9и битие сървър за име на домейн. Демон с имеможе да изпълнява функциите на сървъри от всякакъв тип: господар, роб, кеш. В диаграмата по-горе се опитах да покажа основното как работи BIND DNS сървърът. Двоичният файл, който върши по-голямата част от работата, се намира в /usr/sbin/named. Той взема настройки от основния конфигурационен файл, наречен named.confи се намира в указателя /etc/bind. В основната конфигурацияописано работна директория на сървъра, често това е директория /var/cache/bind, в която лъж файлове с описание на зонии други сервизни файлове. Кореспонденция имена на зониИ файл с описание на зонатакомплекти зонова секцияс параметър файл. Зонова секциятой също така задава типа отговорност на този сървър за зоната (главен, подчинен и т.н.) и също така определя специални параметри за текущата зона (например на кой интерфейс да се обработват заявки за текущата зона). Във файловете с описание на зонисъдържа параметри на зона и записи на ресурси (пътищата, посочени в този параграф, може да се различават, зависи от Linux дистрибуцияили параметри).

Това обща схемаработа, която ще ви помогне да избегнете объркване в бъдеще, когато разглеждате конкретни конфигурации.

Форматът на конфигурационния файл за 4-та версия на програмата се различава от този, използван в осмата и деветата версия BIND. Имайки предвид, че разчитам да монтирам нов DNSсървър, но не виждам смисъл да инсталирам старата версия, така че ще погледна конфигурацията на новата версия.

Изходни данни

За да работи правилно DNS, трябва да имате . DNS в настоящата статия ще бъде конфигуриран за дистрибуцията на Debian; характеристиките на други дистрибуции също ще бъдат отбелязани. Конфигурацията на мрежата на стойката е както следва:

DNS: ~# CAT/ETC/Network/Interfaces Auto LO IFACE LOOPBACK AUTH0 IFACE ETH0 INETCAS 10.0.152 NETMASK 255.255.255.0 GATEWAY 10.0.254 AUTOO AUTH1 AUTH1 ATH1 Ace ETH1 Inet Статичен адрес 192.168.1.1 Net маска 255.255.255.0

Където 10.0.0.152/24 - външен интерфейс (подмрежа, разпределена от доставчика), 192.168.1.1/24 - вътрешна (локална мрежа). Персонализираната зона ще бъде наречена example.com. В примера с подчинен сървър, вторичният сървър ще бъде разположен на IP 10.0.0.191 .

Инсталиране на BIND9

За да работи DNS сървърът, трябва свързване9 (в някои дистрибуции - обвързвам ). Както е отбелязано на диаграмата - основният конфигурационен файл BINDе файл named.conf (този файлмогат да бъдат поставени в директорията /и т.н, понякога в /etc/bind).

Параметри (синтаксис) named.conf

Синтаксис на файла named.confспазва следните правила:

IP адреси- IP списъкът трябва да бъде разделен със символа ";" , възможно е да посочите подмрежа във формат 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (за да изключите IP трябва да поставите знак пред него!), възможно е да посочите имена "всеки", "няма", "localhost"в двойни кавички.

Коментари- редовете, започващи с #, // и затворени в /* и */ се считат за коментари.

IN файлове с описание на зони -символ @е „променлива“, съхраняваща името на зоната, посочена в конфигурационния файл named.confили в директивата @ $ ПРОИЗХОДописание на текущата зона.

всеки завършен низпараметрите трябва да завършват със символа; .

Раздел Acl

Acl (списък за контрол на достъпа)- позволява ви да посочите списък с имена на мрежи. Формат на раздела: acl "мрежово_име" (ip; ip; ip;);

Раздел Опции

Раздел Опциикомплекти глобални параметриконфигурационен файл, който контролира всички зони. Този раздел има формат: опции (опции_раздел_оператори);. Опциите могат да бъдат "вложени". Зонова секцияи отменя глобалните настройки. Често се използва изявления за опции:

разреши-заявка( list_ip} - Позволява отговори на запитвания само от list_ip. Ако липсва, сървърът отговаря на всички заявки.
позволи-рекурсия( list_ip} - Ще се изпълняват рекурсивни заявки за заявки от list_ip. За останалите - итеративни. Ако параметърът не е зададен, сървърът изпълнява рекурсивни заявки за всички мрежи.
разреши прехвърляне ( list_ip} - Показва списъка със сървъри, на които е разрешено да вземат зона от сървъра (тук са посочени предимно подчинени сървъри)
директория /path/to/work/dir- указва абсолютния път до работната директория на сървъра. Това твърдение е валидно само в раздела с опции.
спедитори( ip порт, ip порт...} - показва адреси на хостове и, ако е необходимо, портове, където да се препращат заявки (обикновено DNS на доставчиците на интернет услуги се посочва тук).
напред САМО или напред ПЪРВО - параметър първиуказва, че DNS сървърът трябва да се опита да разреши имена, използвайки DNS сървърите, посочени в параметъра за препращане, и само ако не е възможно да разреши името с помощта на тези сървъри, той ще опита да разреши имената сам.
уведомявам ДА|НЕ - ДА- уведомява подчинените сървъри за промени в зоната, НЕ- не уведомявайте.
рекурсия ДА|НЕ - ДА- изпълнява рекурсивни заявки, ако е поискано от клиента, НЕ- не се изпълняват (само итеративни заявки). Ако отговорът е намерен в кеша, той се връща от кеша. (може да се използва само в секцията Опции)

Зонова секция

Определя описанието на зоната(ите). Формат на раздела: зона( секции_зона_оператори}; Оператори, които най-често се използват:

позволи актуализация( list_ip} - определя системите, на които е разрешено динамично да актуализират тази зона.
файл "име на файл " - указва пътя на файла с параметрите на зоната (трябва да се намира в директорията, посочена в секцията с опции от оператора за директория)
майстори ( list_ip} -показва списъка на главните сървъри. (разрешено само в подчинени зони)
Тип " тип_зона " - показва типа на зоната, описана в текущия раздел; zone_type може да приема следните стойности:
- напред- показва зона за пренасочване, която препраща заявки, пристигащи в тази зона.
- намек- обозначава спомагателната зона ( този видсъдържа информация за основните сървъри, с които сървърът ще се свърже, ако не може да намери отговор в кеша)
- майстор- указва да работи като главен сървър за текущата зона.
- роб- указва да работи като подчинен сървър за текущата зона.

Допълнителни опции за конфигурация

Времеви стойности във файловете на зонитепо подразбиране се посочва в секунди, освен ако не са последвани от една от следните букви: S - секунди, M - минути, H - часове, D - дни, W - седмици. Съответно вх 2 ч. 20 мин. 5 секще има стойност 2 часа 20 минути 5 секунди и съответства на 8405 секунди.

Всяко име на хост/запис, което не завършва с точкаброи не FQDNиме и ще бъде допълнено с името на текущата зона. Например записът за домейн във файла на зоната examle.com ще бъде разширен до FQDN името domen.examle.com. .

IN Конфигурационни файлове на BINDможе да се приложи следното директиви:

$TTL- дефинира TTL по подразбиране за всички записи в текущата зона.
$ ПРОИЗХОД- променя името на зоната от посоченото във файла named.conf. В същото време обхватът на тази директива не се простира „по-горе“ (тоест, ако даден файл е включен от директивата $INCLUDE, тогава обхватът на $ORIGN не се простира до родителя)
$ВКЛЮЧВАНЕ- включва посочения файл като част от файла на зоната.

Бих искал специално да опиша параметър разреши-трансфер (10.0.0.191;);. Този параметър описва сървърите, на които е разрешено да изтеглят копие на зоната - т.нар подчинен сървър. В следващия пример ще разгледаме настройката подчинен DNS.

За да работи правилно регистрирането, трябва да създадете подходящата директория и да зададете необходимите права:

Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep име bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 точки/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 6 юли 18:18 /var/log/bind/

Dns:~# cat /var/cache/bind/example.com $TTL 3D @ В SOA ns.example.com. root.example.com. (2011070601; сериен 8H; опресняване 2H; повторен опит 2W; изтичане 1D); минимум @ IN NS ns.example.com. @ В NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @

както и в домейна in-addr.arpa.

Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ В SOA ns.examle.com. root.example.com. (2007042001; Сериен 3600; Обновяване 900; Повторен опит 3600000; Изтичане 3600) ; Минимум IN NS ns.examle.com. В NS ns2.example.com. 152 В PTR examle.com. 191 В PTR ns.example.com. * В PTR examle.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ В SOA ns.examle.com. root.example.com. (2007042001; Сериен 3600; Обновяване 900; Повторен опит 3600000; Изтичане 3600) ; Минимум IN NS ns.examle.com. В NS ns2.example.com. * В PTR examle.com.

Нашата мрежа е малка, предполага се, че има много малко машини в мрежата. Всички мрежови услуги се хостват на един хост example.com., следователно и главният DNS (ns.example.com.) и пощенски сървър(mx.example.com.) сочи към една машина (10.0.0.152).

Вторичен (подчинен) авторитетен зонов сървър

Главна функция подчинен сървър- автоматично синхронизиране на описанието на зоната с главния сървър. Тази задачарегламентирани с документ RFC 1034В глава 4.3.5. Според този документПрепоръчително е да обменяте данни между сървъри с помощта на AXFR заявка. За тази заявка цялата зона трябва да бъде предадена в една TCP връзка (RFC 1035).

Също, подчинен DNS сървърсподеля натоварването с главния сървър или поема цялото натоварване в случай на повреда на първия сървър.

Преди да започнеш настройка на подчинен DNS сървър, трябва да проверите дали можете да получите зоната ръчно от вторичния сървър, като използвате следната команда:

Root@debian:~# dig @10.0.0.152 example.com. axfr;<<>> DiG 9.7.3<<>> @10.0.0.152 example.com. axfr; (намерен е 1 сървър) ;; глобални опции: +cmd example.com. 259200 В SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 В NS ns.example.com. example.com. 259200 В NS ns2.example.com. example.com. 259200 В 10.0.0.152 example.com. 259200 В MX 5 mx.example.com. mx.example.com. 259200 В 10.0.0.152 ns.example.com. 259200 В 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 В CNAME example.com. example.com. 259200 В SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Време за заявка: 14 msec ;; СЪРВЪР: 10.0.0.152#53(10.0.0.152) ;; КОГА: петък, 8 юли 15:33:54 2011 г. ;; XFR размер: 11 записа (1 съобщения, 258 байта)

копие конфигурационен файл named.confот главния сървър;
Сменете тип главен параметърНа тип роб
Параметър разреши-трансфер (10.0.0.191;); замениНа майстори (10.0.0.152;);в тези зони, за които ще бъде второстепенно;
Изтриване на зони, които текущият сървър няма да обслужва, включително основния, ако подчиненото устройство няма да отговори на рекурсивни заявки;
Създайте директорииза трупи, както в предишния пример.

Като цяло получаваме конфигурацията на подчинения сървър:

Root@debian:~# cat /etc/bind/named.conf options ( директория "/var/cache/bind"; allow-query ( any; ); // отговаряне на заявки от всички интерфейси рекурсия не; // деактивиране на рекурсивно requests auth-nxdomain no; // за RFC1035 compatibility listen-on-v6 (none; ); // не се нуждаем от версията на IPv6 "unknown"; // не показваме версията на DNS сървъра в отговорите; // зоните, описани по-долу, определят сървъра като авторитетен за loopback // интерфейси, както и за излъчващи зони (съгласно RFC 1912) зона "localhost" ( тип master; файл "localhost"; ); зона "127.in-addr.arpa" ( тип master; файл "127.in-addr.arpa"; ); зона "0.in-addr.arpa" ( тип master; файл "0.in-addr.arpa";); зона "255.in-addr.arpa" ( тип master; файл "255.in-addr.arpa"; ); // описание на зоната на основната зона "example.com" ( тип slave; файл "example.com"; masters ( 10.0.0.152; ); ); //описание на зоната на обратната зона "0.0.10.in-addr.arpa" ( тип slave; файл "0.0.10.in-addr.arpa"; masters ( 10.0.0.152; ); ); // регистриране на настройки за регистриране ( канал "разни" ( файл "/var/log/bind/misc.log" версии 4 размер 4m; време за печат ДА; сериозност на печат ДА; категория за печат ДА; ); канал "заявка" ( файл "/var/log/bind/query.log" размер 4m; време за печат ДА; категория за печат НЕ; ); категория по подразбиране ( "разни"; ); ) ;

след рестартиране на нашия подчинен сървърще копира успешно необходимата му информация от главния сървър, което ще бъде индикирано от наличието на файлове в директорията:

Root@debian:~# ls -la /var/cache/bind/ total 28 drwxrwxr-x 2 root bind 4096 8 юли 18:47 . drwxr-xr-x 10 root root 4096 8 юли 15:17 .. -rw-r--r-- 1 свързване свързване 416 8 юли 18:32 0.0.10.in-addr.arpa ...... - rw-r--r-- 1 свързване свързване 455 8 юли 18:32 example.com ........

По принцип /stroallow-transfer (pngp подчинен сървърможе да не съхранява копие на зоната в своя файлова система. Това копие е необходимо само при стартиране на DNS. Наличието на копие на зоната във файловата система може да предотврати повреда, ако главният сървър е недостъпен по време на стартиране на подчинен DNS. Ако не посочите опцията за файл в секцията зона, тогава не се създава копие.

Настройка на netfilter() за DNS BIND

Всъщност, след като конфигурирате сървъра, би било добра идея да го защитите. Знаем, че сървърът работи на порт 53/udp. След като прочетете статията за това и се запознаете с нея, можете да създадете правила за филтриране на мрежовия трафик:

Dns ~ # iptables-save # типични iptables правила за DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate СВЪРЗАНИ, УСТАНОВЕНИ -j ACCEPT -A INPUT -m conntrack --ctstate НЕВАЛИДЕН -j DROP # позволява достъп до локалната мрежа до DNS сървъра: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack - -ctstate НОВО -j ПРИЕМАНЕ -A ИЗХОД -o lo -j ПРИЕМАНЕ -A ИЗХОД -p icmp -j ПРИЕМАНЕ -A ИЗХОД -p udp -m udp --sport 32768:61000 -j ПРИЕМАНЕ -A ИЗХОД -p tcp - m tcp --sport 32768:61000 -j ПРИЕМАНЕ -A ИЗХОД -m conntrack --ctstate СВЪРЗАНИ, УСТАНОВЕНИ -j ПРИЕМАНЕ # разрешаване на достъп до DNS сървъра за извършване на изходящи заявки -A ИЗХОД -p udp -m udp --dport 53 -m conntrack - -ctstate НОВО -j ПРИЕМАНЕ НА АНГАЖИРАНЕ

Това е типичен пример! За да зададете правила на iptables така, че да отговарят на вашите задачи и мрежова конфигурация, трябва да разберете как работи netfilter в Linux, като прочетете горните статии.

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

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

5 юли 18:12:43 dns-сървър с име: стартиране на BIND 9.7.3 -u bind 5 юли 18:12:43 dns-сървър с име: изграден с "--prefix=/usr" "--mandir=/usr/ share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "- -with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "- -with-dlz-postgres=не" "--with-dlz-mysql=не" "--with-dlz-bdb=да" "--with-dlz-filesystem=да" "--with-dlz-ldap =да" "--with-dlz-stub=да" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" " CPPFLAGS=" 5 юли 18:12:43 dns-сървър с име: коригиран лимит за отворени файлове от 1024 до 1048576 5 юли 18:12:43 dns-сървър с име: намерен 1 CPU, използващ 1 работна нишка 5 юли 18:12: 43 dns-сървър с име: използване на до 4096 сокета 5 юли 18:12:43 dns-сървър с име: зареждане на конфигурация от "/etc/bind/named.conf" 5 юли 18:12:43 dns-сървър с име: изградено четене -в доверени ключове от файл "/etc/bind/bind.keys" 5 юли 18:12:43 dns-сървър наименуван: използвайки стандартен UDP/IPv4 обхват на портовете: 5 юли 18:12:43 dns-сървър наименуван: използвайки подразбиране UDP/IPv6 порт обхват: 5 юли 18:12:43 dns-сървър с име: слушане на IPv4 интерфейс lo, 127.0.0.1#53 5 юли 18:12:43 dns-сървър с име: слушане на IPv4 интерфейс eth1, 192.168.1.1 #53 5 юли 18:12:43 dns-сървър с име: генериране на сесиен ключ за динамичен DNS 5 юли 18:12:43 dns-сървър с име: не можа да конфигурира подсказки за root от "/etc/bind/db.root": файл не е намерено 5 юли 18:12:43 dns-сървър с име: конфигурация за зареждане: файлът не е намерен # файлът не е намерен 5 юли 18:12:43 dns-сървър с име: излиза (поради фатална грешка) 5 юли 18:15:05 dns- сървър с име: започва BIND 9.7.3 -u bind 5 юли 18:15:05 dns-сървър с име: изграден с "--prefix=/usr" "--mandir=/usr/share/man" "--infodir= /usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable -shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=не" "--with-dlz-bdb=да" "--with-dlz-filesystem=да" "--with-dlz-ldap=да" "--with-dlz -stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" 5 юли 18:15: 05 dns-сървър с име: коригиран лимит за отворени файлове от 1024 до 1048576 5 юли 18:15:05 dns-сървър с име: намерен 1 CPU, използващ 1 работна нишка 5 юли 18:15:05 dns-сървър с име: използвайки до 4096 сокета 5 юли 18:15:05 dns-сървър наименуван: зареждане на конфигурация от "/etc/bind/named.conf" 5 юли 18:15:05 dns-сървър наименуван: използване на обхват на UDP/IPv4 портове по подразбиране: 5 юли 18 :15:05 dns-сървър с име: използване на UDP/IPv6 портове по подразбиране: 5 юли 18:15:05 dns-сървър с име: слушане на IPv4 интерфейс lo, 127.0.0.1#53 5 юли 18:15:05 dns-сървър наименуван: слушане на IPv4 интерфейс eth1, 192.168.1.1#53 5 юли 18:15:05 dns-сървър наименуван: автоматично празна зона: 254.169.IN-ADDR.ARPA 5 юли 18:15:05 dns-сървър наименуван: автоматично изпразване зона: 2.0.192.IN-ADDR.ARPA 5 юли 18:15:05 dns-сървър с име: автоматично изпразване зона: 100.51.198.IN-ADDR.ARPA 5 юли 18:15:05 dns-сървър с име: автоматично изпразване зона: 113.0.203.IN-ADDR.ARPA 5 юли 18:15:05 dns-сървър с име: автоматично изпразване зона: 255.255.255.255.IN-ADDR.ARPA 5 юли 18:15:05 dns-сървър с име: автоматично изпразване зона: 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 5 юли 18:15:05 dns-сървър с име: автоматично празна зона: 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 5 юли 18:15:05 dns-сървър с име: автоматична празна зона: D.F.IP6.ARPA 5 юли 18:15:05 dns-сървър с име: автоматична празна зона: 8.E.F.IP6.ARPA 5 юли 18:15:05 dns-сървър с име: автоматично празна зона: 9.E.F.IP6 .ARPA 5 юли 18:15:05 dns-сървър с име: автоматична празна зона: A.E.F.IP6.ARPA 5 юли 18:15:05 dns-сървър с име: автоматична празна зона: B.E.F.IP6.ARPA 5 юли 18:15:05 dns -сървър с име: автоматично празна зона: 8.B.D.0.1.0.0.2.IP6.ARPA 5 юли 18:15:05 dns-сървър с име: зона 0.in-addr.arpa/IN: зареден сериен 1 5 юли 18: 15:05 dns-сървър с име: зона 127.in-addr.arpa/IN: зареден сериен номер 1 5 юли 18:15:05 dns-сървър с име: зона 255.in-addr.arpa/IN: зареден сериен номер 1 5 юли 18:15:05 dns-сървър с име: зона localhost/IN: зареден сериен 2 юли 5 18:15:05 dns-сървър с име: изпълнение # стартирането беше успешно

Отличен диагностичен инструмент е.

Резюме

В настоящата статия описах настройката на основни DNS конфигурации на BIND сървър. Целта на статията беше да даде представа за работата на BIND сървъра в UNIX. На практика не засегнах въпросите за сигурността на DNS и малко засегнах такива специфични настройки като работата на сървъра в крайния режим, когато различна информация за зоната (ите) се изпраща до различни мрежи. За по-задълбочено разбиране ще предоставя списък с допълнителни източници, в които, надявам се, ще можете да получите необходимата информация. Ще сложа край на това. До следващия път.

Система за имена на домейни: http://citforum.ru/internet/dns/khramtsov/
RFC 1034- Имена на домейни - Концепции и съоръжения: http://tools.ietf.org/html/rfc1034
RFC 1035- Имена на домейни - Внедряване и спецификация: http://tools.ietf.org/html/rfc1035
RFC 1537- Често срещани грешки при конфигуриране на файлове с DNS данни: http://tools.ietf.org/html/rfc1537
RFC 1591- Структура и делегиране на системата за имена на домейни: http://tools.ietf.org/html/rfc1591
RFC 1713- Инструменти за DNS отстраняване на грешки: http://tools.ietf.org/html/rfc1713
RFC 2606- Запазени DNS имена от най-високо ниво: http://tools.ietf.org/html/rfc2606
DNS сигурност (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Справочно ръководство на администратора: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Сигурен BIND шаблон: http://www.cymru.com/Documents/secure-bind-template.html
Конфигурационните параметри са добре описани наРуски: http://www.bog.pp.ru/work/bind.html
Автоматично създаване на зонов файл: http://www.zonefile.org/?lang=en#zonefile

артем

30.10.2013

10379

Настройване на кеширащ DNS сървър за решаване на проблема с увисването на chan_sip.so.

SIP модулът на Asterisk синхронно разрешава DNS имена; ако DNS сървърът по някаква причина спре да отговаря на заявки, кодът на SIP модула спира да се изпълнява преди времето за изчакване на DNS заявката. Резултатът от това е, че всички клиенти и доставчици, свързани чрез SIP, са неработещи, клиентите не могат да се регистрират и да провеждат разговори.
Начини за решаване на проблема:
1. Не посочвайте DNS имена в параметъра SIP peers ‘host’ и в редовете за SIP регистрация посочвайте само IP адреси (това ви позволява напълно да елиминирате възможността за проблем, но това не е възможно при някои доставчици).
2. Конфигурирайте кеширащ DNS сървър на хоста Asterisk.

Тази статия ще опише начин за решаване на проблема с помощта на BIND DNS сървъра (инструкциите са правилни за CentOS 5-6)

Настройване на BIND DNS сървър

1. Инсталирайте BIND, копирайте шаблони за настройки и стандартни зонови файлове

yum инсталирайте bind bind-chroot
cp /etc/localtime /var/named/chroot/etc

cp /usr/share/doc/bind-*/sample/etc/named.root.hints /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.rfc1912.zones /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.conf /var/named/chroot/etc

cp /usr/share/bind-*/sample/var/named/localdomain.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/localhost.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.broadcast /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.ip6.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.root /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.zero /var/named/chroot/var/named

2. Редактирайте конфигурацията на BIND /var/named/chroot/etc/named.conf

Следните промени трябва да бъдат направени в конфигурацията:

> Добавете следния ред към секцията с опции:

Можете да посочите вашите DNS сървъри. Ако не укажете този ред, BIND ще направи заявка към главните DNS сървъри, което е по-бавно

> Разрешаване на рекурсивни заявки за зоната за преглед на 'localhost_resolver' (заменете 'recursion no' с 'recursion yes'; ако това не е направено, самият хост няма да може да прави рекурсивни заявки през DNS сървъра). Рекурсивните заявки и заявките за кеша за други зони могат да бъдат деактивирани

> Коментирайте или изтрийте секциите, отговорни за настройката на вътрешни зони и DDNS, защото те просто няма да съществуват

Списък на получената конфигурация:

//
// Примерен конфигурационен файл named.conf BIND DNS сървър 'named'
// за разпространението на Red Hat BIND.
// Вижте BIND Administrator's Reference Manual (ARM) за подробности, в:
// file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Вижте също GUI за конфигурация на BIND: /usr/bin/system-config-bind and
// неговото ръководство.
настроики
{
// Тези опции трябва да се използват внимателно, защото деактивират порта
// рандомизация
// източник на заявка порт 53;
// query-source-v6 порт 53;

// Поставете файлове, на които наmed е позволено да записват в директорията data/:
директория “/var/named”; // по подразбиране
дъмп-файл “data/cache_dump.db”;
статистически файл “data/named_stats.txt”;
memstatistics-файл “data/named_mem_stats.txt”;
максимален размер на кеша 2097152;

спедитори ( 8.8.8.8; 8.8.4.4; );
};
//регистриране
//{
/* Ако искате да активирате отстраняване на грешки, напр. използвайки командата "rndc trace",
* named ще се опита да запише файла „named.run“ в директорията $ (/var/named).
* По подразбиране политиката на SELinux не позволява на named да променя директорията /var/named,
* затова поставете регистрационния файл за отстраняване на грешки по подразбиране в data/:
*/
// канал default_debug (
// файл “data/named.run”;
// динамика на тежестта;
// };
//};
// Всички зони на BIND 9 са в „изглед“, което позволява да се обслужват различни зони
// към различни типове клиентски адреси и за опции, които да бъдат зададени за групи
// от зони.
// По подразбиране, ако named.conf не съдържа клаузи „изглед“, всички зони са в
// изглед „по подразбиране“, който съответства на всички клиенти.
// Ако named.conf съдържа клауза „изглед“, тогава всички зони ТРЯБВА да бъдат в изглед;
// така че се препоръчва да започнете да използвате изгледи, за да избегнете необходимостта от преструктуриране
// вашите конфигурационни файлове в бъдеще.
преглед на “localhost_resolver”
{
/* Този изглед настройва named да бъде резолвер на локален хост (кешира само сървър на имена).
* Ако всичко, което искате, е сървър за имена само за кеширане, тогава трябва да дефинирате само този изглед:
*/
съпоставяне на клиенти (localhost;);
съответстващи дестинации (localhost;);
рекурсия да;

/* това са зони, които съдържат дефиниции за всички локални хостове
* имена и адреси, както се препоръчва в RFC1912 – тези имена трябва
* Да се обслужва САМО на клиенти на localhost:
*/
включват “/etc/named.rfc1912.zones”;
};
преглед "вътрешен"
{
/* Този изглед ще съдържа зони, които искате да обслужвате само на „вътрешни“ клиенти
които се свързват чрез вашите директно свързани LAN интерфейси – „локални мрежи“ .
*/
мач-клиенти (локални мрежи;);
мач-дестинации (локални мрежи;);
рекурсия не;

Allow-query-cache (няма;);

// всички изгледи трябва да съдържат зоната за основни съвети:
включват “/etc/named.root.hints”;

// включват “named.rfc1912.zones”;
// не трябва да обслужвате вашите rfc1912 имена на клиенти, които не са локален хост.

// Това са вашите „авторитетни“ вътрешни зони и вероятно биха
// също да бъдат включени в изгледа „localhost_resolver“ по-горе:

//зона “my.internal.zone” (
// тип master;
// файл “my.internal.zone.db”;
//};
//зона “my.slave.internal.zone” (
// тип slave;
// файл “slaves/my.slave.internal.zone.db”;
// masters ( /* поставете IP адреси на главния сървър на имена тук */ 127.0.0.1; ) ;
// // поставянето на подчинени зони в така наречената подчинена директория може да ги актуализира
//};
//зона “my.ddns.internal.zone” (
// тип master;
// позволи актуализация (ключ ddns_key;);
// файл “slaves/my.ddns.internal.zone.db”;
// // поставете динамично обновяеми зони в така наречената slaves/ директория, която може да ги актуализира
//};
};
//ключ ddns_key
//{
// алгоритъм hmac-md5;
// тайна „използвайте /usr/sbin/dns-keygen за генериране на TSIG ключове“;
//};
изглед „външен“
{
/* Този изглед ще съдържа зони, които искате да обслужвате само на „външни“ клиенти
* които имат адреси, които не са във вашите директно свързани подмрежи на LAN интерфейс:
*/
съпоставяне на клиенти ( всякакви; );
съвпадащи дестинации ( всякакви; );

рекурсия не;
// вероятно бихте искали да откажете рекурсия на външни клиенти, така че не го правете
// в крайна сметка предоставя безплатна DNS услуга на всички потребители

разреши-запитване-кеш (няма;);
// Деактивирайте търсенията за всякакви кеширани данни и подсказки за корен

// всички изгледи трябва да съдържат зоната за основни съвети:
включват “/etc/named.root.hints”;

// Това са вашите „авторитетни“ външни зони и вероятно биха
// съдържа записи само за вашите уеб и пощенски сървъри:

//зона “my.external.zone” (
// тип master;
// файл “my.external.zone.db”;
//};
};

3. Стартирайте BIND, активирайте стартирането при стартиране на системата

услуга с име начало

Ако има грешки в синтаксиса на конфигурацията или липсват файлове, съобщение за грешка ще бъде изведено на конзолата и ще бъде записано в журнала /var/log/messages

Подобни статии