Сетевые средства Debian/BIND/Рекурсивное разрешение имен

Рекурсивное разрешение имен обычно используется на DNS-серверах, обслуживающих локальную сеть, сети предприятия, или сети абонентов поставщика услуг доступа к Internet. Именно DNS-сервер, выполняющий рекурсивное разрешение имен, указывается опцией nameserver файла resolv.conf(5), и нередко известен как просто «DNS-сервер».

Переадресация запросов

Возможны два основных режима работы BIND при обработке рекурсивных запросов:

переадресация запроса вышестоящему рекурсивному DNS-серверу;
рекурсивная обработка запроса.

Для выбора первого режима, в блок options файла /etc/bind/named.conf.options вносится опция forwarders, подобно:

options {
    /* . . . */
    forwarders {
        2001:db8:1337::53:53;
        192.0.2.53;
    };
    /* . . . */
}

Кроме того, опция forward only; запретит рекурсивную обработку запроса. По-умолчанию (при непустом списке forwarders) полагается forward first; — выполнение рекурсивной обработки, если обращение к вышестоящему серверу не дало результата. Опция forward игнорируется, если список forwarders — пуст.

Обратные зоны для локальных адресов

Немаршрутизируемым в Internet диапазонам адресов IPv4 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16^[1]; 169.254.0.0/16^[2]) соответствует ряд обратных зон DNS, таких как 10.in-addr.arpa или 22.172.in-addr.arpa. Поскольку такие адреса не маршрутизируются в Internet и, в общем случае, не уникальны, предполагается, что каждая из сетей, использующих такие адреса, будет обслуживать и DNS-запросы к соответствующим обратным зонам.

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

include "/etc/bind/zones.rfc1918";

В противном случае, запросы, выполняемые программным обеспечением (включая: некоторые сервера, запускаемое в средах виртуализации программное обеспечение, а также ping(8) и traceroute(8) — в отсутствие опции -n) могут направляться вышестоящим серверам (при использовании списка forwarders) или же серверам, отвечающим за эти зоны (в частности, — серверам AS112), создавая нежелательную нагрузку на сеть.

Ограничение доступа

Поскольку адрес источника IP-пакета сравнительно несложно подделать в случае традиционно используемого для DNS транспортного протокола UDP (и, следовательно, использовать для организации DoS-атаки), имеет смысл ограничить доступ к функции рекурсивного разрешения имен опцией allow-recursion, подобно:

options {
    /* . . . */
    allow-recursion {
        ::1;  127.0.0.0/8;  /* разрешить localhost */
        2001:db8:1337:cafe::/64;
        192.0.2.128/25;
    };
    /* . . . */
}

Впрочем, при использовании в рамках локальной сети (а не, например, на маршрутизаторе), такая настройка скорее всего окажется избыточной, поскольку в качестве умолчания для allow-recursion будет взято значение опции allow-query-cache, allow-query, или же, если ни одна из них не определена (что является умолчанием для Debian), — значение localnets; localhost; — «только локальные сети.»

DNSSEC

В отношении DNSSEC могут оказаться полезными следующие две опции.

options {
    /* . . . */
    dnssec-lookaside  auto;
    dnssec-must-be-secure "example.org" yes;
    /* . . . */
}

Опция dnssec-lookaside auto; разрешит использование «стороннего» корня DNSSEC dlv.isc.org в дополнение к основному для удостоверения открытых ключей (англ. DNSSEC Lookaside Validation.) Поскольку не все организации, предоставляющие услуги регистрации DNS-доменов, в настоящее время поддерживают DNSSEC, использование такого дополнительного корня может быть единственной возможностью для операторов зоны заверить ее открытые ключи. ^[3]

Опция dnssec-must-be-secure потребует, чтобы ответ, полученный от вышестоящего или отвечающего за зону сервера, был заверен проходящей проверку цифровой подписью.

Примечания

↑ Y. Rekhter; B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear (February 1996) Address Allocation for Private Internets
↑ S. Cheshire; B. Aboba, E. Guttman (May 2005) Dynamic Configuration of IPv4 Link-Local Addresses
↑ https://dlv.isc.org/

См. также

[rfc1918-1] Y. Rekhter; B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear (February 1996) Address Allocation for Private Internets

[rfc3927-2] S. Cheshire; B. Aboba, E. Guttman (May 2005) Dynamic Configuration of IPv4 Link-Local Addresses

[3] ttps://dlv.isc.org/

[1]

[2]

[3]