DNS sunucularının bilinmeyen etki alanı isteklerine yanıt vermesini gerektiren RFC

Alan adı kayıt sitem ve DNS sağlayıcım şu anda bilinmeyen alan adlarına yönelik DNS isteklerini yok sayıyor. Yoksaymak demek, kara delikleri kastediyorum ve hiçbir zaman yanıt vermiyor, bu da DNS istemcilerimin ve çözümleyici kütüphanelerinizin yeniden denemesine, geri çekilmesine ve nihayetinde zaman aşımına neden oluyor.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Diğer popüler alan adı hizmetlerini incelerken, diğer sağlayıcılar 5 RCODE (REFUSED) döndürdüğü için bu davranışın oldukça benzersiz olduğunu görüyorum:

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Hepsi aşağıdaki gibi bir şey döndürür:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

veya

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Geri dönmek REFUSEDveya NXDOMAINhemen IMHO, sunucu odası katındaki isteği bırakmak yerine uygundur.

Sağlayıcımın sunucularının yanıt vermemesinden şikayet ettiğimde, RFC'yi sunucularının ihlal ettiğini belirtmemi istiyorlar. Sunucularının tüm isteklere yanıt vermesi gerektiğini kanıtlamamı istediklerini biliyorum ama öyle olsun.

Sorular :

• Yinelenen istek kimlikleri veya bir çeşit DOS yanıtı olmadığı sürece, sunucunun her zaman isteğe yanıt vermesi şarttır. Bu doğru mu?
• Koşullarımı desteklemek için hangi RFC'yi ve spesifik bölümü teklif etmeliyim?

Bana göre, bir DNS sorgusuna yanıt vermemek kötü. Çoğu istemci aynı sorguyu aynı DNS sunucusuna veya başka bir sunucuya geri gönderir ve sonra yeniden iletir. Yalnızca istemcileri yavaşlatmakla kalmaz, aynı sorguyu yetkili ad sunucularına ve NS girişlerine bağlı olarak kendi veya diğer sunucular tarafından tekrar yapılmasına neden olurlar.

In RFC 1536 ve 2308 Ben performans nedenleriyle ve aynı sorgunun durdurma yeniden iletim negatif önbelleğe alma hakkında birçok bilgi bkz. 4074 yılında , 0 RCODE ile boş bir yanıt döndürme hakkında bilgi görüyorum, böylece istemci, boş bir yanıtın başka bir örneği olan A RR'leri sormasına neden olacak ipv6 bilgisi olmadığını biliyor.

Ancak bir DNS sunucusunun, muhtemelen ima edildiği için bir isteğe yanıt vermesi gerektiğini söyleyen bir RFC bulamıyorum.

Belirli bir sorun, etki alanımı (ve ilişkili DNS kayıtlarını) sunucularına geçirdiğimde veya hizmetlerine yeni bir etki alanı kaydettirdikten sonraki ilk X dakika içinde gerçekleştiğinde ortaya çıkar. Yetkili ad sunucularının değiştiği zaman (bu günlerde oldukça hızlı) ve sunucuları DNS kayıtlarımı sunmaya başlama arasında bir gecikme var. Bu gecikme süresi boyunca, DNS istemcileri sunucularının yetkili olduğunu düşünürler, ancak bir istekle hiçbir zaman yanıt vermezler REFUSED. İyi olan gecikmeyi anlıyorum, ancak DNS taleplerine cevap vermeme kararına katılmıyorum. Kayıt için, sistemlerinde bu sınırlamaların nasıl çözüleceğini anlıyorum, ancak hala hizmetlerini DNS protokolüne daha uygun olacak şekilde geliştirmek için onlarla çalışıyorum.

Yardım için teşekkürler.

Düzenle:

Bunu gönderdikten ve sağlayıcımı takip ettikten birkaç ay sonra, sunucularını NXDOMAINbilinmeyen alanlara geri dönecek şekilde değiştirdiler .

