Google PCNE: Cloud DNS, обнаружение сервисов и гибридное разрешение имен — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Часть Google Professional Cloud Network Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Cloud DNS — это масштабируемый, высокодоступный DNS-сервис Google Cloud, который поддерживает как публичные авторитативные зоны, так и частный DNS для VPC. Он также предоставляет примитивы для гибридного разрешения имен — перенаправление, пиринг, входящие серверы, политики ответов и политики DNS — для интеграции с локальным DNS и мультиоблачными средами. В этом разделе рассматриваются жизненный цикл авторитативного DNS, видимость и совместное использование частных зон, гибридное разрешение, шаблоны обнаружения сервисов, безопасность и целостность (включая DNSSEC и трансферы зон), расширенное управление трафиком с помощью политик маршрутизации, DNS для частных конечных точек сервисов, а также операции второго дня, такие как устранение неполадок, кеширование, логирование и стратегии миграции/сосуществования.

Авторитативный DNS и жизненный цикл DNS

Управляемые зоны и записи
- Управляемая зона (managed zone) — это контейнер для наборов записей ресурсов (RRsets) для одного DNS-имени (вершины зоны).
- Типы записей: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (и другие). Cloud DNS не поддерживает CNAME в вершине зоны; для сопоставления вершины используйте A/AAAA с IP-адресом балансировщика нагрузки.
- Жизненный цикл: создание зоны, добавление/изменение записей (транзакционные изменения), распространение и эксплуатация (мониторинг/логирование/обеспечение безопасности).
- Импорт из существующих файлов BIND для ускорения миграции:
  - Пример: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Публичные и частные зоны
- Публичные зоны глобально доступны через публичные авторитативные серверы имен Google. Делегирование выполняется у регистратора путем обновления NS-записей в родительской зоне.
- Частные зоны отвечают на запросы только для присоединенных сетей VPC. Имена в них разрешаются резолверами Google в пределах VPC для инстансов в этих сетях и, опционально, для гибридных клиентов через входящее перенаправление (inbound forwarding).
Распространение и TTL
- Внутри Google Cloud изменения записей становятся активными за секунды; инвалидация внешних кешей зависит от TTL.
- Компромиссы при выборе TTL: короткий TTL обеспечивает гибкость и более безопасные переключения, но увеличивает нагрузку от запросов и может снизить эффективность кеширования; длинный TTL снижает нагрузку, но продлевает время жизни устаревших ответов. Распространенная практика: 60–300 с для динамических сервисов; 600–3600 с для стабильных записей. Перед переключением сервисов следует уменьшить TTL за 24–48 часов.

Видимость частных зон, ассоциация с VPC и межпроектное проектирование

Присоединение частных зон к VPC
- Частная зона явно связывается с одной или несколькими сетями VPC. Связывание может охватывать несколько проектов (при наличии соответствующих IAM-прав, таких как dns.admin для зоны и разрешения на привязку сетей).
- Приоритет: при совпадении имен в нескольких частных зонах, присоединенных к одной VPC, выбирается зона с самым длинным совпадающим суффиксом; будьте осторожны при использовании пересекающихся частных зон (например, svc.corp.internal. и corp.internal.).
- Шаблоны совместного использования между VPC
  - Прямое присоединение: присоединение одной и той же частной зоны к нескольким VPC. Просто в эксплуатации; избегайте присоединения там, где это не требуется, чтобы уменьшить радиус поражения (blast radius).
  - Shared VPC: централизация администрирования DNS в хост-проекте с предоставлением доступа к DNS сервисным проектам путем присоединения VPC их подсетей к зонам.
  - DNS-пиринг зон: когда между сетями используется VPC Peering, пиринговая зона в VPC-потребителе может разрешать частные записи из VPC-производителя без дублирования зон.
