DNS sorguları her zaman UDP üzerinden mi geliyor?

Bu konuyu araştırmak için biraz zaman harcadım ve kesin bir cevap bulamadım, bu yüzden yinelenen olmadığından eminim ve sorum bir güvenlik ihtiyacına dayanıyor olsa da, hala güvenli olduğunu düşünüyorum. buraya sorun ama güvenlik topluluğunu taşımam gerekip gerekmediğini bana bildirin.

Temel olarak, DNS sorguları hiç TCP kullanıyor mu (eğer öyleyse, bu hangi senaryoda ortaya çıkabilir)? Yine, sadece sorgular hakkında konuşuyorum. TCP üzerinden seyahat etmeleri mümkün mü? Etki alanları yalnızca en fazla 253 bayt olabilir ve UDP paketleri 512 bayt kadar büyük olabilirse, sorgular her zaman UDP olarak çıkmaz mı? Çözülebilir bir sorgunun TCP kullanımını gerektirecek kadar büyük olabileceğini düşünmedim. Bir DNS sunucusu 253 bayttan daha büyük bir etki alanı için bir istek aldıysa, sunucu bunu düşürür mü / çözmez mi? Eminim burada bazı yanlış varsayımlar yaptım.

Bazı bağlamlarda, DNS sorgularını güvenlik izleme aracına dahil etmek için güvenlik grubuyla çalışıyorum ve çeşitli nedenlerden dolayı bu trafiği, DNS sunucuları ve etki alanı denetleyicilerinde standart paket yakalama yoluyla yakalamaya karar verdik. Temel gereksinim, tüm DNS sorgularını yakalamaktır, böylece müşterinin herhangi bir alanı etkilemek için hangi müşteriyi çözmeye çalıştığını tanımlayabilirler. Bu gereksinime dayanarak, DNS yanıtlarını veya bölge trafiği gibi diğer trafik aktarımlarını yakalamakla da ilgilenmiyoruz. Bu, aynı zamanda log hacmini mümkün olduğu kadar sınırlandırmamız gerektiğinden de kaynaklanıyor. Bu nedenle, yalnızca DNS sunucusu için hedeflenen ve UDP üzerinden gönderilen DNS sorgularını yakalamayı planlıyoruz. Daha fazla bağlam için (burada sürünen bir tür soru kapsamı), artık güvenliği genişletmemiz gerekebileceği ortaya çıktı. ibility Görünürlük, böylece DNS üzerinden çalışan gizli kanallar (örneğin, DNS yanıtlarını ve daha sonra TCP trafiğini yakalama ihtiyacı sunacak) gibi etkinlikleri izleyebilirler. Ancak bu tür bir senaryoda bile, herhangi bir giden DNS trafiğinin aramalar / sorgular şeklinde olacağını ve kötü niyetli bir kaynaktan (ilk paragraftaki gerekçelerim nedeniyle) bile, bunların her zaman UDP'nin üzerinde olacağını düşündüm. Yani bu bazı ek sorular getiriyor:

• En azından ana hatlarıyla belirttiğim yaklaşımla konuşmanın yarısını mı yakalayacağız? Veya bir müşteri hiç sorgu şeklinde olmayan bir DNS trafiği gönderir mi? (belki bir DNS sunucusunun yanıtına bir tür cevap gibi ve belki de TCP üzerinden bitiyor olabilir)

• DNS sorguları TCP kullanmak için değiştirilebilir mi? Bir DNS sunucusu TCP üzerinden gelen bir DNS sorgusunu kabul eder ve yanıtlar mı?

İlgili olup olmadığından emin değiliz, ancak DNS isteklerini yetkili DNS sunucularıyla sınırlandırıyoruz ve 53 numaralı bağlantı noktası üzerinden giden diğer tüm trafiği engelliyoruz. Kesinlikle bir çaylakım, bu yüzden sorumun uygun olmaması durumunda özür dilerim ve bana bildirin nasıl değiştirmeliyim

Normal DNS sorguları UDP bağlantı noktası 53'ü kullanır, ancak daha uzun olan sorgular (> 512 oktet) 'kesilmiş' bir yanıt alır; bu, tüm sorgunun gönderilmesini / alınmasını kolaylaştırmak için bir TCP 53 konuşmasına yol açar. Ayrıca, DNS sunucusu 53 numaralı bağlantı noktasına bağlanır, ancak sorgunun kendisi bağlantı noktası 53'e gönderilen rasgele yüksek numaralı bir bağlantı noktasından (49152 veya üzeri) kaynaklanır. Yanıt, aynı bağlantı noktasına 53 numaralı bağlantı noktasından döndürülür.

