Контактная информация

По всем интересующим вас вопросам связывайтесь при помощи контактной информации приведенной на этой странице!

skype: metsof
email: accusser@gmail.com

В социальных сетях...

Форма обратной связи

Авторизация

Статьи об операционной системе Linux

Сайдбар

Настройки программы bind

01 апр. 2014

В качестве сервера имен в Linux/UNIX чаще всего применяется программа named, входящая в состав пакета bind9. BIND означает Berkeley Internet Name Domain. В этой статье мы ограничимся рассмотрением только двух видов конфигурации — кэш для сервера имен и сервер имен для локальной (частной) сети. Более подробно эта тема описана в Интернете: www.isc.org/sw/bind/.

Конфигурация в виде кэша для сервера имен


В большинстве дистрибутивов bind настроена так, что программу можно использовать в качестве кэша для сервера имен, не внося в конфигурацию никаких изменений. При этом программа перенаправляет все адресные запросы на так называемый корневой сервер имен и сохраняет результаты в кэше. При повторном получении того или иного запроса его результат сразу же предоставляется системой. Чтобы использовать bind таким образом, вам придется изменить минимум настроек или вообще не потребуется ничего менять! Только в некоторых устаревших версиях Red Hat понадобится дополнительно установить пакет caching-nameserver.

Хотя конфигурационная работа с этой программой и сводится к минимуму, далее я продемонстрирую вам сравнительно сложные конфигурационные файлы bind хотя бы для ознакомления. В этих листингах вы увидите важнейшие ключевые слова, получите общее представление о синтаксисе и о том, как и почему работает bind. В этом разделе мы рассмотрим, как bind работает в Ubuntu. Особенности программы для Fedora и SUSE будут обобщены в конце этого раздела.

Конфигурационные файлы



Для управления bind используется не один, а несколько конфигурационных файлов. Исходной точкой является файл named.conf, который, в зависимости от дистрибутива, может находиться и непосредственно в каталоге /etc, и в /etc/bind/. В этом файле содержатся указания на различные другие файлы, обычно расположенные в каталоге /etc/bind. В некоторых дистрибутивах, напротив, чаще всего используются каталоги var/named или /var/lib/.

Комментарии.

Если нужно добавить комментарии, они оформляются тремя способами:

# комментарий до конца строки // комментарий до конца строки /* многострочный комментарий */

named.conf. Итак, исходным пунктом при конфигурации является файл /etc/ bind/named.conf. Имена (ключевое слово file) и каталоги (ключевое слово directory) всех остальных конфигурационных файлов разные, в зависимости от дистрибутива.

# Файл /etc/bind/named.conf (Ubuntu)

# Здесь находятся глобальные параметрь include "/etc/bind/named.conf.options";
# Здесь находятся адреса корневых серверов zone "." {

type hint;

file "/etc/bind/db.root"; };

# Правильное обращение с localhost, обратное разрешение адресов для

# петлевого интерфейса (127.0.0.1) и зон широковещания

zone «localhost» { type master;

file "/etc/bind/db.local"; }; zone «127.in-addr.arpa» { type master;

file "/etc/bind/db.127"; }; zone «O.in-addr.arpa» { type master;

file "/etc/bind/db.O"; }; zone «255.in-addr.arpa» { type master;

file "/etc/bind/db.255"; };

# Индивидуальные дополнения в конфигурацию вносятся здесь include "/etc/bind/named.conf.local";

named.conf.local. Файл /etc/bind/named.conf.local — это наилучшее место для внесения индивидуальных дополнений в конфигурацию сервера имен.

named.conf.options. В /etc/bind/named.conf.options содержатся различные глобальные параметры для сервера имен. С помощью ключевого слова forwarders вы можете указать IP-адрес сервера имен вашего провайдера, a named может работать и без указания такой информации, но при этом программа будет вынуждена обращаться к корневому серверу имен. Чем ближе находится сервер имен, тем эффективнее функционирует разрешение имен.

