Перейти к содержанию

Сетевые средства 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 могут оказаться полезными следующие две опции.

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

Примечания

[править]
  1. Y. Rekhter; B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear (February 1996) Address Allocation for Private Internets
  2. S. Cheshire; B. Aboba, E. Guttman (May 2005) Dynamic Configuration of IPv4 Link-Local Addresses
  3. https://dlv.isc.org/

См. также

[править]