Squid Split DNS: kierowanie domen prywatnych przez właściwy resolver

Umieszczenie resolvera wewnętrznego jako pierwszego, a publicznego jako drugiego nie mówi Squidowi, które nazwy należą do której przestrzeni nazw.

W Squidzie 6 i 7 dns_nameservers zastępuje zwykłą listę resolverów adresami serwerów. Jego składnia nie ma mapowania na domenę. Prawidłowa odpowiedź negatywna różni się też od nieosiągalnego resolvera, więc alternatywy nie są niezawodnym sposobem przeszukiwania niekompatybilnych przestrzeni nazw.

Kierowanie zapytań według domeny

Lokalny forwarder DNS może wyrazić brakującą politykę. W istniejącej konfiguracji dnsmasq prywatny sufiks można skierować tak:

server=/internal.example/192.0.2.53

Zastąp domenę i adres. Skonfiguruj zatwierdzony domyślny upstream dla innych nazw, odpowiedni listener i ograniczenia dostępu. Następnie skieruj Squid na ten resolver za pomocą konfiguracji obsługiwanej przez zainstalowaną wersję.

Alternatywnie użyj organizacyjnej usługi DNS, która prawidłowo rozwiązuje obie przestrzenie nazw. Unikaj publicznego fallbacku, który ujawnia prywatne nazwy, nie mogąc na nie odpowiedzieć.

Jeśli nadrzędny proxy wykonuje wyszukiwanie celu, ten przeskok potrzebuje prywatnej przestrzeni nazw. Resolver na lokalnym hoście Squid nie naprawi wyszukiwania nadrzędnego proxy.

Sprawdź też przypadek negatywny

Wybierz prawidłową nazwę prywatną, prawidłową nazwę publiczną i nieistniejącą nazwę prywatną. Dla każdej ustal zamierzony upstream i to, czy oczekiwana odpowiedź jest adresem, czy odpowiedzią negatywną. Ostatni przypadek ujawnia przypadkowy publiczny fallback po wewnętrznej odpowiedzi negatywnej.

Uwzględnij rodziny adresów wymagane przez klienta. Działające wyszukiwanie A nie dowodzi, że AAAA stosuje politykę lub zwraca osiągalny cel. Zwróć uwagę też na stan pamięci podręcznej: zapisana odpowiedź może ukryć, który upstream wybrałoby świeże zapytanie.