Параметр query-source-address определяет порт для обмена информацией между bind и другими серверами имен. Современные версии bind по умолчанию используют случайные, непривилегированные порты (номера портов — от 1024 до 65 535). Если эти порты блокируются брандмауэром, то команду query-source нужно прокомментировать. В этом случае bind будет использовать порт 53, как в более ранних версиях.

# Файл /etc/bind/named.conf.options options {

# Каталог для файлов кэша directory "/var/cache/bind";

# Здесь указывается сервер имен из локальной сети или сервер имен провайдера forwarders { 10.0.0.138; };

# прокомментировать, чтобы использовать для обмена информацией

# порт 53

# query-source address * port 53:

# Соответствие стандарту RFC1035 auth-nxdomain no; listen-on-v6 { any; };

}:

db.root. Файл db.root содержит IP-адреса нескольких центральных серверов имен, которые обращаются к bind для разрешения имен. Эти IP-адреса также содержатся в скомпилированном коде bind, поэтому bind может работать и без файла db.root. И все же этот файл рекомендуется использовать, так как IP-адреса центрального DNS-сервера могут измениться. О том, как создается и обновляется db.root, рассказано в подразделе «Техническая поддержка» этого раздела. Далее приведен фрагмент этого файла:

; Файл /etc/bind/db.root

A.ROOT-SERVERS.NET.

A.ROOT-SERVERS.NET.

B.ROOT-SERVERS.NET.

C.ROOT-SERVERS.NET.

3600000 А 3600000 АААА 3600000 А 3600000 А

198.41.0.4 2001:503:BA3E::2:30 192.228.79.201 192.33.4.12

Файлы db.*. Файлы db.local, db.0, db.1 и db.127, отличающиеся запутанным синтаксисом, описывают, как должен работать сервер имен при разрешении имен, получаемом с интернет-адресов и адреса localhost.


Fedora, Red Hat



Центральный конфигурационный файл в Fedora и Red Hat называется /etc/named. conf. В файле /etc/named.rfcl912.zones содержатся все настройки, необходимые для того, чтобы демон named работал как кэширующий сервер имен. Все остальные конфигурационные файлы находятся в каталоге /var/named. Список корневых DNS расположен в /var/named/named.ca.

Самый важный момент базовой конфигурации заключается в том, что запросы сервера имен принимаются только localhost! Чтобы named также реагировал на запросы других компьютеров, находящихся в локальной сети, потребуется внести два изменения: во-первых, добавьте в listen-on IP-адрес сервера, работающего в LAN (в данном случае 192.168.0.1), во-вторых, укажите в allow-query адресное пространство локальной сети (в данном случае 192.168.0.0/24).

# Файл /etc/named.conf (Fedora) options {

listen-on port 53 { 127.0.0.1; 192.168.0.1: }; # Внимание! listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; 192.168.0.1/24; }; # Внимание!

recursion yes; dnssec-enable yes; dnssec-validation yes;

dnssec-lookaside. trust-anchor dlv.isc.org.;

}:

logging { channel default_debug { file «data/named.run»; severity dynamic:

}:

}:

zone "." IN { type hint; file «named.ca»;

}:

include "/etc/named.rfcl912.zones":

include "/etc/named.dnssec.keys";

include "/etc/pki/dnssec-keys/dlv/dlv.isc.org.conf";

SELinux следит за сервером имен и гарантирует, что программа не будет обращаться ни к каким файлам, кроме /var/named. По мнению разработчиков Red Hat, такой метод более эффективен, чем использование среды chroot. Только если вы отключите SELinux, рекомендуется установить дополнительный пакет bind-chroot.

SUSE



В SUSE используются конфигурационные файлы /etc/named.conf и /etc/named. conf.include. Для хранения собственных конфигурационных файлов и файлов ключей предназначен каталог /etc/named.d. В любом случае содержащиеся в нем файлы нужно специально указать в переменной NAMED_CONF_-INCLUDE_FILES в /etc/sysconfig/ named.

