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

Поставянето на вътрешен resolver първи, а на публичен втори, не казва на Squid кои имена принадлежат на кое пространство от имена.

В Squid 6 и 7 dns_nameservers заменя обичайния списък с resolver-и с адреси на сървъри. Синтаксисът му няма съответствие по домейн. Валиден отрицателен отговор също се различава от недостъпен resolver, затова алтернативите не са надежден начин за търсене в несъвместими пространства от имена.

Насочване на заявки по домейн

Локален DNS препращач може да изрази липсващата политика. В съществуваща конфигурация на dnsmasq частен суфикс може да бъде насочен така:

server=/internal.example/192.0.2.53

Заменете домейна и адреса. Настройте одобрен подразбиращ се upstream за други имена, подходящ слушател и ограничения за достъп. След това насочете Squid към този resolver чрез конфигурацията, поддържана от инсталираната версия.

Като алтернатива използвайте организационна DNS услуга, която разрешава правилно и двете пространства от имена. Избягвайте публичен резервен вариант, който разкрива частни имена, без да може да отговори на тях.

Ако родителски прокси извършва търсенето на дестинацията, този хоп се нуждае от частното пространство от имена. Resolver на локалния Squid хост няма да поправи търсенето на родителя.

Проверете и отрицателния случай

Изберете валидно частно име, валидно публично име и несъществуващо частно име. За всяко определете предвидения upstream и дали очакваният отговор е адрес, или отрицателен отговор. Последният случай разкрива случайно публично връщане след вътрешен отрицателен отговор.

Включете семействата адреси, изисквани от клиента. Работещо A търсене не доказва, че AAAA следва политиката или връща достижима дестинация. Отбележете и състоянието на кеша: кеширан отговор може да скрие кой upstream би избрала свежа заявка.