← Cloudflare DNS / dns / internal-dns

Начало работы

Следуйте этому руководству, чтобы начать работу с Internal DNS.

Перед началом работы

Убедитесь, что у вас есть аккаунт Enterprise с доступом к Политики резолвера Gateway и Internal DNS.
Рассмотрим различные способы, которыми можно подключение к резолверу Gateway.

Внимание
Внимание
Если вы используете WARP, убедитесь, что ваши внутренние зоны DNS или их TLD не указаны в Настройка Local Domain Fallback. Иначе DNS-запросы для соответствующего домена будут отправляться на локальный DNS-сервер, указанный в качестве резервного, а не на Cloudflare.
Если для аутентификации вы будете использовать API-токен, убедитесь, что у вас есть следующие разрешения:

Настройка токена API

Разрешения

Аккаунт - DNS Views - Изменить
Zone - DNS - Изменить
Аккаунт - Account Settings - Изменить
Zone - Настройки DNS - Изменить
Zone - Zone - Изменить

Account Resources

Включить - (Ваша учётная запись)

Zone Resources

Включить - Конкретные зоны

При создании токена для Internal DNS рекомендуем ограничивать его область действия конкретными внутренними зонами, а не использовать вариант «Все зоны». Это соответствует принципу минимальных привилегий. Если позже вы создадите новые внутренние зоны, область действия токена нужно будет обновить, чтобы включить их. Поддержка автоматической привязки области действия по типу зоны (например, «все внутренние зоны») запланирована в одном из будущих релизов.

Об аутентификации

Internal DNS использует ту же модель аутентификации, что и остальной Cloudflare DNS. Отдельной роли или специальной группы разрешений для внутренних зон не существует. Вы применяете стандартные разрешения DNS, ограниченные конкретными зонами, которыми хотите управлять.

Важное отличие: токен с областью действия зоны не может создать зону, так как зона, к которой он должен быть привязан, ещё не существует. Чтобы создать внутреннюю зону через API, вам нужен токен с Zone > Zone > Edit ограниченный Все зоны или на уровне аккаунта. После создания зоны переключитесь на токен с областью действия зоны для управления записями и настройками.

1. Настройте свою внутреннюю зону DNS

На панели управления Cloudflare перейдите к разделу Internal DNS страницу.
Перейдите в Internal DNS ↗
Выберите Создание внутренней зоны.
Присвойте внутренней зоне имя.

Условия настройки внутренней зоны

Внутренние зоны могут содержать те же Типы DNS-записей которые Cloudflare поддерживает для публичных зон.
Внутренняя зона может иметь то же имя, что и публичная зона в том же аккаунте.
Каждую внутреннюю зону можно связать с несколькими представления.¹
В одном аккаунте может быть несколько внутренних зон с одинаковым именем. Однако две внутренние зоны с одинаковым именем нельзя связать с одним и тем же представлением.
На внутренние зоны не распространяются ограничения доменов верхнего уровня (TLD). Это означает, что внутреннюю зону можно создать, даже если её TLD не зарегистрирован публично (например, xyz.local), если она создана непосредственно на самом TLD (local), или даже если в корне (.).

¹ Логические группы внутренних DNS зон, на которые ссылаются политики резолвера Gateway, чтобы определить, как должен быть разрешён конкретный запрос.

Добавьте DNS-записи в свою внутреннюю зону одним из следующих способов:

Импорт отформатированный файл BIND.
Выберите Добавление записи и выберите Создание под типом записи, которую хотите добавить. См. Типы DNS-записей для получения подробностей.

Повторите этот процесс для каждой внутренней зоны, которую хотите добавить.

Используйте Create Zone эндпоинт, чтобы создать внутренняя зона. Укажите идентификатор своего аккаунта и задайте type к internal.

Условия настройки внутренней зоны

Внутренние зоны могут содержать те же Типы DNS-записей которые Cloudflare поддерживает для публичных зон.
Внутренняя зона может иметь то же имя, что и публичная зона в том же аккаунте.
Каждую внутреннюю зону можно связать с несколькими представления.¹
В одном аккаунте может быть несколько внутренних зон с одинаковым именем. Однако две внутренние зоны с одинаковым именем нельзя связать с одним и тем же представлением.
На внутренние зоны не распространяются ограничения доменов верхнего уровня (TLD). Это означает, что внутреннюю зону можно создать, даже если её TLD не зарегистрирован публично (например, xyz.local), если она создана непосредственно на самом TLD (local), или даже если в корне (.).

Пример

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Zone Zone Edit
Zone DNS Edit

Create Zone

curl "https://api.cloudflare.com/client/v4/zones" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"account": {
				"id": "<ACCOUNT_ID>"
		},
		"name": "<ZONE_NAME>",
		"type": "internal"
	}'

Добавьте DNS-записи в свою внутреннюю зону одним из следующих способов:

Импорт отформатированный файл BIND. См. Инструкции по DNS-записям для рекомендаций.
Используйте другие конечные точки API, например /batch, чтобы управлять DNS-записями. См. Пакетное изменение записей для получения подробностей.

Повторите этот процесс для каждой внутренней зоны, которую хотите добавить.

(Необязательно) Ссылка на зону из другой зоны

Во время разрешение внутренних DNS-запросов, если внутренняя запись не найдена в соответствующей внутренней зоне, Cloudflare проверит, не ссылается ли эта внутренняя зона на другую внутреннюю зону. Последовательные ссылки могут учитываться в цепочке длиной не более пяти ссылок.

