Wildcard DNS kaydı eşleşme mantığı ve DNS zone yapısı

Wildcard DNS Kaydı Nedir ve Ne Zaman Kullanılır?

*.example.com biçiminde yazılan bir DNS kaydı, zone dosyasında karşılığı tanımlanmamış her alt alan adı sorgusunu otomatik olarak yakalar. api.example.com, staging.example.com ya da rastgele seçilmiş başka herhangi bir ön ek için zone'da açık bir kayıt bulunmadığı sürece DNS çözümleyicisi wildcard kaydının hedefini döndürür. Bu mekanizma RFC 4592 ile standartlaşmıştır ve DNS çözümleme sürecinin içine entegre edilmiştir; zone'a her yeni alt alan eklendiğinde ayrıca kayıt oluşturmak gerekmez.

Wildcard kaydı en çok iki senaryoda değer üretir: birden fazla alt alan adının aynı sunucuya veya hedefe işaret etmesi gereken yapılarda ve zone yönetimini merkezi tek bir kayıtla basitleştirmek istenen ortamlarda. Onlarca subdomain'in aynı CNAME hedefine bağlandığı platformlarda her birini tek tek tanımlamak yerine bir wildcard kaydı yeterli olur; bu yaklaşım yönetim yükünü önemli ölçüde azaltır.

Bununla birlikte wildcard, zone'daki her alt alan için evrensel bir çözüm değildir. Eşleşme derinliği sınırı, kayıt türü kısıtlamaları, explicit kayıtlarla çakışma kuralları ve e-posta trafiğinde getirdiği riskler, belirli durumlarda beklenmedik sonuçlar üretebilir. Bu ayrıntıları anlamak, wildcard kaydını ne zaman kullanmak gerektiği ve ne zaman alt alan bazında açık kayıt tanımlamanın daha sağlıklı olduğu kararını netleştirir.

Wildcard eşleşme mantığı: hangi sorgular, hangi sınırlar

Bir DNS çözümleyicisi, sorguladığı isim için zone'da tam eşleşme bulamazsa wildcard işleme adımına geçer. *.example.com kaydı yalnızca bir seviye derinliğindeki alt alan adlarını kapsar: foo.example.com eşleşir, ancak foo.bar.example.com eşleşmez. İki seviye derinliğindeki sorguları da yakalamak için ayrıca *.bar.example.com gibi ikinci bir wildcard tanımlanması gerekir. Bu tek seviye davranışı RFC 4592'nin standart yorumudur ve hemen tüm DNS sunucu implementasyonlarında bu şekilde çalışır.

Wildcard etiketi yalnızca asterisk (*) karakterini kabul eder ve mutlaka en sola — yani en spesifik konuma — yerleştirilir. foo.*.example.com gibi ismin ortasına konumlandırılmış bir wildcard geçersizdir; standart DNS çözümlemesi tarafından işlenmez.

*.example.com.  3600  IN  A      203.0.113.10
*.example.com.  3600  IN  AAAA   2001:db8::10

Wildcard eşleşmesi yalnızca zone'da karşılığı olmayan isimler için tetiklenir. www.example.com için açık bir A kaydı zone'da mevcutsa, www sorgusu wildcard'a hiçbir zaman ulaşmaz. Yalnızca staging.example.com, test.example.com gibi tanımsız alt alanlar wildcard hedefine yönlendirilir. Bu davranış, zone dosyasındaki kayıt sıralamasından bağımsızdır — her koşulda explicit eşleşme wildcard'dan önce gelir.

Kayıt türü uyumluluğu ve kısıtlamalar

Wildcard kaydı A, AAAA, CNAME ve TXT kayıt türleriyle birlikte kullanılabilir. En yaygın tercih, tüm tanımsız alt alan adlarını aynı web sunucusuna ya da load balancer'a yönlendiren *.example.com CNAME yapısıdır. CNAME ve A kaydı arasındaki teknik fark bu yapıda da geçerlidir: wildcard CNAME, hedef olarak IP adresi yerine başka bir hostname alır.

*.example.com.  3600  IN  CNAME  example.com.
# ya da harici bir hedefe:
*.example.com.  3600  IN  CNAME  lb.hosting-provider.net.

