Squid Split DNS: спрямування приватних доменів через потрібний резолвер

Якщо внутрішній резолвер стоїть першим, а публічний другим, Squid не дізнається, які імена належать до якого простору імен.

У Squid 6 і 7 dns_nameservers замінює звичайний список резолверів адресами серверів. У його синтаксисі немає зіставлення за доменом. Коректна негативна відповідь теж відрізняється від недосяжного резолвера, тому альтернативи не є надійним способом перебирати несумісні простори імен.

Спрямування запитів за доменом

Локальний DNS-форвардер може виразити відсутню політику. У наявній конфігурації dnsmasq приватний суфікс можна спрямувати так:

server=/internal.example/192.0.2.53

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

Або скористайтеся організаційним DNS-сервісом, який правильно розв'язує обидва простори імен. Уникайте публічного резервного шляху, який розкриває приватні імена, але не може на них відповісти.

Якщо батьківський проксі виконує пошук призначення, цьому стрибку потрібен приватний простір імен. Резолвер на локальному хості Squid не виправить пошук батьківського проксі.

Перевірте й негативний випадок

Виберіть чинне приватне ім'я, чинне публічне ім'я та неіснуюче приватне ім'я. Для кожного визначте передбачуваний upstream і те, чи очікувана відповідь є адресою чи негативною відповіддю. Останній випадок виявляє випадковий публічний резервний шлях після внутрішньої негативної відповіді.

Враховуйте родини адрес, яких потребує клієнт. Робочий пошук A не доводить, що AAAA дотримується політики або повертає досяжне призначення. Звертайте увагу й на стан кешу: збережена відповідь може приховати, який upstream вибере новий запит.