Назад | Перейти на главную страницу

Использование .local для внутренних веб-сайтов

Можно ли использовать app.mycoolname.local для частных / внутренних URL-адресов?

У нас есть несколько веб-приложений, но они являются частными и не публикуются.

Для некоторых из них мы использовали ".net", что не имеет смысла, поскольку они могут совпадать с реальным URL-адресом в Интернете. Это еще не проблема.

Но теперь у меня есть новая группа приложений, и я хочу назвать их, используя «популярное» имя, которое определенно будет совпадать с URL-адресом в Интернете.

Должен ли я использовать app.mycoolname.local? Я настроил это прямо сейчас, и, похоже, он работает. Я читал несколько мест, где это поощрялось, но затем я увидел несколько мест, где это не работало (некоторые проблемы на Mac, но у нас их нет, поэтому NBD).

Не используйте .local. Не используйте. Что-либо, только что подделку. Даже не используйте зарезервированные 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)
  • Внутренний домен с другим TLD (например, 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

Если вам нужна дополнительная информация о .местный и почему это может или не может быть проблемой для вас. На самом деле, похоже, нет зарезервированные зоны для внутреннего пользования

Хорошим компромиссным решением является использование внутреннего поддомена в сочетании с путем поиска DNS.

В качестве примера из реальной жизни приложение, над которым я работаю, может быть полностью адресовано как some-app.beta.internal.mycompany.com, но, как internal.mycompany.com находится в пути поиска DNS для рабочих станций, возвращенном DHCP-сервером, я могу получить к нему доступ как some-app.beta. Если эти имена выбраны неправильно, все еще существует вероятность коллизии, но в этом случае коллизию можно разрешить, используя полное доменное имя. (Или, если вы хотите защитить себя, всегда используйте полные доменные имена для важных вещей - хотя последняя точка в именах DNS, к сожалению, не учитывается.)

читать http://cr.yp.to/djbdns/dot-local.html а затем выберите свое локальное доменное имя. Резюме: не изобретайте свой собственный, покупайте реальный домен или используйте .1 - .9

Как отмечали многие; вообще плохая идея использовать незарегистрированный TLD для интранет. Однако [0] заявляет, что есть несколько часто используемых нанометров (хотя и не одобренных для использования только в интранете). [0] по-прежнему не рекомендует использовать упомянутый TLD для локальных сетей и локальных сетей. не следует использовать ни в какой другой ситуации, кроме многоадресного DNS.

[0] RFC6762, приложение G: http://tools.ietf.org/html/rfc6762#appendix-G

Я всегда был большим поклонником внутреннего TLD .lan.

Мы все время используем .local как для Mac, так и для ПК. наслаждаться

Вполне приемлемо использовать зону .local. У нас есть один для нашей внутренней сети, который в основном используется для сайтов разработки, но он работает хорошо.