Bir ad sunucusunun, TCP üzerinden yapılan sorguları yanıtlaması gerektiği doğru mu?

Birkaç büyük web barındırma sunucusunun DNS sunucularının izlenmesini ayarlama sürecindeyim. Amacım, dns sunucularının yanıt sürelerini ping'e verdikleri yanıtı izleyerek karşılaştırmak.

Bu süreçte, Bluehost ad sunucularının ping'e yanıt vermediğini keşfettim. Bluehost.com'da Pingdom DNS Check'i çalıştırarak daha fazla bilgi almaya çalıştım ve aşağıdaki hatayı verdi:

İsim sunucusu ns1.bluehost.com (74.220.195.31), TCP üzerinden sorgulara cevap vermiyor.

Ad sunucusu, TCP üzerinden gönderilen sorguları cevaplayamadı. Bu muhtemelen isim sunucusunun doğru kurulmamış olmasından veya güvenlik duvarında yanlış yapılandırılmış filtrelemeden kaynaklanmaktadır. Bölge aktarmalarını sağlamadıkça DNS’in TCP’ye ihtiyaç duymaması oldukça yaygın bir yanılgıdır - belki de isim sunucusu yöneticisi TCP’nin genellikle bir gereklilik olduğunun farkında değildir.

Aşağıdakileri bilmek istiyorum:

• Yukarıdaki ifade ne derece doğrudur?
• TCP üzerinden sorgulara cevap vermeyen bir ad sunucusunun etkileri nelerdir?

Pingdom'un tanı metni tam olarak doğru. TCP sadece bölge transferleri için değildir .

DNS sunucusu uygulamaları vardır şimdi TCP, başına destekleme (çok RFC şey gereğine göre cinsinden) "Gerekli" RFC 5966 , "- Uygulama Gereksinimleri TCP üzerinden DNS Taşımacılık".

Bunun sunucu yazılımı uygulamasında bir gereklilik olduğuna dikkat edin, hiçbir sunucunun çalışması için kesinlikle geçerli değildir - operasyonel uygulama kapsanmamaktadır.

Bununla birlikte, belirli DNS sunucularınız TCP'yi destekleyecek şekilde yapılandırılmadıysa veya engelleniyorsa, uzun vadeli etki DNSSEC'yi doğru bir şekilde destekleyemez. Benzer şekilde, yanıtların 512 baytı aşmasına neden olan herhangi bir diğer DNS verisi de engellenebilir.

ob feragatname: Bu RFC'yi yazdım.

EDIT RFC 5966 şimdi RFC 7766 ile değiştirildi

TCP ve UDP'yi desteklemelidir - TCP,> 512 bayt (bölge aktarımlarını da içerecek şekilde) boyutları yanıtlamak içindir (yine de okuduğum öğelere göre. Çalıştığım NS'ler için genellikle TCP ve UDP'yi etkinleştiriyorum ...)

RFC'lerin konuyla ilgili ne söylediğini bilmek güzel ve bununla ilgili çok iyi bir cevabımız var, ancak pratik amaçlar için DJBDNS'in yazarı Prof. Daniel J. Bernstein'in tavsiyesini oldukça eğlenceli buluyorum.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

TCP sorguları ne zaman gönderilir?

Aşağıdaki durumlardan birindeyseniz, DNS sunucunuzu TCP sorgularını yanıtlayacak şekilde yapılandırmanız gerekir:

• 512 bayttan daha büyük kayıt kümeleri yayınlamak istiyorsunuz. (Bu neredeyse her zaman bir hatadır.)
• Örneğin, bir üçüncü taraf sunucuya giden bölge aktarımlarına izin vermek istiyorsunuz.
• Bir ana sunucu, siz TCP servisini ayarlamadan önce size bir isim vermeyi reddeder.

Bu durumların hiçbirinde değilseniz, TCP hizmeti sağlamanıza gerek yoktur ve ayarlamamalısınız. DNS üzerinden TCP, UDP üzerinden DNS'den daha yavaştır ve hizmet reddi saldırılarına karşı daha savunmasızdır. (Bu BIND için de geçerlidir.)

DNSSEC'den açıkça bahsettiğini unutmayın; Bunun nedeni, DJB'ye göre, DNSSEC "her zaman bir hata" kategorisine giriyor. Daha fazla ayrıntı için https://cr.yp.to/djbdns/forgery.html adresine bakın. DJB'nin, DNSCurve - http://dnscurve.org/ - adında alternatif bir standarda sahip olan ve bazı sağlayıcılar (OpenDNS gibi) tarafından zaten bağımsız olarak kabul edilmiştir. İlgi çekici: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

DJBDNS kurulumuyla ilgili yukarıdaki dokümantasyon özelliklerinin herhangi bir göstergesiyse, yalnızca TCP için AXFR'yi desteklediği görülüyor. Pek çok sağlayıcı hala DJBDNS kullandığından, bu yüzden fazladan çaba harcamadan DNS üzerinden TCP'yi desteklemeyeceklerdir.

PS DJB'nin aslında vaaz ettiği şeyi yaptığını unutmayın. Kendi sunucuları (1), DNSCurve (2) 'yi çalıştırıyorlar, TCP'yi doğru cevaplamıyorlar. Sadece +notcpbaşarılı olur (varsayılan):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

bir +tcpoyunda başarısız olur (görünüşe göre sunucularından hangisinin seçildiğine bağlı olarak farklı bir hata mesajı ile):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

TCP yalnızca gereklidir ve genellikle yalnızca uzun bir yanıt gerektiğinde kullanılır. Olumsuz etkiler olabilir. Bölge aktarımları, büyük oldukları için TCP üzerinden yapılır ve güvenilir olmaları gerekir. TCP'ye güvenilmeyen sunuculardan izin vermemek, yalnızca küçük yanıtların verilmesini sağlamanın bir yoludur.

İmzalı DNS cevaplarının sunulmasıyla birlikte, 512 bayt sınırının UPD cevaplarına gevşetilmesi şartı getirildi. EDNS0, daha uzun UDP yanıtları için mekanizma sağlar. TCP üzerinden DNS'e izin verilmemesi, güvenli bir DNS uygulamasını kırma eğiliminde olabilir.

Yalnızca İnternet'e açık olan 53 numaralı UDP bağlantı noktası olan bir DNS sunucusunu çalıştırmak mükemmel bir şekilde mümkündür. DNS eşlerine TCP erişimi gereklidir, ancak bu küçük bir ana bilgisayar listesidir.

Tam DNS uygulaması için TCP gerektiren yeni bir RFC596 var. Bu, uygulayıcıları hedef almaktadır. Belgeler özellikle operatörlere hitap etmiyor, ancak TCP'ye izin vermemenin bazı başarısızlık senaryolarına yol açabileceği konusunda uyarıyor. TCP üzerinden DNS desteklenmiyorsa ortaya çıkabilecek çok çeşitli hatalar hakkında bilgi verir.

DNS yükseltmesi saldırılarını önlemek için TCP kullanımıyla ilgili tartışmalar yapıldı. TCP'nin kendi hizmet reddi riskleri vardır, ancak dağıtım daha zordur.