Gerçekten Önemli Olan DNS Kayıtları

Bir müşterinin DNS zone'una ilk kez erişim aldığım her seferinde, aynı pattern: bir kere denenip bir daha hiç kaldırılmamış servislerden bir avuç kayıt, iki mail provider öncesinden değiştirilmemiş bir SPF kaydı, ve genelde şu anda sessizce sorun yaratan bir şey için eksik ya da yanlış bir kayıt. DNS zone'ları cruft biriktiriyor, çünkü bir kaydı kaldırmak, kimse ne için olduğunu söyleyemese bile, onu bırakmaktan daha riskli geliyor. İşte gerçekten kontrol ettiğim kısa liste, kontrol ettiğim sırayla.

A ve AAAA: temel, ama ikisini de kontrol edin

A kaydı (IPv4) nadiren eksik oluyor, ama AAAA (IPv6) genelde ya yok ya da, daha kötüsü, var ve artık var olmayan bir adrese point ediyor. Eskimiş bir AAAA kaydı, dual-stack client'ların önce IPv6'yı deneyip fail etmesi ve IPv4'e fallback yapması demek, ki bu her connection'a bir delay ekliyor. Aktif olarak IPv6 çalıştırmıyorsanız, hiç AAAA kaydı olmaması, yanlış bir kayıt olmasından daha iyi.

MX ve mail'le ilgili TXT kayıtları

Domain mail gönderiyor ya da alıyorsa, MX kayıtları mail server'a point ediyor, ve SPF, DKIM, ve DMARC, hepsi TXT kayıtları, o domain adına gönderilen mail'e güvenilip güvenilmeyeceğini belirliyor. Bunları doğru kurmak hakkında daha detaylı yazmıştım, ama buradaki kontrol daha basit: bu kayıtlar hâlâ gerçeği mi yansıtıyor? İki yıl önce uzaklaşılmış bir mail provider'ı listeleyen bir SPF kaydı aktif olarak zararlı, sadece yardımcı olmamakla kalmıyor, current provider'dan gelen legitimate mail'in SPF alignment'ında fail etmesine de sebep olabiliyor.

NS kayıtları: registrar'ın düşündüğüyle eşleşiyor mu?

Basit geliyor ama, zone'un kendisinin döndürdüğü NS kayıtlarının domain registrar'ında configure edilenle eşleştiğini doğrulamaya değer. Buradaki bir mismatch, genelde tam tamamlanmamış bir DNS provider migration'ından kalan bir artık, bazı resolver'ların eski provider'ın kayıtlarını, bazılarının da yenisini görmesi demek, caching'e bağlı olarak, ki bu tam olarak "bende çalışıyor ama onlarda çalışmıyor" türünden, önce bunu kontrol etmezseniz saatlerce araştırma gerektiren bir soruna yol açıyor.

dig NS example.com
whois example.com | grep -i "name server"

CAA: neredeyse her zaman eksik olan kolay bir kayıt

CAA (Certification Authority Authorization) kayıtları, domain'iniz için hangi certificate authority'lerin sertifika issue edebileceğini belirliyor. Neredeyse hiç kimse bunu set etmiyor, ve tek bir kayıt:

example.com.  CAA  0 issue "letsencrypt.org"

Her türlü sertifika ile ilgili saldırıyı engellemiyor, ama hiç kullanmadığınız CA'lardan gelecek bir misissuance kategorisinin tamamını kapatıyor, sadece certificate authority değiştirdiğinizde update edilmesi gereken tek bir kayıt karşılığında. Düşük effort, gerçekten kullanışlı, ve bu zone'u kuran kişinin işini titizlikle yaptığının bir işareti.

TTL: değişiklik yaparken düşük, stabil olunca daha yüksek

Bu bir kayıt tipi değil, ama insanları sürekli tuzağa düşürüyor. Bir migration sırasında düşük bir TTL (mesela 300 saniye), bir şeyin rollback edilmesi gerekirse değişikliklerin hızlıca yayılması demek. Her şey stabil olduğunda, daha yüksek bir TTL (birkaç saatten bir güne) DNS provider'ınızdaki query yükünü azaltıyor ve resolver'ları cevabı daha uzun cache'lediği için end user'lar için resolution'ı biraz hızlandırıyor. En sık gördüğüm hata, aylar önce tamamlanmış bir migration'dan kalan, sürekli düşük bir TTL, zararsız, ama aynı zamanda toz dağıldıktan sonra kimsenin geri gelip temizlik yapmadığının bir işareti.

Asıl edinmeye değer alışkanlık

Bu kayıtların hiçbiri exotic değil, ve hiçbiri dig ve birkaç dakikadan başka özel tool gerektirmiyor. Değer tek bir kayıtta değil, bir DNS zone'unu, domain'e dokunmuş her servisin arkeolojik bir kaydı olarak değil, current reality'yi yansıtması gereken bir şey olarak ele almakta. DNS'e dokunan bir projeyi bitirdiğimde, artık kullanılmayan kayıtları kaldırmak otuz saniye sürüyor ve aylar sonra bir sonraki kişiyi (genelde kendimi), o mysterious TXT kaydının güvenle silinip silinemeyeceğini merak etmekten kurtarıyor.