İnternet standartları her cihaz için ters DNS gerektiriyor mu?

Ters DNS'i çevreleyen gereksinimler kafa karıştırıcıdır! İnsanlar, eğer ters DNS bulunmuyorsa ve bu korkutucu geliyorsa, kırılan her şey hakkında sık sık konuşuyor . Uygulamaların ters DNS gerektirmediği durumlarda bile, zorunlu PTR kaydı oluşturma desteği için RFC'lere sık sık atıf yapılır.

Bu RFC'lerden bazıları şunlardır:

RFC1912 : Yaygın DNS Operasyonel ve Konfigürasyon Hataları

İnternete erişilebilen her ana bilgisayarın bir adı olmalıdır. ... PTR ve A kayıtlarınızın eşleştiğinden emin olun. Her IP adresi için, inaddr.arpa etki alanında eşleşen bir PTR kaydı olmalıdır. Bir ana bilgisayar çok kanallıysa (birden fazla IP adresi), tüm IP adreslerinin karşılık gelen bir PTR kaydına (yalnızca birincisine değil) sahip olduğundan emin olun. Eşleşen PTR ve A kayıtlarına sahip olmamak, DNS’de kayıtlı olmamasına benzer İnternet servislerinin kaybına neden olabilir.

RFC1033 : DOMAIN ADMINISTRATORS ÇALIŞMA REHBERİ

Ana bilgisayar ekleme

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Bütün bunlara rağmen, bazı insanlar hala PTR kayıt oluşturma işleminin DNS yönetimini düzenleyen standartlar için gerekli olmadığını söylemekte ısrar ediyor . Gerçek gereksinimler neler?

Kısa cevap

DNS işlemini yöneten standartlar, tüm cihazların eşleşen bir PTR kaydına sahip olmasını gerektiriyor mu? Yok hayır.

Bazı protokollerin standartları PTR, karşılık gelenlerle aynı olan kayıtları mı Ayoksa AAAAkayıtları mı gerektiriyor ? Evet.

Bir RFC tarafından yönetilmeyen bazı uygulamalar aynı şartlara sahip mi? Evet.

Bir PTR kaydı bir CNAME'yi gösterebilir mi? Evet, ancak CNAME hedefi, söz konusu cihazın benzersiz adı olmalıdır (başka bir CNAME değil). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

Zorunlu PTR kaydı oluşturma en iyi yöntem midir? Genelde buna inanıyordu, ama kendine has sorunları var.

Uzun cevap

Bu soru-cevap, ortak bir yanlış anlaşılmanın dinlenmesine yardımcı olmak amacıyla sağlanmıştır.

Bir trajik underquoted bölüm RFC1796 burada da geçerlidir:

RFC olarak yayın yapmanın bir dereceye kadar tanınırlık sağlaması üzücü derecede iyi bir yanılgıdır. Düzenli bir dergide yayınlanan yayından değildir veya hiç olmaz. Aslında, her RFC, İnternet standardizasyon süreci ile olan ilişkisine göre bir statüye sahiptir: Bilgilendirici, Deneysel veya Standartlar Takibi (Önerilen Standart, Taslak Standart, İnternet Standardı) veya Tarihi.

RFC1912 Bilgi amaçlıdır. RFC1033 açıkça etiketlenmiş ve resmi bir tanımı olarak değil BİLİNMEYEN o kadar eski bir demek o şey için bir referans olarak kabul edilmemelidir . Standartları tanımlamıyorlar, resmi olarak bir standardı arttırmak için de kullanılamıyorlar. Asla bir standart tanımladıklarını ima eden bağlamda alıntı yapılmamalıdır.

Bilgilendirici RFC önerilerini iyi bir tavsiye ve yaygın olarak kabul edilmiş en iyi uygulama olarak düşünün. Ters DNS önerileri bir bakışta anlamlıdır: bu yönergelere uymak, bir uygulamanın çalışamadığı durumlarda ortaya çıkma riskinizi azaltır çünkü ters DNS için gerekli ve planlanmamış. Bir DNS yöneticisinin, gerektiren her uygulamayı / protokolü bilmesini kesinlikle bekleyemezsiniz ve ne yazık ki aynı şey, bu kayıtları isteyen hizmet sahipleri için de geçerlidir.

Bununla birlikte, çok iyi otomasyon dışında , zorunlu PTR kaydı oluşturma politikaları da kirlilik yaratıyor.

• Cihazların kullanım dışı PTRkalması nedeniyle kayıtların ilgili A/ AAAAkayıtlarla senkronize edilmemesi son derece olağandır ve PTRzamanla sahte veri sürünmesine neden olur . Bu veriler yalnızca bu bilgiyi güvenilir bulmaya çalışanları yanıltmaya yarar. Bazı uygulama sahipleri, hayalet bir sorunun nedenini araştırırken üzerine atlamak için can atıyorlar. Sorun, IPv6'nın benimsenmesi daha yaygın hale geldiğinden, özellikle taşıyıcı boyutunda IP alanından sorumlu DNS yöneticileri için daha da kötüleşmeye devam edecektir.
• Aynı IP adresi için birden fazla PTR kaydına sahip olmak oldukça yararsızdır ve Bilgilendirici RFC'lerin tavsiyelerine uymak kaçınılmaz olarak bununla sonuçlanacaktır. Bakın: Neden DNS’de birden fazla PTR kaydı önerilmiyor?

Daha kötüsü: PTR kaydının olmaması veya yanlış bir PTR kaydının olmaması? Bir protokol, standardı geçerli bir DNS gerektirdiğinden kırılırsa, ikisi de kötüdür ve ikincisi aslında daha kötü olabilir . Bunun dışında herkesin konuyla ilgili farklı görüşleri var. Sorun değil: ekibiniz ve şirketiniz için en uygun politikaları ve araçları bir araya getirmekte özgürsünüz. Yalnızca tutarlı sonuçlar aldıklarından ve verdiklerinden emin olun ve geriye doğru DNS'in yalnızca ekip üyelerinizin vermesi gereken süre kadar doğru olacağını ve disipline edileceğini unutmayın.

Ancak eksik PTR kayıtları sshd'nin kapanmasına neden oluyor!

Ayrıca doğru değil. İnsanlar genellikle bir PTR kaydının olmaması (NXDOMAIN) ile bozuk DNS tersi arasındaki çizgiyi karıştırır .

Bir yanıtınız NXDOMAINileri reverse DNS (FCrDNS) teyit gerektirir bir hizmeti ile iletişim halinde sadece bir soruna neden olur. Posta sunucuları, Kerberos, Oracle tarama VIP'leri vb.

Bozuk ters DNS, NXDOMAINzamanında yanıt almanızın imkansız olduğu durumdur . Pek çok uygulama (en ünlüsü sshd), yukarı akış kaynaklarından zamanında cevap alarak, uygulamada gecikmelere neden olan sorunlar varsa ters DNS aramasını engeller.