Разрешение имен в сети windows

Аннотация

В данной статье рассматриваются различные методы имя узла для разрешения адреса IP используется клиентами Microsoft Windows. Последовательность методов отличается от последовательность, используемая для разрешения имен NetBIOS в IP-адреса.

Дополнительная информация

В сети, использующей протокол TCP/IP необходимо преобразовать имена ресурсов в IP-адреса для подключения к этим ресурсам. Клиенты Microsoft Windows будет следовать последовательность методов при попытке разрешения имени в адрес, Остановка поиска, если он успешно соответствует имени в IP-адрес. Существуют две последовательности main используется почти во всех случаях: при разрешении NetBIOS и имя узла разрешение. Клиентам, подключающимся к ресурсам на серверах Майкрософт, обычно через диспетчер файлов или сетевом окружении наиболее часто использовать разрешение имен NetBIOS. За дополнительной информацией обратитесь к следующей статье базы знаний Майкрософт:

119493 NetBIOS через WINS и разрешения имен TCP/IP

Разрешение имен узлов разрешения имен TCP/IP ресурсов, которые не подключаются через интерфейс NetBIOS. Наиболее распространенным примером этого является веб-обозревателях, например Microsoft Internet Explorer. Другие примеры приложений Интернета, Ping, FTP и Telnet. Многие современные базы данных и почтового приложения, которые подключаются с помощью Winsock, реализация Microsoft Windows сокеты TCP/IP также использовать разрешение имен узлов. Примерами таких приложений являются Outlook и Exchange.When устранения проблем с разрешением имен, очень важно для сужения ли разрешение приложения NetBIOS-имя или имя узла. Примечание: В контексте этой статьи термин «клиент» не ссылается обязательно на рабочей станции. Windows NT server будет иметь роль клиента при его требуется доступ к ресурсам, требующим разрешения имен узлов. Разрешение имен узлов обычно использует следующую последовательность:

1. Клиент проверяет, если запрашиваемое имя собственного.

2. Клиент затем производит поиск в локальном файле Hosts, список IP-адреса и имена, хранящиеся на локальном компьютере. Примечание: местоположение файла Hosts зависит от операционной системы: Windows NT %Systemroot%\System32\Drivers\Etc Windows 95 <drive>\<Windows folder> Windows for Workgroups <drive>\<Windows folder> Windows 3.1 <drive>\<Windows folder> MS-Client 3.0 <Boot volume>\Net Lan Manager 2.2c Client <Boot volume>\Net Где % Systemroot % — папка, в которой установлена Windows NT, < диск > — это диск, на котором установлена операционная система, а < загрузочного тома > ссылается на загрузочный диск или диск C. Пример файла hosts Hosts.sam, устанавливается вместе с протоколом TCP/IP, показывая в необходимый формат.

3. Серверы имен (DNS) домена запрашиваются.

4. Если имя по-прежнему не устранена, последовательность разрешение имен NetBIOS используется в качестве резервной копии. Этот порядок можно изменить, настроив тип узла NetBIOS клиента.

Клиент Windows попробуйте каждый из этих методов, пока он успешно разрешает имя или исчерпывает эти методы. Windows NT, Windows 95 или Windows для рабочих групп клиентов, использующих Microsoft TCP/IP 3.11b, выполните следующее. LAN Manager 2.2c или клиентов Microsoft 3.0 клиент не будет использовать разрешение имен NetBIOS как резервной копии. Дополнительные сведения можно найти в следующих статьях базы знаний Майкрософт:

169141 разрешение NetBIOS и имя узла для клиента MS и LM 2.2 cПри разрешении имен клиента будет пропускать методы, для которых не настроен. Например если отсутствует файл hosts на компьютере, затем он будет пропустить шаг #2 и повторите запрос к DNS-серверу. Если нет IP-адреса сервера DNS введены в конфигурации TCP/IP клиента, клиент будет перейдите к следующему шагу в последовательности после DNS. Метод для изменения порядка разрешения имени узла, отличается для различных операционных систем и версий. Эти определения приводятся в наборы ресурсов для определенных операционных систем, а также в Base.For знаний Майкрософт Дополнительные сведения, можно найти в следующих статьях базы знаний Майкрософт:

171567 Windows NT 4.0 ServiceProvider приоритета значения не применяется

Как изменить порядок разрешения имен в Windows 95 и Windows NT 139270

119372 Установка порядок поиска разрешение имен для TCP/IP-32

Устранение неполадок