Режимы отказа и меры предосторожности
- Затенение (Shadowing): частная зона с тем же именем, что и публичная, заставляет клиентов в присоединенных VPC предпочитать частные ответы, что потенциально может нарушить доступ к публичным конечным точкам. Используйте split-horizon осознанно, документируйте и тестируйте.
- Избыточное присоединение: широкое присоединение частной зоны может привести к утечке внутренних имен. Следуйте принципу наименьших привилегий и используйте отдельные поддомены (ограниченные регионом/сервисом) для сужения области видимости.
- Разделение IAM-прав: делегируйте права на изменение DNS (dns.admin) отдельно от прав на присоединение сетей (разрешение на привязку сетей), чтобы разделить домены администрирования.

Краткий пример: создание и присоединение частной зоны

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

Гибридное разрешение имен: пересылка, пиринг и политики

Зоны пересылки (Forwarding zones)
- Авторитетно пересылают запросы для определенного суффикса (например, onprem.corp.) на указанные серверы имен (локальные или в других облаках). Используйте, когда вы не размещаете зону в Cloud DNS, но вам необходимо бесшовное разрешение имен из GCP.
- Избегайте циклов: убедитесь, что локальные серверы пересылки не указывают обратно на Cloud DNS для того же суффикса.
Пиринговые зоны (Peering zones)
- Разрешают имена в приватных зонах, размещенных в пиринговой VPC. Требуется подключение через VPC peering; не транзитивно. Используйте для архитектур типа «звезда» (hub-and-spoke), чтобы централизовать приватный DNS в основной (hub) VPC.
Политики DNS (DNS policies)
- Исходящая пересылка (Outbound forwarding): экземпляры в VPC отправляют рекурсивные запросы на локальные резолверы для доменов, которые не разрешаются в приватных зонах Cloud DNS. Настраивается через политику DNS с IP-адресами целевых серверов имен, доступных через Cloud VPN/Interconnect.
- Входящие серверы (Inbound servers): локальные резолверы пересылают запросы на предоставленные Google IP-адреса для входящей пересылки (автоматически выделяется диапазон 35.199.192.0/20) для разрешения имен в приватных зонах Cloud DNS. Используйте для расширения приватного DNS GCP на локальную среду и другие облака.
- Логирование запросов (Query logging): включается на уровне политики для отправки логов запросов резолвера в Cloud Logging для анализа и устранения неполадок. Для публичных зон логирование запросов включается для каждой зоны отдельно для авторитетных запросов.
Политики ответов (Response policies)
- Определяют правила для изменения ответов (например, возврат NXDOMAIN для известных вредоносных доменов или синтезирование внутренних A-записей для переопределения публичных ответов). Применяйте с осторожностью; убедитесь, что критически важные сторонние домены не блокируются случайно.
Требования к связности
- Для работы исходящей/входящей пересылки убедитесь в наличии гибридной связности (Cloud VPN или Interconnect) и правил брандмауэра, разрешающих UDP/TCP 53 в обоих направлениях. Поведение EDNS0 и фрагментации UDP может различаться в разных сетях — при проблемах с MTU разрешите переход на TCP и рассмотрите возможность настройки буфера EDNS(0) на локальных резолверах.
Распространенные ошибки
- Асимметричная доступность: если исходящая пересылка указывает на локальные резолверы, но обратный трафик блокируется брандмауэром или асимметрией маршрутизации, запросы истекают по времени ожидания. Проверьте маршруты, полученные Cloud Router, и разрешите потоки ответов DNS.
- Пересекающиеся суффиксы: совпадающие корпоративные суффиксы (например, corp.local и corp.internal) могут вызывать неожиданные совпадения в путях поиска резолвера. Стандартизируйте пути поиска и принадлежность суффиксов.

Краткие примеры:

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

Обнаружение сервисов, Split-Horizon и приватные конечные точки

