Модуль 2.5: GCP Cloud DNS

Складність: [MEDIUM] | Час на виконання: 1.5 год | Передумови: Модуль 2.2 (Мережі VPC)

Чому цей модуль важливий

У жовтні 2021 року світ на шість годин втратив доступ до сервісів Facebook. Причиною стала помилка в налаштуванні мережевих протоколів, через яку DNS-сервери компанії стали недоступними. Оскільки браузери не могли знайти IP-адреси сайтів, мільярди користувачів бачили лише помилки. Цей інцидент довів: DNS — це фундамент усього інтернету.

Коли ви запускаєте додатки в GCP, вам потрібен надійний спосіб перетворювати імена на кшталт api.company.com на IP-адреси ваших балансувальників. Cloud DNS — це керований сервіс, який робить це за вас із гарантією аптайму 100%.

У цьому модулі ви навчитеся створювати публічні зони для сайтів, приватні зони для внутрішніх серверів та налаштовувати зв’язок між DNS вашої хмари та локального офісу.

Публічні зони: DNS для всього світу

Публічна зона дозволяє всьому інтернету знаходити ваші ресурси.

Як це працює: Ви створюєте зону, отримуєте від Google чотири сервери імен (NS) і прописуєте їх у свого реєстратора доменів.
Основні записи:
- A: перекладає ім’я в IPv4 (app.com -> 34.x.x.x).
- CNAME: створює аліас (www.app.com -> app.com).
- TXT: для верифікації домену (напр. для Google Search Console).

Приватні зони: Внутрішній DNS

Приватні зони бачать тільки ваші віртуальні машини в межах VPC.

Навіщо це потрібно?

Ви можете дати базі даних ім’я db.internal, і ваші додатки будуть звертатися до неї за цим іменем, а не за IP.
Ці імена невидимі зовні, що підвищує безпеку.
Ви можете використовувати одне й те саме ім’я для зовнішнього та внутрішнього трафіку (split-horizon DNS), направляючи внутрішніх користувачів прямо на сервер, минаючи інтернет.

DNS Forwarding: Гібридна хмара

Якщо у вашої компанії є свій офісний дата-центр зі своїм DNS, вам потрібно, щоб хмара знала про нього.

Outbound Forwarding: Хмара пересилає запити на ваші офісні DNS-сервери.
Inbound Forwarding: Ваші офісні сервери питають хмару про адреси в GCP.

Політики маршрутизації (Routing Policies)

Cloud DNS може не просто віддавати IP, а робити це з розумом:

Weighted: направляти 10% трафіку на нову версію сайту (Canary).
Geolocation: направляти користувачів з Європи на європейські сервери, а з США — на американські.

Типові помилки

Помилка	Чому це стається	Як виправити
Забута крапка в кінці	DNS вимагає `example.com.`	Завжди ставте крапку в кінці повного імені в Cloud DNS
Високий TTL при міграції	Записи кешуються на 24 години	За добу до міграції знизьте TTL до 60 секунд
Приватна зона для публічного сайту	Блокує доступ до реального сайту зсередини хмари	Будьте обережні зі створенням приватних зон для доменів, які мають працювати і ззовні
Відсутність логування	”Ми не знаємо, хто куди звертався”	Увімкніть DNS Logging для аудиту безпеки

Тест

1. Що станеться, якщо ви створите приватну зону для "google.com" у вашій VPC?

Ваші віртуальні машини в цій мережі перестануть бачити справжній Google. Вони будуть шукати записи в створеній вами приватній зоні і, швидше за все, нічого не знайдуть (NXDOMAIN).

2. Яка гарантія доступності (SLA) у Cloud DNS?

100%. Google використовує Anycast-мережу з сотень точок по всьому світу, тому DNS працює завжди, навіть якщо впаде цілий регіон.

Практична вправа: Налаштування внутрішнього DNS

Створіть приватну зону internal.lab:

gcloud dns managed-zones create lab-zone --dns-name="internal.lab." --visibility=private --networks=default

Додайте запис A для тестового сервера:
- Ім’я: test.internal.lab.
- IP: 10.0.0.5
Зайдіть на будь-яку ВМ у цій мережі і спробуйте:
Terminal window
```
ping test.internal.lab
```

Наступний модуль

Переходьте до Модуля 2.6: Artifact Registry — ви навчитеся зберігати образи контейнерів, сканувати їх на вразливості та налаштовувати безпечний доступ для CI/CD.