Проблема: Не удается разрешить имя узла клиента. Устранение неполадок действия: Если клиент не может разрешить имя узла, а затем лучше всего проверить узла должны использовать разрешение имен последовательности, перечисленных выше, клиент. Если имя не существует в какие-либо ресурсы, используемые клиентом, необходимо решить для какой ресурс для его добавления. Если имя существует в один из ресурсов, например DNS-сервер или сервер Windows Internet Name Service (WINS), клиент не разрешает имя правильно сосредоточить свое внимание на устранение конкретного ресурса. Кроме того убедитесь, что клиент пытается разрешить имя узла, а не имя NetBIOS. Многие приложения имеют несколько методов, которые они могут использовать для разрешения имен, это особенно верно, почта и базы данных приложений. Приложение может быть настроено для подключения к ресурсам с помощью NetBIOS. В зависимости от конфигурации клиента клиент может обойти разрешения имен узлов. Там будет необходимо либо изменить тип подключения для сокетов TCP/IP или устранения неполадок как проблема NetBIOS. Проблема: Клиент разрешает имя очень медленно или не может разрешить имя и долго не сообщает об ошибке. Действия по устранению неполадок: DNS-серверов в конфигурации TCP/IP клиента, но сервер не доступен для клиента обычно в результате. Так как протокол TCP/IP предполагает сети с низкой надежностью, клиент повторной попытки соединения до оставления попытка запроса на DNS-сервере. Затем клиент попытается опросить второго сервера DNS, если она настроена и использовать то же время к сбою. Только после этого будет клиент шаги для разрешения NetBIOS-имен как описано выше. Существует три способа подход этой проблемы.

• Если имя узла правильно введена в хост-файле, будет разрешена прежде чем клиент предпринимает попытку запроса DNS. Это решение работает также в том случае, если DNS-серверы временно недоступны и есть небольшое количество имена узлов, которые должны быть разрешены. Настройка вручную файлы Hosts для многочисленных клиентов может быть чрезмерно высокой. –ИЛИ-

• Если доступных DNS-серверов, но неверные адреса DNS-серверов в конфигурации TCP/IP для клиентов, затем исправление этих адресов позволит клиентам немедленно связаться с DNS-серверами. Даже если DNS-сервер сообщает о том, что он не может разрешить имя, это будет происходить намного быстрее, чем если клиент не может достичь DNS-сервера на всех. –ИЛИ-

• Если DNS-серверы настроены на клиенте, но эти серверы окончательно недоступны, то удалите IP-адреса DNS-серверов из конфигурации клиента. Клиент затем будет выполнять поиск DNS без задержки. –ИЛИ-

• Если записи в базе данных DNS отсутствуют или являются неверными, затем будет задержка как DNS-серверы запросов другим DNS-серверам перед сообщение о том, что они не могут разрешить имя. Обычно это вызовет задержку на несколько секунд.

Дополнительные сведения о TCP/IP и разрешения имен, можно найти в следующем техническом документе анонимный FTP-сервера корпорации Майкрософт:

Имя файла: Место Tcpipimp2.doc: ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/ название: «3.5/3.51/4.0 Microsoft Windows NT: реализация протокола TCP/IP сведения стека протокола TCP/IP и службы, версия 2.0.»

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат..

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

Дедушка NetBIOS

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

• регистрация и проверка сетевых имен;

• установление и разрыв соединений;

• связь с гарантированной доставкой информации;

• связь с негарантированной доставкой информации;

• поддержка управления и мониторинга драйвера и сетевой карты.

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

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

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

Стандарт наших дней – DNS

DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

• если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

• сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

• после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

• затем сервер, который держит зону google.com уже выдает ответ.

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Порядок разрешения имен

Операционная система Windows пытается разрешить имена в следующем порядке:

• проверяет, не совпадает ли имя с локальным именем хоста;

• смотрит в кэш DNS распознавателя;

• если в кэше соответствие не найдено, идет запрос к серверу DNS;

• если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

• если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

• если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

• последняя попытка – система ищет записи в локальном файле lmhosts.

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

Алгоритм разрешения имен в Windows.

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

@echo off
echo %time%
ping hjfskhfjkshjfkshjkhfdsjk.com
echo %time%
ping xyz
echo %time%
pause

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

Active Directory и суффиксы

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

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

При попытке запуска команды ping servername система проделает следующее:

• если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

• если ответ будет отрицательный – система запросит servername.domain.com, на случай, если мы обращаемся к хосту родительского домена.

При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