NS kaydıyla wildcard kullanımı desteklenmez. Wildcard NS kaydı, zone delegation mekanizmasıyla çeliştiğinden DNS sunucuları bu konfigürasyonu ya reddeder ya da öngörülemeyen biçimde işler.

TXT wildcard teknik olarak mümkündür; ancak SPF, DKIM ya da harici bir servisin domain doğrulaması gibi amaçlara hizmet etmez. Bu doğrulama sistemleri sorgu sonucunun tam isimle eşleşmesini bekler; wildcard TXT mail.example.com gibi spesifik bir alt alan için gereken doğrulamayı karşılayamaz. DNS kayıt türlerinin genel davranışını göz önünde bulundurarak her kayıt türünü kendi kullanım senaryosunda değerlendirmek gerekir.

CAA kaydında wildcard davranışı ayrı bir mekanizma izler. Zone'da *.example.com için bir CAA tanımlansa bile bu, tüm alt alanların sertifika politikasını otomatik olarak belirlemez; CAA'nın miras ve issuewild direktifi kuralları ayrıca uygulanır.

Explicit kayıt ile öncelik sırası

DNS zone'da bir isim için hem explicit hem wildcard kayıt bulunduğunda, explicit kayıt her zaman öncelik alır. Sıralama ya da tanımlama zamanlaması bu davranışı değiştirmez; çözümleme motoru önce tam eşleşmeyi arar, bulamazsa wildcard'a geçer.

example.com.      3600  IN  A  203.0.113.10
www.example.com.  3600  IN  A  203.0.113.20
*.example.com.    3600  IN  A  203.0.113.10

Bu zone yapısında www.example.com sorgusu 203.0.113.20'yi döndürür. api.example.com, beta.example.com ya da tanımlanmamış diğer alt alanlar ise wildcard aracılığıyla 203.0.113.10'a yönlendirilir. Her iki IP farklı olduğundan istenen ayrım sağlanır; www ayrı bir sunucuda kalırken geri kalan alt alanlar ortak hedefe düşer.

Bu kural, subdomain yönetimi sırasında göz ardı edilmesi kolay bir duruma yol açabilir: silinmesi gereken eski bir alt alan zone'dan kaldırıldığında, wildcard hâlâ mevcutsa silinen isim sorgulara yanıt vermeye devam eder. Zone temizleme operasyonlarında bu davranış gözetilmeli; gerçekten yanıt verilmemesi istenen alt alanlar için explicit NXDOMAIN üretecek bir mekanizma ya da ilgili wildcard kapsamının yeniden değerlendirilmesi gerekebilir.

MX kayıtlarında wildcard ve e-posta trafiği

Wildcard MX kaydı teknik olarak geçerli bir yapıdır; zone'da karşılığı olmayan her alt alan adı için e-posta kabulü anlamına gelir. [email protected], [email protected] gibi adresler posta sunucusuna ulaşmaya çalışır — bu alt alanların gerçekten e-posta alması amaçlanmamış olsa bile.

*.example.com.  3600  IN  MX  10  mail.example.com.

Spam gönderenler wildcard MX yapılandırmalarını rastgele alt alan adresleri üzerinden kötüye kullanabilir. Posta sunucusu RCPT TO aşamasında geçersiz adres denetimi yapmıyorsa bu talepler sisteme ulaşır; denetim yapılsa bile gereksiz bağlantı yükü oluşur. E-posta alan alt alanlar için her zaman explicit MX kaydı tercih edilmeli, wildcard MX'ten kaçınılmalıdır.

MX kaydı yapılandırması ele alındığında, her e-posta alan alt alan için ayrı ve açık kayıt tanımlamak hem güvenlik hem de posta akışı güvenilirliği açısından belirgin avantaj sağlar. Wildcard MX yalnızca tüm alt alanların aynı posta sunucusuna gönderilmesi kasıtlı olarak istendiğinde ve bu alt alanların geçerli adresler içerdiği doğrulandıktan sonra kullanılabilir.

Wildcard'ın işe yaramadığı ya da ters etki yarattığı durumlar

Wildcard kaydının kapsam sınırlarını anlamak, hangi senaryolarda çalışmayacağını önceden görmeyi sağlar.

