Sayı 6

Günün kapağı bir ülkenin tüm alan adlarının erişilemez hâle gelmesiyle başlıyor ve çok iyi bir mühendislik sorusuyla bitiyor: bir güvenlik kontrolünü geçici olarak devre dışı bıraktığında, bunu istemciye nasıl söylersin? Sessizce kurtarmak, kurtarmak sayılmıyor.

Günün kapağı Cloudflare Blog 14 Temmuz 2026 7 dk okuma ileri

Sessiz kurtarma bir kusur: .al kesintisi ve görünmez güvenlik kararları

A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed · Sebastiaan Neuteboom

3 Temmuz 2026'da Arnavutluk'un iletişim otoritesi AKEP, .al üst düzey alan adı için bir DNSSEC key rollover (key rollover) denemiş. Bir şeyler ters gitmiş ve DNSSEC doğrulaması başarısız olmaya başlamış. Spesifikasyon gereği, bu imzaları alan her doğrulayıcı DNS çözümleyici bunları reddetmek ve istemciye hata döndürmek zorunda — Cloudflare'in 1.1.1.1'i dahil.

Sonuç: .al altındaki Arnavut devlet servisleri, bankaları ve medya siteleri, nerede barındırıldıklarından bağımsız olarak erişilemez hâle gelmiş.

Sadece iki ay önce Almanya'nın .de alan adında benzer bir olay yaşanmış. O zamanki müdahale bir Negative Trust Anchor (NTA) kurmak olmuş: 1.1.1.1'de DNSSEC doğrulamasını geçici olarak askıya alıp alan adlarını erişilebilir tutmak.

Ama burada asıl mühendislik problemi başlıyor. NTA çözümlemeyi geri getirir — ama sessizce. NTA altında cevap alan bir istemcinin, yalnızca cevaba bakarak DNSSEC doğrulamasının atlandığını anlamasının hiçbir yolu yok. Yani meşru bir cevabı sahte bir cevaptan ayırt edemiyor. Cloudflare'in bu olaydaki katkısı tam olarak bu boşluğu kapatmak: artık Extended DNS Error 33 ile istemciye doğrulamanın atlandığı açıkça bildiriliyor.

Öne çıkanlar

  1. Tek bir key rollover hatası, bir ülkenin tüm alan adlarını erişilemez yapabiliyor — merkezi bileşenlerin blast radius çok geniş.
  2. Kurtarma müdahalesi (NTA) bir güvenlik kontrolünü kapatıyor; bu bir takas ve takasın kendisi görünür olmalı.
  3. Eklenen çözüm yeni bir mekanizma değil, görünürlük: istemci artık hangi garantiyle cevap aldığını biliyor.

Neden önemli?

Bir sistemi ayakta tutmak için bir güvenlik kontrolünü geçici olarak gevşetmek meşru bir karardır. Sessizce yapmak değildir. Bu ayrım her yerde geçerli: sertifika doğrulamasını atlayan bir istemci, hata durumunda kimlik kontrolünü geçen bir servis, dolu olduğu için kontrolü atlayan bir kuyruk — hepsi savunulabilir olabilir, ama hepsi loglanmalı ve görünür olmalıdır.

Pratikte

Bunu koduna doğrudan çevirebilirsin: her try/except bloğunda ‘bu hatayı yutuyorum’ kararı veriyorsun demektir. Sessizce yutma; en azından logla, tercihen bir metriğe say. Bir dosya parse edilemediğinde sistemin ne yaptığına bak: atlanıyor mu ve atlandığı bir yerde görünüyor mu? Aynı şekilde fail-open kararları: yetkilendirme servisi cevap vermezse isteği geçiriyor musun? Geçiriyorsan bu bilinçli bir karar olmalı ve alarma bağlı olmalı. Silent failure’lar en pahalı hata sınıfıdır çünkü aylarca fark edilmezler.

Sözlük

DNSSEC
DNS cevaplarını kriptografik imzayla doğrulayarak sahte cevapları engelleyen uzantı.
key rollover
Kriptografik anahtarın yenisiyle değiştirilmesi; yanlış yapılırsa doğrulama toptan bozulur.
Negative Trust Anchor (NTA)
Bir alan adı için DNSSEC doğrulamasını geçici olarak askıya alan acil durum mekanizması.
silent failure
Sistemin hata verdiğini belli etmeden yanlış ya da eksik davranması; tespiti en zor hata türü.
Orijinali oku

Kısa kısa

AWS Architecture Blog 14 Temmuz 2026 7 dk okuma orta

Dolandırıcılık halkalarını bulmak: yapılandırılmış veri neden yetmiyor

How Mapfre Insurance modernized fraud claims with Amazon EMR Serverless

