Bind: порядок и предпочтение к выдачи информации

В статье будет рассмотрено 2 малоописанные опции rrset-order и sortlist. Первая отвечает за порядок выдачи информации (в каком порядке выдавать адреса), а вторая — за то, кому в каком порядке выдавать.

Тестовый стенд: FreeBSD 8.1 i386, bind-9.7.4

1) Подготовка.

Для того, что бы использовать параметр fixed в rrset  — нужно пересобирать сам пакет, причём вручную, ибо в самом порту нету такой опции для сборки. Иначе можете получить сообщение

option 'rrset-order' is not implemented

И так, делаем следующее:

#cd /usr/port/dns/bind97 && make extract && cd work/bind-9.7.4  && grep enable-fixed-rrset configure
--enable-fixed-rrset enable fixed rrset ordering
# Check whether --enable-fixed-rrset was given.

Если вы видите такое, значит опция присутствует и можно переходить к сборке:

#cd ../../

открываем файл Makefile и после строки

IPV6 "IPv6 Support (autodetected by default)" off \

вставляем такую

RRSET "Enable Mutli records set" on \

после блока

.if defined(WITH_IPV6)
CONFIGURE_ARGS+= --enable-ipv6
.endif

вставляем такой

.if defined(WITH_RRSET)
CONFIGURE_ARGS+= --enable-fixed-rrset
.endif

После внесения всех измнений, собираем порт:

#cd /usr/ports/dns/bind97 && make install clean

После сборки проверим, собран ли bind с поддержкой rrset:

# named -V
BIND 9.7.4 built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' '--disable-openssl-version-check' '--without-openssl' '--without-libxml2' '--without-idn' '--enable-fixed-rrset' '--enable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd8.1' 'build_alias=i386-portbld-freebsd8.1' 'CC=cc' 'CFLAGS=-O2 -pipe -fno-strict-aliasing' 'LDFLAGS= -rpath=/usr/lib:/usr/local/lib' 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -fno-strict-aliasing'

Теперь переходим к конфигурированию. Что бы в логах не появлялось собщение

max open files (3520) is smaller than max sockets (4096)

Увеличим данные лимиты:

#sysctl -w kern.maxfiles=12328
#sysctl -w kern.maxfilesperproc=11095
#sysctl -w kern.ipc.maxsockets=12328

Не забудьте внести эти изменения в файл /etc/sysctl.conf.

2) rrset

Для использования rrset, открываем файл named.conf и в раздел options {…} вносим такую строку:

rrset-order { order fixed; };

Теперь в файле с зоной прописываем такое:

www IN A 10.11.11.11
    IN A 10.22.22.22

После этого запросы будут выдаваться строго в таком порядке:

# nslookup www.aaa.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: www.aaa.com
Address: 10.11.11.11
Name: www.aaa.com
Address: 10.22.22.22

Вообще полный формат опции rrset выглядит так:

rrset-order { order_spec ; [ order_spec ; ... ]

Полная спецификация order_spec выглядит так:

class class_name ][ type type_name ][ name "domain_name"] order ordering;

где  ‘class_name’ — тип записи (IN, MX, …); ‘domain_name’ — ограничивается выражением доменного суффикса, ‘order’ — может принимать одно из значений

  • fixed — записи возвращаются в том порядке, в котором описаны в зонах
  • random — записи возвращаются в случайном порядке
  • cyclic — записи возвращаются в циклическом (round-robin) порядке.

Примечание.

По причинам известных только ISC значение fixed доступно (начиная с версии 9.6+) теперь только через параметр —with-fixed-rrset. Ни BSD, ни Debian не используют эту опцию в стандартной поставке. Некоторые RPM дистрибутивы (Fedora и другие) используют эту опцию, но нужна проверка (используйте named -V). Для практических целей доступны только опции cyclic и random.

Примеры использования

1. Пример случайно выдачи записей

rrset-order {order random;};

2. Пример выдачи всех MX записей домена example.com в случайном виде, всех остальных записей — в циклическом

rrset-order {type MX name "example.com" order random; order cyclic};

3) sortlist

Инструкция sortlist в версиях BIND 4.9 и более поздних принудительно задает порядок адресов в отклике, например для запросов из локальной сети на первое место в отклике будут ставиться адреса из локальной сети, если они существуют.

Такая ситуация может возникнуть, например, при обращении к удаленному ресурсу, чье зеркало находится в локальном сегменте сети.

Конструкция выглядит так:

sortlist { address_match_list; ... };

К примеру, следующая запись

sortlist {
{ 144.206.192/24; { 11.11.11.0/24; 22.22.22.0/24;};};
{ 144.206.160/24; { 33.33.33.0/24; 44.44.44.0/24;};};
};

говорит о том, что если запрос пришёл из сети 144.206.192/24, то в первую очередь выдавать запросы DNS‘ов из сети 11.11.11.0/24, потом из сети — 22.22.22.0/24. Для сети 144.206.160/24 — аналогично.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *