Alan Kontrol Doğrulaması (DCV) Nedir? SSL Sertifikası Doğrulama Yöntemleri için Eksiksiz Rehber

Bir SSL/TLS sertifikası sipariş ettiğinizde, Sertifika Otoritesi bunu size öylece vermez. Güvenliğini sağladığınız alan adını gerçekten kontrol ettiğinize dair kanıt isterler. İşte tam bu noktada Alan Adı Kontrol Doğrulaması (Domain Control Validation – DCV) devreye girer. Bu, herhangi bir sertifika verilmeden önce alan adı sahipliğini doğrulayan süreçtir.

Bu yalnızca bürokratik bir formalite değildir. DCV, saldırganların sahip olmadıkları alan adları için geçerli sertifikalar almasını engeller; aksi takdirde bu durum, HTTPS’i güvenli kılan güven modelini tamamen çökertirdi. Sertifika verilmesine ilişkin temel gereksinimleri belirleyen sektör kuruluşu olan CA/Browser Forumu, tüm Sertifika Otoritelerinin uyması gereken belirli DCV yöntemlerini zorunlu kılar.

Bu rehberde, DCV’nin ne olduğunu ele alacak, mevcut farklı doğrulama yöntemlerini inceleyecek ve altyapınız için doğru yaklaşımı seçmenize yardımcı olacağız.

---

İçindekiler

1. DCV (Alan Adı Kontrol Doğrulaması) nedir?
2. E-posta Tabanlı Alan Adı Doğrulama Yöntemleri
3. DNS Tabanlı DCV Yöntemleri
4. HTTP/HTTPS Dosya Tabanlı Doğrulama Yöntemleri
5. Özel Doğrulama Senaryoları
6. İhtiyaçlarınıza Uygun DCV Yönteminin Seçilmesi
7. Yaygın DCV Sorunları ve Hızlı Çözümler

---

---

DCV (Alan Adı Kontrol Doğrulaması) nedir?

Alan Adı Kontrol Doğrulaması (DCV), Sertifika Otoritelerinin bir SSL/TLS sertifikası vermeden önce alan adı sahipliğini doğrulamak için kullandığı süreçtir. Başvuru sahibinin e-posta yoluyla yanıt vermesini, alan adına bir dosya yüklemesini veya alan adı üzerindeki yetkisini kanıtlamak için DNS kayıtlarını yapılandırmasını gerektirerek kontrolü teyit eder.

Süreç şu şekilde işler: CA benzersiz bir sorgu (genellikle rastgele bir alfanümerik dize) oluşturur ve siz alan adınızın altyapısı üzerinden yanıt vererek kontrolü kanıtlarsınız. Bu, DNS kayıtları, web sunucunuz veya yönetici e-posta adresleri üzerinden yapılabilir. Doğrulama tamamlandığında, CA sertifikayı sitenizi taklit etmeye çalışan biri değil, meşru alan adı sahibine verdiğini bilir.

Sektör Standartları ve Uyumluluk

CA/Browser Forumu‘nun temel gereksinimleri, DCV’nin tam olarak nasıl yapılması gerektiğini tanımlar. Bunlar öneri değil, CA’ların uymak zorunda olduğu ya da tarayıcılardaki güvenilir statülerini kaybetme riskiyle karşı karşıya kaldıkları katı kurallardır.

Güncel standartlar şunları içerir:

• Doğrulama, onaylanmış DCV yöntemlerinden biri kullanılarak yapılmalıdır (aşağıda ele alınmıştır)
• Çoklu Perspektif Sertifika Verme Doğrulaması (Multi-Perspective Issuance Corroboration – MPIC), yerel saldırıları önlemek için birden fazla ağ perspektifinden doğrulama gerektirir
• Doğrulama, Organizasyon Doğrulamalı (OV) ve Genişletilmiş Doğrulama (EV) sertifikaları için 397 gün boyunca yeniden kullanılabilir
• Alan Adı Doğrulamalı (DV) sertifikalar doğrulamayı yeniden kullanamaz; her yenilemede yeniden doğrulama yapmanız gerekir

Önemli bir nokta daha var: bu gereksinimler giderek sıkılaştırılıyor. Sektör, maksimum sertifika ömürlerini ve doğrulama sürelerini kısaltıyor.

