โดเมนระดับบนสุด / คำต่อท้ายโดเมนสำหรับเครือข่ายส่วนตัว

115

ที่สำนักงานของเราเรามีเครือข่ายท้องถิ่นที่มีการตั้งค่า DNS whatever.lanภายในอย่างหมดจดที่ลูกค้าทุกคนที่มีชื่อเป็น ฉันยังมีสภาพแวดล้อม VMware whatever.vmและในเครือข่ายเสมือนเครื่องเดียวผมชื่อเครื่องเสมือน

ปัจจุบันเครือข่ายนี้สำหรับเครื่องเสมือนไม่สามารถเข้าถึงได้จากเครือข่ายท้องถิ่นของเรา แต่เรากำลังตั้งค่าเครือข่ายการผลิตเพื่อโยกย้ายเครื่องเสมือนเหล่านี้ไปยังซึ่งจะสามารถเข้าถึงได้จาก LAN เป็นผลให้เรากำลังพยายามที่จะตั้งอยู่บนการประชุมสำหรับส่วนต่อท้ายโดเมน / TLD เรานำไปใช้กับผู้เข้าพักบนเครือข่ายใหม่นี้เรากำลังตั้งค่า แต่เราไม่สามารถขึ้นมาเป็นหนึ่งที่ดีที่ได้รับว่า.vm, .localและ.lanทุกคนมีความหมายแฝงอยู่ในสภาพแวดล้อมของเรา

ดังนั้นวิธีปฏิบัติที่ดีที่สุดในสถานการณ์นี้คืออะไร มีรายชื่อ TLDs หรือชื่อโดเมนบางแห่งที่ปลอดภัยสำหรับใช้กับเครือข่ายภายในอย่างแท้จริงหรือไม่?

— อ็อตโต
แหล่งที่มา

2

อย่าใช้. local โดยเฉพาะอย่างยิ่งถ้าคุณมีลูกค้าของ Apple

— RainyRat

2

.test ถูกตั้งค่าด้วยเหตุผลนี้: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear นั่นไม่ใช่เหตุผล จริงที่.testจองไว้แม้ว่ามันจะเป็นโดเมนที่ปลอดภัยที่จะใช้สำหรับเครือข่ายทดสอบที่ไม่ได้เชื่อมต่อกับอินเทอร์เน็ต

— voretaq7

10

