Как стать автором
Обновить

[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать

Время на прочтение 8 мин
Количество просмотров 100K
Всего голосов 8: ↑8 и ↓0 +8
Комментарии 13

Комментарии 13

НЛО прилетело и опубликовало эту надпись здесь

Про политику разрешения имен с локальными суффиксами — ой мама, какие грабли! Реально, кому нужен такой функционал? Разве что типа проксировать запросы в Интернет, запретив на локальных станциях внешний DNS resolve. (Хотя чем не способ применения?)


Про DNS-курьезы: Недавно один из серверов DNS стал отдавать внутренние адреса по запросам извне. Долго бились, оказалось, в ответы или пакеты передачи зоны (сервер secondary) влезала циска, за которой он сидел за натом, и правила адреса. Исправили, настроив NAT с флагом no-payload.

"|При использовании NetBIOS имя ограниченно 16 битами" — вероятно, байтами?
Точно, спасибо что указали на ошибку.
В статье хорошо бы еще смотрелось описание проблемы на Windows 10:

И было бы интересно почитать про резолв, если есть несколько VPN-подключений.
Конфигурации с несколькими подключениями – скорее исключительный случай и потому не попала в статью. Я больше ориентировался на обычную локальную сеть.
описание проблемы на Windows 10

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

Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Я бы поправил последнее как name.subdomain.domain.zone.
Суффикс добавляется только к неполным именам без точки на конце.

А вообще, Microsoft писал отличную документацию во времена Windows Server 2003 в которой можно почерпнуть особенности реализации.
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

У вас на каждом скрине сниффера видны какие-то буковки LLMNR. В 2017 году подробно рассказывать про netbios и WINS и не упомянуть про это?


В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service).

Уменьшение количества броадкастов — это, конечно, хорошо, но WINS решает куда более серьезную проблему — разрешение имен NetBIOS работает только в пределах одного широковещательного сегмента.


Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен

А в ОС, где эта политика не настроена или ее вообще нет, вопрос обычно решается тем, что используемый при подключении к VPN виртуальный адаптер получает нужные настройки (DNS, маршруты и т.п.) с самого VPN-сервера. Т.е. политики — это хорошо, но и до них, и без них жизнь вполне себе кипит.


Для удобства проиллюстрирую алгоритм блок-схемой:

По вашей блок-схеме ни одно имя короче 16 байт и не разрешимое через NetBIOS или WINS вообще не будет разрешено. Что, очевидно, не так.


То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути.

Это не так. Причем ответ на вопрос "почему не так" лежит у вас чуть ниже по тексту, но в очень узком контексте. Вы почему-то наличие у хоста доменных суффиксов привязали к членству в домене AD, политикам и т.п., что неверно.


Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам.

Неверно. Она добавляет суффиксы не к "коротким" или "длинным" в каком-либо смысле именам, а просто к любым неполным (без точки в конце).

Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

Это все прекрасно, имена рабочих станций AD знает. А как она узнает IP, для привязки в DNS, если DHCP работает отдельно а не в связке с AD? В случае с динамическими IP адресами получается DNS не работает, тк. IP сменился, и уже по имени доступа к машине не будет
А как она узнает IP, для привязки в DNS, если DHCP работает отдельно а не в связке с AD?

Хосты сами регистрируются, и к способу выдачи IP это никакого отношения не имеет. Читайте про динамический DNS.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий