Мне просто было интересно узнать о различиях в поведении между операторами allow-query-on и listen-on в Bind 9. Похоже, что они выполняют аналогичные функции. Согласно главе 6 ARM («Конфигурация Bind 9»):
Интерфейсы и порты, с которых сервер будет отвечать на запросы, можно указать с помощью параметра прослушивания.
Приведенный синтаксис:
прослушивание [порт ip_port] [dscp ip_dscp] {address_match_list};
Также в той же главе:
allow-query-on: указывает, какие локальные адреса могут принимать обычные вопросы DNS.
Приведенный синтаксис:
разрешить запрос на {address_match_list};
Исходя из синтаксиса, похоже, что allow-query-on не позволяет указывать номера портов. Есть ли другие отличия?
На самом деле это не похожие функции. В listen-on заявление требуется для named для привязки к определенному IP-адресу и порту. Без настройки по умолчанию DNS-запросы прослушиваются на 53-м порту всех интерфейсов вашего сервера. Если у вас есть сервер с несколькими интерфейсами и вы хотите предоставлять службы DNS только на одном из них, используйте listen-on слушать только на одном интерфейсе. Попытка сделать это по-другому с allow-query-on только оставит BIND прослушивающим на всех интерфейсах. Лучше всего использовать оба, то есть привязать только к нужному интерфейсу (-ам), а затем дополнительно ограничить тип разрешенных вами запросов.
listen-on используется для указания комбинаций адресов / портов, которые named процесс должен bind(3).
То есть комбинации адреса / порта, для которых named сообщает операционной системе, что это процесс, который «слушает» и поэтому хочет получить все, что туда отправлено.
Нет понимания DNS на уровне API сокетов, поэтому здесь нет никаких средств для детального контроля. Вы либо слушаете, либо нет, и если вы это сделаете, то ничто другое не сможет прослушивать тот же адрес / порт (с последствиями для того, что еще может работать параллельно на одном и том же хосте).
allow-*-on (и, с противоположной точки зрения, обычный allow-* директивы) - это меры контроля доступа внутри BIND для различных типов сообщений DNS (разные категории запросов, обновлений, зональных передач и т. д.), которые он получил.
Поскольку это функциональность внутри BIND, он интерпретировал полученные данные DNS и позволяет гораздо более детализированный контроль доступа (но он должен был где-то прослушивать, чтобы получать сообщения в первую очередь).
В настоящее время я изучаю BIND и думаю о том же самом. Я думаю, что ответ заключается в утверждениях, которые вы не упомянули, т.е. также существует allow-query-cache-on и allow-recursion-on заявления. Вместе они могут использоваться для более детальной настройки BIND, чем listen-on заявление может.
Кроме того, что касается allow-query-on, в документации говорится:
Это позволяет, например, разрешать запросы к внутренним интерфейсам (...) без обязательного знания адресов внутренней сети.
Я считаю, что это ответ, почему существуют эти утверждения.
Например,
options {
allow-query-on { 203.0.113.17; };
allow-recursion-on { 10.0.0.17; };
allow-query-cache-on { 10.0.0.17; };
};
было бы похоже на
acl corpnets {
10.0.0.0/16;
172.16.0.0/12;
};
options {
allow-query { any; };
allow-recursion { corpnets; };
allow-query-cache { corpnets; };
};
Но во втором примере вам нужно поддерживать ACL в актуальном состоянии.
И в качестве последнего замечания, я считаю, что они нужны только в некоторых угловых случаях, как и многие варианты BIND.