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

Вступление

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

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

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

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

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

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

Role	Айпи адрес
DNS-сервер	192.0.2.1
клиент	192.0.2.100

Role

Айпи адрес

DNS-сервер

192.0.2.1

клиент

192.0.2.100

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

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

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

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

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

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

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

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

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

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

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

Программное обеспечение 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 amplification attack особенно неприятна, потому что она может заставить ваш сервер участвовать в распределенных атаках отказа в обслуживании.

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

Для этого мы делаемnot заменой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

Теперь, когда у вас есть сервер 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-сервер, который является полномочным для ваших собственных доменных зон, вы можете настроитьauthoritative-only DNS server или объединить эти решения.

TOC