nslookup -dc2 ya.ru

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        4.4.8.8.in-addr.arpa, type = PTR, class = IN

    ANSWERS:
    ->  4.4.8.8.in-addr.arpa
        name = google-public-dns-b.google.com
        ttl = 86399 (23 hours 59 mins 59 secs)

------------
╤хЁтхЁ:  google-public-dns-b.google.com
Address:  8.8.4.4

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = A, class = IN

    ANSWERS:
    ->  ya.ru.subdomain.domain.com
        internet address = 66.96.162.92
        ttl = 599 (9 mins 59 secs)

------------
Не заслуживающий доверия ответ:

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = AAAA, class = IN

    AUTHORITY RECORDS:
    ->  domain.com
        ttl = 19 (19 secs)
        primary name server = ns-2022.awsdns-60.co.uk
        responsible mail addr = awsdns-hostmaster.amazon.com
        serial  = 1
        refresh = 7200 (2 hours)
        retry   = 900 (15 mins)
        expire  = 1209600 (14 days)
        default TTL = 86400 (1 day)

------------
╚ь :     ya.ru.subdomain.domain.com
Address:  66.96.162.92

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

ping ya.ru -n 1
Обмен пакетами с ya.ru [87.250.250.242] с 32 байтами данных:
Ответ от 87.250.250.242: число байт=32 время=170мс TTL=52

Это поведение иногда приводит в замешательство начинающих системных администраторов.

Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

Работа со стеком TCP/IP в сетях Windows NT.

5.1. Способы разрешения имен в сетях Windows

Конфигурирование стека TCP/IP в среде Windows NT связано с назначением IP-адреса и имени компьютера, которые уникально идентифицируют каждый компьютер в сети. Для сети TCP/IP и сети Internet используется составное имя компьютера — это глобально известное системное имя плюс имя домена DNS. (В локальной сети Microsoft имя компьютера — это имя в стиле протокола NetBIOS, которое было определено во время инсталляции Windows NT.)

Для идентификации друг друга компьютеры используют IP-адреса, но пользователи обычно предпочитают работать с именами компьютеров. Следовательно, в сети TCP/IP должен быть предусмотрен механизм для установления соответствия между именами и IP-адресами. Для того, чтобы обеспечить уникальность как имени, так и адреса, компьютер Windows NT, использующий TCP/IP, регистрирует свое имя и IP-адрес во время старта системы. Компьютер Windows NT может использовать один или несколько из следующих методов для того, чтобы обеспечить корректное разрешение имен в интерсетях TCP/IP.

Windows Internet Name Service (WINS)

Компьютеры Windows NT могут использовать сервис WINS, если в сети имеется один или несколько серверов WINS, которые содержат динамическую базу данных, отображающую имена компьютеров на IP-адреса. WINS может использоваться в сочетании с широковещательным разрешением имен для интерсети, в которой другие методы разрешения имен не работают. Как описывается в следующем разделе, WINS — режим работы NetBIOS поверх TCP/IP, определенный в RFC 1001/1002 как режим p-node.

Широковещательное разрешение имен

Компьютеры Windows NT могут также использовать широковещательное разрешение имен, которое представляет собой режим работы NetBIOS поверх TCP/IP, определенный в RFC 1001/1002 как режим b-node. Этот метод основан на том, что компьютер посылает широковещательные сообщения IP-уровня для регистрации своего имени в сети. Каждый компьютер этой широковещательной области следит за тем, чтобы регистрируемое имя не дублировалось. Все они также отвечают на запросы о собственных именах.

Разрешение имен с помощью DNS

В Windows NT 4.0 реализован клиент службы DNS (Domain Name System). Служба DNS обеспечивает способ просмотра отображения имен при подключения компьютеров к посторонним (не Windows NT) хостам, в которых работают DNS-серверы. Эта служба предназначена для тех случаев, когда подключение осуществляется путем использования NetBIOS поверх TCP/IP или для приложений, использующих интерфейс Windows Sockets, таких как FTP. DNS — это распределенная база данных, разработанная для решения задач направления трафика, которые возникли во время быстрого роста сети Internet в начале 80-х годов.

Файл LMHOSTS, в котором задается соответствие имен протокола NetBIOS и IP-адресов, или использование файла HOSTS, в котором задается соответствие DNS-имен и IP-адресов.

Файл HOSTS используется приложениями, работающим с интерфейсом Windows Sockets, а файл LMHOSTS используется приложениями, работающими с интерфейсом NetBIOS поверх TCP/IP. Файл LMHOSTS используется обычно для разрешения имен в сетях небольшого масштаба, где служба WINS не установлена.

