Forward first | only
Введение | |
Рекомендации | |
Техническая оценка | |
forward first | |
forward only | |
Похожие статьи |
Введение
На примере bind
Когда сервер настроен на работу в перенаправляющем режиме forward может принимать одно из двух значени
first и only
Рекомендация TN DNS
Разрешение полных имен, как внутренних, так и для Интернета, полностью поддерживается внутренней инфраструктурой DNS HSCN. Поэтому вперед первым идти не нужно. Во всех случаях серверы кэширования DNS будут отвечать не только внутренними nhs.uk DNS-имена, но также имена из Интернета (внешний DNS).
Цель инфраструктуры состоит в том, чтобы обеспечить ту общую точку, где любой DNS-сервер в HSCN может разрешать любые и все DNS-запросы. Поэтому нет необходимости сначала реализовывать пересылку на центральном DNS-сервере.
Техническая оценка
В некоторых случаях единственным приемлемым вариантом может быть только переадресация. В тех случаях, когда брандмауэры или другие средства контроля доступа не позволяют DNS - серверу связываться и взаимодействовать с любым другим сервером, кроме тех, для которых они настроены, выбор прост-он должен быть только для пересылки (так как запросы на прямой контакт с корневыми серверами имен будут отключены).
Даже если имеется открытый доступ к корневым серверам имен (что также требует открытого доступа для связи с любым DNS-сервером, к которому может привести делегирование и ссылки, с использованием итеративного разрешения имен), политика или мандат группы или местоположения все равно могут диктовать только пересылку.
Несмотря на эту рекомендацию, нет 100% правильного или неправильного ответа. Каждый подход имеет свои преимущества и недостатки.
forward first и forward only являются техническими оценками опций, предоставленными для получения дополнительной информации, при условии, что сервер может быть настроен и работать должным образом с любой настройкой.
forward first
Это дает наибольший контроль самому серверу. Это позволяет серверу разрешать имена из Интернета (или с корневых серверов имен, как определено в корневых подсказках) без необходимости полагаться или знать, что перенаправляемые серверы имеют такой доступ. Серверы, на которые перенаправляются, понадобятся только для предоставления ответов на:
Запросы, которые не относятся к доменам, для которых DNS-сервер пересылки является полномочным.
Определенные домены, которые недоступны в Интернете.
Запросы для доменов, которые доступны как в Интернете, так и внутри компании, но на которые невозможно ответить на конкретный запрос с DNS-серверов в Интернете. Затем сам сервер может запросить Интернет или, в качестве альтернативы, сеть, охватываемую корневым сервером имен, определенным в "корневых подсказках", часто называемым "Внутренним корнем".
Еще одно преимущество конфигурации "вперед сначала" заключается в том, что сервер, выполняющий пересылку, если он действительно выходит в Интернет, будет кэшировать не только ответы, которые возвращаются, но и любую информацию, полученную по пути (посредством итерации и ссылок). Это позволяет серверу самостоятельно создавать свой кэш, что может уменьшить объем трафика, генерируемого этим сервером, особенно если общее количество запрашиваемых записей невелико и запрашивается неоднократно.
Имейте в виду, что после завершения пересылки, если сервер пересылается для доступа в Интернет, он будет отвечать на запросы, связанные с Интернетом. Это происходит потому, что пересылка всегда выполняется в первую очередь. Это может создать некоторые трудности при устранении неполадок, поскольку при диагностике необходимо сначала определить, откуда пришел ответ: через перенаправленный запрос или из итеративного запроса.
Переадресация сначала также может маскировать симптомы проблемы - например, если тайм-аут или SERVFAIL возвращаются с переадресованного на сервер, за которым следует повторный запрос в Интернет, этот последний запрос может возвращать либо домен NX, либо нежелательный ответ с DNS-сервера, подключенного к Интернету. Это может привести к ложным выводам о том, в чем может заключаться реальная проблема.
forward only
forward only - отличный способ обеспечить четкий путь разрешения. Это также позволяет лучше контролировать ответы. Например, если имя, обычно используемое в Интернете, не подлежит разрешению, его можно добавить в список запрещенных или удалить, вернув поддельный IP-адрес. Это было очень распространено, особенно когда общедоступные службы обмена мгновенными сообщениями (IM) не должны использоваться в определенной сети (IP-адреса серверов обмена мгновенными сообщениями заменяются поддельными на внутренних DNS-серверах).
Наличие единого пути разрешения упрощает устранение неполадок. При выполнении запроса необходимо проверить только один путь (к IP-адресам, перенаправленным на сервер(ы)).
Поскольку пересылка использует рекурсивные запросы, она вернет только ответ на конкретный заданный вопрос. Это не позволяет DNS-серверу, выполняющему пересылку, накапливать больше информации в кэше.
Однако, перенаправляя в общую точку, он может воспользоваться общей суммой всех запросов, которые сделали многие другие клиенты и серверы. Итеративные запросы часто требуют отправки нескольких пакетов для получения ответа. Концентрируя итеративные запросы в общей центральной точке, общее количество DNS-пакетов, которые могут быть сгенерированы с большего числа DNS-серверов, уменьшается.
Похожие статьи:
DNS | |
Типы DNS серверов | |
Forward first | only | |
DNS сервер BIND на CentOS | |
SSH | |
PuTTY | |
Telnet | |
PSTools | |
Firefox | |
FreeSSHD | |
Компьютерные сети | |
Как создать туннель | |
Как сделать проброс портов |