Split-horizon DNS
- Предоставление разных ответов для одного и того же имени внутри и снаружи сети. Типичный шаблон: публичное имя foo.example.com разрешается в публичный Anycast IP; внутреннее имя foo.example.com разрешается в RFC1918-адрес внутреннего балансировщика (ILB). Реализуется с помощью публичной и приватной зон с одинаковым именем, при этом область действия приватной зоны тщательно ограничивается соответствующими VPC.
Именование внутренних сервисов
- Используйте согласованные внутренние суффиксы (например, svc.corp.internal) и сервис-ориентированные записи (A/AAAA, SRV или специфичные для обнаружения TXT). Устанавливайте низкие значения TTL для динамически масштабируемых сервисов.
- Обнаружение сервисов в GKE: внутрикластерные имена остаются в пределах CoreDNS (svc.cluster.local). Для доступа из других пространств имен или VPC публикуйте VIP-адреса ILB в приватных зонах Cloud DNS или используйте интеграцию с Service Directory.
Интеграция с Service Directory
- Автоматически публикуйте конечные точки сервисов в DNS через Service Directory и Cloud DNS, создавая SRV- и A-записи для каждого пространства имен/сервиса. Полезно для разделения поставщиков и потребителей сервисов и для поддержки обнаружения экземпляров с учетом их состояния работоспособности.
Приватные конечные точки сервисов
- Private Service Connect (PSC) для Google APIs: направляйте трафик к googleapis.com приватно, используя конечные точки PSC, или используйте VIP-адреса Restricted Google APIs (199.36.153.8/30) с приватной зоной для googleapis.com. PSC обеспечивает регионально-локальную приватную IP-связность с контролем на уровне каждой конечной точки; Restricted VIP проще, но использует публичные IP-диапазоны, доступные через маршруты по умолчанию.
- PSC для сервисов-производителей: создайте A/AAAA-записи в приватной зоне, указывающие на конечную точку PSC или VIP-адрес ILB. Для пользовательских внутренних доменов управляйте приватной зоной в Cloud DNS и подключайте ее к VPC потребителей.
Компромиссы
- PSC в сравнении с Restricted VIP: PSC предлагает гранулярный контроль и позволяет избежать путей проверки исходящего трафика; требует настройки конечной точки/DNS для каждого региона. Restricted VIP быстро развертывается, но использует общие VIP-адреса и может взаимодействовать с политиками маршрутизации исходящего трафика.
- Риск split-horizon: неправильно настроенные приватные зоны могут привести к потере доступа (black-hole) к публичным SaaS. Проверяйте с помощью тестовых ВМ (canary VMs) и логирования запросов перед широким внедрением.

Краткий пример: сопоставление внутреннего ILB

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

Безопасность, управление трафиком, эксплуатация и миграция

