Как настроить кэширующий сервер dns

Это первый шаг в настройке DNS, очень полезный для dialup пользователей

Кеширующий сервер найдет ответ на запрос об имени машины и запомнит его, чтобы ответить, когда вы запросите эту же информацию в следующий раз. Это значительно уменьшит время ожидания ответа при следующем запросе, особенно если у вас медленное соединение.

Для начала вам нужен файл, названный /etc/named.conf . Из него named читает информацию при старте. Сейчас он должен просто содержать следующие строки:

Строка ` directory ‘ задает где искать файлы. Все файлы используемые впоследствии, будут именоваться относительно этой директории. Таким образом pz — это директория в директории /var/named , т.е., /var/named/pz . /var/named — это правильная директория согласно Linux File system Standard (Стандарту файловой системы Linux) .

Файл названный /var/named/root.hints должен находится в указанной директории. Он должен содержать следующую информацию:

Этот файл описывает имена корневых серверов имен по всему миру. Их список изменяется время от времени и эта часть в дальнейшем должна сопровождаться. Смотрите раздел по сопровождению для того, чтобы узнать как хранить эту информацию соответствующей действительности.

Следующий раздел в named.conf — это последняя зона . Я объясню как она используется в следующих разделах, сейчас просто создайте файл, названный 127.0.0 в поддиректории pz :

Далее вам необходимо, чтобы ваш файл /etc/resolv.conf выглядел примерно так:

Строка ` search ‘ задает в каких доменах должен идти поиск машин с кокторыми вы хотите соединиться. Строка ` nameserver ‘ указывает адрес вашего сервера имен, в нашем случае это ваша собственная машина, поскольку на ней запущен named (127.0.0.1 это правильный адрес, также никаких проблем, если ваша машина имеет другой адрес). Если вы хотите перечислите несколько серверов имен, то поместите их по одному в строку со словом ` nameserver ‘ для каждого. (Замечание: Named никогда не читает этот файл, это делает программа resolver, которая использует named).

Проиллюстрируем как это работает: Если клиент пытается найти машину с именем foo , то сначала программа пытается найти машину с полным именем foo.subdomain.your-domain.edu , затем с именем foo.your-fomain.edu , и в конце концов foo . Если клиент пытается найти sunsite.unc.edu , то сначала пробуется sunsite.unc.edu.subdomain.your-domain.edu (да это глупо, но вот так это работает), затем sunsite.unc.edu.your-domain.edu , и в конце концов sunsite.unc.edu . Вы можете не помещать слишком много доменов в строку поиска, поскольку поиск в них займет слишком много времени.