CA/Browser Forumu, sertifika ömürleri için net bir zaman çizelgesi belirledi: sertifikalar artık 15 Mart 2026 itibarıyla 200 günle sınırlandırılacak, ardından 15 Mart 2027’den itibaren 100 güne ve 15 Mart 2029’dan itibaren 47 güne indirilecek.

Bu sıkılaştırma doğrulama döngülerini de etkiliyor ve sık yeniden doğrulama ile SSL sertifikası otomasyonunu giderek daha gerekli hale getiriyor.

---

E-posta Tabanlı Alan Adı Doğrulama Yöntemleri

1. Oluşturulmuş E-posta Doğrulaması

E-posta doğrulaması, basit olması ve altyapınızda hiçbir teknik değişiklik gerektirmemesi nedeniyle en yaygın DCV yöntemidir. CA, alan adınızdaki belirli adreslere bir doğrulama bağlantısı veya kod içeren bir e-posta gönderir.

CA şu genel e-posta adreslerini deneyecektir:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Bunların hepsinin kurulu olmasına gerek yoktur, listeden yalnızca bir adresin çalışıyor olması yeterlidir. CA, e-postanın iletilebildiğini teyit etmek için alan adınızın MX kayıtlarını kontrol eder, ardından doğrulama isteğini gönderir.

E-posta ulaştığında, bir doğrulama bağlantısına tıklayacak veya bir kodu sertifika sipariş platformuna geri kopyalayacaksınız. E-postanız doğru yapılandırılmışsa süreç genellikle sadece birkaç dakika sürer.

Bu yöntem şu durumlarda çok iyi çalışır:

• Alan adınız için kurulmuş bir e-posta altyapınız varsa
• Sertifikaları büyük ölçekte değil, ara sıra sipariş ediyorsanız
• DNS veya web sunucusu değişikliği gerektirmeyen en basit doğrulama sürecini istiyorsanız

Dezavantajı ne mi? Kolayca otomatikleştiremezsiniz ve e-postanız devre dışı kalırsa veya adresler izlenmiyorsa, doğrulamanız başarısız olur.

2. E-postadan DNS TXT İletişim Adresine

Bu varyasyon, e-postayı DNS ile birleştirir. Genel adresler kullanmak yerine, _validation-contactemail.yourdomain.com adresinde bir DNS TXT kaydında belirli bir e-posta adresi yayımlarsınız. CA bu kaydı okur ve doğrulamayı o adrese gönderir.

Bu yaklaşım neden kullanılır?

• Yeniden kullanılabilirlik: Bir kez yapılandırıldığında, tüm doğrulama süresi boyunca geçerli kalır
• Merkezi kontrol: Doğrulama isteklerini hangi e-postanın alacağına tam olarak siz karar verirsiniz
• Ekip dostu: Kişisel bir posta kutusu yerine bir dağıtım listesine yönlendirin

İşte pratik kurulum:

_validation-contactemail.yourdomain.com. IN TXT "mailto:[email protected]"

Tercih ettiğiniz iletişim e-postasıyla bu DNS TXT kaydını oluşturmanız yeterlidir, CA bunu otomatik olarak kullanacaktır. Bu, özellikle birden fazla sertifikayı yöneten kuruluşlar için faydalıdır. İzlenen tek bir gelen kutusu üzerinden tüm alan adlarında doğrulamayı standartlaştırabilirsiniz.

---

DNS Tabanlı DCV Yöntemleri

1. DNS TXT Kayıt Doğrulaması

DNS TXT kayıt doğrulaması, esnekliği ve otomasyon potansiyeli nedeniyle popülerdir. Bir sertifika sipariş ettiğinizde, CA size alan adınızın DNS’sine TXT kaydı olarak ekleyeceğiniz belirli bir ana bilgisayar adı ve doğrulama belirteci sağlar.

Temel süreç:

1. CA, sertifika sipariş sırasında bir ana bilgisayar adı (genellikle _dvsauth.yourdomain.com) ve bir belirteç sağlar
2. Bu belirteci değer olarak kullanarak TXT kaydını oluşturursunuz
3. CA, kaydın var olduğunu teyit etmek için DNS’inizi sorgular
4. Doğrulandıktan sonra sertifikayı verirler