Конфигурационные файлы для настройки кэширующей функции сервера имен находятся в каталоге /var/lib/named. Список корневых DNS расположен в /var/log/ named/root.hint.

# Файл /etc/named.conf (SUSE) options { directory "/var/lib/named"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats"; listen-on-v6 { any: }; notify no;

}:

zone "." in { type hint; file «root.hint»;

}:

zone «localhost» in { type master; file «localhost.zone»;

}:

zone «0.0.127.in-addr.arpa» in { type master; file «127.0.0.zone»;

}:

include "/etc/named.conf.include";

В SUSE named по умолчанию работает в среде chroot в каталоге /var/lib/named. Если в ваших конфигурационных файлах стоят ссылки на другие файлы, не ставьте слово chroot перед названием этого каталога!

Начало работы и тестирование



Прежде чем в первый раз запустить named, необходимо обеспечить правильную конфигурацию файлов /etc/resolv.conf и /etc/nsswitch.conf. Оба эти файла не относятся к пакету bind, но указывают, как другие программы, расположенные на локальном компьютере, должны использовать сервер имен.

Файл resolv.conf


Файл /etc/resolv.conf работает со всеми сетевыми службами компьютера и указывает, какими серверами имен должны пользоваться эти службы. Как правило, в этом файле содержится IP-адрес сервера имен вашего провайдера или IP-адрес вашего роутера. Чтобы шлюз вместо этого использовал специально настроенный отдельный сервер имен, ключевое слово nameserver в /etc/resolv обязано указывать на адрес 127.0.0.1. Остальные настройки должны остаться без изменений.

# /etc/resolv.conf search sol

nameserver 127.0.0.1

Если шлюз выходит в Интернет через роутер с собственным DHCP-сервером или через РРР, то файл /etc/resolv.conf обновляется при каждом соединении. В качестве сервера имен при этом используется сервер имен роутера или интернет-провайдера. Таким образом, любые изменения, вносимые в /etc/resolv.conf вручную, при следующем соединении стираются и специально созданный сервер имен никак не влияет на работу шлюза.

Если доступ к Интернету осуществляется через роутер (DHCP), вам больше подойдет статическая конфигурация сети. В некоторых дистрибутивах в программе конфигурации сети предусматривается возможность использования DHCP, но конфигурацию сервера имен все равно придется выполнить вручную. При работе с РРР необходимо удалить параметр usepeerdns из /etc/ppp/options или /etc/ppp/ peers/connection_name. В SUSE есть и другая возможность — можно задать в качестве значения переменной NETC0NFIG_DNS_P0LICY в /etc/sysconfig/network/config пустую строку, чтобы все сценарии SUSE «самовольно» не вносили в этот файл изменений.

Запуск/остановка



Команды для автоматического запуска демона сервера имен различаются в разных дистрибутивах. Все они перечислены в разделе 4.5. Сценарий Init-V в Debian и Ubuntu называется bind9, в Fedora, Red Hat и SUSE — named. Изменения, внесенные в конфигурацию, вступят в силу только тогда, когда вы прикажете серверу имен заново считать конфигурационные файлы:

root# /etc/init.d/bind9 reload (<a class="myClass" href="http://www.modx.cc/linux/zapusk-sistemyi-ubuntu/">Ubuntu</a>, Debian) root# /etc/init.d/named reload (<a class="myClass" href="http://www.modx.cc/linux/zapusk-sistemyi-v-fedora/">Fedora</a>, Red Hat, SUSE)


Журналирование



Для проведения первых тестов нужно активизировать функцию журналирования, если это не предусмотрено в вашем дистрибутиве по умолчанию. Для этого необходимо дополнить один из конфигурационных файлов, например named.conf.local в Ubuntu, следующими строками:

