Использование.local для внутренних сайтов
Это нормально использовать app.mycoolname.local для URL, которые являются частными / внутренними?
У нас есть несколько приложений, основанных на веб-технологиях, но они являются частными и не доступны для общественности.
Мы использовали ".net" для некоторых из них, что не имеет смысла, так как они могли составить реальный URL в Интернете. Это еще не было проблемой.
Но теперь у меня есть новая группа приложений, и я хочу назвать их, используя "популярное" имя, которое определенно будет конфликтовать с URL-адресом в Интернете.
Должен ли я использовать app.mycoolname.local? Я настроил это прямо сейчас, и это, кажется, работает. Я читал несколько мест, где это поощрялось, но потом я видел несколько мест, где это не работало (некоторые проблемы на Mac, но у нас их нет, поэтому NBD).
13 ответов
Вполне допустимо использовать зону.local. У нас есть один для нашей внутренней сети, в основном используется для разработки сайтов, но он работает хорошо.
Не используйте.local. Не используйте.ythingyyouyustmadeup либо. Даже не используйте зарезервированные TLD. Используйте реальный домен или поддомен и просто не позволяйте ему быть видимым для внешнего мира. Основная причина этого заключается в том, что вы работаете на компанию A, которая использует.local (или example.com), и они покупают компанию B, которая также использует.local (или example.com). Не очень весело объединять два пространства имен.
Не используйте изобретенный TLD. Если бы ICANN делегировал это, у вас были бы большие проблемы. То же самое, если вы объединяетесь с другой организацией, которая использует тот же фиктивный TLD. Вот почему глобально уникальные доменные имена являются предпочтительными.
Стандарт RFC 2606 резервирует имена для примеров, документации, тестирования, но ничего для общего пользования, и по веским причинам: сегодня получить реальное и уникальное доменное имя так просто и дешево, что нет веских оснований для использования дурачок один
Итак, купить iamthebest.org и используйте его, чтобы назвать ваши устройства. Другое решение: local.yourdomain.org,
Я бы не стал использовать.local, если вы не понимаете, как работает zeroconf, так как это станет более значительным, когда вы начнете видеть, что IPv6 переходит в мейнстрим.
В прошлом я использовал:
- Придуманный TLD (не очень хорошая практика по разным причинам)
- Внутренний поддомен (т. Е. Corp.example.com)
- Внутренний домен с другим доменом верхнего уровня (например, example.net)
ИМО, любой из последних вариантов - лучшие идеи.
Технически не стоит его использовать. Он используется в многоадресной DNS / сети с нулевой конфигурацией для локальных адресов. На практике это не имеет большого значения. Я использую ноутбук Mac (который использует zeroconf) во внутренней сети с суффиксом.local в течение последних нескольких лет без каких-либо проблем.
Как указал Джеральд Комбс .local является зарезервированным доменом и не должен использоваться иначе, чем предполагалось.
Как Джеральд Комбс указал на .local Домен используется многими программами Apple (и других), поэтому использование его другим способом может вызвать проблемы с этим программным обеспечением.
Почему бы не использовать поддомен вашего публичного сайта? Что-то вроде app.internal.mycompany.com было бы уместно и не столкнулось бы с вашим общедоступным сайтом.
.local используется Microsoft Small Business Server и MDNS на Mac (т. е. Bonjour). Я думаю, что тот факт, что он используется как Apple, так и Microsoft, делает маловероятным, чтобы ICANN делегировала его, но это не зарезервировано, и теоретически возможно, что они это сделают.
Я бы использовал что-то вроде server.internal.yourcompany.com
Если вам нужна дополнительная информация о .local и почему это может быть проблемой для вас. На самом деле, похоже, нет зарезервированных зон для внутреннего использования.
Прочитайте http://cr.yp.to/djbdns/dot-local.html а затем выберите имя своего локального домена. Итог: не изобретай свой, купи себе реальный домен или используй.1 - .9
Хорошим компромиссным решением является использование внутреннего субдомена в сочетании с путем поиска DNS.
В качестве примера из реальной жизни приложение, над которым я работаю, может быть полностью some-app.beta.internal.mycompany.com, но, как internal.mycompany.com находится в пути поиска DNS для рабочих станций, возвращаемых сервером DHCP, я могу получить к нему доступ как some-app.beta, Существует вероятность столкновения, если эти имена выбраны неправильно, но в этом случае конфликт может быть разрешен с использованием полного доменного имени. (Или, если вы хотите защитить себя, всегда используя FQDN для важных вещей - хотя последняя точка в именах DNS, к сожалению, игнорируется.)
Как отмечают многие; вообще плохая идея использовать незарегистрированный TLD для интранета. Однако [0] утверждает, что есть некоторые обычно используемые нанмы (хотя и не одобренные для использования только в интрасети). [0] по-прежнему не рекомендует использовать упомянутый TLD для локальных сетей и локальных. не должен использоваться в любой другой ситуации, кроме многоадресной DNS.
[0] RFC6762, приложение G: http://tools.ietf.org/html/rfc6762
Мы используем.local все время как с Маком, так и с ПК. наслаждаться