سؤال لاحقة المجال / المجال المستوى الأعلى للشبكة الخاصة؟


في مكتبنا ، لدينا شبكة محلية مع إعداد DNS داخلي بحت ، والذي تم تسميته جميع العملاء باسم whatever.lan. لدي أيضًا بيئة VMware ، وفي الشبكة الظاهرية ذات الماكينة الظاهرية فقط ، أطلق اسمًا على الأجهزة الظاهرية whatever.vm.

في الوقت الحالي ، لا يمكن الوصول إلى هذه الشبكة للأجهزة الافتراضية من شبكتنا المحلية ، ولكننا نُعد شبكة إنتاج لترحيل هذه الأجهزة الظاهرية إلى سوف يمكن الوصول إليها من الشبكة المحلية. نتيجة لذلك ، نحاول الاتفاق على اتفاقية لاحقة النطاق / TLD التي نطبقها على الضيوف على هذه الشبكة الجديدة التي نعدها ، ولكن لا يمكننا التوصل إلى اتفاقية جيدة ، .vm، .local و .lan كلهم لديهم دلالات موجودة في بيئتنا.

إذن ، ما أفضل الممارسات في هذا الموقف؟ هل هناك قائمة بنطاقات TLD أو أسماء نطاق في مكان آمن لاستخدامها في شبكة داخلية بحتة؟


104
2018-06-01 21:47


الأصل