logging { channel «namedjog» { file "/var/log/named/named.log" versions 10 size 500k; severity dynamic; print-category yes; print-severity yes; print-time yes;

}:

channel «queryjog» { file "/var/log/named/named-query.log" versions 10 size 500k; severity debug; print-severity yes; print-time yes;

}:

category default { namedjog: }: category queries { queryjog: }:

}:

С помощью следующих команд сначала создаются пустые файлы регистрации и гарантируется, что named может изменять файлы:

root# mkdir /var/log/named

root# touch /var/log/named/named.log

root# touch /var/log/named/named-query.log

root# chown -R bind:bind /var/log/named (Debian, Ubuntu)

root# chown -R named:named /var/log/named (Fedora, Red Hat)

В Fedora и Red Hat named использует имена учетных записей и групп named (а не bind). Кроме того, в этих дистрибутивах named обычно может вносить изменения только в каталог /var/named/, поэтому в него нужно помещать и сами файлы регистрации. По умолчанию для этого применяется /var/named/data/named.run.

Тестирование сервера имен



С помощью команды ping можно проверить, работает ли разрешение имен интернет-адресов. Еще лучше проверить, исправно ли функционирует сервер имен, с помощью команды host. В следующих строках показано, как система узнает IP-адреса Yahoo! и как узнать IP-адреса компьютеров:

root# host yahoo.com

host yahoo.com

yahoo.com has address 69.147.114.224

yahoo.com has address 209.131.36.159

yahoo.com has address 209.191.93.53

yahoo.com mail is handled by 1 d.mx.mail.yahoo.com.

yahoo.com mail is handled by 1 e.mx.mail.yahoo.com.

root# host 69.147.114.224

224.114.147.69.in-addr.arpa domain name pointer bl.www.vip.re3.yahoo.com.

Конфигурация DHCP



Если вы используете DHCP-сервер и передаете адреса DNS компьютерам в сети с его помощью, нужно изменить соответствующую строку в dhcpd.conf. В дальнейшем клиенты будут связываться уже не с DNS вашего интернет-провайдера, а с локальным сервером имен (который, в свою очередь, устанавливает соединения со внешними DNS, если адреса еще нет в кэше). Укажите в dhcpd.conf IP-адрес того компьютера, на котором вы только что установили DNS (в приведенном примере этоадрес 192.168.0.1).

Кроме того, вам потребуется указать в dhcpd.conf доменное имя локальной сети (в примере это имя sol). После проведения этой операции в /etc/resolv.conf DHCP-клиентов появится строка search sol.

# Дополнение в начале /etc/dhcpd.conf option domain-name-servers 192.168.0.1; option domain-name «sol»;

С точки зрения клиента, при создании в локальной сети собственного DNS меняется немногое. Просто клиент теперь связывается с внутрисетевым, а не с внешним DNS.

Разрешение имен локальных компьютеров (динамическая конфигурация)

Теперь конфигурацию DNS необходимо дополнить таким образом, чтобы и сервер имен мог распознавать клиентские компьютеры локальной сети. Для этого DHCP-сервер конфигурируется так, чтобы он мог передавать информацию о полученных из Интернета именах и адресах серверу имен. Информация об адресах важна только в пределах локальной сети и не должна попадать «наружу».

Часто DNS выполняет прямо противоположную задачу: если компьютеры, работающие в вашей сети, имеют адреса, действительные во всем Интернете, то эти адреса будут известны во всем мире. Если ваш провайдер не занимается устранением подобной проблемы, вы сами должны сконфигурировать DNS так, чтобы адреса ваших компьютеров «не разглашались». В большинстве книг и документов, посвященных DNS, такая операция считается обычной практикой. Однако, поскольку в этой книге я заостряю внимание именно на управлении небольшими локальными сетями, более подробно описывать такие случаи я не буду.

