Перейти к содержимому
Калькуляторы
tld в локальной (служебной) сети  

26 пользователей проголосовало

  1. 1. Какой tld используется в локальной сети?

    • не используется
      2
    • domain
      2
    • domain.local
      7
    • domain.lan
      1
    • corp.domain.ru
      11
    • другое
      3


Какой tld использовать в локальной сети?

Когда-то давно я использовал вариант 2 - то есть был приватный домен domain и в нем хосты ns.domain, www.domain и т.д.

Выглядело не очень красиво, браузеры часто на таких ссылках глючили и не распознавали их как ссылки. Ну и по итогу это не очень удобно оказалось.

Поэтому через некоторое время я перешел на вариант 3 - domain.local, хосты ns.domain.local, www.domain.local, адреса hostmaster@domain.local.

Вообщем все было хорошо, но потом внезапно выяснилось, что корневой домен local зарезервирован IANA для mDNS, и пользователи MacOS (а если точнее - сервиса Bonjour) из-за этого могут работать неправильно.

Теперь подумываю над переходом на вариант 4 - domain.lan. Но сеть уже разрослась, менять нужно во многих местах и без особой причины это делать не хочется.

А попутно искал информацию на эту тему в интернете и наткнулся на мнение, что приватные TLD вообще не нужно использовать, а нужно использовать реальные TLD с префиксом (вариант 5, префикс не обязательно corp, может быть и другой). Аргументы разные, но один из основных — на приватный TLD нельзя получить действующий сертификат от CA.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зарегистрируйте реальный. И живите в нём. В чём проблема?

имеющиеся уже, перенести в реально-зарегистрированный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я пока собираю мнения.

У меня сервисная сеть размещается на приватных адресах и совместить публичный домен с приватными адресами будет хлопотно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

совместить публичный домен с приватными адресами будет хлопотно

тут согласен. Это момент.

И всё же, мое мнение на данный момент, вариант - реальный. :)

Как мне кажется универсальный как ни крути. А что адреса внутренние, то это ж Вы никак не решите на уровне домена.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

https://en.wikipedia.org/wiki/.localhost

 

In 1999, the Internet Engineering Task Force reserved the DNS labels localhost, example, invalid, and test so that they may not be installed into the root zone of the Domain Name System.

 

Хотя ".localhost" черевато, ".test" уже в некоторых сетях и прогах используется.

 

Получается, что или сабзона в собственной зоне, или ".example|.invalid".

Изменено пользователем snvoronkov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 вариант самы правильный, только split dns надо настроить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня сервисная сеть размещается на приватных адресах и совместить публичный домен с приватными адресами будет хлопотно.

 

а в чём проблема-то? ну будут сервые A-записи типа xxx.corp.musohransk-telecom.ru , никому они не мешают, даже если снаружи будут резолвится

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да как-то некрасиво, мне кажется.

Если доменное имя публичное, оно должно быть доступно.

А в случае domain.local сразу ясно, что это приватная сеть.

 

Ну и если я использую личный кабинет по адресу lk.corp.domain.ru или почтовый домен support@corp.domain.ru, то теоретически возможен фишинг.

DNS-зона будет правильная и авторитетная, а хосты на ней с адресом 10.x.y.z будут чужие.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если доменное имя публичное, то оно должно вам принадлежать, иначе нет смысла создавать такой домен. Регистрация домена сейчас стоит копейки, так что дальновиднее купить домен и использовать его даже в приватной сети, неизвестно куда потом вырастет ваша сеть.

 

От фишинга покупайте сертификат и прикручивайте ssl. В локальной сети можно использовать свой CA и импортировать сертификат на свои устройства, а извне (если нужно будет), купить пару нормальных сертификатов. Вам не нужно будет запоминать разные адреса для внутренних и внешних сервисов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сейчас уже есть бесплатные сертификаты, если уж совсем денег нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сейчас уже есть бесплатные сертификаты, если уж совсем денег нет.

Его к внутрянке не привертеть никак. Особенность способов верификации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сейчас уже есть бесплатные сертификаты, если уж совсем денег нет.

Его к внутрянке не привертеть никак. Особенность способов верификации.

 

Смысла держать биллинг на внутренних адресах нет. В стратегическом плане это совсем не верно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да как-то некрасиво, мне кажется.

Если доменное имя публичное, оно должно быть доступно.

Ничего оно никому не должно. А некрасиво - это ваш костылинг с .local'ами и .lan'ами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надо же, вариант corp.domain.ru самый популярный.

Неожиданно для меня, нужно будет это обдумать.

 

Смысла держать биллинг на внутренних адресах нет.

В каком смысле?

В моем опыте (что делал я и с чем сталкивался у других) инфраструктуру делали на приватных адресах:

1) Чтобы закрыть ее снаружи. Доступ для API или ЛК обычно делается через DMZ или прокси.

2) Чтобы не ограничиваться пространством доступных IP-адресов. На публичных адресах их дефицит всегда будет мешать, а на приватных можно организовать IP-пространство так, как удобно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Смысла держать биллинг на внутренних адресах нет.

В каком смысле?

В моем опыте (что делал я и с чем сталкивался у других) инфраструктуру делали на приватных адресах:

1) Чтобы закрыть ее снаружи. Доступ для API или ЛК обычно делается через DMZ или прокси.

 

Такая схема не мешает получить бесплатный сертификат.

 

2) Чтобы не ограничиваться пространством доступных IP-адресов. На публичных адресах их дефицит всегда будет мешать, а на приватных можно организовать IP-пространство так, как удобно.

 

Личный кабинет, недоступный снаружи - плохой вариант. Например, нельзя проверить через "телефонку", остаток средств, или пополнить счет, и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если под бесплатным имеется в виду летзинкрипт, то у них есть способ проерки DNS. По идее должно помочь в выписке сертификатов для совсем приватных серверов. (ну по описанию, сам, за ненадобностью, не проверял :) )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Личный кабинет, недоступный снаружи - плохой вариант. Например, нельзя проверить через "телефонку", остаток средств, или пополнить счет, и т.д.

 

Каждый зону безопасности для себя определяет сам. В наш ЛК могут ходить только наши клиенты, и никак извне. Сбер с онлайном ходит по своей схеме, и только для оплаты конкретного ЛС. Я к чему - у нас безлимиты, без допуслуг, клиентам не надо метаться в ЛК, чтобы активировать карту оплаты например, или сменить тариф. Хотя - обещанный платёж в ЛК сделать можно, но можно это и сделать просто звонком. Торчать ЛК в инете - ну кто как решит сам...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.