.de Alan Kesintisi: Registry Altyapısı Çöktüğünde Neler Olur?

Geçen mayısta Almanya'nın internet'inde tuhaf bir şey yaşandı. Amazon.de erişime kapandı. Deutsche Telekom hizmetleri kayboldu. DHL, Bahn, Spiegel—hiçbiri ulaşılamaz oldu. Oysa hosting sunucuları normal çalışıyordu. Domain'ler düzgün kayıtlıydı. DNS kayıtları doğru yerleri gösteriyordu. Monitoring panellerindeki her gösterge yeşildi duruyor, milyonlarca kullanıcı ise bağlantı hatası almaya devam ediyordu.

Sorun kimsenin aradığı yerde değildi.

Hepsini Çöken Görünmez Katman

Registry seviyesinde yaşanan arızalar evinizin temelinin çatladığını keşfetmek gibidir—bunu daha iyi boya ile düzeltmek mümkün değildir. DENIC (Almanya'nın ülke kodlu alan adı kayıt kuruluşu), .de bölgesini yönetmek için yeni nesil bir altyapı devreye almıştı. Taze kod. Güvenlik denetimleri geçmişti. Dış doğrulamalar tamamlanmıştı. Sonra 5 Mayıs'ta planlanan anahtar rotasyonu yapıldı ve her şey ters gitti.

Teknik kısma gelince: sistem, üç ayrı güvenlik cihazına dağıtılacak tek bir şifreleme anahtarı üretecekti. Standart bir yöntem. DNSSEC için kritik—bu teknoloji DNS yanıtlarını şifreli olarak doğrular, böylece gerçek alan adı ile konuştuğunuzdan emin olursunuz, saldırganın tuzağına düşmezsiniz.

Ancak hatalı kod bunun yerine üç farklı anahtar üretti. Biri yayınlandı. Diğer ikisi imzalamaya devam etti, yayınlanan doğrulama anahtarıyla tamamen uyumsuz. Sonuç: .de DNSSEC imzalarının yaklaşık üçte ikisi matematiksel olarak geçersiz hale geldi. Bunu kontrol eden resolver'lar—Google'ın 8.8.8.8, Cloudflare'in 1.1.1.1 ve Quad9—yanıtları hemen reddetti ve hata gösterdi.

İzleme Paradoksu

İşin can sıkıcı kısmı: DENIC'in kendi izleme araçları bunu yakaladı. Üç ayrı doğrulama sistemi bu anormallliği dakikalar içinde işaretledi. Ve sonra... hiçbir şey. İkaz'lar vardı ama zamanında işleme alınmadı. Çözüm bulunana kadar üç saat geçti ve onu ilk bulan DENIC olmadı.

Bu, anlamamız gereken bir örüntüdür. Hızlı yanıt veren olay yönetimi olmayan otomatik izleme sadece bir tiyatro gösterisidir. Güvenli olma yanılsamasını yaratır. Her yeşil panel, bir anda her şey ters gidene kadar "her şey yolunda" der—ve o noktada milyonlarca etkilenen kullanıcı ve üç saatlik bir olay yanıt boşluğu oluşmuş olur.

Hasar Neden Eşit Dağılmadı (Ve Bu Neden Sorun?)

Kesinti rahatsız edici bir asimetri gösterdi: bazı kullanıcılar tamamen erişim kaybı yaşadı. Diğerleri hiçbir şey görmedi. Bu fark hangi DNS resolver'ı kullandıklarına bağlıydı.

Cloudflare'in 1.1.1.1 ve Google Public DNS gibi modern resolver'lar varsayılan olarak DNSSEC doğrulamasını uygularlar. Geçersiz imzaları reddederler. Eski ISS tarafından işletilen resolver'lar? Birçoğu DNSSEC doğrulamasını yapmıyor. Şifreli geçerliliğe aldırış etmeden yanıtları serviste sunuyorlar. Yani anneannesi'nin interneti normal çalışırken startup'ınızın altyapısı başarısız olabilir—sadece hangi resolver'ı yapılandırdığınız nedeniyle.

Bu, görünmez altyapı sorununun bir mikro versiyonudur: güvenlik gelişmeleri, ancak ekosistemin yeterince benimsemesi durumunda işe yarar. Ve yeterince benimsendiklerinde, kesintileri önlemek yerine büyütebilirler.

DNS Güvenliğinden Çıkan Ders

.de alan adları arasında DNSSEC kullanımı yaklaşık yüzde 3,6 seviyesindedir—17,9 milyondan 645,000 alan adı kadarı. Nispeten düşük bu benimsenme oranı, tam etkinin yüksek trafikli, iyi yönetilen alan adlara sınırlanmasını sağladı: DNSSEC'in etkinleştirilmiş olma ihtimali en yüksek olanlar ve bunu doğrulayan resolver'lar kullananlar. Büyük oyuncular vuruldu. Küçük siteler çalışmaya devam etti.

Ama burada rahatsız edici bir gerçek var: DNSSEC benimsenmesi arttıkça (ve artmalıdır), bunun gibi olaylar daha sert ve daha geniş çapta oluyor. Güvensiz altyapıya daha iyi güvenlik eklemeyi bekliyorsanız, hiçbir acı çekmemeyi bekleyemezsiniz. Geçiş maliyeti vardır.

Sizin Domain Stratejiniz İçin Bunun Anlamı

Kritik alan adları işletiyorsanız, bu olay DNS altyapısı hakkındaki düşüncenizi yeniden şekillendirmelidir:

Resolver'larınızı çeşitlendirin. Tek bir halka açık resolver'a güvenmeyin. Birden fazlasını kullanmayı düşünün ve gerçekte hangisini sorgulayacağınızı izleyin. Bazı uygulamalar program aracılığıyla resolver'lar arasında yük dengeleme yapabilir. Bunu kullanın.

Registry'nin olay yanıt sürecini anlayın. Tüm ülke kodlu alan adı kayıt kuruluşları aynı izleme ve yükseltme prosedürlerine sahip değildir. Belirli bir ülke alan adında önemli altyapı işletiyorsanız, kimin sorumlu olduğunu, nasıl uyarıldığını bilin. DENIC'in olay sonrası analizi şeffaftı ve yardımcıydı, ancak ikaz gecikmesi gerçek bir zayıflık ortaya koydu.

DNSSEC önemlidir—ama uygulamayı doğrulayın. .de kesintisi DNSSEC yüzünden yaşandı, spesifik olarak anahtar üretim hatası nedeniyle. Bu DNSSEC'i atlamanız gerektiği anlamına gelmez. Kayıt kuruluşunuzdan uygun test, sürekli doğrulama ve hızlı olay yanıtını talep edin anlamına gelir.

Doğru katmanlarda izleme yapın. Hosting sağlayıcınızın yeşil paneli, registry çöktüğünde hiçbir şey ifade etmez. Registry seviyesi izlemeyi sağlık kontrolllerinize entegre edin. Cloudflare gibi hizmetler, müşteri şikayetleri için beklemekten daha erken uyarı verebilir.

Cloudflare'in Rolü

Başlık Cloudflare'i ilk düzeltici olarak bahsediyor. Bu tesadüf değil. Cloudflare'in 1.1.1.1 resolver'ı hemen etkilendi ve Cloudflare küresel olarak dağıtılmış nameserver'ler ve altyapı işlettiği için sorunu hızlı tespit edebildi. Ayrıca derinlemesine DNS izleme yapıyorlar—bunu ölçekte görüyorlar.

Bu, DNS sağlayıcısını seçmenin neden sadece "çalışıp çalışmadığından" öte önemli olduğunun bir nedenidir. İyi bir DNS sağlayıcısı tüm ağı genelinde sorunları görür ve tek bir operatöre görünmez olacak arızaları üçgenleştirebilir.

Gerçekte Neler Değişti

DENIC güncellenmiş bir anahtar rotasyon yordamı ve geliştirilmiş izleme ikaz yükseltmesi çıkardı. Üçüncü nesil altyapı yıkılmadı—debug edildi. Hatalı kod düzeltildi. Sorunu tespit eden izleme sistemi, uyarıların gerçekten olay yanıtını tetiklemesini sağlamak için iyileştirildi.

Sıkıcı çözüm: daha iyi test, daha iyi uyarılar, daha iyi prosedür dokümantasyonu. Seksi değil, ama bir sonraki üç saatlik kesintiye karşı korunmanızı sağlayan budur.

Asıl Öğrenecek Ders

Registry altyapısı, görünmez olması gerektiği için çoğu alan adı operatörü için bir kör nokta'dır. Registrar'ınız bununla ilgilenir. ülke kodlu Alan adı registry'si ilgilenir. Siz DNS kayıtlarınız ve hosting'iniz ile ilgilenirsiniz. Herkes kendi alanında çalışır.

Ama alanların kenarları vardır ve bazen kenarlar çöker. Çöktüğünde, birden fazla katmanda görünürlüğe sahip olmak—registrar sağlığı, resolver performansı, registry olay yanıtı—kritik hale gelir. .de kesintisi, tüm DNS güvenlik tavrınızı dışarıya devrettirememizi öğretiyor. Uygulama katmanının altında neler olduğunu anlamak zorundasınız, hatta biri onu işletse de.

5 Mayıs'ın gerçek altyapı dersi bu: bazen en kritik arızalar kontrol etmediğiniz katmanlarda olur, tam da bu yüzden onları anlamaya ihtiyacınız vardır.