Источник

Разрешение имен в локальной сети windows

Службы разрешения имен DNS и WINS.

IP-адреса, уникальным образом идентифицирующие узлы сети, не удобны для запоминания пользователем, к тому же IP-адреса могут меняться. Для решения этой проблемы Windows XP и Windows Server 2003 обеспечивают возможность сопоставления (разрешения) IP-адреса с именем компьютера. Существует два типа представления имен:

NetBOIS-имена — «плоские» имена (не отражающие иерархическую структуру организации именуемых объектов), длина которых не может превышать 15 символов;

DNS-имена — иерархические имена, используемые для именования компьютеров в Интернете, имеющие ограничение по длине 63 символа.

В состав Windows XP и Windows Server 2003 входят также две службы, обеспечивающие централизованное хранение информации о соответствии имен компьютеров IP-адресам и обслуживание запросов на поиск такого соответствия:

• служба WINS (Windows Internet Name Service), обеспечивающая управление именами NetBIOS. Эта служба включена для поддержки клиентских компьютеров, управляемых версиями Windows 9x, Me, NT;
• служба DNS (Domain Name System), обеспечивающая поддержку использования DNS-имен в сети.

В данном курсе основное внимание уделено службе DNS, которая является основной службой разрешения имен для Windows XP и Windows Server 2003.

Служба DNS автоматически ведет базу данных, в которой записывает соотношение имени компьютера (узла) с его IP-адресом. Эта база данных похожа на телефонный справочник, где каждому номеру телефона соответствует имя владельца. Если нам необходимо позвонить своему знакомому, то по телефонной книге мы легко найдем его телефон (при условии, что он был зарегистрирован заранее). Так же и служба DNS быстро найдет в базе данных IP-адрес компьютера, если мы зададим только его имя.

Организация пространства имен.

Служба DNS выполняет две основных функции:

• организацию иерархического пространства имен;
• обеспечение механизма разрешения (т.е. поиска соответствия) имен в IP-адреса.

Пространство доменных имен имеет иерархическую структуру. На самом верхнем уровне иерархии располагается корневой домен, который обычно обозначается точкой («.»). Следующий уровень иерархии составляют домены верхнего, или первого уровня (Top Level Domains, TLDs). Каждый домен верхнего уровня включает в себя домены второго уровня и т.д.
Теоретически домен любого уровня может содержать в себе как отдельные узлы, представленные своими именами, так и домены более низкого уровня (субдомены). Однако, на практике домены, уровень которых ниже третьего, встречаются крайне редко.

Домены первого уровня делятся на три группы:

• домены общего назначения;
• национальные домены;
• обратный домен.

Первую группу составляют домены общего назначения (Generic TLDs). К ним доменам относятся:

Изначально домены общего назначения предназначались для объединения доменов нижних уровней, принадлежащих организациям и учреждениям США. Поэтому в силу традиции большая часть доменов, зарегистрированных за организациями других государств, входят не в домены общего назначения, а в так называемые национальные домены. Однако ничто не мешает какой-нибудь компании, например, Российской, зарегистрировать домен второго уровня в домене «com». Исключением являются только домены «mil» и «gov», которые используются только учреждениями и организациями США.

Во вторую группу включены национальные домены (Country Code TLDs, ccTLDs). Имя каждого такого домена состоит из двух символов и представляет собой сокращение названия государства (так называемый «код страны»), которому принадлежит домен, например, «ru» означает Россия. Список национальных доменов разработан и утвержден Национальным Институтом Стандартов США (ISO 3166-1).

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

Общие правила построения имен доменов и узлов следующие:

• имя может состоять только из букв латинского алфавита, цифр и символа «-» (дефис);
• длина имени не может превышать 63 символов.

Кроме того, доменные имена являются нечувствительными к регистру символов, входящих в его состав. Это означает, что последовательности символов «Com», «COM», «cOm», «com» и т.п. обозначают одно и тоже имя.

В процессе разрешения имен DNS участвуют три основных составляющих:

• программа-клиент (resolver), которой требуется найти по доменному имени IP-адрес;
• сервер имен (name server), или DNS-сервер, — программа, осуществляющая по запросу клиента поиск IP-адреса на основе предложенного доменного имени;
• часть иерархического пространства имен DNS, обслуживаемая сервером имен и представленная в его локальной базе данных, называемая зоной ответственности (zone of authority).

