DNS hangi portu kullanır? Port 53, ve kullanmadığı zaman

Sıradan bir arama için DNS hangi portu kullanır?

Tarayıcınızın dakikada onlarca kez gönderdiği türden normal bir sorgu, port 53’e tek bir UDP paketi olarak çıkar ve aynı şekilde geri gelir. RFC 1035, UDP’yi "internette standart sorgular için önerilen yöntem" olarak adlandırır çünkü hiçbir el sıkışma gerektirmez: bir paket dışarı, bir paket içeri, bitti. Bu yüzden DNS çalıştığında anında hissettirir, ve tek bir düşen paket onu bozuk hissettirmeye yeter, çünkü UDP sizin için otomatik olarak yeniden denemez. Cihazınızdaki veya yönlendiricinizdeki çözümleyici yazılımı yeniden denemeyi halleder, genellikle ilki sessiz kalırsa yapılandırılmış ikinci bir sunucuya karşı.

DNS ne zaman bunun yerine TCP kullanır?

İki durum bir DNS alışverişini TCP port 53’e iter. İlki, ikincil bir ad sunucusunun birincilden bir bölgenin tam bir kopyasını çektiği bölge transferidir. RFC 1035 açıkça "UDP bölge transferleri için kabul edilebilir değildir" der, çünkü işlem tek seferlik bir paket değil güvenilir, sıralı bir akış gerektirir. İkincisi ise kullanılan UDP mesaj boyutuna sığmayacak bir yanıttır. Bu olduğunda, sunucu TC (kesilmiş) bitini ayarlanmış kesik bir UDP paketi geri gönderir, ve uyumlu bir çözümleyici bu biti fark edip tam yanıtı almak için aynı sorguyu TCP üzerinden yeniden gönderir. Bu davranışı kendiniz zorlayabilir ve tam yanıtı doğrudan görebilirsiniz:

dig +tcp example.com

Gündelik sorgular bu yola nadiren ihtiyaç duyar, ama tam olarak, eskiden olduğundan daha sık olacak şekilde tek bir UDP paketinin tutabileceğinden büyüyen bir yanıt olduğunda DNS’in çalışmaya devam etmesi için vardır.

512 baytlık sınır neydi, ve onu ne değiştirdi?

RFC 1035, IP veya UDP başlıklarını saymadan, başlık dahil UDP mesaj boyutunu 512 bayta sabitledi. Bir DNS yanıtının bir avuç adres kaydı olduğu 1987’de bu sayı cömertti. DNSSEC imzaları, daha uzun ana bilgisayar adları ve birçok IP adresi içeren kayıtlar normal hale geldiğinde cömert olmaktan çıktı, çünkü bir RRSIG kaydı içeren imzalı bir yanıt rutin olarak tek başına 512 baytı aşıyor.

2013’te yayınlanan RFC 6891, telli protokole dokunmadan tavanı düzeltti: EDNS0, bir çözümleyicinin "isteğin ağ yığınında yeniden birleştirilip teslim edilebilecek en büyük UDP yükünü" duyurmasına izin veren bir OPT sözde kaydı ekler, ve RFC, pratik bir başlangıç noktası olarak 4096 bayt önerir. EDNS0’ı ikisi de destekleyen bir çözümleyici ve sunucu, eski 512 baytlık tavanın birkaç katı yanıtı tek bir UDP paketi üzerinden alışverişe edebilir, ve yalnızca o daha büyük izin bile yetmediğinde TCP’ye geri döner. Bugün kullanılan neredeyse her çözümleyici, kendi işletim sisteminiz dahil, EDNS0’ı varsayılan olarak konuşur, bu yüzden bu yükseltme sizden hiçbir işlem yapılmadan zaten gerçekleşti.

Yalnızca UDP 53’e izin veren güvenlik duvarları neden gerçek sorunlara neden olur