Kayıt genellikle şu şekilde görünür:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

DNS TXT doğrulaması şunlar için idealdir:

• Otomasyon – DNS API’leri bunu ACME istemcileri veya özel araçlar aracılığıyla betikleştirmeyi mümkün kılar
• Web sunucusu olmayan ortamlar – yalnızca DNS erişimine ihtiyacınız vardır
• Wildcard sertifikalar – bu gereksinimi Özel Senaryolar bölümünde ele alacağız

Dikkat edilmesi gereken bir şey var: DNS yayılma süresi. İsim sunucularınızın TTL değerleri yüksekse veya yayılma yavaşsa, doğrulama daha uzun sürebilir. Çoğu CA 24 saat boyunca yeniden dener, ancak doğrulama kayıtlarını eklemeden önce daha düşük TTL değerleri ayarlamak en iyisidir.

2. DNS CNAME Kayıt Yöntemi

CNAME doğrulaması farklı bir kayıt türü kullanır ancak aynı amaca ulaşır. Doğrulama belirtecini doğrudan saklamak yerine, CA’nın kontrol ettiği bir doğrulama hedefine işaret eden bir CNAME oluşturursunuz.

Örnek yapılandırma:

_dnsauth.yourdomain.com. IN CNAME random-token.dcv.digicert.com.

Temel fark şu: CNAME, CA’nın kontrol ettiği bir kayda işaret eder, bu da sizin DNS’i değiştirmenize gerek kalmadan doğrulama hedefini güncelleyebilecekleri anlamına gelir. Bazı CA’lar bunu alan adı ön doğrulaması için de kullanmanıza izin verir: CNAME’i bir kez kurarsınız ve sertifika sipariş ettiğinizde ne zaman isterlerse doğrulama yapabilirler.

CNAME doğrulaması şu durumlarda iyi çalışır:

• DNS sağlayıcınız CNAME’leri TXT kayıtlarından daha kolay yönetilebilir kılıyorsa
• OV/EV sertifikaları için alan adı ön doğrulama yeteneği istiyorsanız
• CNAME tabanlı doğrulama akışlarını destekleyen CA’larla çalışıyorsanız

Tüm CA’lar CNAME doğrulaması sunmaz, bu yüzden sağlayıcınıza danışın. Ancak mevcut olduğunda, bu DNS kayıt türünü tercih eden ekipler için sağlam bir seçenektir.

---

---

HTTP/HTTPS Dosya Tabanlı Doğrulama Yöntemleri

1. HTTP Pratik Gösterimi

Dosya tabanlı doğrulama, web sunucunuzda belirlenen bir yolda belirli bir dosya bulundurmanızı gerektirir. CA daha sonra alan adını barındıran sunucuyu kontrol ettiğinizi teyit etmek için bu dosyaya HTTP veya HTTPS üzerinden erişir.

Standart yol şudur: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

CA hem tam dosya adını hem de içeriği sağlar. Bu dosyayı sunucunuzda oluşturur, erişilebilir olmasını sağlarsınız ve CA bunu getirerek doğrular.

Kritik uygulama noktaları:

• Dosyaya 80 numaralı port (HTTP) veya 443 numaralı port (HTTPS) üzerinden erişilebilmelidir
• .well-known dizini, RFC 8615’te tanımlanan standart bir konumdur
• Bu, IP adresi doğrulaması için zorunludur. IPv4 veya IPv6 adresi için sertifika alıyorsanız, HTTP doğrulaması genellikle tek seçeneğinizdir

Doğrudan web sunucusu erişiminiz varsa dosya tabanlı doğrulama oldukça basittir. Dosya sistemi erişimi kısıtlı barındırma hizmetleri veya doğrulama isteklerini önbelleğe alabilecek ya da müdahale edebilecek CDN’ler kullanıyorsanız daha az idealdir.

Sorun giderme ipuçları:

• Yönlendirmelerin müdahale etmediğinden emin olun. CA’nın tam doğrulama URL’sine ulaşması gerekir
• Güvenlik duvarlarının HTTP/HTTPS erişimine izin verdiğini kontrol edin
• Doğrulama dizini için önbelleğe almayı devre dışı bırakın
• Dosya izinlerinin herkese açık okuma erişimine izin verdiğini doğrulayın