Важным преимуществом DNS является то, что каждый конкретный сервер имен не должен содержать в своей локальной базе данных описание всей иерархии имен DNS. Как правило, организация, регистрирующая свое доменное имя, должна иметь DNS сервер, в базе данных которого представлено только пространство имен, принадлежащих ее домену. Например, если в домене «fio.ru» имеется только два узла — «www» и «center», то в базе данных сервера имен этого домена может присутствовать всего две записи для указанных имен. Кроме того, если домен содержит в себе домены нижних уровней, то каждый такой «субдомен» может иметь свой собственный сервер имен, освобождая тем самым от необходимости обслуживать свое подпространство имен DNS-сервер родительского домена. Таким образом, продолжая пример, сервер имен домена «ru» не имеет в своей базе данных информации об узлах «www» и «center» домена «fio.ru». Такая передача полномочий по управлению именами части зоны называется делегированием.

Алгоритм работы службы DNS достаточно прост. Когда программе-клиенту требуется по доменному имени выяснить IP-адрес, она связывается с сервером имен, адрес которого указан в настройках TCP/IP. Сервер имен, получив запрос, рассматривает его, чтобы выяснить, в каком домене находится указанное имя. Если указанный домен входит в его зону ответственности, то сервер преобразует имя в IP-адрес на основе собственной базы данных и возвращает результат клиенту. В случае же, когда сервер имен не способен самостоятельно осуществить преобразование из-за того, что запрашиваемое доменное имя не входит в его зону, то в зависимости от типа поступившего запроса, он может либо опросить известные ему другие сервера имен с целью получения результата, либо сразу ответить клиенту, сообщив ему адрес другого сервера имен, который, возможно, располагает большей информацией.

Для функционирования серверу имен не обязательно знать адреса всех остальных DNS-серверов Интернет. Достаточно располагать адресами серверов имен корневого домена. Как правило, эта информация изначально и постоянно присутствует в программах-серверах. Очевидно также, что сервер имен должен знать адреса DNS-серверов делегированных зон.

Источник

Разрешение имен в локальной сети windows

Вопрос

Система Windows 7 Домашняя расширенная x64. После удаления вируса не работает разрешение имен, т.е. по IP адресу сайты открываются, по имени нет. Например выполним команду ipconfig /displaydns:

Однако в кэше запись www.ru появилась:

1. netsh int ip reset и netsh winsock reset

2. Переустановка протокола TCP/IP

3. Переустановка драйверов сетевых адаптеров

Кстати, localhost тоже не пингуется. Пингуется 127.0.01

Вопрос: на каком этапе не работает разрешение имен?

Ответы

Аллилуйа! Лыжи действительно не ехали.

Воробей был успешно пристрелен из рогатки, описанной добрым человеком APuh здесь: http://forum.oszone.net/thread-178627-2.html

Моя ошибка была в том что я переустанавливал только протокол TCP/IP 4, а надо было вместе с 6 все грохать. После выполнения всех действий, описанных APuh, включая правку реестра, все заработало.

• Предложено в качестве ответа Dmitriy Vereshchak Microsoft contingent staff, Moderator 11 июня 2014 г. 8:12
• Помечено в качестве ответа Dmitriy Vereshchak Microsoft contingent staff, Moderator 11 июня 2014 г. 8:12

Все ответы

gpedit.msc наст.комп.>адм.шаблоны>сеть>dns клиент там все по умолчанию?

Хотя «редактор локальной групповой политики отсутствует в «домашних» редакциях Windows 7, а именно Начальная, Домашняя базовая и Домашняя расширенная», но кого это останавливало? 😉

Скриншот не удалось прикрепить, на что обратить внимание?

Вроде как все стандартно. все пункты «Not configured»

С AVZ тоже пробовал, именно этот совет по ссылке, забыл про это написать

sfc /scannow от админа в кмд выполните

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

На 10.10.10.20 как с днс?

nslookup что говорит?

Да 10.10.10.20 как днс и как шлюз, это Windows 8.1 с расшаренным сетевым соединением, я думаю это роли не играет. Как DNS прописывал и 8.8.8.8, не помогает.

nslookup говорит что все нормально:

В тоже время ping говорит что все плохо:

С модемом Yota тоже самое.

Кстати, не работал DHCP клиент, пришлось восстанавливать. Может какая-то служба отвечает за передачу данных DNS программам? И она тоже не работает?

Работают только программы, которые не пользуются этой службой.

