DNS kayıt türlerinin A'dan Z'ye listesi: her bölgede bulunan günlük türler, DNSSEC ve güvenlik kayıtları, VoIP, Kerberos veya hizmet keşfinde karşılaşılan özel türler, araçların yazdırdığı yalnızca sorguya özgü sözde türler ve eski bölge dosyalarında hâlâ görülen eskimiş türler. Her kayıt için: tür numarası ve tanımlayan RFC, ne işe yaradığı, bölge dosyası sözdiziminde bir örnek, onu bozan hatalar ve nasıl kontrol edileceği.
Yaygın türleri DNS Sorgulama ile canlı sorgulayın. Sorgu yanlış veri yerine hiç yanıt döndürmüyorsa aldığınız durumu DNS hata kodları A–Z açıklar.
Eşleşen kayıt yok.
Bir adı IPv4 adresine eşler: www.example.com. 300 IN A 192.0.2.10. Bir adda birden fazla A kaydı basit bir round-robin sağlar. Yaygın hatalar: genel DNS'te yayımlanan özel bir adres (10.x, 192.168.x), sunucu taşındıktan sonra A kaydı olmadan kalan kök ad ve bir taşımanın herkese ulaşmasını bir gün sürdüren uzun TTL. DNS Sorgulama ile kontrol edin.
Bir adı IPv6 adresine eşler: www.example.com. 300 IN AAAA 2001:db8::10. Yalnızca hizmet gerçekten IPv6 üzerinden yanıt veriyorsa yayımlayın. Orada dinlemeyen bir sunucuyu gösteren AAAA kaydı, IPv6 istemcilerinin IPv4'e dönmeden önce zaman aşımını beklemesine neden olur. Kaydı DNS Sorgulama, ters adı PTR Sorgulama ile kontrol edin.
AFS hücre veritabanı sunucularını ve DCE/NCA hizmetlerini gösterirdi. Bugün neredeyse kullanılmıyor; RFC 5864, AFS için bunun yerine SRV kayıtlarını önerir. Eski bir AFS kurulumu okumuyorsa kaldırılabilir.
Gerçek bir kayıt türü değildir: IANA kaydında ALIAS yoktur. DNS sağlayıcıları, CNAME'in bölge kökünde olamayacağı kuralını aşmak için bunu sunar. Sağlayıcının sunucusu hedefi kendisi çözer ve sıradan A/AAAA kayıtlarıyla yanıt verir; çözümleyiciler hiçbir "ALIAS" görmez. Adları değişir (ALIAS, ANAME, CNAME flattening). Yalnızca onu sunan sağlayıcıda çalışır ve bölge aktarımıyla taşınmaz. Arka plan: CNAME, A ve ALIAS.
Yayımladığınız bir kayıt değil, bir sorgu türüdür: "bu ad için tüm kayıtları gönder". ANY yanıtları yükseltme saldırılarında kötüye kullanıldığı için RFC 8482, sunucuların her şey yerine en küçük bir yanıt (çoğu zaman tek bir HINFO kaydı) döndürmesine izin verir. Bir bölgeyi listelemek için ANY'ye güvenmeyin; ihtiyacınız olan her türü ayrı sorgulayın.
Adres öneklerini listeler ("address prefix list"), örneğin APL 1:192.0.2.0/24 !1:192.0.2.128/25. Deneyseldir ve pratikte kullanılmaz. Bazı çözümleyiciler ve sağlayıcılar hiç desteklemez.
Bölge aktarımı sorgu türleri: AXFR tüm bölgeyi, IXFR yalnızca belirli bir SOA seri numarasından sonraki değişiklikleri kopyalar. İkincil sunucular birincil ile bu şekilde eşitlenir. Yalnızca kendi ikincil sunucularınıza, IP ile ve tercihen bir TSIG anahtarıyla izin verin; açık bir AXFR, iç adlar dahil tüm bölgenizi herkese verir. NODA bunu test eder (AXFR / Zone Transfer kontrolü).
Alan adı için hangi sertifika otoritelerinin sertifika verebileceğini söyler: example.com. CAA 0 issue "letsencrypt.org"; ayrıca joker sertifikalar için issuewild ve ihlal bildirimleri için iodef. CA'lar sertifika vermeden önce bunu kontrol etmek zorundadır. Kendi CAA kayıtları yoksa alt alan adlarına da uygulanır. Yaygın hata: bir CA için CAA ekleyip CDN'inizin veya e-posta sağlayıcınızın kullandığını unutmak; o sağlayıcının yenilemesi sessizce başarısız olur. DNS Sorgulama ile kontrol edin, kimin gerçekten sertifika verdiğini CT Kayıt Arama ile görün.
Alt bölge tarafından, üst bölgeye hangi DS kaydını istediğini söylemek için yayımlanır. Destekleyen kayıt kuruluşları ve kayıt firmaları CDS/CDNSKEY'i tarar ve DS'yi otomatik günceller; böylece anahtar değişimindeki elle yapılan adım ortadan kalkar. Özel bir değer (CDS 0 0 0 00), üst bölgeden DS'yi kaldırıp DNSSEC'i güvenle kapatmasını ister. Yalnızca kayıt kuruluşunuz veya kayıt firmanız bunu tarıyorsa işe yarar.
Bir sertifikayı veya iptal listesini (X.509, PGP ve diğerleri) DNS'te saklar. Nadiren kullanılır; DNSSEC tabanlı güvenle yaygın durumları TLSA, SMIMEA ve OPENPGPKEY karşılar. Eski PGP anahtar dağıtım düzenlerinde karşınıza çıkabilir.
Bir adı başka bir adın takma adı yapar: www.example.com. CNAME example.net. Çözümleyici sonra hedefi sorgular. CNAME olan bir adın başka kaydı olamaz; bu yüzden CNAME bölge kökünde olamaz (kökte SOA ve NS gerekir) ve MX veya TXT ile aynı adı paylaşamaz. Uzun zincirler her sorguyu yavaşlatır. MX veya NS'yi bir CNAME'e yönlendirmeyin (RFC 2181 §10.3). Daha fazlası: CNAME, A ve ALIAS.
Alt bölgenin, CDS'nin DS için yaptığı gibi, üst bölgeden NS kayıtlarını veya glue kayıtlarını otomatik kopyalamasını istemesini sağlar. Kayıt kuruluşlarındaki desteği hâlâ sınırlıdır. Esas olarak ad sunucularını sık değiştiriyorsanız ve kayıt kuruluşunuz destekliyorsa işe yarar.
DNS'i dinamik olarak güncelleyen DHCP sunucuları tarafından, bir adın hangi istemciye ait olduğunu kaydetmek ve iki istemcinin aynı ad için çakışmasını önlemek amacıyla yazılır. Dinamik DNS'li Windows/ISC DHCP kurulumlarında bulunur; elle düzenlenmek için değildir.
DNSSEC Lookaside Validation: kök ve TLD'ler henüz imzalı değilken güven çapalarını üst bölgenin dışında yayımlayan geçici bir çözüm. Ana DLV kaydı 2017'de kapandı ve RFC 8749 DLV'yi Historic durumuna aldı. Çözümleyicilerden kalan DLV yapılandırmasını kaldırın.
Bütün bir alt ağacı yönlendirir: old.example. DNAME new.example., altındaki her ad için a.old.example adının a.new.example olarak çözülmesini sağlar (ama old.example adının kendisini değil). Alan adı değişikliklerinde ve IPv6 ters bölge taşımalarında kullanılır. Sunucular eski çözümleyiciler için bir CNAME üretir. Yeniden yazılan ad 255 baytı aşarsa yanıt YXDOMAIN olur.
Bölgenin genel DNSSEC anahtarları. 257 bayrağı anahtar imzalama anahtarını (KSK, üst bölgedeki DS'nin gösterdiği), 256 bölge imzalama anahtarını (ZSK) belirtir. Çözümleyiciler RRSIG imzalarını bu anahtarlarla doğrular. Anahtarlar tek başına bölgeyi güvenli yapmaz: üst bölgede eşleşen bir DS yoksa doğrulayıcılar onları yok sayar. Algoritma 13 (ECDSA P-256) veya 15'i (Ed25519) tercih edin. Zinciri DNSSEC Kontrolü ile kontrol edin.
Üst bölgede (genellikle kayıt firmanız aracılığıyla) yayımlanır ve alt bölgenin anahtar imzalama anahtarının özetini taşır. Alt bölgenin DNSSEC'ini güvenilir yapan bağlantı budur. Özet türü 2'yi (SHA-256) kullanın. Klasik kesinti: eski DS kayıt firmasında dururken DNS sağlayıcısını değiştirmek; doğrulayan her çözümleyici SERVFAIL döndürür. Sağlayıcı değişikliğinden önce veya sırasında DS'yi kaldırın ya da değiştirin. DNSSEC Kontrolü ile kontrol edin.
Başlangıçta bir sunucunun işlemcisini ve işletim sistemini tanımlıyordu. Bunu yayımlamak artık bilgi sızıntısı sayıldığı için nadiren kullanılır. Tek bir rolle geri döndü: RFC 8482 sunucuları ANY sorgularına yapay bir HINFO kaydıyla yanıt verir (örneğin "RFC8482" ""). Bunu görüyorsanız sorun yoktur.
Bir ana bilgisayar için Host Identity Protocol kimliğini (bir genel anahtar) ve buluşma (rendezvous) sunucularını yayımlar. Yalnızca araştırma ve bazı endüstriyel ağlar dışında nadir olan HIP kurulumlarında kullanılır.
İstemcilere, bağlanmadan önce nasıl bağlanacaklarını söyler: desteklenen protokoller (alpn="h3,h2"), alternatif uç noktalar, IP ipuçları ve Encrypted ClientHello anahtarları. example.com. HTTPS 1 . alpn="h3,h2", tarayıcıların doğrudan HTTP/3'e geçmesini sağlar. Öncelik 0 takma ad kipidir ve CNAME'in aksine bölge kökünde çalışır. SVCB, diğer protokoller için genel biçimdir. Çoğu CDN bunu otomatik yayımlar.
Bir ana bilgisayar için IPsec genel anahtarını ve ağ geçidini yayımlar; fırsatçı şifreleme için kullanılır. Yalnızca bölge DNSSEC ile imzalıysa güvenilmelidir. Nadiren kullanılır.
Birinci nesil DNSSEC kayıtları. RFC 3755, bölge imzalama için bunları DNSKEY ve RRSIG ile değiştirdi. SIG(0) işlem imzaları birkaç dinamik güncelleme düzeninde hâlâ vardır, ama modern bir imzalı bölgede KEY/SIG görmemelisiniz.
IPsec anahtar görüşmesi için, MX'e benzer biçimde, bir alan adının anahtar değişim sunucusunu adlandırır. Bilgilendirici bir RFC'dir, neredeyse hiç kullanılmaz.
Bir ana bilgisayarın fiziksel konumunu enlem, boylam, yükseklik ve hassasiyet olarak verir: LOC 40 26 57 N 79 58 12 W 300m. Cloudflare destekler; çoğu sağlayıcı desteklemez. Herkese açık olduğunu unutmayın: gizli tutmak istediğiniz bir şeyin konumunu yayımlamayın.
1987'nin ilk e-posta ve hizmet kayıtları; MX (RFC 974) ile değiştirildiler ve o zamandan beri pek kullanılmadılar. Açık portları listeleyen WKS ("well-known services") da eskimiştir. Eski bir yazılımda veya bölge dosyasında hâlâ varsa kaldırın.
Alan adı için hangi sunucuların e-posta aldığını bir öncelikle söyler (düşük olan önce denenir): example.com. MX 10 mx1.example.com. Hedef A/AAAA kayıtları olan bir ana bilgisayar adı olmalıdır; IP veya CNAME olamaz. MX yoksa gönderenler alan adının A kaydına döner. E-posta almayan bir alan adı boş MX (MX 0 ., RFC 7505) ve boş SPF yayımlamalıdır. SPF / DKIM / DMARC Kontrolü ve DNS Sorgulama ile kontrol edin.
Dynamic Delegation Discovery (DDDS) tarafından kullanılan bir yeniden yazma kuralıdır: bir adı bir hizmete ve sorgulanacak sonraki ada ya da URI'ye eşler; ardından genellikle SRV gelir. SIP/VoIP ve ENUM'da (DNS'te telefon numaraları, e164.arpa altında) karşınıza çıkar. Regex alanını yanlış yazmak kolaydır; NAPTR → SRV → A zincirinin tamamını test edin.
Bir bölgenin yetkili ad sunucularını listeler. İki yerde bulunur: üst bölgede (yetki devri, kayıt firmanızda ayarlanır) ve bölgenin kendisinde. İki liste eşleşmelidir. En az iki ad sunucusu kullanın, tercihen farklı ağlarda; sunduğu bölgenin içinde adı olan bir ad sunucusu üst bölgede glue kaydı gerektirir. Yaygın bozulma: sağlayıcı değişikliğinden kalan ve REFUSED döndüren bir NS. Yetki devrini ve tutarlılığı NODA ile, kayıtları DNS Sorgulama ile kontrol edin.
Bir adın veya türün var olmadığına dair DNSSEC'in imzalı kanıtı: her NSEC bölgedeki bir sonraki var olan adı belirtir. Yan etki: herkes zinciri izleyip bölgedeki tüm adları listeleyebilir ("zone walking"). Bu sizin için önemliyse NSEC3'ü veya birçok imzalama sağlayıcısının kullandığı "black lies" / compact denial yaklaşımını kullanın.
NSEC gibidir ama var olmamayı karma (hash) adlar üzerinden kanıtlar; bu, zone walking'i zorlaştırır (imkânsız kılmaz: karmalar çevrimdışı kırılabilir). NSEC3PARAM karma parametrelerini yayımlar. RFC 9276, 0 ek yineleme ve boş tuz kullanılmasını söyler: daha fazla yineleme gerçek koruma sağlamadan çözümleyicilerin işlemcisini yorar ve çözümleyiciler yüksek değerleri güvensiz sayabilir (EDE 27). Mevcut değeri dig NSEC3PARAM example.com ile görün.
Bir kullanıcının OpenPGP genel anahtarını, adresinin yerel kısmının karmasıyla DNS'te yayımlar: <yerel-kısmın-sha256'sı>._openpgpkey.example.com. Yalnızca DNSSEC ile imzalı bir bölgede anlamlıdır. Çoğu kurulum bunun yerine HTTPS üzerinden Web Key Directory (WKD) kullanır.
Bir sorguda veya yanıtta EDNS(0) taşıyan sözde kayıt: UDP yük boyutu, DNSSEC OK (DO) biti ve cookie, client subnet ve Genişletilmiş DNS Hataları gibi seçenekler. Bölge dosyasında asla görünmez. dig bunu "OPT PSEUDOSECTION" olarak yazdırır. Eski sunucuların ve güvenlik duvarlarının OPT'yi bozuk işlemesi FORMERR'in olağan nedenidir.
Bir adresi tekrar bir ada eşler; in-addr.arpa (IPv4) veya ip6.arpa (IPv6) altında: 10.2.0.192.in-addr.arpa. PTR mail.example.com. Ters bölge, IP bloğunun sahibine, genellikle hosting sağlayıcınıza aittir; PTR'yi alan adınızın DNS'inde değil, onların panelinde ayarlarsınız. E-posta sunucuları, ileri A/AAAA kaydı ve HELO adıyla eşleşen bir PTR'ye ihtiyaç duyar. PTR Sorgulama ile kontrol edin.
Bir alan adının "sorumlu kişisini" bir posta kutusu ve TXT işaretçisi olarak adlandırır. Bugün nadiren yayımlanır, çoğunlukla spam çektiği için; aynı ihtiyacı SOA RNAME alanı ve RDAP iletişim bilgileri karşılar.
Bir kayıt kümesi üzerindeki, başlangıç ve bitiş zamanı olan DNSSEC imzası. İmzalayıcılar bunları bir takvime göre yeniden oluşturur; imzalama durursa bölge imzalar dolana kadar çalışır, sonra doğrulamanın açık olduğu her yerde başarısız olur (EDE 7). İmzalı bir bölgede RRSIG'i olmayan bir kayıt kümesi de doğrulamada başarısız olur (EDE 10). dig +dnssec ile isteyin; bitiş tarihlerini DNSSEC Kontrolü ile kontrol edin.
Bir e-posta adresi için S/MIME sertifikasını, TLSA ile aynı biçimde, <karma>._smimecert.example.com altında yayımlar. E-posta istemcilerinin bir alıcının sertifikasını DNSSEC üzerinden bulup güvenmesini sağlar. İstemci desteği şimdilik azdır.
Bölgenin başlık kaydı; bölge başına tam bir tane, kökte: birincil ad sunucusu (MNAME), iletişim posta kutusu (RNAME, ilk nokta @ anlamına gelir), seri numarası ve ikincil sunucular için refresh/retry/expire zamanlayıcıları. Son alan, çözümleyicilerin "yok" yanıtlarını ne kadar süre önbelleğe aldığını belirler (RFC 2308); yeni bir adın bir süre NXDOMAIN kalmasının nedeni budur. Her değişiklikte seri numarasını artırın, yoksa ikincil sunucular değişikliği almaz; olağan biçim tarih tabanlı YYYYMMDDnn'dir. Ad sunucuları arasında SOA tutarlılığını NODA ile kontrol edin.
SPF için hiç tutmayan özel bir kayıt türü. RFC 7208 (2014) bunu kaldırdı: SPF, v=spf1 ile başlayan bir TXT kaydında yaşar ve tür 99 kayıtları alıcılar tarafından yok sayılır. Sağlayıcınız hâlâ bir "SPF" kayıt türü sunuyorsa bunun yerine TXT kullanın. TXT sürümünü SPF Kaydı Oluşturucu ile oluşturup kontrol edin.
Bir hizmetin nerede çalıştığını söyler: _sip._tcp.example.com. SRV 10 60 5060 sip1.example.com. (öncelik, ağırlık, port, hedef). SIP, XMPP, LDAP, Kerberos, Active Directory, Minecraft, Matrix ve diğerleri kullanır. Adda iki etiket de bulunmalıdır, _service._proto; hedef A/AAAA kaydı olan bir ana bilgisayar adı olmalı, CNAME olmamalıdır. . hedefi "hizmet burada sunulmuyor" anlamına gelir. DNS Sorgulama ile kontrol edin.
Bir ana bilgisayarın SSH anahtarının parmak izini yayımlar; böylece istemci ilk bağlantıda "are you sure?" diye sormak yerine sunucuyu doğrulayabilir. OpenSSH bunu VerifyHostKeyDNS yes ile kullanır, ama yalnızca DNSSEC ile doğrulanmış yanıta güvenir. Kayıtları sunucuda ssh-keygen -r host.example.com ile üretin.
DANE: bir TLS sertifikasını veya anahtarını bir hizmet adına bağlar; _port._proto.host altında, örneğin _25._tcp.mail.example.com. TLSA 3 1 1 <sha256>. Çoğunlukla e-posta sunucuları arasındaki SMTP için kullanılır; orada şifreleme düşürmeye ve sahte sertifikalara karşı korur. DNSSEC ile imzalı bir bölge gerektirir. Anahtarı değiştirmeden önce TLSA kaydını güncelleyin, yoksa size e-posta teslimi bozulur. Sertifikayı SSL Kontrolü ile kontrol edin.
Yalnızca bir mesajın içinde var olan, bölgede asla bulunmayan meta kayıtlar. TSIG, sunucular arasındaki bölge aktarımlarını, NOTIFY ve dinamik güncellemeleri doğrulamak için bir DNS mesajını paylaşılan bir sırla (genellikle HMAC-SHA256) imzalar. TKEY bu anahtarları müzakere eder. İki tarafta anahtar adı, algoritma ve sır aynı olmalı, saatler izin verilen fark içinde olmalıdır; aksi halde BADSIG, BADKEY veya BADTIME alırsınız.
Serbest metin; SPF (v=spf1 …), DKIM anahtarları (selector._domainkey), DMARC (_dmarc) ve Google, Microsoft gibi hizmetlerin alan adı doğrulama belirteçleri için kullanılır. Her dize 255 karakterle sınırlıdır; daha uzun değerler, alıcının boşluksuz birleştirdiği birkaç tırnaklı dizeye bölünür. Yaygın hatalar: iki SPF kaydı (geçersiz), bir belgeden yapıştırılan akıllı tırnaklar ve kullanıldıktan yıllar sonra unutulmuş doğrulama belirteçleri. SPF/DKIM/DMARC'ı SPF / DKIM / DMARC Kontrolü ile kontrol edin.
Bir hizmet adını, SRV gibi öncelik ve ağırlıkla bir URI'ye eşler: _ftp._tcp.example.com. URI 10 1 "ftp://ftp.example.com/pub". Kerberos (MIT, KDC keşfi için) ve bazı diğer protokoller kullanır. DNS sağlayıcıları arasında yaygın desteklenmez.
Bütün bölgenin kökte yer alan bir özeti; alıcının, nasıl aktarıldığından bağımsız olarak tam bir kopyanın eksiksiz ve değiştirilmemiş olduğunu doğrulamasını sağlar. Kök bölge 2023'ten beri yayımlıyor. Dosya olarak dağıtılan bölgeler için kullanışlıdır (örneğin yerel kök kopyaları, RFC 8806).
Tür numaraları IANA DNS Parameters kaydından; tanımlayan RFC her kayıtta belirtilmiştir. Bir alan adının DNS'ini bütünüyle NODA ile puanlayın.
