Pull to refresh

Comments 9

почему на запрос пушистые-котики.рф компьютер открывает сайт котиков, а не чертежи крыла самолета

нет там никаких котиков :/

Так какой домен использовать стоит для приватного DNS в локальной сети? Ведь .local занят для MDNS (Bonjour) разве не так?

TLDs for Testing, & Documentation Examples There is a need for top level domain (TLD) names that can be used for creating names which, without fear of conflicts with current or future actual TLD names in the global DNS, can be used for private testing of existing DNS related code, examples in documentation, DNS related experimentation, invalid DNS names, or other similar uses. For example, without guidance, a site might set up some local additional unused top level domains for testing of its local DNS code and configuration. Later, these TLDs might come into actual use on the global Internet. As a result, local attempts to reference the real data in these zones could be thwarted by the local test versions. Or test or example code might be written that accesses a TLD that is in use with the thought that the test code would only be run in a restricted testbed net or the example never actually run. Later, the test code could escape from the testbed or the example be actually coded and run on the Internet. Depending on the nature of the test or example, it might be best for it to be referencing a TLD permanently reserved for such purposes. To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.

Все описано в RFC 2606

https://www.rfc-editor.org/rfc/rfc2606.html

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

в приватных сетях облака Selectel зона .local работает без проблем, клиенты её используют для своей инфраструктуры.

в плане рекомендации какого-то конкретного имени - выбирайте тот домен, который лучше всего вам подходит. как вариант - .internal.

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

для облачной инфры такой вопрос обычно не стоит - практически везде mdns выключен. в этом плане я немного предвзят, признаю.

В смысле выключен провайдером инфраструктуры, и это не предвзятость, а просто адаптация к условиям?

(Ну и могу понять желание сразу перейти на "взрослое" решение – особенно у тех, кто застал netbeui и выборы координатора сети).

Много общих слов об очевидных, в общем-то, вопросах. А вот о самых проблемных нифига.

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

Тут-то и начинаются всевозможные пляски с бубном (и/или с самоподписанными сертификатами и их установкой на клиенты).

Кстати не особо понятно чё там за беда такая с публичными DNS-записями. Ну вот есть у вас три домена, условных:

git.domen.com

lls.domen.com

stt.domen.com

Ни один из них снаружи не пингуется, открыто два порта на каждом, которые не отвечают. А может и вовсе открытых портов не быть, потому что они слушают только внутренние интерфейсы, а записи и сертификаты обновляются через manual hook серт-бота. Ну и чо, какую это инфу нападающему о сети даст?

Sign up to leave a comment.

Information

Website
slc.tl
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия
Representative
Александр Шилов