Shane'nin tavsiyesi doğrudur. Kesmeye başlamadan önce verileri yetkili bir sunucudan diğerine geçirmemek bir kesinti davetidir. Bu noktadan sonra ne olursa olsun, bu NS kayıtlarını sallayan kişi tarafından başlatılan bir kesinti. Bu, neden daha fazla kişinin bu şikayeti sağlayıcınıza yapmadığını açıklar.

Bununla birlikte, bu hala cevaplanması ilginç bir soru, bu yüzden çatlağımı alacağım.

DNS sunucularının temel işlevleri toplu olarak STD 13'ü oluşturan RFC 1034 ve RFC 1035 belgeleri tarafından kapsanmaktadır . Cevap ya bu iki RFC'den gelmeli ya da onu güncelleyen daha sonraki bir RFC tarafından netleştirilmelidir.

Devam etmeden önce, DNS kapsamı dışında çağrılması gereken büyük bir tuzak var: bu RFC'lerin her ikisi de BCP 14 (1997), MAY, MUST, MUST, SHOULD, vb. Dilini açıklayan belge.

• Bu dil resmileştirilmeden önce yazılmış olan standartlar, açık bir dil kullanabilir, ancak bazı durumlarda kullanmamıştır. Bu, yazılım, kitle karışıklığı vb.
• STD 13 maalesef birçok alanda yorumlayıcı olmaktan suçlu. Bir operasyon alanında dil sağlam değilse, açıklayıcı bir RFC bulmak sıklıkla gereklidir.

Bu arada o dışarı ile, en ne başlayalım RFC 1034 §4.3.1 şöyle demektedir:

• Sunucu için en basit mod özyinelemeli değildir, çünkü yalnızca yerel bilgileri kullanarak sorguları yanıtlayabilir: yanıt bir hata, yanıt veya yanıta "daha yakın" başka bir sunucuya bir başvuru içerir. Tüm ad sunucuları, özyinelemesiz sorguları uygulamalıdır.

...

Yinelemeli hizmet istenmezse veya kullanılamıyorsa, yinelemesiz yanıt aşağıdakilerden biri olacaktır:

• Adın mevcut olmadığını belirten yetkili bir ad hatası.

• Geçici bir hata göstergesi.

• Bazı kombinasyonları:

  Soruyu cevaplayan RR'ler, verilerin bir bölgeden gelip gelmediğini veya önbelleğe alındığını gösterir.

  Yanıtı gönderen sunucudan daha yakın ataları olan bölgeleri olan ad sunucularına yönlendirme.

• Ad sunucusunun düşündüğü RR'ler istekte bulunan için yararlı olacaktır.

Buradaki dil oldukça sağlam. "Olması gereken" yoktur, ama "olması gerekir". Bu, nihai sonucun 1) yukarıdaki listede tanımlanmış olması veya 2) Standartları İzleme'de işlevselliği değiştiren daha sonraki bir belgenin izin vermesi gerektiği anlamına gelir. İsteği görmezden gelmek için var olan böyle bir sözün farkında değilim ve araştırmanın çürütüleceği dili bulmak için geliştiricinin üzerinde olduğunu söyleyebilirim.

Ağ kötüye kullanım senaryolarında DNS'nin sık rolü göz önüne alındığında, DNS sunucusu yazılımının teknik olarak bunun ihlali olabilecek zeminde trafiği seçici bir şekilde düşürmek için düğmeler sağlamadığı söylenmemelidir. Bununla birlikte, bunlar ya varsayılan davranışlar ya da çok muhafazakar temerrütler; her ikisinin de örnekleri, yazılımın belirli bir adı bırakmasını gerektiren kullanıcı ( rpz-drop.) veya belirli sayısal eşiklerin aşılmasıdır (BIND'ler max-clients-per-query). Bu, bir standardı ihlal eden eski ürünler için toleransı artıran bir seçenek olmadığı sürece, yazılımın tüm paketler için varsayılan davranışı standardı ihlal edecek şekilde tamamen değiştirmesi benim deneyimimden neredeyse duyulmuyor . Burada durum böyle değil.

