nslookup sunucuyu bilinmiyor olarak gösteriyor: bu yalnızca bir etiket

VPN'e bağlanın, nslookup çalıştırın; üst bilgi, ad alanı Unknown olarak doldurulmuş halde çözümleyicinin adresini gösterir. O sözcük yanıtın üstünde durur ve çoğu insan önemli kısımdan önce okumayı bırakır. Etiket, çözümleyicinin kendi ters adı olup olmadığını açıklar; sorduğunuz ana makine adının çözülüp çözülmediği hakkında henüz hiçbir şey söylemez. O pencereyi erken kapatmak buradaki bütün beceridir.

İki farklı sorgu o görüntüyü üretebilir ve bunlardan yalnızca biri sizin sorununuzla ilgilidir. Onları ayırmak bir ek komut gerektirir ve hiç yanlış olmamış DNS ayarlarını düzenleyerek geçen bir öğleden sonrayı kurtarır.

Araç size yanıt vermeden önce ne yapar

nslookup, kullanmak üzere olduğu sunucu adresi için bir ad bulmaya çalışabilir; bu, in-addr.arpa veya ip6.arpa etki alanında ters aramadır. O PTR kaydı yoksa, ilkeyle filtrelenmişse ya da yalnızca yayımlanmamışsa araç Unknown yazar ve devam eder. İleri çözümleme bu hatadan etkilenmez, çünkü aynı sunucuya gönderilen başka bir sorudur.

Bu yüzden özel bir çözümleyici her kurumsal ada doğru yanıt verebilir ve yine de aracın üst bilgisinde anonim görünebilir. Adres bilinir; arkasındaki ad bilinmez ve araç bu konuda dürüsttür, seçtiği sözcük konusunda biraz teatral kalsa da.

İki sorguyu bilerek çalıştırın

Önemsediğiniz bir ana makineyi sorun, sonra çözümleyicinin kendi adresini sorun. İlk istek ihtiyacınız olan adı taşır; ikincisi sunucuya kendini adlandırıp adlandıramayacağını sorar. Yazıldığında şöyle görünürler: ana makine için nslookup app.corp.example 10.77.0.53 ve çözümleyicinin ters adı için nslookup 10.77.0.53 10.77.0.53.

İki örnek de açıklayıcıdır, bu yüzden kendi adlarınız ve adreslerinizle değiştirin. Mesele tam söz dizimi değil, ayrımdır: iki komut farklı sorular sorar ve hiçbiri arıza olmadan farklı sonuçlar verebilir.

Benzer görünen ama olmayan üç sonuç

Zaman aşımı hiçbir yanıtın gelmediği anlamına gelir; bu, erişilebilirliğe, filtrelemeye veya yanlış sunucu adresine işaret eder. Olumsuz yanıt, sunucunun yanıt verip adın var olmadığını söylediği anlamına gelir; bu, bölgeye veya son eke işaret eder. Eksik ters ad, sunucunun ikinci soruyu yararlı hiçbir şeyle yanıtlamadığı anlamına gelir ve ileri yanıt hâlâ kusursuz olabilir. Üç sonuç, üç sorumlu ve bunlardan yalnızca biri ihtiyacınız olan ana makine adıyla ilgilidir.

Yalnızca ilk ikisi uygulamanız için başarısız olan bir DNS yolunu tanımlar. Üçüncüsü hiç yayımlanmamış bir kaydı tanımlar ve ona arıza olarak davranmak, düzeltemeyecek değişikliklere yol açar; örneğin üst bilgi daha dostça görünene kadar arama son ekini yeniden yazmak gibi.

Bölümleri okuyun, üst bilgiyi değil

Üst bilginin altında araç yanıtı, yetkiyi ve varsa ek kayıtları yazdırır. Yanıt bölümündeki doğru adres, üst bilgideki ad Unknown olsa bile istediğiniz sonuçtur. Yetkili bir reddetmeyle gelen boş yanıt farklı bir sonuçtur ve kendi incelemesini hak eder.

Desteğe gönderdiğiniz her şeyde iki nesneyi açık tutun: hangi adın sorgulandığı ve hangi sunucuya sorulduğu. Yalnızca VPN üzerinden DNS'in bozuk olduğunu belirten raporlar, bir sonraki kişiyi zaten yaptığınız bir testi yeniden kurmaya zorlar.

Ters ad gerçekten önemli olduğunda

Bazı hizmetler PTR kayıtlarını gerçekten önemser: istemci adreslerini çözen günlük kaydı, e-posta itibarı kontrolleri veya adları gösteren yönetim araçları. Bunlardan biri başarısız olursa kaydı yayımlayın veya onu tutması gereken bölgeyi düzeltin. Bu iş meşrudur ve VPN'in sorguları doğru iletip iletmediği sorusundan ayrıdır.

Dar nokta geçerliliğini korur: tek bir eksik çözümleyici etiketi, tünel üzerinden ileri çözümlemenin bozuk olduğunu kanıtlamaz ve tek bir çalışan ileri arama, bölgedeki her adın çözüldüğünü kanıtlamaz. Gerçekten ihtiyacınız olan adı test edin, sonra üst bilgideki sözcüğün neye değdiğine karar verin.