Sigorta dolandırıcılığında klasik yaklaşım kural tabanlı kontroller, elle tetiklenen incelemeler, geçmiş talep desenleri ve yalnızca yapılandırılmış veri analizine dayanıyor. Bilinen desenler için işe yarıyor, ama karmaşık dolandırıcılık halkalarını ya da talep sahipleri, poliçeler, araçlar, sağlayıcılar, adresler ve önceki şüpheli faaliyetler arasındaki gizli ilişkileri yakalamakta zorlanıyor.

Mapfre'nin çözümü Amazon EMR Serverless üzerine kurulu. Problemin özü şu: sahte talepler her zaman izole olaylar değil — çoğu zaman poliçe sahipleri, araçlar ve sağlayıcılardan oluşan gizli ağlar içeriyor. Bu ilişkileri tespit etmek, geleneksel yapılandırılmış veri analizinin ötesine geçmeyi gerektiriyor.

Öne çıkanlar

  1. Anahtar geçiş: satırlara bakmaktan satırlar arası ilişkilere bakmaya. Aynı adresi paylaşan üç ayrı talep, tek tek bakınca normal.
  2. Serverless Spark (EMR Serverless), sürekli çalışan bir küme tutmadan ağır analitik iş yükü çalıştırmayı ucuzlatıyor.

Pratikte

Bu, PostgreSQL bilgin üzerine kurabileceğin bir beceri. ‘İlişkileri ara’ sorusu SQL’de recursive CTE ile çözülür: bir noktadan başlayıp bağlantıları adım adım takip edersin. WITH RECURSIVE sözdizimini öğrenmek yarım günlük iş ama bir kapı açar: ağaç yapıları, organizasyon şemaları, bağlantı zincirleri, hepsi aynı desen. ‘Bu firmayla ilişkili tüm belgeler’ gibi sorular tablo birleştirmelerinden çok bir graph traversal’dır; bunu baştan bilerek modellemek, sonradan sorguyla çözmeye çalışmaktan iyidir.

Sözlük · 3 terim
fraud ring
Tek tek meşru görünen ama birbirine bağlı kişiler/varlıklar üzerinden yürütülen organize dolandırıcılık.
recursive CTE
SQL'de kendini çağıran sorgu yapısı; ağaç ve graf gezinmelerini tek sorguda yapmayı sağlar.
serverless Spark
Küme yönetmeden, yalnızca çalıştığı sürede ücretlendirilen Spark iş yükü çalıştırma modeli.
Orijinali oku
OpenAI Research 14 Temmuz 2026 4 dk okuma başlangıç

Token fiyatı %97 düştü ama fatura büyüyor: farklı irtifalardan bakmak

How to manage AI investments in the agentic era

Rakamlar çarpıcı: GPT-4'ten GPT-5.4'e milyon token başına fiyat %97 düşmüş. GPT-5.6 ise kodlama agent’ı endeksinde daha iyi performansı %54 daha az çıktı token'ı ve görev başına %57 daha az zamanla veriyor.

Ama yazının asıl tezi şu: token fiyatı tek başına değer yaratılıp yaratılmadığını göstermez. Bakılması gereken dolar başına faydalı iş: tamamlanan görevler, kazanılan zaman, iyileşen kararlar.

Pratik kısım, kullanımı üç farklı irtifadan izlemek: çalışma alanı seviyesinde (benimseme ile harcama birlikte mi hareket ediyor?), ekip ve kullanıcı seviyesinde (talep nerede büyüyor, kimin desteğe ihtiyacı var?), ürün ve model seviyesinde (daha pahalı zekâ nerede kullanılıyor ve bu talep kalıcı mı?).

Öne çıkanlar

  1. Birim fiyat düşerken toplam faturanın artması bir çelişki değil — ucuzlayan şey daha çok kullanılır.
  2. Tek bir toplam sayı yanıltıcıdır; aynı veriye farklı kırılımlardan bakmak asıl bilgiyi verir.

Pratikte

Bir alışkanlık olarak şunu kur: her LLM çağrısında harcanan token’ı kaydet ve gün, özellik ve model bazında kır. usage.input_tokens ve usage.output_tokens her API cevabında geliyor; bunları bir CSV’ye yazmak beş satırlık iş. Bir ay sonra ‘en pahalı gün hangisiydi ve neden?’ sorusunu cevaplayabilirsin. Aynı disiplin ürün için de geçerli: kullanıcı başına LLM maliyeti, abonelik fiyatının ne kadarını yiyor? Bu sayıyı bilmeyen bir ürün, farkında olmadan zarar edebilir.

Sözlük · 1 terim
unit economics
Bir kullanıcı ya da işlem başına gelir ile maliyetin karşılaştırılması; ürünün sürdürülebilirliğinin ölçüsü.
Orijinali oku