Резолвер для ваших пристроїв, а не відкритий підсилювач.

Виберіть роль

Рекурсивний резолвер, як-от Unbound, і фільтрувальний інтерфейс, як-от AdGuard Home, вирішують пов'язані, але різні проблеми. Вирішіть, чи сервіс виконує рекурсію самостійно, чи пересилає до вищого рівня, і зрозумійте, яка сторона тоді бачить запити.

Зберігайте приватність

Необмежений публічний резолвер можна використати для атак відбиття. Прив'яжіть його до приватної мережі або дозвольте лише авторизовані джерела, зокрема IPv6. Якщо використовується шифрування DNS, автентифікуйте або іншим чином належно обмежте доступ, а не припускайте, що HTTPS робить його приватним.

Встановіть політику журналювання

Запити DNS можуть розкривати чутливу активність перегляду та застосунків. Вимкніть непотрібне зберігання, захищайте записи, які зберігаєте, і пояснюйте обсяг користувачам. Зашифрований транспорт захищає шлях; він не заважає самому резолверу бачити запити.

Перевірте більше ніж одну назву

Перевірте поведінку DNSSEC, де ввімкнено, результати IPv4 та IPv6, винятки фільтрації та відновлення, коли вищерівневий сервер не працює. Збережіть безпечний спосіб виправити доступ, не покладаючись виключно на резолвер, який ви ремонтуєте.

Доведіть, що сторонні не можуть її запитати

Прив'яжіть резолвер до потрібного інтерфейсу, визначте дозволені діапазони клієнтів і обмежте брандмауер. Перевірте конфігурацію перед перезапуском. Запитайте його з авторизованого клієнта, потім повторіть із-за меж довіреної мережі: такий запит має бути відхилений або завершитися тайм-аутом. Перевірте IPv6 окремо. Резолвер, який приймає довільні запити з інтернету, може стати джерелом зловживань.

• Запустіть валідатор конфігурації перед застосуванням змін
• Перевірте дозволеного та забороненого клієнта
• Тримайте докладну діагностику запитів тимчасовою

unbound-checkconf

Офіційна документація: Необмежена конфігурація контролю доступу

Тримайте заяви про зашифровані DNS точними

DNS-over-HTTPS або DNS-over-TLS шифрує певний шлях транспорту. Резолвер усе одно отримує запит, а пересилаючий резолвер може передати його іншому оператору. Перегляньте вибір вищого рівня та зберігання. Якщо ви відкриваєте зашифровану кінцеву точку резолвера, зробіть її політику доступу такою ж продуманою, як і звичайний порт DNS.

Виберіть ланцюжок резолвера перед відкриттям порту

Корисна приватна схема — це VPN-клієнт, що звертається до AdGuard Home, а AdGuard пересилає запити до Unbound на loopback. Далі Unbound виконує рекурсію; AdGuard додає фільтрацію та інтерфейс керування. Або використовуйте лише Unbound для меншого стеку. Надайте кожному слухачу окрему адресу/порт і намалюйте напрямок пересилання: надсилання Unbound назад до AdGuard створює цикл. Вирішіть, які приватні клієнти можуть користуватися сервісом, перш ніж щось публікувати.

• Тримайте публічні вхідні TCP і UDP 53 закритими, якщо немає конкретної політики для авторизованих клієнтів.
• Надайте інтерфейсу фільтрування та слухачу DNS окремі правила доступу.
• Перевірте зайнятість порту перед встановленням; наявний системний резолвер може вже займати потрібну адресу.

Офіційна документація: Налаштування AdGuard Home

Початкова точка Unbound на loopback

У системі, де Unbound уже встановлено, наведений фрагмент ілюструє бекенд, доступний лише на хості. Інтегруйте його з конфігурацією дистрибутива, а не перезаписуйте налаштування пакета чи керування довірчими якорями. Високий порт дає змогу іншому фронтенду DNS використовувати порт 53. Перевірте повний чинний файл, потім перезавантажте через встановлений менеджер служб. Віддаленому клієнту потрібен окремо контрольований тунель або фронтенд; цей фрагмент навмисно не створює публічного резолвера.

server:
  interface: 127.0.0.1
  port: 5335
  access-control: 127.0.0.0/8 allow
  access-control: 0.0.0.0/0 refuse
  access-control: ::0/0 refuse

# Validate the complete installed configuration:
unbound-checkconf

Офіційна документація: Довідник конфігурації Unbound

Проведіть контрольний список приймання з двох мереж

Спочатку запитайте бекенд локально, потім звичайним шляхом клієнта. Перевірте звичайні записи A/AAAA, навмисно неіснуюче ім’я та перевірку DNSSEC за допомогою задокументованого тестового домену. Повторіть із машини поза дозволеною підмережею: вона не повинна отримувати рекурсію. Перевірте, чи браузер використовує власний зашифрований резолвер і обходить налаштований DNS пристрою. Тримайте тимчасовий незалежний резолвер доступним під час зміни, щоб помилка DNS не позбавила вас маршруту адміністрування.

• Локальна діагностика: dig @127.0.0.1 -p 5335 example.org A
• Перевірте доступність як через UDP, так і через TCP, а також слухачі IPv6.
• Підтвердьте винятки фільтрації та записуйте лише фактично потрібну діагностику.

Діагностуйте тайм-аути, цикли та помилки валідації

Тайм-аут фронтенду за працездатного локального бекенду вказує на адресу фронтенду, брандмауер або ціль переспрямування. Повторювані самоспрямовані запити вказують на цикл. Масштабні збої DNSSEC можуть бути пов'язані з неправильним системним часом або обслуговуванням довірчого якоря; усуньте причину, а не залишайте перевірку вимкненою. Якщо не вдаються лише великі відповіді, дослідіть резервний перехід на TCP і мережевий шлях. Зберігайте журналювання запитів тимчасовим і перевірте перезапуск та відновлення конфігурації, перш ніж робити резолвер залежністю для кожного пристрою.