sfc /scannow пишет что некоторые файлы не смог восстановить.

Выполните sfc еще два-три раза, возможно восстановит!

После этого выложите cbs.log

Еще, попробуйте следующее:

Посмотрел в Network Monitor какой трафик ходит. Оказалось DNS запросы прекрасно уходят и возвращаются. Программы которые напрямую обращаются к DNS серверам работают, например прекрасно себя чувствует Skype. Кроме того, видно как при выполнении ping уходит запрос на DNS сервер от DNS-клиента и приходит ответ, только вот ping эту информацию не получает.

sfc /scannow пишет что некоторые файлы не смог восстановить.

попробуйте sfc после этих действий

Хочется все-таки разобраться что в Windows 7 отвечает за разрешение имен (где находятся настройки). Ведь если на нормальной системе отключить DNS-клиент, имена все-равно разрешаются, тот же ping прекрасно себе работает.

В моем же случае такое впечатление что система даже не пытается разрешить имя, порядок проверки ведь какой — локальное имя, файл hosts, DNS, NetBt. Но, даже если прописать соответствие в hosts имя не разрешается, т.е. проверка просто не производится. Почему?

Источник

Разрешение имен NetBIOS

Если включена система NetBIOS, то на всех компьютерах Windows поддерживается
кэш имен NetBIOS, разрешение которых они уже выполняли. Когда компьютеру
требуется разрешение NetBIOS-имени, то сначала происходит обращение к кэшу.
Если это имя не найдено в кэше, то далее используется метод, определяемый типом
узла данного компьютера.

• Клиент, не использующий WINS, отправляет широковещательные сообщения для разрешения имени, и в случае неудачного результата обращается к локальному файлу LMHOSTS.
• Клиент WINS может использовать для разрешения имен NetBIOS любой из имеющихся методов. Сначала он использует кэш имен NetBIOS, затем обращается к серверу WINS. Если сервер WINS не дает результата, то происходит рассылка широковещательных сообщений, и в случае неудачного результата происходит обращение к файлу LMHOSTS.

В следующих разделах дается описание возможных методов разрешения имен
NetBIOS в том порядке, как они использовались бы на компьютере, поддерживающем
WINS.

Кэш имен NetBIOS. Во время каждого сетевого сеанса клиентский компьютер сохраняет
в кэше памяти все имена NetBIOS, для которых было успешно выполнено разрешение,
чтобы их можно было использовать повторно. Поскольку кэш хранится в
памяти, его использование является самым быстрым и эффективным способом разрешения
имен. Это первый ресурс, к которому обращаются узлы всех типов, когда
им требуется разрешение какого-либо имени. Вы можете увидеть текущее содержимое
кэша имен NetBIOS вашего компьютера, набрав nbtstat -c в командной строке.

Разрешение имен WINS. WINS – это средство на уровне сети предприятия для регистрации
и разрешения имен NetBIOS. Это единственный механизм, доступный сети
Windows Server 2003/2000, который автоматически поддерживает базу данных
NetBIOS-имен сети и соответствующих им IP-адресов. В отличие от широковещательных
сообщений служба WINS использует только отдельные сетевые сообщения,
что позволяет ей работать независимо от границ между сегментами сети. Использование
отдельных сообщений WINS позволяет существенно сократить объем
сетевого трафика, который возникает за счет операций разрешения имен NetBIOS.

WINS поставляется вместе с Windows Server 2003, и она функционирует как служба.
В ваш комплект администрирования включена оснастка WINS, которая позволяет
вам управлять всеми серверами WINS в сети вашего предприятия из одной центральной
точки. Для повышения скорости (а также отказоустойчивости) вы можете
запускать в сети предприятия несколько серверов WINS. Базы данных WINS могут
автоматически реплицироваться через заранее заданные периоды времени или в
указанные моменты дня. Вы можете запланировать репликацию WINS через каналы
глобальной сети (WAN) на периоды низкого уровня трафика, создавая тем самым
унифицированную базу данных для распределенной по всему миру сети.

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

Если клиенту WINS требуется разрешение имен NetBIOS, то он отправляет отдельное
сообщение NAME QUERY REQUEST первому серверу WINS, указанному
на странице WINS Address диалогового окна TCP/IP Properties. Затем сервер WINS
отвечает сообщением POSITIVE NAME QUERY RESPONSE, содержащим запрашиваемое
имя и соответствующий IP-адрес, или сообщением NEGATIVE NAME
QUERY RESPONSE, указывающим, что в базе данных нет записи с этим именем.