Подробности см. в ссылочные зоны.

На панели управления Cloudflare перейдите к разделу Internal DNS страницу.
Перейдите в Internal DNS ↗
Выберите зону.
В выбранной зоне перейдите в Эталонная зона.
Выберите Add reference zone.
Найдите зону, которую нужно использовать в качестве образца, и выберите Выбрать в соответствующей строке.

Используйте Обновление настроек DNS эндпоинт, чтобы добавить ссылку из одной внутренней зоны на другую внутреннюю зону. В --json, укажите internal_dns объект с параметром reference_zone_id.

В следующем примере внутренняя зона A (ID 8a904aeb565c42cfa207d98f6edea2f3) ссылается на внутреннюю зону B (ID 8e64c6fb4b514f3faf64de81efc11e51).

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Zone DNS Settings Write
DNS Write

Обновление настроек DNS

curl "https://api.cloudflare.com/client/v4/zones/8a904aeb565c42cfa207d98f6edea2f3/dns_settings" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"internal_dns": {
				"reference_zone_id": "8e64c6fb4b514f3faf64de81efc11e51"
		}
	}'

2. Свяжите свою внутреннюю зону с представлением

Поскольку политика резолвера потребует DNS-представление, у вас должно быть хотя бы одно представление, чтобы иметь возможность направлять запросы во внутренние зоны.

На панели управления Cloudflare перейдите к разделу Internal DNS страницу.
Перейдите в Internal DNS ↗
Перейдите в Представления Internal DNS.
Выберите Создание представления.
Присвойте представлению понятное имя.

Условия настройки DNS-представления

DNS-представления могут быть пустыми, без внутренние зоны связанных с ними.
DNS View не может содержать публичные DNS-зоны.¹
Имя каждой внутренней DNS-зоны должно быть уникальным в пределах одного DNS view.
Имя каждого DNS view должно быть уникальным в пределах одной учётной записи Cloudflare.

¹ DNS зоны, которые содержат публичные DNS записи и доступны публичным резолверам.

Выберите Управление зонами чтобы добавить зоны в ваше представление. Выберите внутренние зоны, которые должны использоваться для разрешения запросов, отправляемых резолвером Gateway в это представление.
Выберите Save для подтверждения.

Используйте Создание Internal DNS View конечная точка. Для каждого созданного представления укажите все внутренние зоны, которые должны быть объединены в этом представлении.

Условия настройки DNS-представления

DNS-представления могут быть пустыми, без внутренние зоны связанных с ними.
DNS View не может содержать публичные DNS-зоны.¹
Имя каждой внутренней DNS-зоны должно быть уникальным в пределах одного DNS view.
Имя каждого DNS view должно быть уникальным в пределах одной учётной записи Cloudflare.

¹ DNS зоны, которые содержат публичные DNS записи и доступны публичным резолверам.

3. Настройте политики Gateway

Помимо выбора внутреннего представления DNS при настройке политик резолвера, вы также можете включить резервный вариант через публичный DNS опцию.

В Cloudflare One ↗, перейдите в Политики трафика > Политики Firewall > Резолвера политики.
Выберите Добавление политики и введите название и описание.
Создайте выражение для трафика, который нужно маршрутизировать. Рекомендации по селекторам, операторам и значениям приведены в Политики резолвера Gateway.
Выберите Использование Internal DNS. Выберите представление, в которое должны направляться запросы, соответствующие выражению.
(Необязательно) Настройте параметр Резервный вариант через публичный DNS в зависимости от вашего сценария использования.

Off: DNS-резолвер Gateway возвращает клиенту ответ без изменений.
On: если ответ от внутренней зоны REFUSED, NXDOMAIN или содержит запись типа CNAME, DNS-резолвер Gateway отправляет запрос на публичный резолвер Cloudflare 1.1.1.1 и пытается разрешить его через публичный DNS.

Выберите Создать политику для подтверждения.

Используйте конечные точки API из раздела Zero Trust > Gateway > Rules чтобы настроить политики резолвера. Рекомендации по селекторам, операторам и значениям см. в Gateway.

Используйте объект настроек правила, чтобы определить resolve_dns_internally, указав view_id и fallback опцию. Резервные варианты работают следующим образом:

none: DNS-резолвер Gateway возвращает клиенту ответ без изменений.
public_dns: Если ответ от внутренней зоны имеет тип REFUSED, NXDOMAIN или CNAME, DNS-резолвер Gateway отправляет запрос на публичный резолвер Cloudflare 1.1.1.1 и пытается разрешить его через публичный DNS.

После добавления политики резолвера Gateway она появится в соответствующем внутреннем представлении в разделе Политики резолвера, ссылающиеся на это представление.

Управление с помощью Terraform

Вы также можете управлять ресурсами Internal DNS с помощью Провайдер Terraform для Cloudflare ↗. Шаблоны совпадают с шаблонами публичных зон DNS: единственное отличие в том, что нужно задать type = "internal" на cloudflare_zone ресурс.

Для повседневного управления используйте API-токен с областью действия зоны, а для создания новых зон используйте токен уровня аккаунта. Если токен ограничен конкретными зонами, не забывайте обновлять его при добавлении новых внутренних зон. Полный рабочий пример см. в разделе Документация провайдера Terraform ↗.