Apakah standar internet memerlukan DNS terbalik untuk setiap perangkat?

Persyaratan seputar reverse DNS membingungkan! Orang-orang sering berbicara tentang segala sesuatu yang melanggar jika reverse DNS tidak ada, dan itu terdengar menakutkan. Bahkan dalam kasus di mana aplikasi tidak memerlukan reverse DNS, RFC sering dikutip untuk mendukung pembuatan catatan PTR wajib.

Beberapa RFC ini meliputi:

RFC1912 : Kesalahan Operasional dan Konfigurasi DNS Umum

Setiap host yang dapat dijangkau Internet harus memiliki nama. ... Pastikan PTR dan A Anda cocok. Untuk setiap alamat IP, harus ada catatan PTR yang cocok di domain in-addr.arpa. Jika sebuah host multi-homed, (lebih dari satu alamat IP) pastikan bahwa semua alamat IP memiliki catatan PTR yang sesuai (bukan hanya yang pertama). Kegagalan untuk memiliki pencocokan PTR dan catatan A dapat menyebabkan hilangnya layanan Internet yang mirip dengan tidak terdaftar di DNS sama sekali.

RFC1033 : PANDUAN OPERASI DOMAIN ADMINISTRATOR

Menambahkan host

 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.

Terlepas dari semua itu, beberapa orang masih bersikeras mengatakan bahwa pembuatan catatan PTR tidak diperlukan oleh standar yang mengatur administrasi DNS. Apa persyaratan sebenarnya?

Jawaban singkat

Apakah standar yang mengatur operasi DNS mengharuskan semua perangkat memiliki catatan PTR yang cocok? Tidak.

Apakah standar untuk protokol tertentu memerlukan PTRcatatan yang sesuai dengan yang sesuai Aatau AAAAcatatan? 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 PTRcatatan untuk tidak disimpan dalam sinkronisasi dengan korespondensi mereka A/ AAAAcatatan sebagai perangkat dinonaktifkan, mengakibatkan creep PTRdata 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 NXDOMAINhanya 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 NXDOMAINrespons 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.