Что касается примера, приведенного в этом разделе, локальная сеть sol находится в адресном пространстве www.modx.cc/manager/?a=resource/create&class_key=Article&parent=982&context_key=web&template=30192.168.0.*. DNS работает на компьютере mars.sol с адресом 192.168.0.1. Для расширения требуются два новых файла зон: db.sol для разрешения локальных адресов *.sol в IP-адресах (например, merkur.sol^l92.168.0.15), а также db.192.168.0 для обратного разрешения локальных IP-адресов в именах компьютеров (например, 192.168.0.15^merkur.sol).

Все имена файлов, каталогов, учетных записей и групп далее описаны для Ubuntu. В конце раздела приводятся советы по конфигурации Fedora и SUSE.

Создание ключа



Обмен данными между DHCP-сервером и сервером имен защищается общим ключом. Далее поэтапно показано, как подготовить к работе файл ключей. Сначала с помощью dnssec-keygen создается файл ключей:

root# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom \ -n USER DHCP_UPDATER

Команда dnssec-keygen создает в актуальном каталоге два файла, названия которых начинаются с Kdhcp. Определяющее значение имеет файл ^.private, который может выглядеть следующим образом:

root# cat Kdhcp*.private

Private-key-format: v1.2

Algorithm: 157 (HMAC_MD5) Key: 8D9AcWw2G+sIAV42cgMPwg== Bits: AAA=

Теперь последовательность символов key переносится в новый файл ddns.key. Пример такого файла можно скопировать из man dhcpd.conf.

# Файл /root/ddns.key key DHCP_UPDATER { algorithm HMAC-MD5.SIG-ALG.REG.INT; secret «8D9AcWw2G+sIAV42cgMPwg==»;

}:

Этот файл копируется в каталоги /etc/bind и /etc/dhcp3, после чего для него настраиваются следующие права доступа:

root# cp ddns.key /etc/bind/

root# cp ddns.key /etc/dhcp3/

root# chown root:bind /etc/bind/ddns.key

root# chown root:dhcpd /etc/dhcp3/ddns.key root# chmod 640 /etc/bind/ddns.key root# chmod 640 /etc/dhcp3/ddns.key root# ls -l /etc/*/ddns.key

-rw-r----- 1 root bind… /etc/bind/ddns.key

-rw-r----- 1 root dhcpd… /etc/dhcp3/ddns.key

Конфигурация dhcpd



В следующем листинге в обобщенном виде показано, как нужно дополнить /etc/ dhcp3/dhcpd.conf для обеспечения динамической конфигурации. Если в dhcpd.conf содержится несколько групп, то дополнения вносятся вне этих групп.

# Дополнения в /etc/dhcpd3/dhcpd.conf

include "/etc/dhcp3/ddns.key";

ddns-updates on;

ddns-update-style interim;

ddns-domainname «sol.»;

update-static-leases on; zone sol. { primary 127.0.0.1;

key «DHCP_UPDATER»; } zone 0.168.192.in-addr.arpa. { primary 127.0.0.1;

key «DHCP_UPDATER»; }

Поясню этот пример. Параметр include считывает файл ключей, создание которого было описано Bbime;ddns-updates активизирует динамическое обновление сервера HMeH;ddns-update-style описывает, каким методом должны производиться обновления. Этот метод пока не стандартизирован, поэтому называется временным (метод подробно описан в man dhcpd.conf).

Параметр ddns-domainname указывает доменное имя локальной сети — во всех примерах в книге используется доменное имя sol; update-static-leases заставляет DHCP-сервер переадресовывать на сервер имен и ту информацию, которая поступает с хостов, имеющих статическую конфигурацию. (Как правило, DHCP-сервер переадресовывает только те IP-адреса и имена, которые были присвоены динамически. Устройства, имеющие статическую конфигурацию, в таком случае будут «не замечены» системой.)

Оба определения zone в итоге указывают, какие зоны сервера имен следует обновить. При этом primary указывает IP-адрес сервера имен, a key — используемый ключ (определение ключа находится в ddns.key).