Yıllar önce yazılmış ve hiç gözden geçirilmemiş bir güvenlik duvarı kuralı genellikle şöyle okunur: "UDP port 53’e izin ver, DNS’le ilgili geri kalan her şeyi reddet." Bu kural, protokolün ihtiyaç duyduğu TCP yedeğini engeller, ve ürettiği arıza kolayca yanlış teşhis edilir çünkü çoğu arama sorunsuz çalışmaya devam eder. Yalnızca UDP sınırını aşanlar başarısız olur, ve rastgele görünen bir şekilde başarısız olurlar: bir alan adı çoğu zaman normal şekilde çözülür ve sonra zaman aşımına uğrar, özellikle DNSSEC doğrulaması devreye girdiğinde, çünkü doğrulayan bir çözümleyici sorduğu yanıtın yanı sıra RRSIG ve DNSKEY kayıtlarını da getirmek zorundadır.

Pratik sonuç şudur: DNSSEC ile imzalanmış bölgeler ve çok değerli herhangi bir kayıt kümesi (örneğin bir düzine posta sunucusu olan bir alan adı), yalnızca UDP’ye izin veren bir güvenlik duvarının arkasında güvenilmez hale gelirken, geri kalan her şey sağlıklı görünür. TCP 53’ü giden trafikte engellemek, veya yalnızca tek bir yönde engellemek, en yaygın kendi kendine verilen DNS kesintilerinden biridir, ve bu genellikle temel bir bağlantı kontrolünde ortaya çıkmaz çünkü o kontrol genellikle yalnızca UDP’yi dener.

DNS over TLS ve DNS over HTTPS: farklı portlar, aynı aramalar

İki yeni transport, aynı DNS sorgularını ve yanıtlarını taşır ama bunları tamamen port 53’ün dışına çıkarır. RFC 7858’de tanımlanan DNS over TLS, her sorguyu TCP port 853 üzerinde bir TLS oturumuna sarar; bu port, bir ağ operatörünün DoT’yi şifresini çözmeden bile onun gerçekleştiğini görebilmesi (ve engelleyebilmesi) için seçilmiştir, çünkü portun kendisi zaten açık bir sinyaldir.

DNS over HTTPS, RFC 8484’te tanımlanır, daha da ileri gider. DNS sorgularını, ziyaret ettiğiniz her diğer web sitesiyle aynı port olan 443 portunda sıradan HTTPS istekleri olarak gönderir, ve RFC, "DoH trafiğini aynı bağlantıda diğer HTTPS trafiğiyle karıştırma yeteneğini" kasıtlı bir özellik olarak adlandırır. DoH’nin tüm amacı budur: yalnızca porta göre inceleme veya filtreleme yapan bir ağ, aynı protokol aynı port üzerinde olduğu için bir DNS aramasını başka bir HTTPS isteğinden ayıramaz. Chrome, Firefox ve Edge, hepsi artık varsayılan olarak DNS’i bu şekilde gönderebilir, bu yüzden bir ağda "port 53"ü engellemek artık DNS’i engellediğiniz anlamına gelmez. Klasik transportu engellediğinizi garanti eder; DoH etkin bir tarayıcı ise ne olursa olsun isimleri 443 üzerinden çözmeye devam eder.

Port 5353’teki mDNS nedir?

Multicast DNS, benzer bir isim taşıyan farklı bir protokoldür. RFC 6762, bunu, belirli bir sunucuya değil çoklu yayın grubuna 224.0.0.251’e (veya IPv6 eşdeğeri FF02::FB’ye) adreslenmiş, cihazların "IP Multicast üzerinden UDP port 5353’e DNS benzeri UDP sorgu ve yanıt mesajları gönderdiği" bir protokol olarak tanımlar. Burada hiçbir merkezi ad sunucusu yoktur: yerel ağ segmentindeki her cihaz port 5353’ü dinler ve kendi adına yanıt verir. Bir yazıcının veya akıllı bir hoparlörün, kimse onun için bir DNS kaydı yapılandırmadan device.local olarak erişilebilir hale gelmesinin yolu budur. Tasarım gereği yerel bağlantıyla sınırlıdır ve genel bir alan adını çözmekle hiçbir ilgisi yoktur, bu yüzden mDNS trafiğinin yönlendiricinizi hiç terk etmesine gerek yoktur.