2. ACME Meydan Okuma Entegrasyonu

ACME (Automated Certificate Management Environment) protokolü, otomatik DCV için HTTP-01 ve DNS-01 meydan okumalarını kullanır. Let’s Encrypt veya başka bir ACME uyumlu CA kullanıyorsanız, ACME istemciniz tüm doğrulama sürecini otomatik olarak yönetir.

HTTP-01 meydan okuması: /.well-known/acme-challenge/ konumuna bir doğrulama dosyası yerleştirir (standart HTTP doğrulamasına benzer)

DNS-01 meydan okuması: _acme-challenge.yourdomain.com adresinde bir TXT kaydı oluşturur

İstemciniz (Certbot, acme.sh veya cPanel gibi platformlara entegre araçlar) doğrulamayı ve sertifika yenilemesini herhangi bir manuel müdahaleye gerek kalmadan yönetir. ACME, özellikle büyük sertifika envanterlerini yöneten kuruluşlar için otomatik sertifika yönetiminin standardı haline geldi.

---

Özel Doğrulama Senaryoları

1. Çoklu Alan Adı ve SAN Sertifika Doğrulaması

Çoklu alan adı sertifikası (SAN veya UCC sertifikaları olarak da adlandırılır) sipariş ediyorsanız, her alan adını ayrı ayrı doğrulamanız gerekir. Tek bir DCV kontrolü, sertifikadaki tüm alan adlarını kapsamaz.

Örnek: example.com, www.example.com ve shop.example.com için bir sertifika, aralarında ilişki olsa bile üç ayrı doğrulama gerektirir.

İyi haber şu ki, doğrulama yöntemlerini karıştırabilirsiniz. Bir alan adı için e-posta doğrulaması, diğeri için DNS doğrulaması kullanabilirsiniz; bu altyapınıza uygunsa. CA’nın platformu her alan adı için doğrulama durumunu takip eder ve tüm alan adları doğrulandıktan sonra ancak sertifikayı verir.

2. Wildcard Alan Adı Doğrulaması

Wildcard sertifikalar (*.example.com’u kapsayan) DNS tabanlı doğrulama yöntemleri gerektirir. Çoğu CA, güvenlik açısından wildcard’lar için e-posta veya HTTP doğrulamasını kabul etmez.

Wildcard’lar için neden DNS doğrulaması?

Wildcard sertifikalar, sınırsız sayıda alt alan adını güvence altına alır. Dosya tabanlı doğrulama yalnızca bir seferde tek bir alt alan adının kontrolünü kanıtlayabilir ve e-posta doğrulaması tüm olası alt alan adları üzerindeki kontrolü göstermez. DNS doğrulaması, tüm alan adının DNS altyapısını kontrol ettiğinizi kanıtlar, bu da tüm alt alan adlarını koruyan bir sertifika için uygundur.

Wildcard sertifikaya ihtiyacınız varsa, DNS TXT veya CNAME doğrulaması kullanmayı planlayın. Bunlar genellikle tek seçenekleriniz olacaktır.

3. Alt Alan Adı Doğrulama Değerlendirmeleri

Doğrulama yöntemine bağlı olarak alt alan adı düzeyinde veya üst alan adı düzeyinde doğrulama yapabilirsiniz. HTTP doğrulaması için, dosyanın doğrulamakta olduğunuz belirli alt alan adında erişilebilir olması gerekir. DNS doğrulaması için, uygun alt alan adı düzeyinde kayıtlar oluşturursunuz.

Önemli bir ayrım: Üst alan adını (example.com) doğrulamak, çoğu doğrulama yöntemi için alt alan adlarını (blog.example.com) otomatik olarak doğrulamaz. Wildcard sertifika kullanmadığınız sürece her alt alan adının kendi doğrulamasına ihtiyacı vardır.

---

İhtiyaçlarınıza Uygun DCV Yönteminin Seçilmesi

Yöntemi altyapınıza uygun şekilde eşleştirin:

Tüm DCV Yöntemlerini Bir Bakışta Karşılaştırın

