Описала зону DNS із 20 записів як код

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

Завдання. Зона мала стати декларацією в репозиторії, і потрібен був спосіб порівнювати цю декларацію з тим, що провайдер віддає насправді.

Дія. Зону записано як дані — чинні записи, записи застосунків, записи транспортних політик і окремий список записів, що чекають на видалення, а це чесний спосіб зафіксувати видалення, яке ще не відбулося. Один плей узгоджує її з API провайдера. Ще дві точки входу запускаються лише за явно вказаними тегами: аудит, який показує різницю, нічого не змінюючи, і експорт, що записує зону у стандартному форматі файлу зони, щоб її могло прочитати щось поза цим репозиторієм. Найцікавішим рішенням стала відмова від уже зробленого. Проксування двох публічних сайтів через мережу доставлення контенту провайдера налаштували, воно працювало, а потім його знову вимкнули — бо за нього довелося б заплатити тим єдиним реченням, заради якого існує сторінка конфіденційності компанії. Коли попереду стоїть проксі, адресу кожного відвідувача й кожну URL‑адресу, яку він запитує, обробляє інша компанія — раніше за нас і за своєю політикою, а не за нашою. Для бізнесу, який вирізняється саме тим, що ніхто не стежить, такий обмін гірший за атаки, від яких захищає проксі.

Результат. Зона тепер під контролем версій, її можна порівняти й експортувати, а єдине рішення, що суперечить очевидному варіанту за замовчуванням, записано разом з обґрунтуванням, щоб ніхто випадково не взявся переглядати його знову. Найчастіше використовується аудит, бо знати різницю потрібно частіше, ніж її усувати.