DNS Tarafından Kullanılan Ağ Bağlantı Noktaları | Microsoft Dokümanlar

Bu nedenle, ağınızdaki DNS sorguları üzerinde bazı güvenlik aramaları yapmayı planlıyorsanız, yukarıdakileri dikkate almanız gerekir.

Arama dışı trafiğe gelince, DNS'nin diğer DNS sunucularını yeni kayıtlarla güncellemek için bölge aktarımlarını (AXFR sorgu türü) kullandığını da göz önünde bulundurun. Orta saldırıdaki bir adam böyle bir transferle başlayabilir, DDOS bir Birincil isim sunucusudur, böylece bir Sekonder'e güncellenen kayıtları sormak için çok meşgul olur. Hacker daha sonra, aynı DNS'i 'zehirlenmiş' kayıtları beslemek için, Sahte DNS etki alanlarını tehlikeye sokan ana bilgisayarlara yönlendiren İkinciye kaydeder.

Bu nedenle, güvenlik denetiminiz AXFR sorgu tipine çok dikkat etmeli ve DNS sistemleriniz sadece belirli IP adreslerinden AXFR değişimlerini kabul etmelidir.

SANS Enstitüsü Bilgi Merkezi Okuma Odası | sans.org

Bu George'un cevabına bir yorum olarak başladı, ancak uzun sürdü. Büyük resim, biraz tarihin anlaşılmasını gerektirdiğinden biraz karmaşıktır.

• RFC 1035, başlangıçta UDP'nin parçalanmasını önlemek için 512 baytlık bir limit istedi. DNS işlemlerinin ek yükünü en aza indirgemek için son çare seçenekleri olarak parçalanmış UDP datagramları ve TCP seçildi. Bölge transferleri, doğası gereği> 512 bayt alan bölge transferleri nedeniyle her zaman TCP kullanır. (UDP ile başlamak için hiç bant genişliği kaybı olur)

• Kısaltmada TCP yeniden denemesi, 1989'dan beri RFC 1123'te belirtildiği gibi yaygın olarak desteklenmektedir .

• EDNS (0), RFC 6891 (2013) tarafından tanımlanmıştır ve bundan önce 1999 yılına kadar olan bir Önerilen Standart olarak mevcuttu . İstemcilerin ve sunucuların 512'den büyük UDP boyutlarını pazarlayabilecekleri bir mekanizma tanımlar. EDNS'nin (0) yeniliği nedeniyle, birçok donanım cihazı, uyumlu paketlerin atılmasına neden olan DNS paketlerinin yapısı hakkında varsayımlarda bulunur. En sık neden, 512 bayttan fazla DNS iletisinin geçersiz olduğu varsayımıdır, ancak bu birkaç tanesi arasındadır.

Bunu gözlemlenen davranışlara bölersek:

1. DNS sorguları genellikle yanıtın başlayamayacak kadar büyük olacağı bilinmediği sürece UDP olarak başlar. (bölge transferleri)
2. Cevap verebilir bir kesilmiş yanıt görülürse istemci TCP yeniden deneme tetikler. Bu oldukça iyi desteklenmektedir.
3. 512 bayttan daha fazlası, UDP yanıt olabilir müşteri daha büyük bir yük reklam (0) EDNS kullanıldığında görülen olması ve alıcı sunucusu destekler o. Bu sadece ikisi arasında oturan donanımın karışmaması ve düşmüş ya da sıkışmış bir pakete neden olması durumunda gerçekleşir .
4. Müşteri , bir cevap görünmezse daha az reklam yükü olan bir EDNS (0) sorgusunu yeniden denemeyi seçebilir, ancak özellikler uygulamalar arasında farklılık gösterecektir.
   • Sonunda cevap veren cevabın istenen boyuta sığmayacak kadar büyük olabileceğini ve yukarıdaki davranış # 2 ile sonuçlanabileceğini not etmek önemlidir. (TCP yeniden denediğinizde)
   • Müşteri tarafı , sonunda başarı ile sonuçlanan boyutu hatırlamayı tercih edebilir . Bu, tekrar sorgulayan gereksiz sorguları boşa harcamasını önler. Aksi takdirde, özellikle nihai sonuç TCP geri dönüşü gerektiriyorsa, oldukça israf olur.