Doğrulama Yöntemi	Tamamlanma Süresi	Otomasyon Yeteneği	Teknik Beceri	Wildcard Desteği	Yeniden Kullanılabilirlik (OV/EV)	En Uygun Kullanım
E-posta (Genel)	5-30 dakika	❌ Düşük	⭐ Minimal	✅ Evet	❌ Hayır	Tek seferlik sertifikalar, küçük dağıtımlar
E-posta (DNS TXT)	15-60 dakika	❌ Düşük	⭐⭐ Düşük-Orta	✅ Evet	✅ Evet (397 gün)	Birden fazla sertifikası olan ekipler, kurulu e-posta
DNS TXT Kaydı	10-60 dakika	✅ Yüksek	⭐⭐⭐ Orta	✅ Evet	✅ Evet (397 gün)	Otomasyon, wildcard’lar, büyük dağıtımlar
DNS CNAME	15-60 dakika	✅ Yüksek	⭐⭐⭐ Orta	✅ Evet	✅ Evet (397 gün)	Alan adı ön doğrulama, CA tarafından yönetilen belirteçler
HTTP Dosya	5-20 dakika	⚠️ Orta	⭐⭐ Düşük-Orta	❌ Hayır	❌ Hayır	Doğrudan sunucu erişimi, IP adresleri
ACME (HTTP-01)	2-10 dakika	✅ Çok Yüksek	⭐⭐⭐⭐ Orta-Yüksek	❌ Hayır	Geçerli değil (otomatik yenileme)	Tam otomasyon, Let’s Encrypt
ACME (DNS-01)	2-10 dakika	✅ Çok Yüksek	⭐⭐⭐⭐ Orta-Yüksek	✅ Evet	Geçerli değil (otomatik yenileme)	Wildcard’larla tam otomasyon

Senaryoya Göre Yöntem Seçimi

Şu durumlarda e-posta doğrulaması kullanın:

• Basit, tek seferlik sertifika siparişleriniz varsa
• Genel yönetici e-posta adresleri izleniyorsa
• Otomasyona ihtiyacınız yoksa

Şu durumlarda DNS TXT/CNAME doğrulaması kullanın:

• Wildcard sertifikalara ihtiyacınız varsa
• Birden fazla sertifikayı yönetiyorsanız
• Web sunucusu erişiminiz yoksa
• Otomasyon yetenekleri istiyorsanız

Şu durumlarda HTTP dosya doğrulaması kullanın:

• Doğrudan web sunucusu erişiminiz varsa
• IP adreslerini doğruluyorsanız
• Kuruluşunuzda DNS değişiklikleri zorsa

---

Yaygın DCV Sorunları ve Hızlı Çözümler

Doğrulama başarısızlıkları yaşanabilir. İşte karşılaşacağınız en sık hatalar ve bunları hızlıca çözmenin yolları.

HTTP Dosya Doğrulaması: “404 Not Found”

Hata: “The system queried for a temporary file at http://example.com/.well-known/pki-validation/[filename].txt, but the web server responded with the following error: 404 (Not Found).”

Hızlı çözümler:

• Dizin yapısını manuel olarak oluşturun: /public_html/.well-known/pki-validation/
• İzinleri ayarlayın: dizinler için 755, dosyalar için 644
• /.well-known/ yolunu engelleyebilecek .htaccess kurallarını kontrol edin
• Alan adı yeni eklendiyse, yayılma için 24-48 saat bekleyin
• Erişilebilirliği test edin: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

Yaygın neden: Doğrulama dosyası yolu mevcut değil veya herkese açık olarak erişilebilir değil.

HTTP Doğrulaması: “Forbids DCV HTTP Redirections”

Hata: “cPanel (powered by Sectigo) forbids DCV HTTP redirections.”

Hızlı çözümler:

