DNS kayıt türleri: sözdizimi, örnek ve sınırlamalar için tam referans

Zone dosyası açık, panel kaydın kaydedildiğini söylüyor, ama dig yanıt vermiyor ya da yanlış yanıt veriyor. Sorun neredeyse her zaman belirli bir yerdedir: kayıt sözdizimi. Bir fazla ya da eksik nokta, yanlış bir boşluk veya o konumda izin verilmeyen bir kayıt türü seçimi. Bu metin tam o an için kısa referanstır; her kayıt kesin sözdizimi, gerçek örnek ve pratikte karşılaşacağınız sınırlamayla birlikte.

Tüm DNS kayıt türlerinin üzerine oturduğu temel yapı

Zone dosyasındaki her satırın dört bölümü vardır: ad, TTL, sınıf ve tür, ardından değer. TTL ve sınıf isteğe bağlıdır ve yazmazsanız zone'un varsayılan değeri uygulanır. Sınıf %99 durumda IN'dir ve pratikte her zaman atlanır.

www    3600    IN    A    185.10.20.30
^      ^       ^     ^    ^
ad     TTL   sınıf  tür  değer

Çoğu kişiyi yere seren nokta: zone dosyasında nokta ile bitmeyen bir ad, zone'un sonuna eklenir. Yani mail, mail.example.com. olur; ancak sondaki nokta ile mail.example.com. mutlaktır. MX veya CNAME kaydının değerinde sondaki noktayı atlarsanız, sunucunuzu tamamen farklı bir alan adına yönlendirirsiniz ve hiçbir hata da almazsınız.

Adres kayıtları: A, AAAA ve gerçek sınırlamaları

A ve AAAA

A kaydı bir IPv4 adresini, AAAA ise bir IPv6 adresini eşler. Her ikisi de birden fazla değere sahip olabilir ve DNS yanıtı rastgele sırayla döndürür; bu en basit load balancing biçimidir, ancak ne health check'i ne de failover'ı vardır.

example.com.     300   IN   A      185.10.20.30
example.com.     300   IN   A      185.10.20.31
example.com.     300   IN   AAAA   2a01:4f8:c17:1234::1

Buradaki 300 saniye sayısı anlamlıdır. Sunucu taşıması için A kaydını değiştiriyorsanız, TTL'yi değişiklikten en az 24 saat önce 300 veya daha azına düşürün; aksi halde önceki TTL'in ömrü bitene kadar kullanıcıların bir kısmı eski sunucuya gider. Bu davranışın ayrıntılarını DNS yayılımı ve TTL önbelleği rehberinde yazdık.

CNAME kaydı ve ihlal edilen kural

CNAME bir adı IP'ye değil, başka bir ada alias yapar. Katı kuralı şudur: bir adda CNAME hiçbir başka kayıtla birlikte bulunamaz. Ne MX, ne TXT, ne A.

shop.example.com.   3600   IN   CNAME   example.myshopify.com.

Burada hata yaparlar: CNAME kaydını alan adının köküne (example.com.) koyarlar ve sonra e-postanın çalışmadığını ya da alan adı doğrulama TXT kaydının kaybolduğunu görürler. Bazı DNS sağlayıcıları bunu CNAME flattening ile gizler ve sorun, bir üçüncü taraf hizmet aynı adda başka bir kayda ihtiyaç duyana kadar görünmez. Alan adının kökünü harici bir hizmete bağlamanız gerekiyorsa, ham CNAME değil ALIAS veya ANAME kaydı kullanın.

E-posta kayıtları: MX, SPF, DKIM ve DMARC

MX

MX kaydının iki bölümü vardır: öncelik numarası ve sunucu adı. Daha düşük sayı daha yüksek öncelik demektir. Aynı öncelikle iki sunucu koyarsanız, sıra rastgele olur ve bu neredeyse her zaman yanlış yapılandırmadır.

example.com.   3600   IN   MX   10   mail1.example.com.
example.com.   3600   IN   MX   20   mail2.example.com.

MX değeri ad olmalıdır, IP değil. Değer sütununa IP adresi yazmak, bazı panellerin sessizce kabul ettiği ve bazılarının reddettiği yaygın bir hatadır.

SPF, DKIM ve DMARC

Bu üçü, belirli adlara sahip TXT kayıtlarıdır. SPF köke oturur ve yalnızca bir SPF kaydına izin verilir; v=spf1 içeren iki TXT kaydı permerror'a neden olur ve sonucu tüm e-postaların fail olmasıdır.

example.com.                3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
sel1._domainkey.example.com. 3600 IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
_dmarc.example.com.         3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

SPF'deki 10 lookup sınırı bir öneri değil, gerçek bir sınırlamadır. Her include, a ve mx bir lookup tüketir ve 10'u aşmak permerror'a neden olur. SPF'niz 8'e ulaştıysa, include eklemenin yeri yoktur; yeniden yazılması gerekir.

Hizmet ve yönlendirme kayıtları: SRV, CAA, TXT ve NS

SRV

SRV'nin dört değeri vardır: priority, weight, port ve target. SIP, XMPP ve Minecraft gibi hizmetler için kullanılır.

_sip._tcp.example.com.   3600   IN   SRV   10 60 5060 sipserver.example.com.

SRV kaydının adı her zaman alt çizgi ile başlar: _service._proto.name. Alt çizgiyi kaldırırsanız, kayıt geçerlidir ama kimse onu query etmez.

CAA

