Сортировка адресов
Если имеется множество адреса, доступных для сервера имен, с которыми захочет контактировать BIND, BIND сначала будет пробовать те, которые он считает "самыми близкими". "Близость" определяется в терминах похожести по адресу; то-есть если один из адресов находится в той же самой подсети что и некоторый интерфейс хоста, то первым будет опробован этот адрес. Если это не получится, то затембудет попробован адрес, находящийся в той же сети. Если и это провалится, и если в файле named.boot не была задана директива sortlist, то адреса будут опробованы в более или менее произвольном порядке. Директива sortlist имеет синтаксис, подобный forwarders, xfrnets, и bogusns - вы задаете ему список сетей в виде xxx.xxx.xxx.xxx, и он использует их при "предпочтении" одних серверов имен перед другими. Если никакая явная маска не обеспечивается каждым элементом sortlist , то будет сделан вывод основанный на битах адреса старшего разряда.
Если вы находитесь в сети класса C, имеющей сеть класса B вами и остальным Internet, вы могли бы попробовать увеличить удачу сервера имен в получении ответов, перечислив сеть класса B в директиве sortlist. Это должно иметь эффект при опробовании "ближайших" серверов перед более "удаленными". Обратите внимание, что это поведение является новым, и появилось начиная с, BIND 4.9.
Другой и более старый эффект директивы sortlist должен заставить, BIND сортировать записи типа A в любом генерируемом ответе, чтобы поместить те, которые имеются в sortlist перед остальными. Это не настолько полезно, как вы могли бы подумать, так как многие клиенты будут пересортировывать записи типа A в произвольном порядке или используя "магазинный порядок" (LIFO); также учтите то, что сервер будет способен догадаться о топологии сети клиента, и таким образом не будет способен точно упорядочить "близость" ко всем возможным клиентам. Выполнение упорядочения в разрешителе ясно выше.
В реальной практике, эта директива используется очень редко, так как это жестко привязывает быстро меняющуюся информацию; сеть, которая "близка" сегодня, может быть "отдалена" уже в следующем месяце. Так как BIND создает кэш времен ответа удаленных серверов имен, то он будет быстро сходиться на "приемлемом" поведении, которое не означает "оптимальное", но почти то же самое. Будущие направления развития BIND, включают выбор адресов, основываясь на метриках локальных интерфейсов (хостах, имеющих больше чем один интерфейс) и, возможно, на информации из таблицы маршрутизации. Мы не собираемся решать обобщенную проблему "multihomed" хостов, но мы должны быть способны сделать что-то получше чем то,что мы имеем сейчас. Аналогично, мы надеемся увидеть библиотеку разрешителя на более высоком уровне, сортирующую ответы на основе информации о топологии, существующей только на клиентском хосте.