Ayrıca, RFC 7766'nın TCP üzerinden bağlantının yeniden kullanılmasına izin verdiğini ve doğada TCP üzerinden sorgu boru hattıyla karşılaşmanın mümkün olduğunu unutmamalısınız . Bazı araçlar yok böyle bir örnek olma dnscap, ilk TCP oturumu görülen ötesinde DNS sorgularını algılar.

Orada olan RFC 7766, TCP üzerinden DNS Taşımacılık - Uygulama Gereksinimleri .

1. Giriş

DNS [ RFC1034 ] işlemlerinin çoğu UDP [ RFC768 ] üzerinden gerçekleştirilir. TCP [ RFC793 ] her zaman tam bölge aktarımlarında (AXFR kullanarak) kullanılır ve genellikle boyutları DNS protokolünün orijinal 512 bayt sınırını aşan iletilerde kullanılır. Artan DNS Güvenliği (DNSSEC) ve IPv6 dağıtımı, yanıt boyutlarını ve dolayısıyla TCP kullanımını artırdı. Artırılmış TCP kullanımına duyulan ihtiyaç, adres sahteciliğine karşı sağladığı koruma ve dolayısıyla yansıma / büyütme saldırılarında DNS'den faydalanma ile de sağlanmıştır. Şimdi Yanıt Oranı Sınırlamasında [ RRL1 ] [ RRL2 ] yaygın olarak kullanılmaktadır . Ek olarak, [ TLS üzerinden over DNS] gibi DNS gizlilik çözümleri üzerinde yapılan son çalışmalar] DNS üzerinden TCP gereksinimlerini tekrar ziyaret etmek için başka bir motivasyondur.

[RFC1123] bölüm 6.1.3.2'de ;

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Bununla birlikte, bazı uygulayıcılar TCP desteğinin DNS protokolünün isteğe bağlı bir özelliği olduğu anlamına gelmek için yukarıda belirtilen metni almıştır.

DNS sunucusu operatörlerinin çoğu zaten TCP'yi desteklemektedir ve çoğu yazılım uygulaması için varsayılan yapılandırma TCP'yi desteklemektir. Bu belgenin birincil izleyici kitlesi, TCP için sınırlı desteği birlikte çalışabilirliği kısıtlayan ve yeni DNS özelliklerinin dağıtımını engelleyen uygulayıcılardır.

Bu nedenle bu belge, temel DNS protokolü özelliklerini günceller; böylece TCP desteği bundan böyle tam bir DNS protokolü uygulamasının GEREKLİ bir parçası olacaktır.

Dikkat edilmesi gereken uygulama detaylarının yanı sıra , artan TCP kullanımının (bakınız Ek A ) avantajları ve dezavantajları vardır . Bu belge bu sorunları ele almaktadır ve TCP'yi DNS için geçerli bir aktarım alternatifi olarak sunmaktadır. [ RFC5966 ] ' nın içeriğini, DNS'de ve diğer İnternet protokollerinde, araştırma, geliştirme ve TCP uygulamalarından öğrenilen ek düşünceler ve derslerle birlikte genişletir .

Bu belge, DNS sunucuları işletmecilerinin karşılaması için özel bir gereklilik göstermese de, işletmenlere sunucuları ve ağlarında TCP desteğinin optimum olmasını sağlamaya yardımcı olmak için bazı önerilerde bulunur. TCP'yi desteklememedeki başarısızlığın (veya ağ katmanında TCP üzerinden DNS'in engellenmesi) muhtemelen çözülme başarısızlığına ve / veya uygulama düzeyinde zaman aşımına neden olacağı belirtilmelidir.

TCP / 53'ü hiçbir yönde filtrelememelisiniz. Örneğin, nsupdatesorgular istek çok büyük olduğu anda TCP'yi kullanabilir (bu hızlı olabilir). Bu nedenle, bağlantı noktası 53 için UDP ve TCP'nin (IPv4 ve V6'da) her yöne akmasına izin vermelisiniz.

Ayrıca, TLS üzerinden DNS konusunda giderek daha fazla çalışma yapıldığından, her iki yönde de TCP'ye ihtiyaç duyulacaktır. RFC7858'e bakınız.