Если имеется некоторая задержка с ответом на запрос, сервер WINS отправляет
клиенту пакеты WACK (WAIT FOR ACKNOWLEDGEMENT RESPONSE – ожидать
подтверждающего ответа), чтобы клиент не перешел к использованию следующего
метода разрешения имен.

Если сервер WINS не может выполнить разрешение имени, отправив отрицательный
ответ или не отправив никакого ответа, то клиент обращается к вторичному
(резервному) серверу WINS и повторяет весь процесс. Если это не может сделать
и вторичный сервер, то компьютер, который является H-узлом, переходит к использованию
широковещательных сообщений для разрешения имени. Но если серверы
WINS не могут ответить на любые запросы разрешения имен, то клиент продолжает
попытки контакта с этими серверами, чтобы вернуться к разрешению имен WINS,
как только появится такая возможность.

Разрешение имен с помощью широковещательных сообщений

Если разрешение имен NetBIOS происходит с помощью широковещательных сообщений,
то все зарегистрированные компьютеры должны отвечать на запросы, в
которых указаны их имена. Компьютер, который применяет широковещательные
сообщения для разрешения имен, генерирует тот же пакет NAME QUERY REQUEST,
что и клиент WINS, за исключением того, что запрос направляется в виде широковещательных
сообщений всем компьютерам данной локальной подсети. Каждый
компьютер, получивший этот пакет, должен проверить имя, для которого запрашивается
IP-адрес.

Если пакет содержит нераспознаваемое имя, то он «молча» удаляется. Но если
компьютер опознал свое собственное имя в этом запросе, то он должен ответить
отправителю пакетом POSITIVE NAME QUERY RESPONSE, содержащим его IP-адрес.
Этот пакет отправляется как отдельное (не широковещательное) сообщение.

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

Файл LMHOSTS

Если не удается разрешить имя NetBIOS с помощью широковещательных сообщений,
то следующая альтернатива – это файл LMHOSTS на локальном жестком диске.
Клиенты, не поддерживающие WINS, делают это автоматически. Чтобы клиент
WINS мог использовать файл LMHOSTS (после того, как поиск с помощью WINS и
широковещательных сообщений не дал результата), вы должны установить флажок
Enable LMHOSTS Lookup (Разрешить поиск в LMHOSTS) на странице WINS Address
диалогового окна TCP/IP Properties.

Примечание. Использование файла LMHOSTS не включено в стандарт NetBT как
часть определений типов узлов. Поэтому клиентов, которые используют LMHOSTS,
называют системами расширенного B-узла или H-узла.

Файл LMHOSTS аналогичен файлу HOSTS (который используется для разрешения
хост-имен) за исключением того, что он содержит список имен NetBIOS. Он
находится в той же папке, что и HOSTS ( %SystemRoot%\System32\drivers\...), и
Windows предоставляет файл-образец с именем Lmhosts.sam, который вы можете
использовать как модель для своего собственного файла (это текстовый файл, который
вы можете просматривать с помощью Notepad [Блокнот]).

Для компьютера, который не являются клиентом WINS, файл LMHOSTS – это
единственное средство разрешения имен, доступное компьютерам в других сегментах
сети. Чтобы регистрировать имена NetBIOS, нужно вручную отредактировать
файл LMHOSTS и добавить запись для каждого компьютера, с которым вы будете
взаимодействовать. Каждая запись должна содержать IP-адрес компьютера, после
которого в той же строке (через пробел) должно следовать соответствующее NetBIOS-имя.

В отличие от файла HOSTS файл LMHOSTS может содержать дополнительные
средства, которые помогают в процессе разрешения имен.