CAA, alan adınız için hangi CA'nın SSL sertifikası vermeye yetkili olduğunu belirler. CAA koyar ve yanlış CA'ya izin verirseniz, otomatik sertifika yenileme başarısız olur ve site süresi dolmuş sertifika hatasıyla açılır.

example.com.   3600   IN   CAA   0 issue "letsencrypt.org"
example.com.   3600   IN   CAA   0 iodef "mailto:security@example.com"

TXT ve NS

TXT'nin uzunluk sınırı vardır: her dize en fazla 255 karakter ve toplam kayıt yaklaşık 4096 bayta kadar. DKIM anahtarı gibi uzun değerler için dizeyi tırnak içinde birkaç bölüme ayırın; DNS yazılımı kendisi birleştirir.

Kendi zone'unuzdaki NS kaydı yalnızca alt alan adları için anlamlıdır (delegation). Kök NS kaydını DNS panelinden değiştirmek genellikle etkisizdir, çünkü kök NS zone'da değil, registry'de kayıtlıdır. .ir alan adları için bu işlem IRNIC panelinden yapılır; ayrıntısı IRNIC kimliği ile ir alan adı kaydı ve yönetimi rehberinde yer alıyor.

DNS kayıt türlerinin hızlı karşılaştırması

PTR kaydını ayrıca vurguluyorum çünkü en çok yanlış anlaşılan kayıttır. PTR'yi alan adınızın DNS panelinde oluşturamazsınız; IP sağlayıcısının onu ayarlaması gerekir. E-posta sunucunuz varsa ve PTR, helo adınızla uyuşmuyorsa, Gmail e-postayı reddeder ve hata mesajı da açık değildir.

Bir şey çalışmadığında kontrol sırası

1. dig +trace example.com ile yanıtın hangi seviyeden geldiğine bakın.
2. dig @1.1.1.1 example.com A +short ile genel resolver yanıtını authoritative yanıtla karşılaştırın.
3. Farklıysa, TTL bitmemiştir; kaydı yeniden kaydetmek yerine bekleyin.
4. E-posta için dig example.com TXT +short çalıştırın ve kaç v=spf1 kaydının döndüğünü sayın.

Tam kontrol sırası ve her adımın belirtileri pratik DNS sorun giderme rehberinde yer alıyor. Resolver'ların dışarıdan ne gördüğünü görmek istiyorsanız, DNS kayıt kontrol aracını kullanın; tarayıcı önbelleğini temizlemekten daha hızlıdır.

TTL seçimi: sonradan pişmanlık yaratan karar

Sabit kayıtlar için 3600 saniye varsayılanı doğrudur. Taşıma veya failover'da değişebilecek kayıtlar için 300 saniye daha mantıklıdır. Ancak kısa TTL'in maliyeti vardır: nameserver'ınıza query yükü katlanır ve DNS'niz zayıf bir altyapıdaysa, kendisi kesinti kaynağı olur. Ben yüksek trafikli alan adları için TTL 300'ü yalnızca A ve CNAME kayıtlarında kullanıyorum, gerisini 3600'de tutuyorum.

Hedef sunucunuz bir VPS ise ve A kaydından SSL sertifikasına kadar her şeyi tek seferde kurmak istiyorsanız, iş sırası alan adını sanal sunucuya bağlama rehberinde adım adım verilmiştir. Dinamik alt alan adları için de wildcard kaydı ve alt alan adı yönetiminde yüzlerce manuel kayıt oluşturmayı önleyen bir ipucu var.

Pratik bir not: DNS'yi kendi kontrol ettiğiniz bir altyapıda barındırıyorsanız, nameserver kararlılığı web sunucusu kararlılığı kadar önemlidir. Küçük ve orta ölçekli yükler için, zone dosyasına tam erişimli Linux hosting başlamak için makul bir yerdir.

Sık sorulan sorular

Alan adının köküne CNAME kaydı konabilir mi?

Standarta göre hayır. Kökteki CNAME, NS ve SOA kayıtlarıyla çelişir. Bazı sağlayıcılar bunu CNAME flattening ile simüle eder ve görünüşte çalışır, ancak sonradan aynı ada MX veya TXT kaydı koymak isterseniz sorun yaşarsınız. Doğru yol, ALIAS veya ANAME kaydıdır.

Kaydı değiştirdikten sonra neden hâlâ eski IP'yi görüyorum?

Çünkü önceki kaydın TTL'i bitmemiştir ve resolver'lar önbelleğe alınmış yanıtı döndürür. dig @8.8.8.8 example.com A +short ile resolver yanıtına bakın ve dig @ns1.example.com example.com A +short ile authoritative yanıtı karşılaştırın. Fark, önbellek demektir, yapılandırma hatası değil.

Kaç SPF kaydım olabilir?

Yalnızca bir tane. v=spf1 içeren iki TXT kaydı permerror'a neden olur ve sonucu doğrulamanın fail olmasıdır. Yeni bir hizmete ihtiyacınız varsa, include'u mevcut kayda ekleyin ve 10 lookup sınırına dikkat edin.

PTR kaydını nereden ayarlayabilirim?

Alan adınızın DNS panelinden ayarlayamazsınız. PTR, IP bloğunun sahibinin kontrolündeki in-addr.arpa zone'unda bulunur. Sunucu veya IP sağlayıcınızdan onu helo adınıza ayarlamasını istemelisiniz. E-posta sunucuları için bu isteğe bağlı değildir.

Her değişiklikten önce bir kez dig +short çalıştırın ve çıktıyı kaydedin. Bir şey bozulduğunda, o tek satır beş dakika ile beş saat arasındaki sorun giderme farkıdır.