Домен верхнього / доменного суфікса для приватної мережі?

У нашому офісі у нас є локальна мережа із суто внутрішньою настройкою DNS, в якій всі клієнти названі як whatever.lan. У мене також є середовище VMware, і в мережі, що використовується лише для віртуальної машини, я називаю віртуальні машини whatever.vm.

В даний час ця мережа для віртуальних машин недоступна з нашої локальної мережі, але ми встановлюємо виробничу мережу для перенесення цих віртуальних машин, які будуть бути доступні з локальної мережі. Як результат, ми намагаємося домовитись про домовленість щодо доменного суфікса / TLD, яку ми застосовуємо до гостей у цій новій мережі, яку ми встановлюємо, але ми не можемо придумати хорошого, враховуючи це .vm, .localі .lanвсі вони мають існуючі конотації в нашому середовищі.

Отже, яка найкраща практика в цій ситуації? Чи є десь список TLD або доменних імен, які безпечно використовувати для чисто внутрішньої мережі?

Не використовуйте винайдений TLD. Якби ICANN делегував його, ви мали би великі проблеми. Те саме, якщо ви об'єднаєтесь з іншою організацією, яка, звичайно, використовує ту саму фіктивну TLD. Ось чому перевагу мають глобально унікальні доменні імена.

Стандарт RFC 2606 залишає назви для прикладів, документації, тестування, але нічого для загального використання та з поважних причин: сьогодні так просто і дешево отримати справжнє та унікальне доменне ім’я, що немає жодної вагомої причини використовувати манекен.

Отже, купуйте iamthebest.orgта використовуйте його для іменування своїх пристроїв.

Використовуйте субдомен зареєстрованого домену вашої компанії для внутрішніх машин, імена яких ви не бажаєте доступні в Інтернеті. (Тоді, звичайно, розміщуються лише ті імена на внутрішніх серверах DNS.) Ось кілька прикладів для вигаданого корпорації Example.

Інтрнет-сервери:
доменів 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 локацій, кожна з яких має свою підмережу, але всі локації використовують однакове (внутрішнє) доменне ім'я. І навпаки, у вас може бути лише одна або кілька підмереж, але багато однорідних внутрішніх доменів або рівнів субдоменів, які допоможуть вам організувати ваші машини.

Є ще одна перевага використання внутрішнього піддомену: вміло використовуючи пошукові суфікси та лише імена хостів замість FQDN, ви можете створювати конфігураційні файли, які працюють як у розробці, якості та виробництві.

Наприклад, ви завжди використовуєте "database = dbserv1" у своєму конфігураційному файлі.

На сервері розробки ви встановлюєте суфікс пошуку на "dev.example.com" => використовуваний сервер бази даних: dbserv1.dev.example.com

На сервері QA ви встановлюєте суфікс пошуку на "qa.example.com" => використовуваний сервер бази даних: dbserv1.qa.example.com

А на виробничому сервері ви встановлюєте суфікс пошуку на "example.com" => сервер бази даних, який використовується: dbserv1.example.com

Таким чином, ви можете використовувати однакові налаштування в будь-якому середовищі.

Оскільки попередні відповіді на це запитання були написані, було кілька RFC, які дещо змінюють керівництво. RFC 6761 обговорює доменні імена спеціального призначення, не надаючи конкретних вказівок для приватних мереж. RFC 6762 все ще рекомендує не використовувати незареєстровані TLD, але також визнає, що є випадки, коли це все одно буде зроблено. Оскільки загальновживаний .local конфліктує з багатоадресною DNS (основна тема RFC), додаток G. Приватні простори імен DNS рекомендують такі TLD:

• інтранет
• внутрішній
• приватний
• корп
• додому
• лан

Схоже, IANA розпізнає обидва RFC, але не містить (на даний момент) імен, перелічених у Додатку G.

Іншими словами: ви не повинні цього робити. Але коли ви все-таки вирішите це зробити, використовуйте одне з перерахованих вище імен.

Як уже було сказано, ви не повинні використовувати незареєстрований TLD для вашої приватної мережі. Особливо зараз, коли ICANN дозволяє практично будь-кому реєструвати нові TLD. Потім слід використовувати справжнє доменне ім’я

З іншого боку, RFC 1918 зрозумілий:

Непрямі посилання на такі адреси повинні міститися в межах підприємства. Видатними прикладами таких посилань є записи DNS-ресурсів та інша інформація, що стосується внутрішніх приватних адрес. Тому ваш сервер імен також повинен використовувати представлення даних, щоб запобігти передачі приватних записів в Інтернеті.

Ми, як правило, не вважаємо різницю у віртуальному іменуванні хостів від фізичного - насправді ми взяли до вилучення конфігурації (програмного забезпечення) хосту від фізичного рівня.

Таким чином, ми купуємо елементи обладнання та створюємо елементи хосту над ними (і використовуємо прості відносини, щоб показати це в нашій документації).

Мета полягає в тому, що коли існує хост, DNS не повинен бути визначальним фактором - оскільки у нас машини переходять з одного простору в інший - наприклад, низькопродуктивний веб-сервер не потребує споживання дорогих циклів процесора - віртуалізуйте його , і вона зберігає свою схему іменування, все продовжує працювати.

Я не впевнений, що це допоможе вам, але для внутрішнього DNS всередині мого облікового запису AWS я використовую .awsяк tld, і, здається, він працює чудово.

Я знаю, що є деякі TLD, які ви повинні просто не використовувати, але крім них, я не думаю, що це занадто суворо.

Я працював у кількох більших компаніях, де вони використовували б джерело аутентифікації як TLD, тобто якщо це був сервер MS / Windows, використовуючи Active Directory як джерело автентичності, це було б .ad, і деякі інші були б .ldap(чому вони були я просто використовую той самий джерело? або сервери, що реплікуються з тієї ж служби каталогів? Не знаю, це було так, коли я потрапив туди)

Удачі