DNS istemci hizmetindeki bir kusurun birden fazla Cisco Small Business Switch’in tekrar tekrar yeniden başlatılmasına ve bazı durumlarda tamamen çekirdek dökümüne neden olmasının ardından, 8 Ocak 2026’da bir DNS Çökmesi dünya çapında ağları kesintiye uğrattı. Kesinti, bir avuç anahtarı yöneten küçük BT ekiplerinden birden fazla siteye yayılmış düzinelerce cihazdan sorumlu yöneticilere kadar her büyüklükteki kuruluşu etkiledi.
Sorun gece saat 02.00 sıralarında ortaya çıkmaya başladı ve hızla küresel bir boyuta ulaştı. Ağ yöneticileri, anahtarların her 10 ila 30 dakikada bir aniden yeniden başlatma döngülerine girdiğini ve acil değişiklikler yapılana kadar ağların kararsız veya kullanılamaz hale geldiğini bildirdi. En sık bahsedilen etkilenen modeller arasında CBS250, C1200, CBS350, SG350 ve SG550X serileri vardı. Bazı durumlarda, anahtarlar aynı anda arızalanmadan önce bir yıldan fazla bir süre boyunca güvenilir bir şekilde çalışıyordu.
DNS Çökmesi Modellerde Yeniden Başlatma Döngülerine Neden Oluyor
Etkilenen cihazlardan toplanan günlükler, sürekli olarak DNS istemci işleminde DNSC görevi olarak tanımlanan önemli hatalara işaret ediyordu. En yaygın günlük girişlerinden biri şuydu:
“%DNS_CLIENT-F-SRCADDRFAIL: Sonuç 2. Belirtilen ‘www.cisco.com’ adı için adres belirlenemedi.”
Diğer hatalar, “time-c.timefreq.bldrdoc.gov” gibi NIST tarafından barındırılan sunucular da dahil olmak üzere zaman senkronizasyonu etki alanlarını içeriyordu. Bu DNS çözümleme hataları, anahtarları çekirdek dökümleri oluşturmaya ve otomatik olarak sıfırlamaya zorlayan önemli hataları tetikledi. Yığın izlemeler, çökmelerin doğrudan SNTP veya diğer hizmetlerde değil, DNS istemci kodu yolunda meydana geldiğini gösterdi.
Yöneticiler bu sorunu 4.1.7.17 (26 Mayıs 2025 tarihli), 4.1.3.36 (19 Mayıs 2024 tarihli) ve 4.1.7.24 (27 Ağustos 2025 tarihli) dahil olmak üzere birden fazla donanım yazılımı sürümünde gözlemledi. Etkilenen versiyonların genişliği, yalnızca belirli bir harici durum meydana geldiğinde ortaya çıkan, uzun süredir devam eden bir kusurun varlığını akla getiriyordu.
Yöneticiler DNS Aramalarının ve SNTP Varsayılanlarının Etkisini İzliyor
Cisco’nun topluluk forumlarında bir yönetici, kesintinin kapsamını net bir şekilde anlattı. Kullanıcı, 8 Ocak 2026’da “Cisco CBS250 ve C1200 DNS çökmesi” başlığı altında paylaşımda şunları yazdı:
“Bugün Cisco CBS250 ve C1200’ler için kötü bir gündü. Bunları 1 ila 2 yıldır çalıştırıyorum ve bugüne kadar hiçbir sorun yaşamadım. Sanırım bugün her biri çöktü ve ben DNS yapılandırmasını kaldırana kadar çökmeye devam etti. Bunlardan yaklaşık 50 tane var.”
Aynı yönetici, anahtarlar hem “www.cisco.com” hem de “time-c.timefreq.bldrdoc.gov”u çözmeye çalıştığında ölümcül DNSC hatalarını gösteren ayrıntılı kilitlenme günlüklerini paylaştı. Reddit’te de benzer raporlar ortaya çıktı; burada SG550X sahipleri, farklı sitelerdeki cihazların aynı anda arızalanmaya başladığını doğruladı ve bu da tetikleyicinin yerelleştirilmiş bir yapılandırma hatasından ziyade harici olduğu sonucunu güçlendirdi.
Çökmeleri, bellenimde yerleşik varsayılan hizmetler için DNS aramalarına bağlayan bir model ortaya çıktı. Açık NTP yapılandırmaları olmayan anahtarlar bile time-pnp.cisco.com veya www.cisco.com gibi etki alanlarını çözümlemeye çalıştı. Bu aramalar başarısız olduğunda veya beklenmedik yanıtlar verdiğinde, DNS istemcisi durumu kurtarılabilir değil ölümcül olarak değerlendirdi ve doğrudan yeniden başlatmaya yol açtı.
Geçici Çözümler, Temel Neden Yamasız Kaldığından Ağları Stabilize Ediyor
Birkaç forum katılımcısı, çözümleyici tarafındaki bir değişikliğin rol oynadığını öne sürdü. Dikkatler, etkilenen birçok anahtarın birincil veya ikincil çözümleyici olarak kullandığı Cloudflare’in 1.1.1.1 DNS hizmetine odaklandı. Bir yönetici endişeyi açıkça özetledi: “Cisco’nun DNS uygulamasının tüm anahtarı sıfırlamadan hatalı bir sorgu yanıtını kaldıramaması ne kadar korkunç.”
Kesin olarak doğrulanmamış olsa da, çok sayıda rapor 1.1.1.1’deki bir bozulmanın veya davranış değişikliğinin DNS Çökmesinin senkronize başlangıcıyla çakıştığını ileri sürdü. Yöneticiler, alternatif çözümleyiciler kullanan veya DNS’nin tamamen devre dışı bırakıldığı anahtarların genellikle etkilenmediğini belirtti. Ancak diğerleri, 1.1.1.1 yalnızca yedek olarak yapılandırıldığında bile çökmeler bildirdi; bu, DNS istemcisinin sorunlu yanıtlar tarafından hala tetiklenebileceğini gösteriyor.
8 Ocak günü öğle vakti, etkili geçici çözümler geniş çapta dolaşıyordu. En güvenilir etki azaltma yöntemi, “ip ad sunucusu yok” ve “ip etki alanı araması yok” gibi komutları kullanarak DNS’yi tamamen devre dışı bırakmaktı. Diğerleri, “sntp sunucusu yok time-pnp.cisco.com” ile varsayılan SNTP sunucularını kaldırdı veya anahtarlardan giden internet erişimini engelledi. Neredeyse tüm durumlarda, DNS sorguları durdurulduğunda anahtarlar stabil hale geldi.
Cisco desteği, sorunu müşterilere özel olarak bildirdi ve sorunun CBS250 ve C1200 aileleri de dahil olmak üzere CBS, SG ve Catalyst 1200 ve 1300 hatlarını etkilediğini doğruladı. 9 Ocak 2026 itibarıyla herhangi bir kamu tavsiyesi, yama veya saha bildirimi yayınlanmamıştı.