Ana site açılıyor, ancak shop.example.com veya staging.example.com DNS_PROBE_FINISHED_NXDOMAIN hatası veriyor ya da hosting'in varsayılan sayfasına düşüyor. Sorun neredeyse her zaman üç şeyden biridir: DNS kaydı oluşturulmamış, kayıt oluşturulmuş ama yanlış Zone'da, veya sunucudaki VirtualHost o ad için tanımlanmamış. Bu metin tam olarak izlemeniz gereken yoldur, ayrıca çok az kişinin zamanında fark ettiği iki tuzağa da değiniyor: SSL sertifikası ve terk edilmiş alt alan adları.
DNS'te alt alan adı nedir ve nereye kaydedilir
Alt alan adı bir ana makine adıdır, bağımsız bir alan adı değildir. Yani üst alan adının Zone dosyasına bir A veya CNAME kaydı olarak yazılır. DNS'i hosting panelinden yönetiyorsanız genellikle basit bir form görürsünüz; ayrı bir DNS servisi kullanıyorsanız kaydı kendiniz yazmalısınız:
shop 3600 IN A 185.xx.xx.xx
staging 3600 IN CNAME shop.example.com.
* 3600 IN A 185.xx.xx.xx
İlk nokta: Zone dosyasında ana makine adını üst alan adı olmadan yazarsınız. example.com alan adının Zone'unda shop.example.com. IN A ... yazmak, shop.example.com.example.com adında bir kayıt oluşturulmasına neden olur. Bu hata grafik panellerde görülmez, ancak Zone dosyasını elle yazdığınızda veya API kullandığınızda sıkça görülür. Teşhis işareti de basittir: dig shop.example.com NXDOMAIN yanıtı verirken kayıt dosyada vardır.
İkinci nokta: CNAME'i alan adının köküne (@) koymayın. DNS standardı bunu yasaklamıştır ve bazı Resolver'lar sessizce yok sayar. Kök için A kullanın.
Wildcard kaydı: kolay, ama bir şartla
* kaydı, özel kaydı olmayan her adı bir IP'ye yönlendirir. Sürekli rastgele alt alan adı oluşturduğunuz test ortamları için mükemmeldir. Ancak pratikte can sıkan iki sınırlaması vardır. Birincisi, wildcard yalnızca bir seviyeyi kapsar: *.example.com, a.b.example.com adına yanıt vermez. İkincisi, daha sonra bir alt alan adını kasıtlı olarak erişim dışı bırakmak isterseniz bunu yapamazsınız; çünkü wildcard her şeyi yakalar. Tek yol, geçersiz değere sahip açık bir kayıt oluşturmaktır ki bu da kendi başına bir teknik borç haline gelir.
Alt alan adı için SSL sertifikası: burada hata yapıyorlar
SSL sertifikası ana alan adında alt alan adı için hiçbir şey yapmaz. example.com için sertifika aldıysanız ve shop.example.com'u aynı sunucuda açtıysanız, tarayıcı alt alan adı için NET::ERR_CERT_COMMON_NAME_INVALID hatası verir. Bu hata sunucu loglarında görünmez çünkü istek hiçbir zaman uygulamaya ulaşmaz; en azından TLS handshake bozulur. Çoğu kişi saatlerce Nginx logunu okur ve hiçbir şey bulamaz.
Üç yolunuz var:
| Yöntem | Kapsam | Gerçek maliyet |
|---|---|---|
| Her alt alan adı için ayrı sertifika | Kesin ve kontrollü | Her biri için ayrı yenileme ve otomasyon |
| Wildcard sertifikası | *.example.com bir seviye | DNS doğrulaması ve TXT kaydı yayınlama gerektirir |
| Çok alan adlı sertifika (SAN) | Belirli bir ad listesi | Her yeni alt alan adı sertifikanın yeniden düzenlenmesi demektir |
Alt alan adı sayısı sabit ve azsa SAN'ı seçerim; daha basit ve daha öngörülebilirdir. Sürekli alt alan adı oluşturup siliyorsanız wildcard avantajlıdır, yeter ki yenileme otomasyonunu doğru kurun. Certbot ile bu, --manual --preferred-challenges dns bayraklı bir komut gerektirir ve DNS'i elle doğruladığınız için otomatik yenileme devre dışı kalır. Burada hata yapıyorlar: wildcard sertifikası alıyorlar, üç ay sonra elle yenilemeyi unutuyorlar ve pazartesi sabahı tüm alt alan adları aynı anda sertifika hatası veriyor.
VirtualHost ve ServerAlias
DNS ve SSL'den sonra sıra web sunucusuna gelir. Nginx'te server_name'i tam olarak yazmalısınız:
server {
listen 443 ssl;
server_name shop.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/shop;
}
Alt alan adını server_name'e koymazsanız, Nginx onu aynı porttaki ilk VirtualHost'a yönlendirir. Sonuç: ana siteyi görürsünüz, ama alt alan adı adresiyle. Bu tam olarak kullanıcının DNS'in bozuk olduğunu düşündüğü durumdur, oysa DNS sağlamdır ve sorun sunucudadır. curl -I https://shop.example.com ile Server başlığına ve dönen içeriğe bakmak hızlıca ortaya çıkarır.
Terk edilmiş alt alan adı nasıl ihlale yol açar
Bu bölümü ciddiye alın. old-panel.example.com gibi bir alt alan adını geçen yıl bir bulut sunucusuna yönlendirmişsiniz. O sunucuyu boşaltmışsınız, ancak DNS kaydını silmemişsiniz. Şimdi herkes aynı IP'yi alıp old-panel.example.com üzerinde tarayıcı açısından tamamen geçerli görünen içerik yayınlayabilir. Ana alan adında .example.com alan adıyla çerez oluşturduysanız, o çerez bu alt alan adına da gider. Bu saldırı sınıfının bir adı var: Subdomain Takeover.
Belirtilerini loglarda görmezsiniz. Genellikle dışarıdan haberdar olursunuz. Bunları bulmak için alt alan adları listesini şeffaflık sertifikalarından (Certificate Transparency) çekin ve her birini dig +short ile kontrol edin. Artık size ait olmayan bir IP'ye veya harici servise işaret eden her kayıt aynı gün silinmelidir. Alt alan adı sayısı fazlaysa bu işi bir cron betiğine bırakın ve haftalık çalıştırın.
Bir yan not: Alt alan adlı WordPress multisite kullanıyorsanız, her yeni site yeni bir alt alan adıdır ve bu durum DNS ile SSL yönetimini karmaşıklaştırır. Bu mimariyi seçmeden önce WordPress multisite maliyet-fayda analizini okuyun; çoğu durumda birkaç ayrı kurulum daha az sorun çıkarır.
Pratik kurulum kontrol listesi
- Üst alan adının Zone'unda
AveyaCNAMEkaydını oluşturun vedig shop.example.com +shortile doğrulayın. - Uygun SSL sertifikasını alın ve son kullanma tarihini zihninizdeki takvime değil, izleme sistemine koyun.
- Web sunucusuna
server_nameekleyin vecurl -Iile doğru yanıtı görün. - WordPress ise, site adresini veritabanında güncelleyin; aksi halde yönlendirme döngüsü alırsınız.
- Kullanılmayan alt alan adlarını gözden geçirmek için zamanlanmış bir görev koyun.
Daha hızlı kurulum için, Linux hosting aynı panelden alt alan adı tanımlama ve sertifika kurma imkanı verir ve Zone dosyasını elle yazmanız gerekmez. WordPress üzerinde çalışıyorsanız ve test ortamını ayırmak istiyorsanız, WordPress staging kurulumu test alt alan adının ana alan adına bağlanmaması için daha güvenli bir yol gösterir. Terminal komutları için de ServerNet dokümantasyonu daha hızlı bir başvuru kaynağıdır.
Ve eğer sadece şu anda kaç alt alan adınız olduğunu ve hangilerinin ölü olduğunu bilmek istiyorsanız, ücretsiz araçlar iyi bir başlangıç noktasıdır. Bu hafta yapmanız gereken tek şey var: alt alan adları listesini çekin ve artık size ait olmayan bir harici servise işaret eden her kaydı silin. Geri kalan işler daha sonra da yapılabilir; bu yapılamaz.
Sık sorulan sorular
Alt alan adı yeni alan adı satın almayı gerektirir mi?
Hayır. Alt alan adı üst alan adının bir parçasıdır ve aynı Zone'da kaydedilir. Sadece DNS kaydı oluşturmanız ve sunucuda onun için VirtualHost tanımlamanız gerekir. Adın kendisi için ek ücret ödemezsiniz, ancak ayrı SSL sertifikası gerekirse o maliyet ayrıdır.
Alt alan adım neden açılıyor ama ana siteyi gösteriyor?
Çünkü DNS kaydı doğrudur ancak web sunucusu ana makine adını tanımaz ve isteği o porttaki ilk VirtualHost'a yönlendirir. Nginx'te server_name veya Apache'de ServerAlias ekleyip servisi yeniden başlatmanız yeterlidir.
Wildcard sertifikası tüm alt alan adları için çalışır mı?
Yalnızca bir seviyeyi kapsar. *.example.com, shop.example.com adını kapsar ama a.shop.example.com'u kapsamaz. İkinci seviye için ayrı sertifika veya ayrı wildcard kaydı gerekir.
Bir alt alan adının terk edilmiş ve tehlikeli olduğunu nasıl anlarım?
dig +short altalanadı ile kaydın değerini görün. Artık sizin kontrolünüzde olmayan bir IP'ye veya bulut servisine işaret ediyorsa, o kaydı hemen silin. Emin olmak için alt alan adları listesini Certificate Transparency'den çekin ve hepsini bir kez gözden geçirin.
Yorumlar 0
Henüz yorum yok — ilk siz olun!