Bir iç çözümleyiciyi ilk, bir genel çözümleyiciyi ikinci sıraya koymak Squid'e hangi adların hangi ad alanına ait olduğunu söylemez.

Squid 6 ve 7'de dns_nameservers olağan çözümleyici listesinin yerine sunucu adreslerini koyar. Sözdiziminde alan adı başına eşleme yoktur. Geçerli bir olumsuz yanıt da erişilemeyen bir çözümleyiciden farklıdır, bu nedenle alternatifler uyumsuz ad alanlarında arama yapmanın güvenilir bir yolu değildir.

Sorguları alan adına göre yönlendirin

Yerel bir DNS ileticisi eksik politikayı ifade edebilir. Mevcut bir dnsmasq yapılandırmasında özel bir son ek şöyle yönlendirilebilir:

server=/internal.example/192.0.2.53

Alan adını ve adresi değiştirin. Diğer adlar için onaylanmış varsayılan upstream, uygun bir dinleyici ve erişim kısıtlamaları yapılandırın. Ardından Squid'i kurulu sürümün desteklediği yapılandırmayla o çözümleyiciye yönlendirin.

Alternatif olarak, her iki ad alanını da doğru çözen bir kurumsal DNS hizmeti kullanın. Özel adları açığa çıkarıp onlara yanıt veremeyen genel bir yedek yoldan kaçının.

Üst proxy hedef aramasını yapıyorsa, o atlama özel ad alanına ihtiyaç duyar. Yerel Squid ana bilgisayarındaki bir çözümleyici üst proxy'nin aramasını düzeltmez.

Olumsuz durumu da denetleyin

Geçerli bir özel ad, geçerli bir genel ad ve var olmayan bir özel ad seçin. Her biri için amaçlanan upstream'i ve beklenen yanıtın adres mi yoksa olumsuz yanıt mı olduğunu belirleyin. Son durum, iç olumsuz yanıttan sonra istemeden genel yedeğe düşüldüğünü ortaya koyar.

İstemcinin gerektirdiği adres ailelerini dahil edin. Çalışan bir A araması, AAAA'nın politikaya uyduğunu veya erişilebilir bir hedef döndürdüğünü kanıtlamaz. Önbellek durumunu da not edin: saklanan bir yanıt, yeni bir sorgunun hangi upstream'i seçeceğini gizleyebilir.

İlgili makaleler