Пример предполагает, что вы находитесь в домене subdomain.your-domain.edu , и ваша машина вероятно называется your-machine.subdomain.your-domain.edu . Строка поиска не должна содержать ваш TLD (Top Level Domain (Домен Верхнего Уровня), ` edu ‘ в нашем случае). Если вам необходимо часто соединяться с машиной в другом домене, то вы можете добавить этот домен в строку поиска, примерно вот так:

и так далее. Очевидно, что вам необходимо поместить в эту строку имена настоящих доменов, вместо вышеприведенных. Пожалуйста заметьте отсутствие точки в конце имени домена. Это важно, пожалуйста заметьте отсутствие точки в конце имени доменов.

Далее в зависимости от вашей версии libc вам необходимо вносить исправления либо в файл /etc/nsswitch.conf , либо в файл /etc/host.conf . Если у вас уже есть файл nsswitch.conf , то значит мы будем вносить исправления в него, если же его нет, то мы будем вносить изменения в файл host.conf .

Это длинный файл описывающий как получить разные типы данных, из какого файла или базы данных. В начале он обычно содержит полезные комментарии, которые вы должны учесть при чтении этого файла. После того, как вы найдете строку начинающуюся с ` hosts: ‘, вы должны увидеть: Если в этом файле нет строки начинающейся с ` hosts: ‘, то поместите вышеприведенную строку в файл. Эта строка указывает программам сначала выполнять поиск в файле /etc/hosts , а затем просматривать DNS в соответствии с порядком указанном в файле resolv.conf .

Этот файл вероятно содержит разные данные, одна из строк должна начинаться со слова order и выглядеть примерно так:

Если строки с ` order ‘ нет, то вы должны ее добавить. Она заставляет подпрограмму разрешения имен сначала посмотреть в файле /etc/hosts , а затем сделать запрос к серверу имен (который в resolv.conf указан как машина с адресом 127.0.0.1).

После этих приготовлений пришло время запуска named. Если вы используете dialup соединение, то сначала производите подключение. Наберите ` ndc start ‘ без опций, и нажмите клавишу return. Если это не работает, то попробуйте следующую команду ` /usr/sbin/ndc start ‘. Если опять попытка не удалась, то смотрите раздел Вопросы и ответы. Если вы посмотрите в файл сообщений syslog (обычно названный /var/adm/messages , но может быть другая директория /var/log и другой файл syslog в которые необходимо посмотреть) во время запуска named (выполните команду tail -f /var/log/messages ), то вы должны увидеть что-то подобное следующему:

(строки заканчивающиеся на \ продолжаются на следующей строке)

Если есть какие-нибудь сообщения об ошибках, то значит вы что-то сделали неправильно. Named укажет в каком файле ошибка (я надеюсь, что это один из файлов named.conf и root.hints :-). Завершите выполнение named и проверьте файлы конфигурации.

Теперь вы можете протестировать ваше настройку. Запустите nslookup для проверки вашей работы.

Если это выглядит так, то значит вы заставили систему работать. Мы так надеемся. Если что-то другое, то вернитесь назад и все проверьте. Каждый раз когда вы изменяете файл named.conf , вам необходимо перезапустить named, используя команду ndc restart .

Теперь мы можем ввести запрос на поиск информации. Попробуйте найти машину близкую к вам. pat.uio.no находится близко от меня, в Университете Осло:

Сейчас nslookup попросит ваш named посмотреть информацию о машине pat.uio.no . Затем он соединится с одним из серверов имен, перечисленных в вашем файле root.hints , и запросит у него путь к данной машине. Это может занять какое-то время, до того как вы получите результаты, поскольку система может понадобится попробовать найти заданную машину во всех доменах, перечисленных в вашем файле /etc/resolv.conf .

Если вы запросите то же самое, то вы получите такой ответ:

Заметим, что мы в это раз получили сообщение ` Non-authoritative answer: ‘. Это означает, что named в этот раз не делал запрос к внешним серверам имен, информация находиться в кеше. Но кешированная информация может быть устаревшей. Так что он вас информируют об этой (весьма незначительной) опасности сообщением ` Non-authorative answer: ‘. nslookup выдает это сообщение, когда вы второй раз запрашиваете об одной и той же машине — это знак того, что named кеширует информацию и это значит, что он работает правильно. Вы можете завершить работу nslookup дав команду ` exit ‘.

В больших, хорошо организованных академических сетях или сетях ISP (Internet Service Provider) вы иногда сможете обнаружить, что администраторы сети настроили иерархию серверов DNS, которые помогут облегчить загрузку внутренней сети, также загрузку внешних серверов. Не так легко узнать находитесь ли вы внутри такой сети или нет. Однако это не совсем важно, и используя DNS-сервер вашего сетевого провайдера как «forwarder» вы можете сделать ответы на запросы быстрее и уменьшить загрузку вашей сети. Если вы используете модем, то это может быть большой победой. Для пользы этого примера мы предполагаем, что ваш сетевой провайдер имеет два сервера имен, который вы можете использовать, с сетевыми номерами 10.0.0.1 и 10.1.0.1 . Затем в вашем файле named.conf , внутри открывающего раздела под названием «options» вставьте следующие строки:

Перезапустите ваш сервер имен и протестируйте его используя nslookup. Все должно работать отлично.

Теперь вы знаете как установить кеширующий сервер имен. Возьмите пива, молока или того, что вы предпочитаете и отпразднуйте это. Next Previous Contents

Источник

Настройка Bind как кэширующего или перенаправляющего DNS-сервера в Ubuntu 14.04

DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.

В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.

Требования

Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в этой статье.
Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).

Вы научитесь настраивать клиентскую машину для отправки запросов через DNS-сервер.

Кэширующий DNS-сервер

Серверы этого типа также называются определителями, поскольку они обрабатывают рекурсивные запросы и, как правило, могут выполнить поиск данных DNS не других серверах.

Когда кэширующий DNS-сервер отслеживает ответ на запрос клиента, он возвращает ответ клиенту, а также сохраняет его в кэше в течение периода времени, разрешенного значением TTL соответствующих DNS-записей. Затем кэш можно использовать в качестве источника ответов на последующие запросы, чтобы ускорить общее время обработки запроса.

Почти все DNS-серверы в вашей сетевой конфигурации будут кэширующими. Кэширующий DNS-сервер – хороший выбор для многих ситуаций. Если вы не хотите полагаться на DNS-серверы вашего хостинг-провайдера или другие общедоступные DNS-серверы, настройте собственный кэширующий DNS-сервер. Чем меньше расстояние от DNS-сервера к клиентским машинам, тем меньше время обслуживания запросов DNS.

Перенаправляющий DNS-сервер

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

Перенаправляющий DNS-сервер имеет те же преимущества, что и кэширующий сервер. Однако на самом деле он не выполняет ни одного рекурсивного запроса. Вместо этого он перенаправляет все запросы на внешний разрешающий сервер, а затем кэширует результаты для последующих запросов.

Это позволяет перенаправляющему серверу обслуживать запросы из своего кэша, не обрабатывая при этом рекурсивных запросов. Таким образом, этот сервер обрабатывает только одиночные запросы (перенаправленные запросы клиента), а не всю процедуру рекурсии. Это может быть преимуществом в средах с ограниченной внешней пропускной способностью, в которых необходимо часто менять кэширующие серверы, и в ситуациях, когда нужно перенаправить локальные запросы на один сервер, а внешние – на другой.

1: Установка Bind на DNS-сервер

Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

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

2: Настройка кэширующего DNS-сервера

Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.

Конфигурационные файлы Bind хранятся в каталоге /etc/bind.

Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.

Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.

sudo nano named.conf.options

Этот файл выглядит так (комментарии опущены для простоты):

options <
directory «/var/cache/bind»;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.

Нужно защитить DNS-сервер, обрабатывающий рекурсивные запросы, от злоумышленников. Атаки DNS-усиления особенно опасны, поскольку могут вовлечь сервер в распределенные атаки на отказ в обслуживании.

Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.

Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.

Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).

В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
. . .

Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:

options <
directory «/var/cache/bind»;
recursion yes;

allow-query < goodclients; >;
. . .

Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.

Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.

Сохраните и закройте файл.

Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.

Примечание: Если вы хотите использовать только этот тип DNS, переходите к проверке конфигураций, перезапустите сервис и настройте свой клиент.

3: Настройка перенаправляющего DNS-сервера

Если вашей инфраструктуре больше подходит перенаправляющий DNS-сервер, вы можете немного откорректировать настройку.

На данный момент файл named.conf.options выглядит так:

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.

Не меняйте значение recursion на no. Перенаправляющий сервер все-таки поддерживает рекурсивные сервисы. Чтобы настроить перенаправляющий сервер, нужно создать список кэширующих серверов, на которые он будет перенаправлять запросы.

Это делается в блоке options <>. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):

Далее нужно в директиве forward установить значение only, поскольку сервер должен только перенаправлять все запросы и не пытаться разрешить их самостоятельно.

В результате конфигурация выглядит так:

acl goodclients <
192.0.2.0/24;
localhost;
localnets;
>;
options <
directory «/var/cache/bind»;
recursion yes;
allow-query < goodclients; >;
forwarders <
8.8.8.8;
8.8.4.4;
>;
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 < any; >;
>;

Последнее изменение касается параметра dnssec. При текущей конфигурации и в зависимости от настройки DNS-серверов, на которые перенаправляются запросы, в логах могут появиться такие ошибки:

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving ‘in-addr.arpa/DS/IN’: 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving ‘111.111.111.111.in-addr.arpa/PTR/IN’: 8.8.4.4#53

Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.

4: Проверка настроек и перезапуск Bind

Теперь нужно убедиться, что настройки работают должным образом.

Чтобы проверить синтаксис конфигурационных файлов, введите:

Если в файлах нет ошибок, командная строка не отобразит никакого вывода.

Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.

После этого можно перезапустить демон Bind, чтобы обновить настройки.

sudo service bind9 restart

После нужно проверить логи сервера. Запустите на сервер команду:

sudo tail -f /var/log/syslog

Теперь откройте новый терминал и приступайте к настройке клиентской машины.

5: Настройка клиента

Войдите на клиентскую машину. Убедитесь, что клиент был указан в группе ACL настроенного DNS-сервера. В противном случае DNS-сервер откажется обслуживать запросы этого клиента.

Отредактируйте файл /etc/resolv.conf, чтобы направить сервер на сервер имен.

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

Откройте файл с помощью sudo в текстовом редакторе:

sudo nano /etc/resolv.conf

В файле нужно перечислить DNS-серверы, которые будут использоваться для разрешения запросов. Для этого используйте директиву nameserver. Закомментируйте все текущие записи и добавьте строку nameserver, указывающую на ваш DNS-сервер:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Сохраните и закройте файл.

Теперь можно отправить тестовый запрос, чтобы убедиться, что он разрешается правильно.

Для этого можно использовать ping:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
— google.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Это значит, что клиент может подключиться к google.com с помощью DNS-сервера.

Более подробную информацию предоставит инструмент dig. Попробуйте подключиться к другому домену:

dig linuxfoundation.org
; > DiG 9.9.5-3-Ubuntu > linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE rcvd: 64

Как видите, обработка запроса заняла 36 миллисекунд. Повторите запрос. Сервер должен извлечь данные из кэша, что укорит обработку запроса:

dig linuxfoundation.org
; > DiG 9.9.5-3-Ubuntu > linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE rcvd: 64

Теперь запрос обрабатывается гораздо быстрее.

Также можно протестировать обратное преобразование. Для этого используйте найденный IP (в данном случае 140.211.169.4) и dig с флагом –x:

dig -x 140.211.169.4
; > DiG 9.9.5-3-Ubuntu > -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER

Как видите, обратное преобразование выполнено успешно.

Вернитесь на DNS-сервер. Если во время настройки клиента возникли какие-либо ошибки, вы увидите их. К примеру, часто случается такая ошибка:

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving ‘ns4.apnic.net/A/IN’: 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving ‘ns4.apnic.com/A/IN’: 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving ‘sns-pb.isc.org/AAAA/IN’: 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving ‘ns3.nic.fr/A/IN’: 2a00:d78:0:102:193:176:144:22#53

Это значит, что сервер пытается разрешить данные IPv6, но он не настроен для поддержки IPv6. Чтобы устранить ошибку, нужно настроить Bind для обслуживания только IPv4.

sudo nano /etc/default/bind9

Найдите параметр OPTIONS и добавьте в него флаг -4, чтобы настроить поддержку только IPv4.

OPTIONS=»-u bind -4 «

Сохраните и закройте файл.

sudo service bind9 restart

После этого в логах не должно быть ошибок.

Сохранение настроек клиента DNS

Параметры файла /etc/resolv.conf сбрасываются после перезапуска. Чтобы эти настройки использовались на постоянной основе, нужно отредактировать файлы, которые обращаются к этому файлу.

Откройте этот файл:

sudo nano /etc/network/interfaces

Найдите параметр dns-nameservers. Удалите текущую запись и замените ее данными о вашем DNS-сервере или просто добавьте новый DNS-сервер в качестве одного из значений.

. . .
iface eth0 inet static
address 111.111.111.111
netmask 255.255.255.0
gateway 111.111.0.1
dns-nameservers 192.0.2.1
. . .

Сохраните и закройте файл.

В системах CentOS и Fedora для этого нужно открыть файл /etc/sysconfig/network/network-scripts/ifcfg-eth0:

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

В нем найдите строки, которые начинаются с DNS. Среди них будет строка DNS1, в ней нужно указать ваш DNS-сервер. Если вы не хотите пользоваться другими DNS-серверами, удалите остальные записи.

Сохраните и закройте файл.

Заключение

Теперь вы умеете настраивать кэширующий и перенаправляющий DNS-сервер. Это поможет вам ускорить обработку DNS-запросов.

Источник

Как настроить кэширующий сервер dns

Кэширующий DNS сервер на BIND.

Настройка зоны.