DNSSEC и целостность
- Публичные зоны: включите подписание DNSSEC в Cloud DNS и опубликуйте DS-записи у регистратора для защиты от спуфинга и отравления кэша. Планируйте окна для смены ключей и отслеживайте сбои валидации.
- Частные зоны: валидация/подписание DNSSEC обычно не требуется, так как разрешение имен происходит в доверенных сетях; сосредоточьтесь на безопасности транспорта (гибридные подключения) и усилении защиты резолверов.
Управляемые трансферы зон
- Cloud DNS может выступать в качестве основного (primary) или вторичного (secondary) сервера для AXFR/IXFR. Используйте TSIG для аутентификации/авторизации трансферов и NOTIFY для своевременного распространения изменений. Паттерны трансфера зон упрощают сосуществование систем во время миграции и поддерживают локальные вторичные серверы для соответствия нормативным требованиям или для повышения отказоустойчивости.
- Сценарии сбоев: трансфер заблокирован файрволами, несоответствие ключа TSIG, не увеличен серийный номер SOA или отключен IXFR на основном сервере, что приводит к полным трансферам AXFR.
Политики маршрутизации и проверки работоспособности
- Cloud DNS поддерживает политики управления трафиком (взвешенные, географические, по задержке и отказоустойчивые). Привяжите проверки работоспособности к конечным точкам, чтобы автоматически исключать неработоспособные ответы.
- Советы по проектированию: поддерживайте небольшое количество наборов записей для каждой цели политики; предпочитайте региональное ограничение, соответствующее расположению пользователей; сочетайте низкие значения TTL с интервалами обнаружения сбоев, чтобы ограничить время переключения.
- Подводные камни: слишком гранулированные географические карты могут усложнить эксплуатацию; отсутствие стабильного сигнала о работоспособности приводит к «флаппингу» (частым переключениям) — используйте пороги стабилизации и тайм-ауты проверок, соответствующие поведению приложения.
Поиск и устранение неисправностей
- Инструменты: dig/nslookup с опциями +trace, +short и +dnssec для проверки цепочек доверия; просмотр Cloud Logging для журналов запросов резолверов (политики DNS) и журналов запросов к авторитативным серверам (управляемые зоны).
- Кэширование: убедитесь, какой резолвер вы тестируете (файл /etc/resolv.conf на ВМ обычно указывает на резолвер VPC от Google). Очищайте кэш локального резолвера при тестировании изменений TTL. Учитывайте негативное кэширование (RFC 2308): ответы NXDOMAIN кэшируются на время, указанное в SOA MINIMUM/negative TTL.
- Распространенные проблемы: циклы между исходящей пересылкой и локальными условными форвардерами; блокировка UDP-порта 53 или проблемы с MTU, приводящие к усеченным ответам; перекрытие публичных зон частными.
Эксплуатационные паттерны
- Управление изменениями: группируйте изменения в транзакции, уменьшайте TTL перед переключениями и используйте «канареечное» подключение VPC для проверки видимости.
- Логирование и мониторинг: включайте логирование запросов выборочно; экспортируйте логи в BigQuery для анализа тенденций и создавайте оповещения о всплесках SERVFAIL/NXDOMAIN.
- Контроль доступа: разделяйте роли для изменения записей и для подключения сетей; применяйте принцип наименьших привилегий для редакторов политик ответов, чтобы избежать случайной блокировки доменов.
Миграция и сосуществование
- Сосуществование: разверните Cloud DNS в качестве вторичного сервера через AXFR/IXFR, пока локальный DNS остается основным; или наоборот (Cloud DNS — основной, локальные серверы — вторичные). Используйте TSIG и списки разрешений.
- Условная пересылка: для доменов, остающихся в локальной среде, создайте зоны пересылки или политики исходящей пересылки. Обеспечьте высокую доступность гибридных каналов (двойные VPN с разными пирами и Cloud Router).
- Объединение нескольких организаций: соедините VPC через Cloud VPN/Cloud Router, настройте взаимную условную пересылку или пиринг по необходимости и используйте трансферы зон для перемещаемых зон. Снижайте TTL задолго до изменения NS- или DS-записей у регистратора.

Краткие примеры:

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

Практический сценарий

Contoso Retail и Fabrikam Payments — это отдельные организации Google Cloud, которые должны взаимодействовать в течение одного года, пока они интегрируют сети и DNS с минимальным временем простоя. Каждая организация использует непересекающееся пространство адресов 10.0.0.0/8. Contoso будет размещать внутренние сервисы на svc.contoso.internal; Fabrikam продолжит размещать pay.fabrikam.internal в своей локальной среде. Обе стороны должны разрешать частные имена друг друга и постепенно переносить некоторые зоны в Cloud DNS.

Подход:

