Jawaban singkat
Apakah standar yang mengatur operasi DNS mengharuskan semua perangkat memiliki catatan PTR yang cocok? Tidak.
Apakah standar untuk protokol tertentu memerlukan PTR
catatan yang sesuai dengan yang sesuai A
atau AAAA
catatan? Iya nih.
Apakah beberapa aplikasi yang tidak diatur oleh RFC memiliki persyaratan yang sama? Iya nih.
Bisakah PTR merekam titik pada CNAME? Ya, tetapi target CNAME haruslah nama unik perangkat yang dimaksud (dan bukan CNAME lain). ( RFC 2181§10.2 , RFC1034 §3.6.2 )
Apakah pembuatan arsip PTR wajib merupakan praktik terbaik? Secara umum diyakini begitu, tetapi ia memiliki masalah sendiri.
Jawaban panjang
T&J ini disediakan dengan maksud membantu menghilangkan kesalahpahaman yang umum.
Bagian tragis underquoted dari RFC1796 berlaku di sini:
Sayangnya, kesalahpahaman menyebar dengan sangat baik bahwa publikasi sebagai RFC memberikan tingkat pengakuan tertentu. Itu tidak, atau setidaknya tidak lebih dari publikasi dalam jurnal reguler. Faktanya, setiap RFC memiliki status, relatif terhadap hubungannya dengan proses standardisasi Internet: Jalur Informasi, Eksperimental, atau Standar (Standar yang Diusulkan, Standar Draf, Standar Internet), atau Historis.
RFC1912 adalah Informasi. RFC1033 tidak diberi label dengan jelas dan memiliki penunjukan resmi UNKNOWN , yang berarti sudah sangat tua sehingga tidak boleh dianggap sebagai referensi untuk apa pun . Mereka tidak mendefinisikan Standar, juga tidak dapat digunakan untuk menambah standar secara resmi. Mereka tidak boleh dikutip dalam konteks yang menyiratkan bahwa mereka mendefinisikan suatu standar.
Pikirkan saran RFC Informasional sebagai nasihat yang baik dan praktik terbaik yang diterima secara umum. Sekilas tentang rekomendasi DNS terbalik masuk akal: mengikuti panduan ini, kurangi risiko Anda dimasukkan ke dalam situasi di mana aplikasi gagal berfungsi karena DNS balik diperlukan dan tidak direncanakan. Anda tentu tidak dapat mengharapkan admin DNS untuk mengetahui setiap aplikasi / protokol yang membutuhkannya, dan sayangnya hal yang sama cenderung berlaku pada pemilik layanan yang meminta catatan tersebut.
Yang mengatakan, di luar otomatisasi yang sangat baik , kebijakan pembuatan catatan PTR wajib juga menciptakan polusi.
- Sangat umum bagi
PTR
catatan untuk tidak disimpan dalam sinkronisasi dengan korespondensi mereka A
/ AAAA
catatan sebagai perangkat dinonaktifkan, mengakibatkan creep PTR
data palsu dari waktu ke waktu. Data ini hanya berfungsi untuk menyesatkan mereka yang berusaha memperlakukan informasi tersebut sebagai kredibel. Beberapa pemilik aplikasi ingin sekali menggunakannya ketika mereka memburu penyebab masalah hantu. Masalahnya hanya akan terus menjadi lebih buruk karena adopsi IPv6 menjadi lebih umum, terutama untuk admin DNS yang bertanggung jawab untuk ruang IP berukuran operator.
- Memiliki beberapa catatan PTR untuk alamat IP yang sama sangat tidak berguna, dan mengikuti saran dari RFC Informasional akan menghasilkan hal ini. Lihat: Mengapa beberapa catatan PTR dalam DNS tidak disarankan?
Apa yang lebih buruk: tidak adanya catatan PTR, atau catatan PTR yang tidak akurat? Jika protokol rusak karena standarnya membutuhkan DNS yang valid, keduanya buruk, dan yang terakhir sebenarnya bisa lebih buruk . Di luar itu, setiap orang memiliki pendapat berbeda tentang masalah ini. Tidak apa-apa: Anda bebas untuk menyusun kebijakan dan alat yang paling cocok untuk tim dan perusahaan Anda. Pastikan saja mereka mengukur dan menghasilkan hasil yang konsisten, dan ingat bahwa membalikkan DNS hanya akan seakurat waktu dan disiplin yang harus diberikan oleh anggota tim Anda.
Tetapi hilangnya catatan PTR menyebabkan sshd hang!
Itu juga tidak benar. Orang sering membingungkan garis antara tidak adanya catatan PTR (NXDOMAIN), dan DNS terbalik yang terputus .
Balasan NXDOMAIN
hanya akan menimbulkan masalah jika Anda berkomunikasi dengan layanan yang memerlukan DNS balik yang dikonfirmasi ke depan (FCrDNS). Server surat, Kerberos, Oracle memindai VIP, dll.
DNS terbalik yang rusak adalah ketika tidak mungkin bagi Anda untuk mendapatkan NXDOMAIN
respons secara tepat waktu. Banyak aplikasi (yang paling terkenal sshd
) akan diblokir pada pencarian DNS terbalik jika ada masalah dalam memperoleh respons dari sumber hulu secara tepat waktu, menyebabkan keterlambatan dalam aplikasi.
sshd
menanggapi perlahan dapat dihindari dengan menempatkanUseDNS no
disshd_config
. (Tetapi meskipun Anda dapat mengatasi masalah itu tentu saja masih tidak dapat diterima, jika membalikkan waktu DNS habis atau menghasilkan respons kegagalan server.)