• Doğrulama sırasında HTTPS’e yönlendirmeleri geçici olarak devre dışı bırakın
• Yönlendirme kurallarından /.well-known/* yolunu hariç tutun
• .htaccess, Cloudflare sayfa kurallarını veya sunucu yapılandırmasını yönlendirmeler için kontrol edin
• CDN kullanıyorsanız, geçici olarak devre dışı bırakın veya istisna ekleyin

Yaygın neden: Siteniz HTTP’yi HTTPS’e yönlendiriyor veya başka bir alan adına yönlendiriyor, bu da CA’nın doğrulama girişimini engelliyor.

DNS Doğrulaması: “No TXT Record That Matches”

Hata: “The DNS query to ‘_dvsauth.example.com’ for the DCV challenge returned no ‘TXT’ record that matches the value ‘[expected-value]’.”

Hızlı çözümler:

• DNS yayılması için 1-24 saat bekleyin (TTL’ye bağlıdır)
• Tam ana bilgisayar adını ve değeri doğrulayın: dig _dvsauth.example.com TXT +short
• Doğrulama belirtecinde kopyala/yapıştır hatalarını kontrol edin
• Devredilmiş DNS (NS kayıtları) kullanıyorsanız, TXT kaydını doğru sağlayıcıda ekleyin
• Doğrulama kayıtlarını eklemeden önce TTL’yi 300 saniyeye (5 dakika) düşürün

Yaygın neden: DNS henüz yayılmamış veya kayıtta yazım hataları var.

DNS Doğrulaması: CAA Kayıtları Sertifika Verilmesini Engelliyor

Hata: “Certificate authority encountered a multiple perspective CAA check error.”

Hızlı çözümler:

• Mevcut CAA kayıtlarını kontrol edin: dig example.com CAA
• CA’nızı izin verilen sertifika verenler listesine ekleyin: example.com. CAA 0 issue “digicert.com”
• ping.pe aracını kullanarak CAA kayıtlarının global olarak çözümlendiğini doğrulayın
• CAA kaydı yoksa, herhangi bir kayıt eklemenize gerek yoktur (yokluk tüm CA’lara izin verir)

Yaygın neden: CAA kayıtları, alan adınız için hangi CA’ların sertifika verebileceğini kısıtlıyor.

E-posta Doğrulaması: E-posta Alınmıyor

Hızlı çözümler:

• Önce spam/gereksiz klasörlerini kontrol edin
• Bu adreslerin var olduğunu ve e-posta aldığını doğrulayın: admin@, administrator@, webmaster@, hostmaster@, postmaster@
• MX kayıtlarını kontrol edin: dig example.com MX
• CA’nın e-posta gönderim alan adlarını spam filtrenizde beyaz listeye alın
• CA’nın kontrol panelinden e-postanın yeniden gönderilmesini isteyin

Yaygın neden: Doğrulama e-postası spam filtreleri tarafından yakalanıyor veya yönetici adresleri mevcut değil.

Platforma Özgü: cPanel AutoSSL Hataları

Hata: “Local HTTP DCV error: An internal error occurred.”

Hızlı çözümler:

• Ayrıntılar için WHM > Manage AutoSSL günlüklerini kontrol edin
• 30 dakika bekleyip tekrar deneyin (genellikle kendiliğinden çözülür)
• Sectigo ve Let’s Encrypt sağlayıcıları arasında geçiş yapın
• AutoSSL kuyruğunu temizleyin: WHM > Manage AutoSSL > Clear pending queue

Hızlı Tanılama Komutları

Destekle iletişime geçmeden önce şu kontrolleri çalıştırın:

# Verify DNS propagation
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short

# Test HTTP file accessibility
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

# Check CAA and MX records
dig yourdomain.com CAA
dig yourdomain.com MX

---

SSL Sertifikası Yönetiminizi SSL Dragon ile Basitleştirin

Alan adı kontrol doğrulamasını doğru yapmak, sorunsuz sertifika dağıtımı için son derece önemlidir. SSL Dragon, ister e-posta, ister DNS, ister HTTP tabanlı doğrulamayı tercih edin, ihtiyacınız olan tüm doğrulama yöntemleriyle güvenilir Sertifika Otoritelerinden sertifikalar sunar.

Ekibimiz, Alan Adı Doğrulamalı, Organizasyon Doğrulamalı ve Genişletilmiş Doğrulama sertifikaları için DCV gereksinimlerinde size yol gösterir. Altyapınıza uygun doğrulama yöntemini sizinle birlikte adım adım geçer ve doğrulama sorunları ortaya çıktığında sorularınızı yanıtlarız.

Sertifika doğrulamasıyla boğuşmayı bırakın. SSL sertifikası seçeneklerimize göz atın!