Kısacası, bu RFC, operatörlerin takdirine bağlı olarak ihlal edilebilir ve ihlal edilir, ancak genellikle bu bir hassasiyetle yapılır. Özellikle profesyonel fikir birliği (örnek: BCP 16 §3.3 ), bir bütün olarak DNS sisteminde gereksiz yük oluşturmanın istenmediği lehine olduğunda, standardın bölümlerini uygun olduğu gibi tamamen göz ardı etmek son derece nadirdir . Hiçbir yetkili verinin mevcut olmadığı tüm talepleri bırakmaya gerek kalmadan yapılan yeniden denemeler, bunu göz önünde bulundurarak istenenden daha azdır.

Güncelleme:

Elbette zeminde sorguları bırakmanın istenmediği konusunda @Alnitak, şu anda bu konuyu ayrıntılı olarak kapsayan bir Taslak BCP'nin olduğunu bizimle paylaştı . Bunu bir alıntı olarak kullanmak biraz erken, ancak topluluk mutabakatının burada ifade edilenlerle hizalanmasının güçlendirilmesine yardımcı oluyor. Özellikle:

Bir ad sunucusu saldırı altında değilse, aşağıdaki delegasyonların bir sonucu olarak kendisine yöneltilen tüm sorgulara yanıt vermelidir. Ayrıca kod, bölgeyi sunmak için yapılandırılmamış olsa bile sunucuda bir temsilci olmadığını varsaymamalıdır. Bozuk temsilciler DNS'de sık karşılaşılan bir durumdur ve sunucunun yapılandırılmadığı bölgeler için sorgu almak, sunucunun saldırı altında olduğunu göstermez. Ana bölge operatörlerinin, yetki veren NS kayıtlarının yetki verilen bölgenin kayıtlarıyla tutarlı olup olmadığını düzenli olarak kontrol etmesi ve [RFC1034] olmadığında bunları düzeltmesi gerekir. Bu düzenli olarak yapılsaydı, kırık heyet örnekleri çok daha düşük olurdu.

Bu yanıt, bu belgenin durumu değiştiğinde güncellenecektir.

Bir alan adı için yetkili DNS'yi yeni bir sağlayıcıya taşırken, alan adı kaydı (whois) bilgilerinizi değiştirmeden önce her zaman (her zaman!) Yeni sağlayıcıyı açıkça test etmeli (ve doğru, yapılandırılmış kayıtlar gönderdiğinden emin olmalısınız) yeni yetkili DNS sunucularına yönlendirin.

Kabaca, atacağınız adımlar:

1. Her şeyi yeni DNS sağlayıcısında ayarlayın. Tüm bölgeleri oluşturmalı ve doldurmalısınız.

2. Yeni yetkili sunucuların düzgün çalıştığından emin olun. Onları açıkça sorgulayın:

   dig @new-ns.example.com mydomain.com
   

   Sorunuza göre, bu sorgulara yanıt vermiyorlar mı? Ancak, bu noktada olmaması gereken "bilinmeyen alanlar" dediniz, sistemlerinde tam olarak yapılandırılmalıdır (ve yapılandırdığınız kayıtlara yanıt olarak).

   Eğer Ama eğer var zaten onların sisteminde etki alanını yapılandırılmış, bu noktada doğru kayıtları ile yanıt gerekir. Değilse, bölgeyi düzgün bir şekilde barındırmıyorlar ve onlara bağırmalısınız; yapılandırılmayan bir etki alanına yanıt verip vermemesinin önemsiz olması gerekir. (Söylediklerinizi hala bir şekilde özlüyorsanız, lütfen bana bildirin).

3. Eski DNS sağlayıcısını trafik artık isabet etmeyene kadar çalışır durumda bırakarak (en az 24 saat verin) alan adı kayıt kuruluşunuzla (whois) yetkili ad sunucularını değiştirin.

Geçiş yapmadan önce yeni sağlayıcı kesinlikle kayıtlara sahip olamıyorsa, nasıl yanıt verdikleri gerçekten önemli olmayacaktır - kullanıcıları sorguyu tamamen reddeden yetkili bir kişiye yönlendirmek, alan adınız için olduğu gibi kesinti süresine neden olacaktır. hiç yanıt alamıyorum.