DNS Push Notifications Nedir ve Nasıl Çalışır?
DNS verisi değiştiğinde bir istemcinin bunu öğrenmesinin klasik yolu aynı DNS sorgusunu belirli aralıklarla yeniden göndermektir. Değişiklikleri hızlı görmek için sorgu aralığı kısaltıldığında, kayıt hiç değişmese bile istemci ve DNS altyapısı tekrar tekrar trafik üretir.
DNS Push Notifications bu işleyişi abonelik modeline dönüştürür. İstemci belirli bir DNS adı, kayıt türü ve sınıfı için abone olur; DNS Push sunucusu da ilgili cevap kümesindeki değişiklikleri, TLS ile şifrelenen uzun süreli bağlantı üzerinden yeni bir sorgu beklemeden istemciye gönderir. Bu mekanizma normal DNS çözümlemesinin yerini alan genel bir yöntem değildir; destekleyen istemci ve sunucular arasında, canlı değişiklik takibinin gerçekten gerekli olduğu durumlarda kullanılır.
Abonelik Nasıl Kurulur?
İstemci her abonelikte belirli bir DNS sorgusunu izler. Sorgu bir ad, tür ve sınıfla tanımlandığı için istemci DNS bölgesindeki bütün değişiklikleri almak zorunda değildir. Sunucu da yalnız etkin aboneliklerle eşleşen değişiklikleri ilgili DSO (DNS Stateful Operations) oturumuna gönderir; DSO, abonelik bilgisinin bağlantı boyunca tutulmasını sağlar.
Uygun DNS Push Sunucusunun Bulunması
İstemci önce yapılandırılmış recursive resolver’a (özyinelemeli DNS çözümleyicisine) TCP 853 portundan TLS bağlantısı açıp Push aboneliği kurmayı dener. Bu yol desteklenmiyorsa istemci, bölgenin genel bilgilerini taşıyan SOA kaydını kullanarak ilgili DNS bölgesinin başlangıç adını belirleyip o bölge için DNS Push hizmetini ilan eden SRV kaydını kullanarak doğrudan uygun sunucuyu keşfedebilir.
Hizmet keşfi için istemci, bölge adının önüne _dns-push-tls._tcp etiketlerini ekleyerek oluşan ada ait SRV kaydını sorgular. Bu kayıt hedef sunucuyu ve bağlantı portunu bildirir; birden fazla hedef varsa SRV öncelik ve ağırlık kuralları hangi sunucunun önce denenebileceğini belirler.
TLS ile Korunan TCP Bağlantısında DSO Oturumu
DNS Push Notifications, DSO kullanan oturum tabanlı bir protokoldür ve RFC 8765 kapsamında TCP üzerindeki TLS bağlantısında çalışır. TLS, istemci ile sunucu arasındaki Push trafiğinin açık metin olarak iletilmesini engeller; DSO ise abonelik gibi bağlantı boyunca korunması gereken durum bilgisini taşımak için kullanılır.
Uzun süre açık kalan bağlantıda Keepalive (bağlantıyı canlı tutma) işlemleri, istemci ile sunucunun bağlantının sürdüğünü doğrulamasına ve adres çevirisi yapan NAT cihazlarında ya da güvenlik duvarlarında gerekli bağlantı durumunun korunmasına yardımcı olur. Etkin abonelik bulunan bir DSO oturumu, uzun süre veri akmasa bile yalnız bu nedenle boşta kabul edilmez.
SUBSCRIBE ile İzlenecek Sorgunun Tanımlanması
İstemci SUBSCRIBE mesajında izlemek istediği NAME (DNS adı), TYPE (kayıt türü) ve CLASS (kayıt sınıfı) alanlarını belirtir. Örneğin TYPE, IPv4 adresi kaydı olan A; CLASS ise yaygın kullanılan Internet sınıfı IN olabilir. TYPE veya CLASS için ANY (255) seçilirse abonelik o ada ait bütün türleri veya sınıfları kapsar; adın altındaki bütün alanlara genişlemez. Sunucu her aboneliği ayrı ayrı kabul edebilir ya da istek hatalıysa, kaynakları yetersizse, güvenlik politikası izin vermiyorsa, istenen ad için yetkili değilse veya SUBSCRIBE işlemini desteklemiyorsa reddedebilir. İstemci aynı DSO oturumunda aynı ad, tür ve sınıf için yinelenen SUBSCRIBE gönderemez; sunucu böyle bir istek alırsa bağlantıyı sonlandırır.
İstenen kayıt henüz yoksa bu tek başına abonelik hatası değildir; sunucunun sorumlu olduğu adlarda abonelik kurulabilir ve kayıt oluştuğunda bildirim gönderilir. Başarılı abonelik, istemci UNSUBSCRIBE gönderene veya DSO oturumu kapanana kadar sürer. İstemci aboneliği yalnız veriye gerçekten ihtiyaç duyduğu süre boyunca açık tutmalıdır; böylece sunucuda gereksiz durum birikmez.
PUSH Mesajlarının DNS Değişikliklerini İletmesi
Abonelik kurulduğunda mevcut cevap kümesi boş değilse sunucu ilk PUSH mesajıyla bu başlangıç durumunu iletir. Daha sonra eşleşen DNS verisinde ekleme veya silme olduğunda, değişiklikler yeni bir istemci sorgusu beklenmeden aynı oturum üzerinden gönderilir.
PUSH mesajı sunucudan istemciye tek yönlüdür; istemci her PUSH için ayrı bir yanıt göndermez. Bir UNSUBSCRIBE mesajı ile sunucudan daha önce yola çıkmış bir PUSH aynı anda ağda bulunabileceği için istemci, iptal ettiği aboneliğe ait gecikmiş bir bildirimi alıp yok saymaya hazır olmalıdır.
İstemci, PUSH ile gelen kayıtların önbellekte kalma süresini belirten TTL değerini saklar, fakat ilgili abonelik etkinken bu süreyi azaltmaz. Kayıt kaldırıldığında veya değiştiğinde sunucunun bildirim göndermesini bekler. Abonelik sona erince TTL geri sayımı başlar; TTL değeri sıfır olan kayıtlar hemen silinir. Sunucuyu keşfetmek için normal DNS sorgusuyla alınan SOA ve SRV kayıtlarında ise olağan TTL kuralları geçerlidir.
Oturumun Sonlandırılması ve Yeniden Abonelik
Tek bir abonelik UNSUBSCRIBE ile kaldırılabilir; istemci DSO oturumunu kapatırsa o oturumdaki tüm abonelikler sona erer. Bağlantı daha sonra yeniden kurulduğunda önceki abonelik durumu kendiliğinden geri gelmez, bu nedenle ihtiyaç devam ediyorsa istemcinin abonelikleri yeniden oluşturması gerekir.
Periyodik Sorgulama ile Push Arasındaki Farklar
İki yaklaşımın amacı aynıdır: değişen DNS cevabını öğrenmek. Ancak değişikliği fark etme biçimleri ile oluşturdukları oturum ve trafik yükü farklıdır. Push, özellikle değişiklikleri izlemek için sık sorgu gerektiren durumlarda gereksiz tekrarları azaltmayı amaçlar.
| Karşılaştırma konusu | Periyodik sorgulama | DNS Push Notifications |
|---|---|---|
| Değişikliği öğrenme | İstemci sonraki sorguyu gönderdiğinde fark edilir. | Sunucu etkin abonelikle eşleşen değişikliği eşzamansız olarak gönderir. |
| Trafik modeli | Değişiklik olmasa da belirlenen aralıkta yeni sorgular oluşur. | Uzun süre açık kalan oturum korunur; değişiklikler PUSH mesajlarıyla taşınır. |
| Durum yönetimi | Her sorgu bağımsız biçimde ele alınabilir. | Sunucu, etkin DSO oturumları ve abonelikler için durum bilgisi saklar. |
| Uygulanabilirlik | Geleneksel DNS sorgusunun çalıştığı geniş bir altyapıda kullanılabilir. | İstemcide ve aboneliği yöneten recursive resolver veya yetkili DNS sunucusunda DSO ve Push desteği gerekir. |
Push, sık sorgulamaya göre DNS sunucusunda daha az sorgu yükü oluşturabilir; ancak maliyetsiz değildir. Açık tutulan TCP/TLS oturumları, abonelik kayıtları ve Keepalive trafiği kaynak tüketir. Bu nedenle istemci, aboneliği yalnız canlı veriye ihtiyaç duyduğu sürece açık tutmalıdır.
DNS Push Ne İşe Yarar, Ne Yapmaz?
DNS Push Notifications, belirli bir DNS cevap kümesindeki değişikliğin istemciye hızla ulaşması gereken senaryolarda kullanılır. Örneğin bir uygulama, belirli bir hizmete ait kayıt kümesini ekranda canlı gösteriyorsa her birkaç saniyede bir aynı DNS sorgusunu tekrarlamak yerine o sorguya abone olabilir ve yalnız değişiklik geldiğinde görünümünü güncelleyebilir.
DNS Push bir kayıt değiştirme mekanizması değildir. DNS Update veya bir DNS sağlayıcısının kayıt yönetim API'si kaydı yazmayı ya da değiştirmeyi hedeflerken, DNS Push mevcut değişikliği abone istemciye taşır. Benzer biçimde DNS prefetching de başka bir ihtiyaca yöneliktir; Push'ın amacı gelecekte gerekebilecek veriyi önceden sorgulamak değil, izlenen veride oluşan değişikliği bildirmektir.
Normal recursive DNS çözümlemesi de ortadan kalkmaz. Push aboneliği kurulamıyorsa istemci yine geleneksel DNS sorgularına dönebilir; RFC 8765, bu geri dönüşte iki sorgu arasındaki sürenin 15 dakika ile yanıtın TTL değerinin iki saniye fazlasından küçük olanı kadar veya daha uzun olmasını önerir. İstemci her yeniden sorgulamadan önce Push aboneliğini tekrar denemelidir.
TLS ve DNSSEC ile Push Sunucusunu Doğrulama
RFC 8765, DNS Push bağlantılarında sunucunun kimliğinin doğrulandığı TLS kullanımını zorunlu tutar; açık metin veya kimliği doğrulanmamış Push bağlantısına izin vermez. İstemci Push sunucusunun adını DNS SRV kaydından öğrendiği için saldırgan bu kaydı değiştirerek istemciyi sahte bir sunucuya yönlendirebilir. DNSSEC, dijital imzalar ve güven zinciriyle DNS verisinin yetkili kaynaktan geldiğini ve değiştirilmediğini doğrular; RFC 8765 bu nedenle sunucu keşfinde DNSSEC kullanımını önerir.
DANE, DNSSEC ile doğrulanmış TLSA kayıtlarını kullanarak hedef sunucunun sertifikasını veya açık anahtarını doğrular. TLSA sorgusu SRV hedefinin adı, portu ve taşıma protokolü için yapılır. SRV kaydı DNSSEC doğrulamasını geçmiş ve hedef için kullanılabilir, DNSSEC ile doğrulanmış TLSA kaydı bulunmuşsa istemci bu kayıtla sunucuyu doğrular; TLS görüşmesindeki SNI alanında da hedef adını gönderir. SNI, bağlanılmak istenen sunucu adını bildirir; tek başına kimlik doğrulamaz.
DANE kullanılamadığında da TLS kimlik doğrulaması atlanamaz; istemci güvenilir sertifika zinciri ve güvenilir biçimde belirlenmiş sunucu adı gibi desteklediği başka bir doğrulama yoluna ihtiyaç duyar. DNSSEC doğrulaması başarısız olan veriler, imzasız veriyle aynı kabul edilip kullanılmamalıdır.
DNS Push Sunucusunda Abonelik Kapasitesi
Her sunucunun yönetebileceği eşzamanlı abonelik sayısının bir sınırı vardır. Abonelik bilgileri bellek ve işlem kapasitesi, açık oturumlar ise bağlantı kaynakları tüketir; bir oturumda birden fazla abonelik bulunabilir. Sunucu kapasitesi dolduğunda yeni abonelikleri reddedebilir; istemci de aynı bölgeye hizmet veren uygun alternatif DNS Push sunucularını deneyebilir. Kullanılmayan abonelikleri kapatmak, sunucunun kaynaklarını gereksiz yere tüketmesini önler.