لا تستخدم. خاصة إذا كان لديك أي من عملاء Apple. - RainyRat
تم تعيين .test جانبًا لهذا السبب: secure.wikimedia.org/wikipedia/en/wiki/.test - CWSpear
CWSpear ليس هذا هو الفعلي السبب  .test محجوز ، على الرغم من أنه يجعل من نطاق آمن للاستخدام اختبار الشبكات التي لن تكون متصلة بالإنترنت. - voretaq7
@ تملي أفضل الممارسات بأنك تحصل على اسم نطاق "حقيقي" (بموجب TLD المعترف به من قِبل ICANN) وأنشئ نطاقًا فرعيًا لذلك من الأشياء المحلية الخاصة بك (مثل التسجيل mydomain.com، مندوب internal.mydomain.com إلى NS داخلي ، وتكوين DNS منقسم بشكل صحيح ("طرق العرض" في BIND) حتى لا تسرّب الأسماء / العناوين الداخلية إلى الإنترنت. إﻧﮭﺎ ﻟﯾﺳت ﺟﻣﻟﺔ TLD / Tse Pseudo-TLD ، وﻟﮐﻧﮭﺎ أﻗل ﻋرﺿﺔ ﻟﻟﮐﺳر ﻷﻧﮭﺎ ﺗﺣت ﺳﯾطرﺗك. - voretaq7
ومع ذلك: لا تستخدم اسم مجال حقيقي استخدمته بالفعل لخدمات الإنتاج المواجه للعموم. هناك تفاعلات مختلفة مسموح بها بين www.example.com و *.internal.example.com غير مسموح بها بين www.example.com و *.example.net، وأبرزها إعداد ملفات تعريف الارتباط عبر الموقع. يؤدي تشغيل الخدمات الداخلية والخارجية على نفس المجال إلى زيادة خطر أن يؤدي التوصل إلى حل وسط في الخدمة العامة إلى إدخال بعض الخدمات الداخلية ، وعلى العكس من ذلك قد تؤدي الخدمة الداخلية غير الآمنة إلى إساءة الاستخدام الداخلي للخدمة الخارجية. - bobince


الأجوبة:


لا تستخدم TLD مخترع. إذا قامت ICANN بتفويضها ، فستكون في ورطة كبيرة. نفس الشيء في حالة الدمج مع مؤسسة أخرى تحدث لاستخدام نفس TLD الوهمي. هذا هو السبب في تفضيل أسماء النطاقات الفريدة عالميا.

المعيار، RFC 2606 أسماء الاحتياطيات للحصول على أمثلة ، وثائق ، اختبار ، ولكن لا شيء للاستخدام العام ، ولأسباب وجيهة: اليوم ، من السهل ورخيص الحصول على اسم نطاق حقيقي وفريد ​​لا يوجد سبب وجيه لاستخدام نموذج وهمي.

لذا ، اشتري iamthebest.org واستخدامها لتسمية أجهزتك.


86
2018-06-02 07:39



لكي أكون آمنًا تمامًا ، أضع كل شيء على نطاق فرعي من اسم نطاق شركتي ، مثل local.company.org ، و vm.company.org ، وما إلى ذلك. - drybjed
+1 هذا. من المفترض أن شركتك لديها بالفعل مجال. ما عليك سوى إنشاء نطاق فرعي من هذا. ليس من الضروري أن تكون مرئية / قابلة للحل خارج الشبكة المحلية الخاصة بك. - Dan Carley
حسنًا ، حتى مع وجود محامين جيدين جدًا ، ستواجهك مشكلة في المطالبة بـ ".lan" أو ".local" من خلال استدعاء علامة تجارية. والحجة "هي داخلية فقط" ضعيفة للغاية: دمج المنظمات ، وإنشاء شبكات خاصة افتراضية مع المنظمات الشريكة وببساطة ارتكاب أخطاء مثل تسرب الأسماء "الخاصة". - bortzmeyer
بلدي لحم البقر الوحيد مع هذا هو أنه لا يمكنك "شراء" المجال: يمكنك فقط استئجار واحد. ينسى بعض bozo دفع فاتورة (وقد حدث هذا في عدد قليل من الحالات البارزة) وجزء أساسي من التكوين الخاص بك يذهب إلى بعض العشوائي العشوائي. هل تستخدم مجال شركتك؟ تقرر Execs إعادة تسمية أو شراء ، وأنت عالق مع اسم قديم. .local تستخدم للعمل بشكل جيد بما فيه الكفاية ، ولكن الآن تم استباقها من قبل شركة معينة بطرق ترفض اللعب لطيفة. أود حقاً أن أرى شيئًا مثل .lan أو .internal محجوز رسميًا لهذا الغرض ، ولكن حتى ذلك الحين ، هذا هو الخيار الأفضل. - Joel Coel
اتفق معJoel Coel ، فأنت مستأجر ، ولا شيء أكثر من ذلك. يجب أن يكون هناك اسمان TLD محجوزان للاستخدام الداخلي فقط التي يجب اعتبارها غير صالحة في الأماكن العامة ولا يمكن الوصول إليها بواسطة الشبكات العامة. سيكون اسم واحد للاستخدام الداخلي الداخلي ، سيكون الاسم الثاني للاستخدام التجاري الداخلي. سيعتبر كلاهما "نطاقات TLD خاصة" بنفس المعنى الذي لدينا "شبكات فرعية خاصة" غير قابلة للتوجيه (192.168.x.x و ilk). هذا يسمح للمستخدمين المنزليين بعمل شيء ما إلى جانب إجبارهم على .local و mDNS. كما سبق للشركات الصغيرة التي تدير شبكة محلية داخلية خلف NAT بدون مجال. - Avery Payne


استخدم نطاقًا فرعيًا لنطاق شركتك المسجل للأجهزة الداخلية التي لا تريد اسمها على الإنترنت. (ثم ​​، بالطبع ، فقط استضافة تلك الأسماء على خوادم DNS الداخلية الخاصة بك.) وفيما يلي بعض الأمثلة لمؤسسة Example الوهمية.

الخوادم المواجهة للإنترنت:
www.example.com
mail.example.com
dns1.example.com

الآلات الداخلية:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

استخدمت "corp" للدلالة على أن هذا النطاق الفرعي وصف الأجهزة على شبكة الشركة الداخلية ، ولكن يمكنك استخدام أي شيء تريده هنا ، مثل "internal": client1.internal.example.com.

تذكر أيضًا ، أن مناطق DNS والنطاقات الفرعية لا يلزم مواءمتها مع نظام ترقيم الشبكة. فشركتي ، على سبيل المثال ، بها 37 موقعًا ، لكل منها شبكة فرعية خاصة بها ، ولكن جميع المواقع تستخدم نفس اسم النطاق (الداخلي). وبالعكس ، يمكن أن يكون لديك واحد أو عدة شبكات فرعية ، ولكن العديد من النطاقات الداخلية أو مستويات النطاقات الفرعية لمساعدتك على تنظيم أجهزتك.


47
2018-06-02 13:03





هناك ميزة أخرى لاستخدام نطاق فرعي داخلي: بذكاء باستخدام لاحقات البحث وأسماء المضيفات فقط بدلاً من FQDN ، يمكنك إنشاء ملفات التكوين التي تعمل في كل من التطوير ، وضمان الجودة والإنتاج.

على سبيل المثال ، يمكنك دائمًا استخدام "database = dbserv1" في ملف التكوين الخاص بك.

على خادم التطوير ، يمكنك تعيين لاحقة البحث على "dev.example.com" => خادم قاعدة البيانات المستخدم: dbserv1.dev.example.com

على خادم QA ، يمكنك تعيين لاحقة البحث على "qa.example.com" => خادم قاعدة البيانات المستخدم: dbserv1.qa.example.com

وعلى خادم الإنتاج ، يمكنك تعيين لاحقة البحث على "example.com" => خادم قاعدة البيانات المستخدم: dbserv1.example.com

بهذه الطريقة ، يمكنك استخدام نفس الإعدادات في كل بيئة.


30
2018-06-04 12:00



هذا رائع. - Chris Magnuson
حتى يخطئ شخص ما في تهيئة محطة العمل الخاصة به باستخدام لاحقة البحث عن الإنتاج لاختبار إحدى المشكلات ، ثم يقوم لاحقًا بتحديث مجموعة من سجلات الإنتاج عن غير قصد. - Joel Coel
هذا هو الخام جدا ، SRV سجلات بسيطة جدا لتحليل ويمكن وضعها في أي منطقة ، بحيث يخدم نفس الخادم ديسيبل عدة مناطق. في هذه الحالة ، سيتم ملء بعض الشفرات بالقيمة داخل ملفات التهيئة. ويمكنك استخدام اسم قاعدة البيانات كمفتاح SRV وقيمة الدورة التدريبية التي تشير إلى اسم المضيف. لن أعتمد أبدا على لاحقات البحث. يمكنك أيضًا أن تكون مبدعًا تمامًا باستخدام سجلات TXT ، ويمكن أن تقوم بتجميعها باستخدام قيم aes-256 المشفرة (المشفرة في الأساس 64) ، إذا كانت أسرارًا. يمكنك استخدام سجلات TXT لجميع أنواع الأشياء. - figtrap
انظر ، ولكن ما أريده هو example.com ، و example.dev ، و example.stg. آخر 2 فقط على شبكة خاصة ، هل يمكنني إعداد ملقم DNS محلي للوصول صفر التكوين؟ لا تزال تستخدم تكوينًا مشابهًا هنا لجميع المواقع ، فما عليك سوى نقل التغييرات إلى tld. من السهل على .dev مع ملف مضيف ، ولكن التكوين صفر ... - DigitalDesignDj


كما ذكر من قبل ، يجب ألا تستخدم TLD غير مسجل لشبكتك الخاصة. خاصة الآن أن ICANN تسمح لأي شخص تقريباً بتسجيل TLDs جديدة. يجب عليك عندئذ استخدام اسم مجال حقيقي

على الجانب الآخر ، فإن RFC 1918 واضح:

إشارات غير مباشرة إلى مثل هذه العناوين   ينبغي احتواؤها داخل   مشروع - مغامرة. أمثلة بارزة من هذا القبيل   المراجع هي سجلات مورد DNS   وغيرها من المعلومات التي تشير إلى   عناوين خاصة داخلية.   لذا يجب أن يستخدم خادم الاسم أيضًا طرق العرض لمنع إرسال السجلات الخاصة على الإنترنت.


11
2018-06-02 12:41





نحن نميل إلى عدم التفكير في أي اختلاف في التسمية الافتراضية للمضيفين من الناحية الفعلية - في الواقع ، لقد اتخذنا لإستخلاص التكوين المضيف (البرنامج) من الطبقة المادية.

لذلك نقوم بشراء عناصر الأجهزة ، وإنشاء عناصر المضيف فوقها (واستخدام علاقة بسيطة لإظهار ذلك في وثائقنا).

والغرض من ذلك هو أنه في حالة وجود مضيف ، لا ينبغي أن يكون DNS هو العامل الحاسم - حيث أن لدينا آلات تنتقل من مساحة إلى أخرى - على سبيل المثال ، لا يحتاج تطبيق webapp ذو الأداء المنخفض إلى استهلاك دورات CPU باهظة الثمن - فعليًا ، ويحتفظ مخطط التسمية الخاص به ، كل شيء يستمر في العمل.


9
2018-06-01 21:52





منذ كتابة الإجابات السابقة على هذا السؤال ، كان هناك بعض RFCs التي تغير التوجيه إلى حد ما. RFC 6761 يناقش أسماء نطاقات للاستخدام الخاص دون تقديم إرشادات محددة للشبكات الخاصة. RFC 6762 لا تزال توصي بعدم استخدام TLDs غير المسجلة ، ولكنها تقر أيضًا بوجود حالات سيتم تنفيذها فيها على أي حال. منذ شائعة الاستخدام .محلي يتعارض مع DNS Multicast (الموضوع الرئيسي لـ RFC) ، الملحق G. مساحات الأسماء الخاصة بـ DNS توصي بـ TLDs التالية:

  • الشبكة الداخلية
  • داخلي
  • نشر
  • كورب
  • الصفحة الرئيسية
  • الشبكة المحلية

يبدو أن IANA التعرف على كل من RFCs ولكن لا (حالياً) تُدمج الأسماء المذكورة في الملحق زاي.

بعبارة أخرى: لا يجب عليك فعل ذلك. ولكن عندما تقرر القيام بذلك على أي حال ، استخدم أحد الأسماء المذكورة أعلاه.


3
2017-10-30 07:00





لست متأكدًا من أن هذا سيساعدك ، ولكن بالنسبة إلى DNS الداخلي داخل حساب AWS الخاص بي ، فأنا أستخدمه .aws كما tld ، ويبدو أنه يعمل بشكل جيد.

أﻋﻟم أن ھﻧﺎك ﺑﻌض ﻧطﺎﻗﺎت TLD ﯾﺟب ﻋﻟﯾك ﻓﻘط اﻟﺗوﺻﯾل ﻋدم اﺳﺗﺧداﻣﮭﺎ ، وﻟﮐن ﺑﺧﻼف ذﻟك ، ﻻ أﻋﺗﻘد أﻧﮭﺎ ﺻﺎرﻣﺔ ﺟدا.

لقد عملت في عدد قليل من الشركات الكبيرة ، حيث كانوا يستخدمون مصدر المصادقة كـ TLD ، مما يعني أنه لو كان خادم MS / Windows ، باستخدام Active Directory كمصدر المصادقة ، فسيكون .ad، وبعض الآخرين سيكون .ldap (لماذا لم يكونوا يستخدمون نفس المصدر فقط أو خوادم تم نسخها من نفس خدمة الدليل؟ لا أعرف ، كان الأمر كذلك عندما وصلت إلى هناك)

حظا سعيدا


-4
2018-02-29 14:28



الأمازون قد سجلت الآن .aws كنطاق TLD ، لذا قد تبدأ في رؤية المشكلات في النهاية: nic.aws - Mark McKinstry
للحصول على معلومات ، يتم تسجيل .aws مؤخرًا "25 آذار 2016" => newgtlds.icann.org/en/program-status/delegated-strings - Bruno Adelé
في حين أنني لا أعتقد أن استخدام TLD زائفة هو ذلك الجزء الكبير من الصفقة ، على الأقل ليس إذا تم إغلاق النظام بأكمله واستخدام بروكسي للتواصل مع الإنترنت بشكل عام ، ".aws" هو اختيار سيئ للغاية ما لم لا في AWS! هناك الكثير من السيناريوهات التي يمكن تصورها حيث لن تتمكن من التواصل مع AWS بعد الآن. - figtrap