Конфигурация bind


Со стороны DHCP конфигурация уже завершена, а с named еще надо поработать. В первую очередь укажем в конфигурационном файле named.conf.local две новые зоны, которые называются «основными» (master zone). Иначе говоря, теперь named не может обращаться ко внешним источникам для разрешения имен, а сама

отвечает за такое pa3pemeHHe;notify no исключает возможность передачи named информации из локальной сети на внешнюю DNS.

Обратите внимание, что в названиях зон адреса указываются в обратном порядке. Вместо 192.168.0.* записывается 0.168.192. Синтаксис named.conf требует обязательно указывать .in-addr.arpa.

Имена файлов зон (в данном случае db.sol и db.192.168.0) можно выбирать произвольно. Однако по этим именам, разумеется, должно быть понятно, конфигурация каких областей сети задается.

# Изменения в /etc/bind/named.conf.local include "/etc/bind/ddns.key";

# Эти зоны обновляют DHCP-сервер zone «sol» {

type master; notify no;

file "/var/cache/bind/db.sol"; allow-update { key «DHCP_UPDATER»: };

}:

zone «0.168.192.in-addr.arpa» { type master; notify no;

file "/var/cache/bind/db.192.168.0"; allow-update { key «DHCP_UPDATER»: };

}:

Файл db.sol.

Строение файлов зон соответствует указанному образцу, причем, как правило, требуется откорректировать лишь немногие строки. Во второй строке файла /etc/bind/db.sol указывается sol. и root.sol., где sol заменяется доменным именем вашей сети. В строке NS указывается имя локального сервера имен (оканчивается точкой!), а в следующей строке — его IP-адрес. При использовании статической конфигурации вы можете задать и другие имена компьютеров, а также их IP-адреса. Однако в данном примере этого не требуется. В следующем листинге все изменения, которые следует внести в образец, выделены полужирным:

; новая зона файла /etc/bind/db.sol $TTL 86400

@ IN SOA sol. root.sol. (

1

604800

2419200 86400 )

IN NS mars.sol. mars IN A 192.168.0.1

Serial

Refresh (7 days) Retry (1 day) Expire (28 days) Negative Cache TTL (1 day)

db.192.168.0. Первые строки файла /etc/bind/db.192.168.0 выглядят так же, как и в db.sol. Но следующий список построен прямо противоположным образом, то есть строятся взаимосвязи между окончаниями IP-адресов и именами. Поскольку файл ссылается на зону 192.168.0.*, в каждом IP-адресе нужно указать только последнее число.

; новая зона файла /etc/bind/db.sol $TTL 86400

@ IN SOA sol. root.sol.

1

604800

2419200 86400 )

@ IN NS mars.sol.

1 IN PTR mars.sol

Вы, вероятно, заметили, что файл named.conf.local ссылается на файлы зон из каталога /var/cache/bind, а не на сам каталог /etc/bind, как обычно. Причина заключается в том, что named записывает изменения, указываемые DHCP-сервером, в файлы регистрации *.jnl. При завершении работы сервера имен изменения сохраняются в файлах *.db, так что при новом запуске в вашем распоряжении оказываются самые актуальные версии файлов. Чтобы все работало, сервер имен должен иметь право вносить изменения в файлы *.jnl, а они есть лишь в каталоге /var/ cache/bind. По этой причине теперь нам понадобятся еще две символьные ссылки, которые будут указывать на файлы зон в /etc/bind:
root# cd /var/cache/bind/ root# ln -s /etc/bind/db.sol. root# ln -s /etc/bind/db.192.168.0.

Fedora, Red Hat



В Fedora и Red Hat скопируйте ddns.key в следующие каталоги:

root# cp ddns.key /var/named/ root# cp ddns.key /etc/dhcp/

В конфигурационном файле DHCP файл ключей указывается таким образом:

# в /etc/dhcp/dhcpd.conf include "/etc/dhcp/ddns.key";

В Fedora и Red Hat для файлов зон db.sol и db.192.168.0 символьные ссылки не требуются, но эти файлы нужно сохранить в специальном каталоге /var/named/ dynamic. Тогда изменения, которые потребуется внести в named.conf, будут выглядеть так:

# в /etc/named.conf

include "/var/named/ddns.key"; zone «sol» { type master; notify no;

file "/var/named/dynamic/db.sol"; allow-update { key «DHCP_UPDATER»: };}; zone «0.168.192.in-addr.arpa» { type master; notify no;

file "/var/narned/dynarnic/db.192.168.0": allow-update { key «DHCP_UPDATER»: };};

Serial

Refresh

Retry

Expire

Negative Cache TTL

SUSE



В SUSE и DHCP-сервер, и сервер имен работают в среде chroot. Поэтому файл ddns.key нужно скопировать в следующие каталоги:

root# cp ddns.key /var/lib/dhcp root# cp ddns.key /var/lib/named

Файл конфигурации DHCP не содержит данных о каталогах, а ссылается прямо на ddns.key:

# in /etc/dhcpd.conf include «ddns.key»;

Файлы зон db.sol и db.192.168.0 должны находиться в каталоге /var/lib/named/ dyn. Ссылки не нужны. Файл named.conf дополняется следующими строками:

# в конце /etc/named.conf include «ddns.key»;

zone «sol» { type master; notify no; file «dyn/db.sol»;

allow-update { key «DHCP_UPDATER»: };}; zone «0.168.192.in-addr.arpa» { type master; notify no;

file «dyn/db.192.168.0»;

allow-update { key «DHCP_UPDATER»: };};

Техническая поддержка



Практически с ходу named начинает работать как кэширующий сервер имен, не требуя никаких дополнительных изменений конфигурации. Это происходит благодаря наличию файла корневых серверов, который, в зависимости от дистрибутива, может называться db.root, named.ca или root.hint. В этом файле содержится список центральных DNS (так называемых корневых серверов), которые разбросаны по всему миру. Не исключено, что после установки отдельные записи из этого файла будут уже не актуальны, но как минимум часть адресов должна работать.

В любом случае вам потребуется регулярно обновлять этот файл. Для этого необходимо выполнить следующую команду. Она запрашивает корневой сервер А из актуального списка корневых серверов (если этот сервер сейчас недоступен, измените АнаВ, Сит. д.).

root# dig @A.ROOT-SERVERS.NET

; «» DIG 9.4.2-P2 «» 0A.ROOT-SERVERS.NET

;; QUESTION SECTION: ;. INNS

;; ANSWER SECTION:

. 518400 IN NS A.ROOT-SERVERS.NET.

518400 IN NS K.ROOT-SERVERS.NET. 518400 IN NS H.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:

A.ROOT-SERVERS.NET. 3600000 IN

A.ROOT-SERVERS.NET. 3600000 IN

B.ROOT-SERVERS.NET. 3600000 IN

A 198.41.0.4

AAAA 2001:503:ba3e::2:30

A 192.228.79.201

Если все сработает, просто переадресуйте вывод dig в файл /etc/bind/db.root (сначала создайте резервную копию!).

root# cd /etc/bind

root# cp db.root db.root.bak

root# dig @A.ROOT-SERVERS.NET > db.root

merkur (192.168.0.4)


Читайте так же:
Интеграция WLAN в сеть

Никакого спама, только обновления!!!

Комментарии (0)


    Услуги по MODX Revolution

    Посмотреть все услуги

    Техническая оптимизация сайта

    Подробнее & Заказать

    Создание сайта на MODX Revolution

    Подробнее & Заказать

    Перенос сайта на MODX Revolution

    Подробнее & Заказать

    Продвижение сайта на MODX

    Подробнее & Заказать