Создание отказоустойчивого гибридного подключения
- Создайте два туннеля Cloud VPN между хаб-VPC Contoso и локальными маршрутизаторами Fabrikam, каждый на отдельный публичный IP-адрес Fabrikam, с BGP на Cloud Router в обоих туннелях.
- Обоснование: Два туннеля и динамическая маршрутизация обеспечивают избыточность путей и автоматически распространяют маршруты для целей DNS, снижая риски асимметричной маршрутизации для UDP/TCP 53.
Реализация условного разрешения имен в обоих направлениях
- В Contoso создайте зону пересылки fabrikam.internal, которая перенаправляет запросы на локальные DNS-серверы Fabrikam (например, 172.20.10.53 и 172.20.11.53), и подключите ее к VPC приложений.
- В Fabrikam настройте условные форвардеры на локальном DNS для пересылки запросов по svc.contoso.internal на IP-адреса для входящих запросов Cloud DNS от Contoso, предоставленные политикой входящих запросов Cloud DNS.
- Обоснование: Зоны пересылки позволяют избежать дублирования авторитативных данных и дают каждой стороне возможность сохранить свой DNS там, где он находится сейчас. Серверы для входящих запросов расширяют частное разрешение имен Cloud DNS на Fabrikam без глобального изменения их резолверов.
Защита от циклов пересылки и обеспечение границ видимости
- Убедитесь, что условные форвардеры Fabrikam не пересылают запросы по contoso.internal обратно в Contoso для имен, которыми все еще владеет Fabrikam; аналогично, Contoso должна пересылать только fabrikam.internal.
- Подключайте частные зоны Contoso только к тем VPC, которым они необходимы; не подключайте их глобально, чтобы уменьшить зону потенциального воздействия.
- Обоснование: Устраняет циклы рекурсии DNS и предотвращает перекрытие публичных доменов частными зонами.
Миграция общей зоны с помощью управляемых трансферов зон
- Для устаревшей общей зоны legacy.shared.internal, которая в настоящее время размещена на основном BIND-сервере Fabrikam, настройте Cloud DNS как вторичный сервер с TSIG и внесите основной сервер Fabrikam в список разрешенных для AXFR/IXFR. Оставьте Fabrikam в качестве основного сервера на период сосуществования.
- Обоснование: Режим вторичного сервера обеспечивает синхронизацию в реальном времени без изменения клиентов. Это позволяет безопасно проводить валидацию в Contoso, сохраняя единый источник истины.
Внедрение split-horizon для сервисов, доступных извне
- Создайте публичную зону contoso.example с записями, указывающими на IP-адрес глобального HTTPS-балансировщика нагрузки для клиентов. Создайте одноименную частную зону, подключенную к внутренним VPC, которая сопоставляет те же имена с внутренними адресами ILB.
- Обоснование: Внешние пользователи продолжают обращаться к пограничным балансировщикам нагрузки; внутренние сервисы обращаются к частным ILB по адресам RFC1918, что оптимизирует задержку и затраты при сохранении единообразных имен хостов.
Обеспечение частного доступа к Google API без выхода через файрволы
- Для ВМ Contoso без внешних IP-адресов включите Private Service Connect для Google API и создайте управляемую частную DNS-зону для googleapis.com, которая сопоставляет имена с конечными точками PSC.
- Обоснование: Гарантирует, что доступ к BigQuery и Pub/Sub остается частным и локальным для VPC, избегая использования сторонних устройств для исходящего трафика и сохраняя уровень безопасности.
Обеспечение наблюдаемости и контроля
- Включите логирование запросов Cloud DNS в политике DNS Contoso для задействованных VPC и логирование запросов к авторитативным серверам в публичных зонах. Создайте правила политики ответов для блокировки известных вредоносных доменов на уровне всей организации.
- Обоснование: Телеметрия запросов помогает в поиске неисправностей и планировании мощностей; политики ответов обеспечивают централизованный контроль безопасности без необходимости изменять каждый резолвер.
Выполнение управления изменениями с безопасными TTL
- За неделю до изменений уменьшите TTL до 60 секунд для записей, которые будут мигрировать. После валидации и переключения (например, перевод сервиса с локальной среды на ILB в GCP) постепенно увеличьте TTL до 300–600 секунд.
- Обоснование: Короткие TTL ограничивают риски во время переходных периодов; восстановление более высоких TTL повышает эффективность кэширования после стабилизации.
Тестирование, валидация и усиление защиты
- С «канареечных» ВМ с обеих сторон запустите dig с опцией +trace и проверьте авторитативные пути, убедитесь в отсутствии всплесков SERVFAIL/NXDOMAIN в логах и сымитируйте сбои каналов связи, чтобы наблюдать за поведением DNS при избыточности VPN.
- Обоснование: Проактивная валидация позволяет на раннем этапе выявлять проблемы с циклами/видимостью; симуляция сбоев проверяет, что гибридное разрешение имен выдерживает инциденты на транспорте без влияния на пользователей.