• #PRE. Если тег #PRE добавляется к какой-либо записи в файле LMHOSTS, то эта запись заранее загружается в кэш имен NetBIOS при каждой загрузке данного компьютера. Добавление в файл LMHOSTS компьютеров, к которым чаще всего выполняется доступ, ускоряет разрешение имен даже для клиентов WINS. Тег #PRE следует добавлять в конец записи с одним или несколькими пробелами, отделяющими его от имени NetBIOS.
• #DOM:имя_домена. Тег #DOM используется, чтобы связать запись файла LMHOSTS с доменом Windows NT, который указывается переменной имя_домена. В результате компьютер, указанный в этой записи, будет получать список для навигации среди компьютеров домена от главного контроллера (PDC) указанного домена. Это позволяет компьютерам, не использующим WINS, выполнять навигацию среди компьютеров домена, которые находятся в других сегментах сети. Тег #DOM вместе со своим параметром помещается в конец записи после пробела.
• #INCLUDE путь. Тег #INCLUDE позволяет вам получать доступ к файлу LMHOSTS, находящемуся в другом месте. Обычно это средство используется для доступа к файлу на каком-либо сетевом диске, где он может одновременно использоваться другими клиентами. Это означает, что вы можете редактировать один централизованный файл LMHOSTS вместо обновления по отдельности копий на рабочих станциях. Этот тег, после которого следует полный UNC-путь к файлу, должен быть помещен в отдельную строку файла LMHOSTS, как это показано ниже:

  #INCLUDE \\сервер1\разделяемый_ресурс\...\lmhosts

  Примечание. Проследите, чтобы NetBIOS-имя, используемое в UNC-пути, можно
  было разрешить с помощью тега #PRE, если эта машина находится в другом сегменте
  сети.
• #BEGIN_ALTERNATE/#END_ALTERNATE. Эти теги используются, чтобы обеспечить отказоустойчивость для тега #INCLUDE. Если поместить несколько тегов #INCLUDE между тегами #BEGIN_ALTERNATE и #END_ALTERNATE, как это показано ниже, то теги #INCLUDE будут обрабатываться по порядку, пока не будет выполнен успешный доступ к соответствующему файлу LMHOSTS. После успешного чтения этого файла все следующие теги #INCLUDE игнорируются и происходит переход к следующей строке после тега #END_ALTERNATE.

  #BEGIN_ALTERNATE#INCLUDE \\сервер 1\разделяемый_ресурс\...\lmhosts#INCLUDE\\
  сервер 2\разделяемый_ресурс\...\lmhosts#END_ALTERNATE

• \Oxhh. Этот тег используется для задания специальных символов в именах NetBIOS по их шестнадцатеричным значениям. Если приложению требуется специальный символ в 16-й позиции имени NetBIOS, то вы можете задать его, заключив это имя в кавычки и применив \Oxhh в соответствующей позиции (с заменой hh шестнадцатеричным значением этого символа). \Oxhh заменяет только какой-либо один символ в имени NetBIOS. Вы должны включить нужное число пробелов, чтобы в имени было 16 символов, например:

  139.41.129.18 "application \ox14"

Когда следует прекратить использование NetBIOS

Microsoft рекомендует переходить к более «чистой» реализации TCP/IP в сетевых
окружениях Windows. Теперь уже не обязательно использовать NetBIOS over TCP/IP
для разрешения имен, поскольку эти функции взяла на себя DNS. Кроме того,
NetBIOS поддерживается только для совместимости с унаследованными системами
и приложениями.

DNS просто лучше – это более масштабируемое и надежное решение для разрешения
имен. Она выдержала испытание временем, и интернет является наилучшим
примером ее успеха. Чтобы детальнее ознакомиться с DNS и ее влиянием на среду
Windows, обратитесь к
«Ознакомление с DNS»
.

Как вы, вероятно, уже поняли, чем быстрее вы прекратите использовать NetBIOS,
тем лучше станет ваша среда Windows. Первый шаг – это модернизировать клиентов
прежних версий Windows, перейдя к текущей версии Windows.

К сожалению, модернизация не позволит полностью выполнить вашу задачу.
Вам придется также проверить, работают ли у вас приложения, которые зависят от
NetBIOS. Если у вас есть такие приложения и они все еще нужны вам, обратитесь к
поставщику, чтобы узнать, нет ли у него модернизированной версии, которая не
использует NetBIOS (для начала проверьте свою версию Microsoft Office). После
того как вы отключите NetBIOS, любые приложения, которые основываются на этой
службе, перестанут правильно работать или не будут работать совсем. И последний
шаг – это фактическое отключение NetBIOS на всех машинах Windows Server 2003/XP/2000.
Для этого выполните следующие шаги.

1. В меню Start\Settings выберите Network Connections.
2. Щелкните правой кнопкой на значке Local Area Connection и выберите пункт Properties.
3. Выберите Internet Protocol (TCP/IP) и щелкните на кнопке Properties.
4. В диалоговом окне Properties щелкните на кнопке Advanced, чтобы появилось диалоговое окно Advanced TCP/IP Settings.
5. Перейдите во вкладку WINS и выберите вариант Disable NetBIOS over TCP/IP (Отключить NetBIOS поверх TCP/IP).
6. Два раза щелкните на кнопках OK и затем щелкните на кнопке Close.