Domain / akhiran domain tingkat atas untuk jaringan pribadi?

115

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, .localdan .lansemua 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?

— Otto
sumber

2

Jangan gunakan .local. Terutama jika Anda punya klien Apple.

— RainyRat

2

.test dikesampingkan karena alasan ini: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear Itu bukan alasan sebenarnya .testyang dicadangkan, meskipun itu membuatnya menjadi domain yang aman untuk digunakan untuk jaringan uji yang tidak akan terhubung ke internet.

— voretaq7

10

@Otto praktik terbaik akan menentukan bahwa Anda memperoleh nama domain "nyata" (di bawah TLD yang diakui ICANN) dan membuat subdomain untuk hal-hal lokal Anda (mis. Mendaftar mydomain.com, mendelegasikan internal.mydomain.comke 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.

— voretaq7

9

Namun : jangan gunakan nama domain asli yang telah Anda gunakan untuk layanan produksi yang dihadapi publik. Ada berbagai interaksi yang diizinkan antara www.example.comdan *.internal.example.comyang tidak diizinkan antara www.example.comdan *.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.

— bobince

94

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.orgdan gunakan untuk memberi nama perangkat Anda.

— bortzmeyer
sumber

53

Agar benar-benar aman, saya akan meletakkan semuanya pada subdomain dari nama domain perusahaan saya, seperti local.company.org, vm.company.org, dan sebagainya.

— drybjed

4

Beri ini +1. Agaknya perusahaan Anda sudah memiliki domain. Cukup buat sub-domain dari ini. Itu tidak harus terlihat / diselesaikan di luar LAN Anda.

— Dan Carley

3

Yah, bahkan dengan pengacara yang sangat baik, Anda akan kesulitan mengklaim ".lan" atau ".local" dengan menggunakan merek dagang. Dan argumen "itu hanya internal" sangat lemah: organisasi bergabung, mengatur jaringan pribadi virtual dengan organisasi mitra dan hanya membuat kesalahan sedemikian rupa sehingga nama "pribadi" bocor.

— bortzmeyer

8

Satunya saya dengan ini adalah bahwa Anda tidak dapat benar-benar "membeli" domain: Anda hanya bisa menyewa satu. Beberapa bozo lupa untuk membayar tagihan (dan ini telah terjadi dalam beberapa kasus profil tinggi) dan bagian inti dari konfigurasi Anda masuk ke beberapa penghuni liar acak. Jadi Anda menggunakan domain perusahaan Anda? Execs memutuskan untuk mengubah citra atau dibeli, dan Anda terjebak dengan nama lama. .Local dulu bekerja dengan cukup baik, tetapi sekarang sudah diprediksi oleh perusahaan tertentu dengan cara yang menolak untuk bermain bagus. Saya benar-benar ingin melihat sesuatu seperti .lan atau .internal secara formal dicadangkan untuk tujuan ini, tetapi sampai saat itu ini adalah pilihan terbaik.

— Joel Coel

6

Setuju dengan @ Joel Coel, Anda adalah penyewa, dan tidak lebih. Seharusnya ada dua nama TLD yang dicadangkan untuk penggunaan internal saja yang harus dianggap tidak valid di publik dan tidak dapat dijangkau oleh jaringan publik. Satu nama untuk penggunaan internal rumah, nama kedua untuk penggunaan bisnis internal. Keduanya akan dianggap "TLD pribadi" dalam arti yang sama dengan yang kita miliki "subnet pribadi" yang non-routable (192.168.xx dan sejenisnya). Ini memungkinkan pengguna rumahan untuk melakukan sesuatu selain dipaksa ke .local dan mDNS. Ditto untuk usaha kecil yang menjalankan LAN internal di belakang NAT tanpa domain.

— Avery Payne

49

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.

— Jay Michaud
sumber

32

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.

— geewiz
sumber

2

Itu brilian.

— Chris Magnuson

19

Sampai seseorang salah mengkonfigurasi stasiun kerja mereka dengan akhiran pencarian produksi untuk menguji suatu masalah, dan kemudian secara tidak sengaja memperbarui banyak catatan produksi.

— Joel Coel

1

Itu cukup kasar, catatan SRV sangat sederhana untuk diurai dan dapat ditempatkan di dalam zona apa pun, sehingga server db yang sama melayani beberapa zona. Dalam hal ini beberapa kode akan mengisi nilai dalam file konfigurasi Anda. Dan Anda dapat menggunakan nama database sebagai kunci SRV dan nilai tentu saja menunjuk ke nama host. Saya tidak akan pernah bergantung pada sufiks pencarian. Anda juga bisa mendapatkan cukup kreatif dengan catatan TXT, dan bisa mengisinya dengan nilai-nilai terenkripsi aes-256 (kemudian di-encode base64), jika itu rahasia. Anda dapat menggunakan data TXT untuk semua jenis hal.

— figtrap

lihat, tetapi yang saya inginkan adalah example.com, example.dev, dan example.stg. 2 yang terakhir hanya pada jaringan pribadi, dapatkah saya menyiapkan server DNS lokal untuk akses tanpa konfigurasi? Masih menggunakan konfigurasi serupa di sini untuk semua situs, hanya memindahkan perubahan ke tld. Mudah untuk .dev dengan file hosts, tetapi tanpa konfigurasi ...

— DigitalDesignDj

15

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:

intranet
intern
pribadi
corp
rumah
lan

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.

— blihp
sumber

Lampiran G memiliki sebelum daftar yang Anda kutip: "Kami tidak merekomendasikan penggunaan domain tingkat atas yang tidak terdaftar sama sekali". Ini lebih merupakan titik kunci. Nama-nama yang diberikan tidak "direkomendasikan" untuk digunakan, mereka hanya mengamati nama-nama yang terlihat akan bekerja lebih baik daripada .localjenis yang dicadangkan untuk MulticastDNS, yang merupakan diskusi dalam Lampiran G.

— Patrick Mevzek

2

Saya tidak akan setuju. Poin kuncinya adalah absurditas saran: 'jangan lakukan itu ... tetapi ketika Anda melakukannya ...' Harapan bahwa jaringan rumah / usaha kecil / yang tidak menghadap ke publik harus mendaftarkan TLD adalah tidak realistis. Orang - orang akan menggunakan TLD yang tidak terdaftar sejauh ini lebih baik untuk membantu semua orang dan berkata 'OK, ini daftar TLD yang tidak terdaftar yang dapat Anda gunakan secara internal' daripada berpura-pura setiap orang akan mengikuti saran garis keras.

— blihp

Kami akan tetap berselisih tentang itu. Fakta bahwa beberapa orang menggunakan TLD seperti mereka internal (misalnya .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

— Patrick Mevzek

12

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:

Referensi tidak langsung ke alamat tersebut harus dimuat dalam perusahaan. Contoh penting dari referensi tersebut adalah Catatan Sumber Daya DNS dan informasi lain yang merujuk ke alamat pribadi internal. Jadi server nama Anda juga harus menggunakan tampilan untuk mencegah catatan pribadi untuk dikirim di Internet.

— Benoit
sumber

10

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.

— Mike Fiedler
sumber

-4

Saya tidak yakin ini akan membantu Anda, tetapi untuk DNS internal di dalam akun AWS saya, saya gunakan .awssebagai 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

— Justin
sumber

2

Amazon sekarang telah terdaftar .awssebagai TLD sehingga Anda mungkin mulai melihat masalah pada akhirnya: nic.aws

— Mark McKinstry

1

Untuk informasi, .aws baru-baru ini terdaftar "25 Maret 2016" => newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

Meskipun saya tidak berpikir menggunakan TLD palsu adalah masalah besar, setidaknya tidak jika seluruh sistem ditutup dan menggunakan proxy untuk berkomunikasi dengan internet pada umumnya, ".aw" adalah pilihan yang sangat buruk kecuali Anda TIDAK di AWS! Ada terlalu banyak skenario yang mungkin terjadi di mana Anda tidak akan dapat berkomunikasi dengan AWS lagi.

— figtrap