@Otto แนวทางปฏิบัติที่ดีที่สุดจะกำหนดให้คุณได้รับชื่อโดเมน "ของจริง" (ภายใต้ TLD ที่รู้จักใน ICANN) และสร้างโดเมนย่อยสำหรับสิ่งในพื้นที่ของคุณ (เช่นลงทะเบียนmydomain.comมอบสิทธิ์internal.mydomain.comให้กับ NS ภายในและกำหนดค่า horizon DNS อย่างถูกต้อง ( "views" ใน BIND) ดังนั้นคุณจะไม่รั่วไหลชื่อ / ที่อยู่ภายในกับอินเทอร์เน็ตมันไม่สวยเท่า TLD / pseudo-TLD แต่มันก็มีโอกาสน้อยที่จะแตกเมื่ออยู่ภายใต้การควบคุมของคุณ

— voretaq7

9

อย่างไรก็ตาม : อย่าใช้ชื่อโดเมนจริงที่คุณใช้ไปแล้วสำหรับบริการการผลิตสาธารณะ มีการโต้ตอบหลายอย่างที่ได้รับอนุญาตระหว่างwww.example.comและ*.internal.example.comที่ไม่ได้รับอนุญาตระหว่างwww.example.comและ*.example.netการตั้งค่าคุกกี้ข้ามไซต์ที่สะดุดตาที่สุด การเรียกใช้บริการภายในและภายนอกบนโดเมนเดียวกันเพิ่มความเสี่ยงที่การประนีประนอมของบริการสาธารณะจะทำให้เกิดการเข้าใช้บริการภายในและในทางกลับกันว่าบริการภายในที่ไม่ปลอดภัยสามารถกระตุ้นการใช้บริการภายนอกในทางที่ผิด

— bobince

94

อย่าใช้ TLD ที่ประดิษฐ์ หาก ICANN ต้องมอบสิทธิ์คุณจะประสบปัญหาใหญ่ สิ่งเดียวกันถ้าคุณรวมกับองค์กรอื่นซึ่งเกิดขึ้นเพื่อใช้ดัมมี่ที่เหมือนกัน นั่นเป็นเหตุผลที่ต้องการชื่อโดเมนที่ไม่ซ้ำกันทั่วโลก

มาตรฐานRFC 2606ขอสงวนชื่อสำหรับตัวอย่างเอกสารการทดสอบ แต่ไม่มีอะไรสำหรับการใช้งานทั่วไปและด้วยเหตุผลที่ดี: วันนี้มันง่ายและราคาถูกที่จะได้รับชื่อโดเมนจริงและไม่ซ้ำกันซึ่งไม่มีเหตุผลที่ดีที่จะใช้ คนบ้า ๆ บอ ๆ

ดังนั้นซื้อiamthebest.orgและใช้มันเพื่อตั้งชื่ออุปกรณ์ของคุณ

— bortzmeyer
แหล่งที่มา

53

เพื่อความปลอดภัยอย่างสมบูรณ์ฉันจะใส่ทุกอย่างในโดเมนย่อยของชื่อโดเมน บริษัท ของฉันเช่น local.company.org, vm.company.org และอื่น ๆ

— drybjed

4

+1 สิ่งนี้ บริษัท ของคุณอาจมีโดเมนอยู่แล้ว เพียงสร้างโดเมนย่อยจากสิ่งนี้ ไม่จำเป็นต้องมองเห็น / แก้ไขนอก LAN ของคุณ

— Dan Carley

3

แม้ว่าคุณจะมีทนายที่ดีมาก แต่คุณก็มีปัญหาในการอ้างสิทธิ์ ".lan" หรือ ". local" ด้วยการกล่าวอ้างเครื่องหมายการค้า และข้อโต้แย้ง "มันเป็นแบบภายในเท่านั้น" นั้นอ่อนแออย่างยิ่ง: องค์กรผสานตั้งค่าเครือข่ายส่วนตัวเสมือนกับองค์กรพันธมิตรและเพียงทำผิดพลาดเช่นชื่อ "ส่วนตัว" รั่วไหล

— bortzmeyer

8

เนื้อวัวตัวเดียวของฉันคือคุณไม่สามารถ "ซื้อ" โดเมนได้จริง: คุณสามารถเช่าได้ Bozo บางคนลืมที่จะจ่ายบิล (และนี่เกิดขึ้นในบางกรณีที่โปรไฟล์สูง) และส่วนหลักของการกำหนดค่าของคุณไปที่ผู้บุกรุกบางคน ดังนั้นคุณใช้โดเมนของ บริษัท ของคุณ? ผู้บริหารตัดสินใจที่จะเปลี่ยนโฉมหรือซื้อออกไปและคุณติดอยู่กับชื่อเก่า . local ใช้งานได้ดีพอ แต่ตอนนี้ได้รับการจองโดย บริษัท บางแห่งในรูปแบบที่ปฏิเสธการเล่นที่ดี ฉันอยากจะเห็นสิ่งที่ต้องการ. lan หรือ. ภายในอย่างเป็นทางการที่สงวนไว้สำหรับจุดประสงค์นี้ แต่จนถึงตอนนี้เป็นตัวเลือกที่ดีที่สุด

— Joel Coel

6

เห็นด้วยกับ @Joel Coel คุณเป็นผู้เช่าและไม่มีอะไรเพิ่มเติม ควรมีชื่อ TLD ที่สงวนไว้สองชื่อสำหรับการใช้ภายในเท่านั้นที่ควรถือว่าไม่ถูกต้องในที่สาธารณะและไม่สามารถเข้าถึงได้โดยเครือข่ายสาธารณะ ชื่อหนึ่งสำหรับใช้ภายในบ้านชื่อที่สองจะใช้สำหรับธุรกิจภายใน ทั้งสองจะถูกพิจารณาว่าเป็น "TLD ส่วนตัว" ในแง่เดียวกับที่เรามี "เครือข่ายส่วนตัว" ที่ไม่สามารถกำหนดเส้นทางได้ (192.168.xx และ ilk) สิ่งนี้ทำให้ผู้ใช้ตามบ้านสามารถทำอะไรบางอย่างนอกเหนือจากการถูกบังคับเข้าสู่. local และ mDNS เหมือนกันสำหรับธุรกิจขนาดเล็กที่ใช้ LAN ภายในหลัง NAT โดยไม่มีโดเมน

— Avery Payne

49

ใช้โดเมนย่อยของโดเมนที่จดทะเบียนของ บริษัท สำหรับเครื่องภายในที่มีชื่อที่คุณไม่ต้องการให้มีในอินเทอร์เน็ต (แน่นอนว่าให้โฮสต์เฉพาะชื่อเหล่านั้นในเซิร์ฟเวอร์ DNS ภายในของคุณ) ต่อไปนี้เป็นตัวอย่างบางส่วนสำหรับ บริษัท ตัวอย่างที่สมมติขึ้น

เซิร์ฟเวอร์ที่เข้ากับอินเทอร์เน็ต:
www.example.com
mail.example.com
dns1.example.com

เครื่องภายใน:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

ฉันใช้ "corp" เพื่อแสดงว่าโดเมนย่อยนี้อธิบายเครื่องในเครือข่ายภายในองค์กร แต่คุณสามารถใช้สิ่งที่คุณต้องการได้ที่นี่เช่น "ภายใน": client1.internal.example.com

โปรดจำไว้ว่าโซน DNS และโดเมนย่อยไม่จำเป็นต้องสอดคล้องกับโครงร่างการกำหนดหมายเลขเครือข่ายของคุณ ตัวอย่างเช่น บริษัท ของฉันมี 37 ที่ตั้งซึ่งแต่ละแห่งมีซับเน็ตของตัวเอง แต่ที่ตั้งทั้งหมดใช้ชื่อโดเมน (ภายใน) เดียวกัน ในทางกลับกันคุณอาจมีซับเน็ตเพียงหนึ่งหรือสองสามตัวเท่านั้น แต่มีโดเมนภายในเพียร์หรือหลายโดเมนย่อยที่จะช่วยคุณจัดการเครื่องของคุณ

— Jay Michaud
แหล่งที่มา

32

มีข้อดีอีกอย่างของการใช้โดเมนย่อยภายใน: ใช้ส่วนต่อท้ายการค้นหาอย่างชาญฉลาดและมีเพียงชื่อโฮสต์แทน FQDN คุณสามารถสร้างไฟล์การกำหนดค่าที่ทำงานได้ทั้งในการพัฒนา QA และการผลิต

ตัวอย่างเช่นคุณใช้ "database = dbserv1" ในไฟล์กำหนดค่าของคุณ

บนเซิร์ฟเวอร์การพัฒนาคุณตั้งค่าส่วนต่อท้ายการค้นหาเป็น "dev.example.com" => เซิร์ฟเวอร์ฐานข้อมูลที่ใช้: dbserv1.dev.example.com

บนเซิร์ฟเวอร์ QA คุณตั้งค่าส่วนต่อท้ายการค้นหาเป็น "qa.example.com" => เซิร์ฟเวอร์ฐานข้อมูลที่ใช้: dbserv1.qa.example.com

และบนเซิร์ฟเวอร์ที่ใช้งานจริงคุณต้องตั้งคำต่อท้ายการค้นหาเป็น "example.com" => เซิร์ฟเวอร์ฐานข้อมูลที่ใช้: dbserv1.example.com

ด้วยวิธีนี้คุณสามารถใช้การตั้งค่าเดียวกันในทุกสภาพแวดล้อม

— geewiz
แหล่งที่มา

2

นั่นเป็นสิ่งที่ยอดเยี่ยม

— Chris Magnuson

19

จนกว่าจะมีใครกำหนดค่าเวิร์กสเตชันของตนด้วยส่วนต่อท้ายการค้นหาการผลิตเพื่อทดสอบปัญหาและหลังจากนั้นอัปเดตบันทึกการผลิตจำนวนมากโดยไม่ตั้งใจ

— Joel Coel

1

นั่นค่อนข้างหยาบบันทึก SRV นั้นง่ายมากในการแยกวิเคราะห์และสามารถวางในโซนใดก็ได้เช่นเดียวกับที่เซิร์ฟเวอร์ db เดียวกันให้บริการหลายโซน ในกรณีนี้โค้ดบางส่วนจะเติมในไฟล์ config ของคุณ และคุณสามารถใช้ชื่อของฐานข้อมูลเป็นคีย์ SRV และค่าของหลักสูตรที่ชี้ไปที่ชื่อโฮสต์ ฉันจะไม่พึ่งพาคำต่อท้ายการค้นหา นอกจากนี้คุณยังสามารถสร้างความคิดสร้างสรรค์ได้ด้วยระเบียน TXT และสามารถบันทึกค่าด้วยการเข้ารหัส aes-256 (จากนั้นเข้ารหัส base64) หากพวกเขาเป็นความลับ คุณสามารถใช้ระเบียน TXT สำหรับทุกสิ่ง

— figtrap

เห็น แต่สิ่งที่ฉันต้องการคือ example.com, example.dev และ example.stg 2 ล่าสุดมีเฉพาะในเครือข่ายส่วนตัวฉันสามารถตั้งค่าเซิร์ฟเวอร์ DNS ในเครื่องสำหรับการเข้าถึงการกำหนดค่าศูนย์ได้หรือไม่ ยังคงใช้การตั้งค่าที่คล้ายกันที่นี่สำหรับเว็บไซต์ทั้งหมดเพียงแค่ย้ายการเปลี่ยนแปลงถึง tld ง่ายสำหรับ. ไฟล์ที่มีไฟล์โฮสต์ แต่ไม่มีค่าคอนฟิก ...

— DigitalDesignDj

14

เนื่องจากคำตอบก่อนหน้านี้สำหรับคำถามนี้ถูกเขียนขึ้นมี RFC สองสามตัวที่เปลี่ยนแนวทางไปบ้าง RFC 6761กล่าวถึงชื่อโดเมนที่ใช้งานพิเศษโดยไม่ต้องให้คำแนะนำเฉพาะสำหรับเครือข่ายส่วนตัว RFC 6762ยังคงแนะนำไม่ใช้ TLD ที่ไม่ได้ลงทะเบียน แต่ยังรับทราบว่ามีหลายกรณีที่จะต้องดำเนินการต่อไป เนื่องจาก. localขัดแย้งกันกับ Multicast DNS (หัวข้อหลักของ RFC) ภาคผนวก G. Private DNS Namespacesขอแนะนำ TLD ต่อไปนี้:

อินทราเน็ต
ภายใน
เอกชน
คอร์ป
บ้าน
แลน

IANA ดูเหมือนว่าจะรับรู้ทั้ง RFCแต่ไม่รวมถึงชื่อที่ระบุไว้ในภาคผนวก G

กล่าวอีกนัยหนึ่ง: คุณไม่ควรทำ แต่เมื่อคุณตัดสินใจที่จะทำมันให้ใช้ชื่อใดชื่อหนึ่งข้างต้น

— blihp
แหล่งที่มา

ภาคผนวก G มีอยู่ก่อนรายการที่คุณอ้างอิง: "เราไม่แนะนำให้ใช้โดเมนระดับบนสุดที่ไม่ได้ลงทะเบียนเลย" นี่คือจุดสำคัญมากกว่า ชื่อที่ให้ไม่ใช่ "แนะนำ" ให้ใช้พวกเขาเป็นเพียงชื่อที่สังเกตเห็นว่าจะทำงานได้ดีกว่า.localที่สงวนไว้สำหรับ MulticastDNS ซึ่งเป็นการสนทนาในภาคผนวก G.

— Patrick Mevzek

2

ฉันจะไม่เห็นด้วย ประเด็นสำคัญคือความไร้เหตุผลของคำแนะนำ: 'อย่าทำ ... แต่เมื่อคุณทำ ... ' ความคาดหวังว่าบ้าน / ธุรกิจขนาดเล็ก / เครือข่ายที่ไม่ต้องเผชิญกับสาธารณะควรลงทะเบียน TLD นั้นไม่สมจริง คนกำลังจะใช้ TLDs ที่ไม่ได้จดทะเบียนเพื่อให้ห่างไกลดีกว่าที่จะช่วยให้ทุกคนออกมาและพูดว่า 'ตกลงนี่คือรายการที่ไม่ได้จดทะเบียน TLDs ที่คุณสามารถใช้ภายในมากกว่าทำท่าทุกคนจะต้องปฏิบัติตามคำแนะนำสายยาก

— blihp

เราจะไม่เห็นด้วยในตอนนั้น ความจริงที่ว่าบางคนใช้ TLD เหมือนภายใน (ตัวอย่างเช่น.MAIL พบในเอกสารจำนวนมาก) เป็นเหตุผลที่ว่าทำไม TLD เหล่านี้จึงไม่สามารถมอบหมายและตอนนี้ตายไปเรื่อย ๆ ดังนั้นการแนะนำผู้คนให้ใช้ TLD อย่างต่อเนื่องในลักษณะนั้นเป็นการก่อความเสียหายต่อชุมชนอินเทอร์เน็ตทั่วโลก คำแนะนำบอกว่าเนื่องจาก TLD บางส่วนถูกทารุณกรรมเช่นนั้นแล้วหากผู้คนต้องทำทารุณกรรมพวกเขาควรนำสิ่งนั้นกลับมาใช้ใหม่แทนที่จะนำไปใช้ในทางที่ผิด RFC2606 มีความชัดเจนสำหรับ TLD ที่จะใช้ภายในที่จะทำงาน:.EXAMPLE .TEST .INVALID

— Patrick Mevzek

12

ตามที่ได้กล่าวไปแล้วคุณไม่ควรใช้ TLD ที่ไม่ได้ลงทะเบียนสำหรับเครือข่ายส่วนตัวของคุณ โดยเฉพาะอย่างยิ่งตอนนี้ที่ ICANN อนุญาตให้ทุกคนลงทะเบียน TLD ใหม่ คุณควรใช้ชื่อโดเมนจริง

อีกด้านหนึ่งRFC 1918นั้นชัดเจน:

การอ้างอิงทางอ้อมไปยังที่อยู่ดังกล่าวควรมีอยู่ภายในองค์กร ตัวอย่างที่เด่นชัดของการอ้างอิงดังกล่าวคือ DNS Resource Records และข้อมูลอื่น ๆ ที่อ้างถึงที่อยู่ส่วนตัวภายใน ดังนั้นเซิร์ฟเวอร์ชื่อของคุณควรใช้มุมมองเพื่อป้องกันไม่ให้มีการส่งบันทึกส่วนตัวบนอินเทอร์เน็ต

— เบอนัวต์
แหล่งที่มา

10

เรามักจะพิจารณาความแตกต่างในการตั้งชื่อโฮสต์เสมือนจากฟิสิคัล - ในความเป็นจริงเราได้นำนามธรรมการกำหนดค่าโฮสต์ (ซอฟต์แวร์) ออกจากฟิสิคัลเลเยอร์

ดังนั้นเราจึงซื้อรายการฮาร์ดแวร์และสร้างรายการโฮสต์ที่ด้านบนของรายการ (และใช้ความสัมพันธ์แบบง่าย ๆ เพื่อแสดงให้เห็นในเอกสารของเรา)

จุดประสงค์คือเมื่อโฮสต์มีอยู่ DNS ไม่ควรเป็นปัจจัยกำหนดเนื่องจากเรามีเครื่องที่ย้ายจากที่หนึ่งไปยังอีกพื้นที่หนึ่งตัวอย่างเช่น webapp ที่มีประสิทธิภาพต่ำไม่จำเป็นต้องใช้วงจร CPU ที่มีราคาแพง และยังคงรูปแบบการตั้งชื่อทุกอย่างยังคงทำงานต่อไป

— Mike Fiedler
แหล่งที่มา

-4

ฉันไม่แน่ใจว่าสิ่งนี้จะช่วยคุณได้ แต่สำหรับ DNS ภายในภายในบัญชี AWS ของฉันฉันใช้.awsเป็น tld และดูเหมือนว่าจะทำงานได้อย่างสมบูรณ์

ฉันรู้ว่ามี TLD บางตัวที่คุณควรเลิกใช้ แต่นอกเหนือจากนั้นฉันไม่คิดว่ามันเข้มงวดเกินไป

ฉันทำงานที่ บริษัท ขนาดใหญ่ไม่กี่แห่งซึ่งพวกเขาจะใช้แหล่งข้อมูลการตรวจสอบความถูกต้องเป็น TLD ซึ่งหมายความว่าเป็นเซิร์ฟเวอร์ MS / Windows โดยใช้ Active Directory เป็นแหล่งข้อมูลรับรองความถูกต้อง.adและอื่น ๆ ก็เป็น.ldapเช่นนั้น ไม่ใช้แหล่งเดียวกันหรือเซิร์ฟเวอร์จำลองจากบริการไดเรกทอรีเดียวกันหรือไม่ฉันไม่รู้เหมือนกันว่าเมื่อฉันไปถึงที่นั่น)

โชคดี

— จัสติน
แหล่งที่มา

2

ตอนนี้อเมซอนได้ลงทะเบียน.awsเป็น TLD แล้วดังนั้นคุณอาจเริ่มพบปัญหาในที่สุด: nic.aws

— Mark McKinstry

1

สำหรับข้อมูล, .aws มีการลงทะเบียนเมื่อเร็ว ๆ นี้ "25 มีนาคม 2559" => newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

ในขณะที่ฉันไม่คิดว่าการใช้ phony TLD เป็นเรื่องใหญ่ แต่อย่างน้อยถ้าระบบทั้งหมดถูกปิดและใช้พร็อกซีเพื่อสื่อสารกับอินเทอร์เน็ตในวงกว้าง ".aws" เป็นตัวเลือกที่แย่มากเว้นแต่คุณจะ ไม่ได้อยู่ใน AWS! มีหลายสถานการณ์ที่เป็นไปได้ที่คุณจะไม่สามารถสื่อสารกับ AWS ได้อีกต่อไป

— figtrap