Di kantor kami, kami memiliki jaringan area lokal dengan pengaturan DNS murni internal, di mana semua klien dinamai whatever.lan
. Saya juga memiliki lingkungan VMware, dan pada jaringan hanya mesin virtual, saya beri nama mesin virtual whatever.vm
.
Saat ini, jaringan untuk mesin virtual ini tidak dapat dijangkau dari jaringan area lokal kami, tetapi kami sedang menyiapkan jaringan produksi untuk memigrasikan mesin virtual ini, yang akan dapat dijangkau dari LAN. Akibatnya, kami mencoba menyelesaikan konvensi untuk akhiran domain / TLD yang kami terapkan untuk para tamu di jaringan baru ini yang kami siapkan, tetapi kami tidak dapat menghasilkan yang bagus, mengingat itu .vm
, .local
dan .lan
semua memiliki konotasi yang ada di lingkungan kita.
Jadi, apa praktik terbaik dalam situasi ini? Apakah ada daftar TLD atau nama domain di suatu tempat yang aman digunakan untuk jaringan internal murni?
.test
yang dicadangkan, meskipun itu membuatnya menjadi domain yang aman untuk digunakan untuk jaringan uji yang tidak akan terhubung ke internet.mydomain.com
, mendelegasikaninternal.mydomain.com
ke NS internal, dan mengkonfigurasi DNS cakrawala terpisah dengan benar ( "dilihat" di BIND) sehingga Anda tidak membocorkan nama / alamat internal ke internet. Ini tidak secantik TLD / pseudo-TLD, tetapi kurang rentan terhadap kerusakan karena berada di bawah kendali Anda.www.example.com
dan*.internal.example.com
yang tidak diizinkan antarawww.example.com
dan*.example.net
, terutama pengaturan cookie lintas situs. Menjalankan layanan internal dan eksternal pada domain yang sama meningkatkan risiko kompromi dari layanan publik akan memberikan sedikit tekanan pada layanan internal, dan sebaliknya bahwa layanan internal yang tidak aman dapat memicu penyalahgunaan internal layanan eksternal.Jawaban:
Jangan gunakan TLD yang ditemukan. Jika ICANN mendelegasikannya, Anda akan berada dalam masalah besar. Hal yang sama jika Anda bergabung dengan organisasi lain yang kebetulan menggunakan boneka TLD yang sama. Itu sebabnya nama domain yang unik secara global lebih disukai.
Standar, RFC 2606 mencadangkan nama untuk contoh, dokumentasi, pengujian, tetapi tidak untuk penggunaan umum, dan untuk alasan yang baik: hari ini, sangat mudah dan murah untuk mendapatkan nama domain yang nyata dan unik sehingga tidak ada alasan yang baik untuk menggunakan boneka satu.
Jadi, beli
iamthebest.org
dan gunakan untuk memberi nama perangkat Anda.sumber
Gunakan subdomain dari domain terdaftar perusahaan Anda untuk mesin internal yang namanya tidak Anda inginkan tersedia di Internet. (Kemudian, tentu saja, hanya host nama-nama itu di server DNS internal Anda.) Berikut adalah beberapa contoh untuk Contoh Perusahaan fiktif.
Server yang menghadap Internet:
www.example.com
mail.example.com
dns1.example.com
Mesin internal:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com
Saya menggunakan "corp" untuk menandakan bahwa subdomain ini mendeskripsikan mesin di jaringan internal perusahaan, tetapi Anda dapat menggunakan apa pun yang Anda inginkan di sini, seperti "internal": client1.internal.example.com.
Ingat juga bahwa zona DNS dan subdomain tidak harus sejajar dengan skema penomoran jaringan Anda. Perusahaan saya, misalnya, memiliki 37 lokasi, masing-masing dengan subnet sendiri, tetapi semua lokasi menggunakan nama domain (internal) yang sama. Sebaliknya, Anda hanya dapat memiliki satu atau beberapa subnet, tetapi banyak domain internal rekan atau level subdomain untuk membantu Anda mengatur mesin Anda.
sumber
Ada keuntungan lain menggunakan subdomain internal: secara cerdik menggunakan sufiks pencarian dan hanya nama host alih-alih FQDN, Anda dapat membuat file konfigurasi yang berfungsi baik dalam pengembangan, QA dan produksi.
Misalnya, Anda selalu menggunakan "database = dbserv1" di file konfigurasi Anda.
Pada server pengembangan, Anda mengatur akhiran pencarian ke "dev.example.com" => server database yang digunakan: dbserv1.dev.example.com
Pada server QA, Anda mengatur akhiran pencarian ke "qa.example.com" => server database yang digunakan: dbserv1.qa.example.com
Dan pada server produksi, Anda mengatur akhiran pencarian ke "example.com" => server database yang digunakan: dbserv1.example.com
Dengan begitu, Anda dapat menggunakan pengaturan yang sama di setiap lingkungan.
sumber
Karena jawaban sebelumnya untuk pertanyaan ini ditulis, ada beberapa RFC yang sedikit mengubah pedoman. RFC 6761 membahas nama domain penggunaan khusus tanpa memberikan panduan khusus untuk jaringan pribadi. RFC 6762 masih merekomendasikan untuk tidak menggunakan TLD yang tidak terdaftar, tetapi juga mengakui bahwa ada beberapa kasus di mana hal itu akan dilakukan. Karena konflik lokal yang umum digunakan dengan Multicast DNS (topik utama RFC), Lampiran G. Private DNS Namespaces merekomendasikan TLD berikut:
IANA tampaknya mengenali kedua RFC tetapi tidak (saat ini) memasukkan nama-nama yang tercantum dalam Lampiran G.
Dengan kata lain: Anda seharusnya tidak melakukannya. Tetapi ketika Anda memutuskan untuk tetap melakukannya, gunakan salah satu nama di atas.
sumber
.local
jenis yang dicadangkan untuk MulticastDNS, yang merupakan diskusi dalam Lampiran G..MAIL
ditemukan di banyak dokumentasi) adalah alasan mengapa TLD ini tidak mungkin untuk didelegasikan dan sekarang mati tanpa batas waktu. Oleh karena itu terus merekomendasikan kepada orang-orang untuk menggunakan TLD dengan cara itu adalah merugikan komunitas Internet global. Saran tersebut mengatakan bahwa karena beberapa TLD sudah disalahgunakan seperti itu, jika orang harus menyalahgunakan mereka harus menggunakan kembali yang bukan menyalahgunakan yang baru. RFC2606 jelas bagi TLD untuk menggunakan secara internal yang akan bekerja:.EXAMPLE
.TEST
.INVALID
Seperti yang sudah dikatakan, Anda tidak boleh menggunakan TLD yang tidak terdaftar untuk jaringan pribadi Anda. Apalagi sekarang bahwa ICANN memungkinkan hampir semua orang untuk mendaftar TLD baru. Anda kemudian harus menggunakan nama domain asli
Di sisi lain, RFC 1918 jelas:
sumber
Kami cenderung menganggap tidak ada perbedaan dalam penamaan virtual host dari fisik - pada kenyataannya, kami telah mengabstraksi konfigurasi host (perangkat lunak) dari lapisan fisik.
Jadi kami membeli Item Perangkat Keras, dan membuat Item Host di atasnya (dan menggunakan hubungan sederhana untuk menunjukkannya dalam dokumentasi kami).
Tujuannya adalah ketika ada host, DNS seharusnya tidak menjadi faktor penentu - karena kami memiliki mesin yang berpindah dari satu ruang ke ruang yang lain - misalnya webapp berkinerja rendah tidak perlu menggunakan siklus CPU yang mahal - virtualisasikan , dan mempertahankan skema penamaannya, semuanya terus bekerja.
sumber
Saya tidak yakin ini akan membantu Anda, tetapi untuk DNS internal di dalam akun AWS saya, saya gunakan
.aws
sebagai tld, dan tampaknya berfungsi dengan baik.Saya tahu ada beberapa TLD yang seharusnya tidak digunakan, tetapi selain itu, saya rasa itu tidak terlalu ketat.
Saya bekerja di beberapa perusahaan besar, di mana mereka akan menggunakan sumber otentikasi sebagai TLD, artinya jika itu adalah server MS / Windows, menggunakan Active Directory sebagai sumber auth, itu akan
.ad
, dan beberapa yang lain akan menjadi.ldap
(Mengapa mereka tidak hanya menggunakan sumber yang sama? Atau server mereplikasi dari layanan direktori yang sama? Saya tidak tahu, rasanya seperti itu ketika saya sampai di sana)Semoga berhasil
sumber
.aws
sebagai TLD sehingga Anda mungkin mulai melihat masalah pada akhirnya: nic.aws