Поиск по сайту:

Как настроить Bind в качестве кэширующего или пересылающего DNS-сервера в Ubuntu 14.04

Введение

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

В этом руководстве мы обсудим, как установить и настроить DNS-сервер Bind9 в качестве кэширующего или пересылающего DNS-сервера на компьютерах с Ubuntu 14.04. Обе эти конфигурации имеют преимущества при обслуживании сетей машин.

Предпосылки и цели

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

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

Чтобы продолжить, вам потребуется доступ к двум компьютерам (по крайней мере, один из которых должен быть сервером Ubuntu 14.04). Один будет работать как клиент, а другой будет настроен как DNS-сервер. Детали нашего примера конфигурации:

Role IP Address
DNS Server 192.0.2.1
Client 192.0.2.100

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

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

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

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

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

Переадресация DNS-сервера

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

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

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

Установите Bind на DNS-сервере

Независимо от того, какой вариант конфигурации вы хотите использовать, первым шагом в реализации Bind DNS-сервера является установка фактического программного обеспечения.

Программное обеспечение Bind доступно в репозиториях Ubuntu по умолчанию, поэтому нам просто нужно обновить наш локальный индекс пакетов и установить программное обеспечение с помощью apt. Мы также включим документацию и некоторые общие утилиты:

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

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

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

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

Файлы конфигурации Bind по умолчанию хранятся в каталоге /etc/bind. Перейдите в этот каталог сейчас:

cd /etc/bind

Мы не собираемся заниматься большинством файлов в этом каталоге. Основной файл конфигурации называется named.conf (named и bind — это два названия одного и того же приложения). Этот файл просто является источником файла named.conf.options, файла named.conf.local и named.conf.default-zones. файл.

Для кэширующего DNS-сервера мы будем изменять только файл named.conf.options. Откройте это в текстовом редакторе с правами sudo:

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 — это один из способов, которым злоумышленники пытаются вывести из строя серверы или сайты в Интернете. Для этого они пытаются найти общедоступные DNS-серверы, которые будут разрешать рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который возвращает большой ответ на DNS-сервер. При этом DNS-сервер отвечает на небольшой запрос большой полезной нагрузкой, направленной на сервер жертвы, эффективно увеличивая доступную пропускную способность злоумышленника.

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

Над блоком options мы создадим новый блок с именем acl. Создайте метку для группы ACL, которую вы настраиваете. В этом руководстве мы будем называть группу goodclients.

acl goodclients {
};

options {
    . . .

В этом блоке перечислите 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; };
    . . .

Мы явно включили рекурсию, а затем настроили параметр allow-query для использования нашей спецификации ACL. Мы могли бы использовать другой параметр, например allow-recursion, для ссылки на нашу группу ACL. Если присутствует и рекурсия включена, allow-recursion определяет список клиентов, которые могут использовать рекурсивные службы.

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

Когда вы закончите вносить эти изменения, сохраните и закройте файл.

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

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

Настройка в качестве пересылающего 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):

. . .
options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

После этого мы должны установить для директивы forward значение «только», поскольку этот сервер будет пересылать все запросы и не должен пытаться разрешать запросы самостоятельно.

Когда вы закончите, файл конфигурации будет выглядеть так:

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-сервер. Перейдите к следующему разделу, чтобы проверить файлы конфигурации и перезапустить демон.

Проверьте свою конфигурацию и перезапустите привязку

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

Прежде чем мы совершим решительный шаг и перезапустим сервер Bind в нашей системе, мы должны использовать встроенные инструменты Bind для проверки синтаксиса наших файлов конфигурации.

Мы можем сделать это легко, набрав:

sudo named-checkconf

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

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

Убедившись, что в файлах конфигурации нет синтаксических ошибок, перезапустите демон Bind, чтобы изменения вступили в силу:

sudo service bind9 restart

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

sudo tail -f /var/log/syslog

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

Настройте клиентский компьютер

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

Войдите в свою клиентскую машину. Убедитесь, что используемый вами клиент был указан в группе 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-сервера.

Мы можем получить более подробную информацию, используя специальные инструменты DNS, такие как dig. На этот раз попробуйте другой домен:

dig linuxfoundation.org

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6017	IN	A	140.211.169.4

;; Query time: 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<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6012	IN	A	140.211.169.4

;; Query time: 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) с опцией -x программы dig:

dig -x 140.211.169.4

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN	CNAME	4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN	PTR	load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

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

Вернувшись на свой 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.

Для этого откройте файл /etc/default/bind9 с правами sudo:

sudo nano /etc/default/bind9

Внутри измените параметр OPTIONS, чтобы включить флаг -4, чтобы заставить работать только IPv4:

OPTIONS="-u bind -4"

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

Перезапустите сервер:

sudo service bind9 restart

Вы больше не должны видеть эти ошибки в журналах.

Сделать настройки DNS клиента постоянными

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

Если на клиентском компьютере работает Debian или Ubuntu, откройте файл /etc/network/interfaces с правами sudo:

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-серверы в качестве запасного варианта, удалите другие записи:

DNS1=192.0.2.1

Сохраните и закройте файл, когда закончите. Ваш клиент должен использовать эти настройки при следующей загрузке.

Заключение

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

Если вы хотите создать DNS-сервер, который является авторитетным для ваших собственных доменных зон, вы можете настроить только авторитетный DNS-сервер или объединить эти решения.