DNSSEC imzalı zone'larda wildcard kayıtlar özel imzalama gerektirir. Wildcard eşleşmeleri NSEC3 reddiyatı ile birlikte imzalanmalıdır; zone imzalama yazılımı bunu otomatik olarak yapsa da güvenlik yapılandırması sırasında wildcard'ın zone'da bulunması bazı doğrulama araçlarında ek dikkat gerektirebilir. Wildcard eşleşmesinin DNSSEC doğrulamasından geçmesi için resolver'ın RRSIG kaydını doğrulaması zorunludur.

Cloudflare DNS'e geçiş yapıldığında proxied olarak tanımlanan bir wildcard kaydı, tüm tanımsız alt alanları Cloudflare ağı üzerinden geçirir. Bu, her eşleşen alt alan için SSL sertifikası gerektirdiğinden Cloudflare'ın Universal SSL planının wildcard sertifikayı kapsayıp kapsamadığına dikkat etmek gerekir. DNS Only modunda wildcard, doğrudan IP'ye işaret eder ve bu sınırlama ortadan kalkar.

Subdomain takeover riski özellikle wildcard CNAME yapılandırmalarında gözetilmesi gereken bir güvenlik durumudur. Wildcard CNAME hedefi üçüncü taraf bir servise işaret ediyorsa ve o hesap kapatılırsa, servisin boşalttığı subdomain alanını başka bir kullanıcı sahiplenebilir. Wildcard hedefinin aktif ve kontrollü bir kaynağa işaret ettiği düzenli aralıklarla teyit edilmelidir.

Son olarak, TTL yönetimi açısından wildcard kaydı tüm eşleşen alt alanlar için tek bir TTL değeri uygular. Belirli alt alanlar için farklı önbellek süresi gerekiyorsa — örneğin sık IP değişen bir servis için düşük TTL, sabit bir IP için yüksek TTL — explicit kayıt tanımlamak zorunlu hale gelir.

Zone'da wildcard kaydını doğrulama

Wildcard kaydının beklendiği gibi çalışıp çalışmadığını test etmenin en güvenilir yolu, zone'da açık kaydı olmayan rastgele bir alt alan adı sorgulamaktır:

dig randomtest99.example.com A +short

Wildcard etkin ve DNS propagasyonu tamamlandıysa bu sorgu wildcard hedefinin IP adresini döndürür. Yanıt NXDOMAIN ya da boşsa zone'da wildcard kaydı bulunmuyor ya da sorgu farklı bir zone'a yönlendiriliyordur.

Explicit kaydın wildcard'ı override ettiğini doğrulamak için her iki sorgunun sonuçlarını karşılaştırabilirsiniz:

dig www.example.com A +short
dig randomtest99.example.com A +short

İki sorgu farklı IP adresi döndürüyorsa explicit ve wildcard kayıtlar beklenen biçimde çalışıyordur. Aynı IP dönüyorsa ya iki kayıt aynı hedefe işaret ediyor ya da www için explicit kayıt tanımlanmamış demektir.

Windows ortamında aynı test nslookup ile yapılabilir:

nslookup randomtest99.example.com

Kaydı az önce oluşturduysanız sonuç hemen gelmeyebilir. DNS değişikliklerinin yayılma süresi TTL değerine ve çözümleyicinin önbellek durumuna bağlıdır; yeni eklenen bir wildcard için bekleme süresi birkaç dakikadan saatlere kadar uzanabilir.

Wildcard kaydı, zone tasarımında bilinçli kullanıldığında zaman kazandıran ve yönetimi kolaylaştıran bir mekanizmadır. Eşleşme mantığı, tek seviye kapsam sınırı, explicit kayıt önceliği ve MX'te getirdiği riskler netleştiğinde hangi durumlarda wildcard'ın yerinde bir seçim olduğu görülür. Büyük zone yapılarında her alt alan için explicit kayıt tutmak bazen daha tahmin edilebilir bir davranış sunar; ancak dinamik ve genişleyen subdomain yapıları için wildcard, tekrarlayan yapılandırma yükünü ortadan kaldıran pratik bir çözümdür.

Zone'unuzda hem wildcard hem explicit kayıt birlikte kullanılıyorsa, hangi sorguların wildcard'a düştüğünü ara sıra test etmek faydalıdır — özellikle yeni alt alanlar eklendikçe veya eski olanlar kaldırıldıkça bu denetim, beklenmedik yönlendirmelerin önüne geçer.