Port 53’ün erişilebilir olup olmadığını nasıl test edersiniz

İyi bilinen bir çözümleyiciye karşı doğrudan bir sorguyla başlayın, bu size sıradan UDP aramalarının çalışıp çalışmadığını söyler:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Bu başarılı olursa ama TCP yedek yolunun engellendiğinden şüpheleniyorsanız, TCP’yi zorlayın ve karşılaştırın:

dig +tcp example.com @1.1.1.1

Başarılı bir UDP sorgusuyla birlikte zaman aşımına uğrayan zorlanmış TCP sürümü, sizinle çözümleyici arasındaki bir şeyin özellikle TCP 53’ü düşürdüğünün güçlü bir işaretidir, yukarıda tarif edilen tam arıza şeklidir. Kendi ağınızın dışından ham port erişilebilirliğini test etmek, port kontrol aracımızın faydalı olduğu yerdir: onu çözümleyicinizde veya ad sunucunuzda port 53’e yönlendirin, ve başka bir ağdan gerçek bir TCP bağlantısı açarak TCP 53’ün hiç erişilebilir olup olmadığını doğrular. Bir uyarıyla sonucu okuyun: bir port kontrolü TCP’yi test eder, bu yüzden orada bir başarı yedek yolun açık olduğunu doğrular ama hiçbir el sıkışması olmayan UDP hakkında hiçbir şey söylemez. Sorgunun kendisi için, birden fazla genel çözümleyiciden ve farklı bölgelerden yanıtları aynı anda karşılaştırmak dahil, DNS sorgu aracını çalıştırın.

Sık sorulan sorular

TCP 53’ü UDP 53’ün yanında açmam gerekiyor mu?

Giden çözümleyici trafiği için evet. Yalnızca UDP 53’e izin veren bir güvenlik duvarı çoğu sorguyu sorunsuz işler ve sonra TCP yedeğine ihtiyaç duyan daha büyük, tipik olarak DNSSEC ile imzalanmış yanıtlarda öngörülemez şekilde başarısız olur.

Port 53’ü engellemek tüm DNS trafiğini durdurur mu?

Artık değil. Klasik UDP/TCP transportunu engeller. DNS over HTTPS port 443’te çalışır ve diğer her HTTPS isteği gibi görünür, ve DNS over TLS kendi portu 853’te çalışır, bu yüzden ikisinden biri etkin bir tarayıcı veya uygulama isimleri çözmeye devam eder.

DNS over HTTPS, sıradan DNS ile aynı protokol mü?

Sorgular ve yanıtlar, RFC 1035’in tanımladığı aynı DNS kayıtları ve kodlarıdır. Yalnızca transport değişir: port 53’te ham bir UDP veya TCP paketi yerine, aynı istek port 443’te bir HTTPS isteğinin içine sarılır.

dig bazen neden söylenmeden TCP kullanıyor?

Bir UDP yanıtı TC biti ayarlanmış şekilde kesik geri geldiğinde, standartlara uygun bir istemci tam yanıtı almak için sorguyu otomatik olarak TCP üzerinden yeniden gönderir. Bunu en çok DNSSEC etkin alan adlarında veya aynı türden birçok kaydı olanlarda görürsünüz.

mDNS, port 5353’te, İSS’min DNS’iyle aynı mı?

Hayır. mDNS yalnızca yerel ağ segmentinizde çalışır, merkezi bir sunucusu yoktur, ve aynı bağlantıdaki cihazlar için device.local gibi isimleri çözer. example.com gibi genel bir alan adını çözmekle hiçbir ilgisi yoktur.

Bugün normal bir EDNS0 yük boyutu nedir?

RFC 6891, pratik bir varsayılan olarak 4096 bayt önerir, ve çoğu güncel çözümleyici, ancak o bile yetmediğinde TCP’ye geri dönmeden önce, orijinal 512 baytlık tavanın çok üzerinde bir şeyi o aralıkta duyurur.