Не резолвится имя компьютера в локальной сети
Здравствуйте. Есть машинка, на ней стоит свежая Win7 Максимальная x64, билд 7600 RU.
На ней с перебоями работает разрешение имен. Инет приходит через Ethernet от домашнего роутера (Acorp W422G_v3), к которому машинка цепляется по DHCP. DHCP наряду с айпишниками раздает клиентам адреса DNS-серверов в явном виде, то есть не relay самого роутера, а в моем случае OpenDNS (208.67.222.222, 208.67.220.220).
Аналогично не резолвятся имена в других приложениях.
Вывод ipconfig /all:
Я, если честно, не понимаю, как такое вообще возможно - разве механизм разрешения имен в ping и nslookup не один и тот же?
И да, пробовал прописать другие DNS (провайдерские, гугловский, и т.п.) - то же самое. Пробовал статически вписать DNS и айпишники - все равно то же самое.
Причем данная ситуация наблюдается случайным образом - иногда резолвинг работает, иногда нет. Подозреваю, что это что-то связанное со сбросом какого-либо кэша по времени (ARP, DNS), но не знаю куда копать. ipconfig /flushdns ничего не дает.
В Linux и WinXP все нормально работает.
Конфигурация компьютера | |
Процессор: Intel Core i7-3770K | |
Материнская плата: ASUS P8Z77-V LE PLUS | |
Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб) | |
HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб | |
Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS | |
Звук: Realtek ALC889 HD Audio | |
Блок питания: be quiet! Straight Power 11 650W | |
CD/DVD: ASUS DRW-24B5ST | |
Монитор: ASUS VG248QE 24" | |
ОС: Windows 8.1 Pro x64 | |
Индекс производительности Windows: 8,1 | |
Прочее: корпус: Fractal Design Define R4 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Петя, ю а май хиро.
В общем, дело не в ipv6 (ping -4 тоже не работает), дело в службе dnscache, которая, видимо, за каким-то дьяволом пытается резолвить имена через netbios, а не DNS.
По ссылке что вы дали, люди решили проблему, но у кого-то не работало, у кого-то работало. ну его нафиг.
Я поступил топорней - вырубил DNS-кэш нафиг (net stop dnscache), и пустил DNS-запросы через привычный dnsmasq на отдельной машине.
Проблема решена, хоть и костыльно, конечно.
Последний раз редактировалось mexico, 20-06-2010 в 01:08 .
mexico,
А серверов провайдера без всяких заморочек не хватает?
При чем тут netbios?
А серверов провайдера без всяких заморочек не хватает? » |
Не-а. Я и их ставил, не в них дело. Про UDP 53 не надо - азы же.
Поскольку у меня есть сторонний DNS-кэш на Linux, я не стал заморачиваться и искать причины (я не в ладах с вендой, да и время - деньги), а просто отключил виндовый кэш. Работает - и ладно.
Если предложите 100% работающий способ обойтись без этого костыля - буду только рад.
Последний раз редактировалось mexico, 20-06-2010 в 01:13 .
mexico,
Nslookup действительно кэш DNS не нужен.
2.Потом обычный запрос по имени www.yandex.ru получить IP адреса.
3.Получить полностью запись типа "А"
Вы получили -
При отключении windows кэша DNS вы заставляете лишний раз ПК клиента определять IP по мнемонике используя запросы по сети на ваш DNS (если они есть у него в кэше, то он просто их отправит), по времени это доли секунд.
Реестр по кэшу DNS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache
Проблема такая - не пингуются хосты в локалке по полному имени. По краткому имени все проходит нормально.
Выглядет это так:
ping DC2 разрешает, а
ping DC2.domain.local нет
По этой причине, я подозреваю, терминальные сервера не могут подцепиться с серверу лицензирования RDP клиентов
Почему так происходит не понимаю((((
Ответы
Доброго дня, друзья.
Проблему решили путем отключения и остановки службы DNS client. Все. Все ошибки исчезли.
Хотелось бы услышать комментарии от специалистов Майкрософт по этому поводу. Если можно.
Мы мучались больше 3 лет имея вот такие ошибки в частности:
An error occurred while signing a message using the inserted smart card: Provider could not perform the action since the context was acquired as silent.
An error occurred while retrieving a digital certificate from the inserted smart card. Invalid type specified.
An error occurred while retrieving a digital certificate from the inserted smart card. Incorrect function.
An error occurred while retrieving a digital certificate from the inserted smart card. Keyset does not exist
An error occurred while retrieving a digital certificate from the inserted smart card. 0x81000001
An error occurred while retrieving a digital certificate from the inserted smart card. The handle is invalid.
- Помечено в качестве ответа Petko Krushev Microsoft contingent staff, Moderator 30 января 2018 г. 7:39
Все ответы
И что Вы хотели этим сказать? Поставить или убрать?)) У меня галка стоит.
Все хосты в сети не резолвятся или только определенные?
проверьте присутствуют ли эти записи в DNS
Доброго дня.
Проблема такая - не пингуются хосты в локалке по полному имени. По краткому имени все проходит нормально.
Выглядет это так:
ping DC2 разрешает, а
ping DC2.domain.local нет
По этой причине, я подозреваю, терминальные сервера не могут подцепиться с серверу лицензирования RDP клиентов
Почему так происходит не понимаю((((
1. Посмотрите, какое имя пишет ping перед IP после команды ping DC2. Если там написано просто DC2, без доменного суффикса, то имя, скорее всего, было разрешено через NetBIOS, а не через DNS
2. Проверьте как настроены у вас на компьютерах сервера DNS (командой ipconfig /all ). В списке серверов DNS должны быть только контроллеры домена (или другие серверы, которые про ваш домен знают, но обычно таких не бывает) и не должно быть посторонних серверов (провайдерских, 8.8.8.8 и т.п.).
Данная проблема наблюдается на серверах терминальной фермы. Их 22 и на 3 из них подобная проблема.
Никаких изменений в настройки не вносилось. DNS НАСТРОЕНЫ КОРРЕКТНО. Как рабоатало 3 года так и рабоатет. Проблема только на этих 3 появилась.
Было определенно, что если остановить службу dns client-проблема исчезает и пинг по полному имени идёт. Я даже подохреваю, что после перезагрузки данных серверов все нормализуется. Вопрос-что именно произошло с ними?(((
Доброго дня.
Проблема такая - не пингуются хосты в локалке по полному имени. По краткому имени все проходит нормально.
Выглядет это так:
ping DC2 разрешает, а
ping DC2.domain.local нет
По этой причине, я подозреваю, терминальные сервера не могут подцепиться с серверу лицензирования RDP клиентов
Почему так происходит не понимаю((((
1. Посмотрите, какое имя пишет ping перед IP после команды ping DC2. Если там написано просто DC2, без доменного суффикса, то имя, скорее всего, было разрешено через NetBIOS, а не через DNS
2. Проверьте как настроены у вас на компьютерах сервера DNS (командой ipconfig /all ). В списке серверов DNS должны быть только контроллеры домена (или другие серверы, которые про ваш домен знают, но обычно таких не бывает) и не должно быть посторонних серверов (провайдерских, 8.8.8.8 и т.п.).
Слава России!
Если остановить службу DNS client и сделать ping -a IP, то разрешается корректно по полному имени.
Если же опять включить службу и сделать ping -a IP-то, разрешается только по крроткому
А также еще одна странная вещь.
Как только я захожу по RDP на сервер, у меня выходит окно, что не доступн сервер лицензирования RDP, захожу тут же в Манеджер лицензирования-всё ок, сервер доступен, зеленные галочки
Откуда такая уверенность? Из того, что за три года ошибка проявилась в первый раз? Это не основание.
Вполне возможно, что ошибка может проявляться очень редко. В частности, если она возникает из-за того, что неверно указан (т.е. ничего не знает про домен) не первый в списке север DNS, переключение на который происходит только при недоступности предыдущих серверов - то такое событие вполне может случаться лишь по прошествии нескольких лет.
Поэтому проверьте, что имена в домене разрешают все серверы DNS, которые могут использоваться на клиенте. В Win8/2K12 это можно легко автоматизировать через Powershell:
DNS НАСТРОЕНЫ КОРРЕКТНО.
Откуда такая уверенность? Из того, что за три года ошибка проявилась в первый раз? Это не основание.
Вполне возможно, что ошибка может проявляться очень редко. В частности, если она возникает из-за того, что неверно указан (т.е. ничего не знает про домен) не первый в списке север DNS, переключение на который происходит только при недоступности предыдущих серверов - то такое событие вполне может случаться лишь по прошествии нескольких лет.
Поэтому проверьте, что имена в домене разрешают все серверы DNS, которые могут использоваться на клиенте. В Win8/2K12 это можно легко автоматизировать через Powershell:
Слава России!
Ну вот, что выдала проверка:
PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9
Server: 172.16.100.13
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9
Server: 127.0.0.1
dc5.domain.local AAAA 1200 Question ::1
dc5.domain.local A 1200 Question 172.16.100.9
PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
DC2.domain.local A 3600 Answer 172.16.100.12
Server: 172.16.100.13
DC2.domain.local A 3600 Answer 172.16.100.12
Server: 127.0.0.1
DC2.domain.local A 3600 Answer 172.16.100.12
PS C:\Users\admin> Get-DNSClientServerAddress -AddressFamily IPv4 | select -expand ServerAddresses | foreach
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
DC3.domain.local A 3600 Answer 172.16.100.13
Server: 172.16.100.13
DC3.domain.local A 3600 Answer 172.16.100.13
Server: 127.0.0.1
DC3.domain.local A 3600 Answer 172.16.100.13
Вы проверяли на контроллерах домена, потому что проблема с поиском имён проявляется именно там?
Насколько я понял, это не так. А проверять надо как раз там, где проблема проявляется - потому что настройки DNS - они, вообще-то, свои у каждого компьютера. И даже если они раздаются по DHCP и у всех рядовых серверов домена и рабочих станциях должны быть одинаковы, то на контроллерах домена всё равно обычно свои, особые настройки.
Поэтому, раз вы подозреваете, что есть проблема на терминальном сервере с поиском имени сервера лицензирования, то проверяйте на нём, лучше - подставив вместо dc2.domain.local имя сервера лицензирования.
PS Если версия на терминальном сервере ниже Win2012, то проверяйте вручную - получите ipconfig /all список серверов DNS и проверьте разрешение на каждом командой
nslookup сервер.лицензирования сервер.DNS
Нет. В данныей момент не используем. Это может быть причиной?
Основными ДНС на клиентах и серверах стоят 12 и 13.
Вы проверяли на контроллерах домена, потому что проблема с поиском имён проявляется именно там?
Насколько я понял, это не так. А проверять надо как раз там, где проблема проявляется - потому что настройки DNS - они, вообще-то, свои у каждого компьютера. И даже если они раздаются по DHCP и у всех рядовых серверов домена и рабочих станциях должны быть одинаковы, то на контроллерах домена всё равно обычно свои, особые настройки.
Поэтому, раз вы подозреваете, что есть проблема на терминальном сервере с поиском имени сервера лицензирования, то проверяйте на нём, лучше - подставив вместо dc2.domain.local имя сервера лицензирования.
PS Если версия на терминальном сервере ниже Win2012, то проверяйте вручную - получите ipconfig /all список серверов DNS и проверьте разрешение на каждом командой
nslookup сервер.лицензирования сервер.DNS
Слава России!
Значит, прямо сейчас у вас проблемы с разрешением имён нет. И придётся вам ловить ошибку и искать источник проблемы во время её проявления.
PS На всякий случай, для исключения всяческих чудес - проверьте, если ещё не проверяли, репликацию между контроллерами домена (repadmin /showrepl * на любом из них в режиме администратора), а ещё лучше - проведите диагностику исправности каждого КД командой dcdiag /q (тоже в режиме администратора).
Значит, прямо сейчас у вас проблемы с разрешением имён нет. И придётся вам ловить ошибку и искать источник проблемы во время её проявления.
PS На всякий случай, для исключения всяческих чудес - проверьте, если ещё не проверяли, репликацию между контроллерами домена (repadmin /showrepl * на любом из них в режиме администратора), а ещё лучше - проведите диагностику исправности каждого КД командой dcdiag /q (тоже в режиме администратора).
Слава России!
Спасибо. Буду мониторить и вылавливать.
1. Проверка репликации was successful на всех
2. А вот, что дал dcdiag /q
There are warning or error events within the last 24 hours after the
SYSVOL has been shared. Failing SYSVOL replication problems may cause
Group Policy problems.
. DC2 failed test DFSREvent
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 08:41:34
The session setup from computer 'Alt-A306250' failed because the security database does not contain a trust account 'Alt-A306250$' referenced by the specified computer.
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 08:43:24
The session setup from the computer Alt-A14543 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 08:43:48
The session setup from the computer Alt-A306250 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 08:51:56
The session setup from the computer Alt-A8942 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x00003006
Time Generated: 01/16/2018 08:54:43
The SAM database was unable to lockout the account of Administrator due to a resource error, such as a hard disk write failure (the specific error code is in the error data) . Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above.
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 08:55:14
The session setup from computer 'Alt-A8942' failed because the security database does not contain a trust account 'Alt-A8942$' referenced by the specified computer.
An error event occurred. EventID: 0x00003006
Time Generated: 01/16/2018 08:58:47
The SAM database was unable to lockout the account of Administrator due to a resource error, such as a hard disk write failure (the specific error code is in the error data) . Accounts are locked after a certain number of bad passwords are provided so please consider resetting the password of the account mentioned above.
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 09:06:27
The session setup from computer 'Alt-A10900' failed because the security database does not contain a trust account 'Alt-A10900$' referenced by the specified computer.
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 09:06:37
The session setup from computer 'Alt-A21172' failed because the security database does not contain a trust account 'Alt-A21172$' referenced by the specified computer.
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 09:08:28
The session setup from the computer Alt-A10900 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 09:08:49
The session setup from the computer Alt-A21172 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 09:12:02
The session setup from computer 'Alt-A00323-VB' failed because the security database does not contain a trust account 'Alt-A00323-VB$' referenced by the specified computer.
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 09:14:05
The session setup from the computer Alt-A00323-VB failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 09:24:04
The session setup from computer 'Alt-A18166' failed because the security database does not contain a trust account 'Alt-A18166$' referenced by the specified computer.
An error event occurred. EventID: 0x000016AD
Time Generated: 01/16/2018 09:26:07
The session setup from the computer Alt-A18166 failed to authenticate. The following error occurred:
An error event occurred. EventID: 0x0000165B
Time Generated: 01/16/2018 09:26:23
The session setup from computer 'Alt-A306249' failed because the security database does not contain a trust account 'Alt-A306249$' referenced by the specified computer.
. DC2 failed test SystemLog
В журнале System ничего критичного: кто-то пытается перебором подобрать пароль Administrator'а (ищите вирус в сети) и какие-то компьютеры вывалились из домена. А вот в журнал службы DFS Replication стоит загянуть на всякий случай (хотя возможные там ошибки вряд ли могут служить причиной проблемы - они могут касаться только содержимого политик).
В журнале System ничего критичного: кто-то пытается перебором подобрать пароль Administrator'а (ищите вирус в сети) и какие-то компьютеры вывалились из домена. А вот в журнал службы DFS Replication стоит загянуть на всякий случай (хотя возможные там ошибки вряд ли могут служить причиной проблемы - они могут касаться только содержимого политик).
Слава России!
Только, что выловил данную проблему. При попытке сделать nslookup на проблемном сервере
1. По DC2 отрабоатло корректно
2. По DC2.domain.local отработало корректно
3. А вот по 172.16.100.12 *** UnKnown can't find 172.16.100.12: Non-existent domain
4. 172.16.100.13 отработало корректно -это DC3
5. По DC3 отрабоатло корректно и по DC3.domain.local
6. 172.16.100.9 отработало корректно -это DC5
7. По DC5 отрабоатло корректно и по DC5.domain.local
>3. А вот по 172.16.100.12 *** UnKnown can't find 172.16.100.12: Non-existent domain
Для работы AD разрешение IP-адресов в имена ("обратное разрешение") некритично, ибо не требуется. Но если вас это напрягает, добавьте нужную запись в зону обратного разрешения имён.
>3. А вот по 172.16.100.12 *** UnKnown can't find 172.16.100.12: Non-existent domain
Для работы AD разрешение IP-адресов в имена ("обратное разрешение") некритично, ибо не требуется. Но если вас это напрягает, добавьте нужную запись в зону обратного разрешения имён.
Слава России!
Это контролер домена и обратная запись для него имеется из начально.
Оставил ничего не делая на ночь проблемный сервер. Сегодня утром попробовал опять nslookup 172.16.100.12 он разрешися в имя. Почему вчера именно 172.16.100.12 не разрешался в имя на проблемно терминальном сервере, а сегодня разрешился- я не могу понять.
*** UnKnown can't find 172.16.100.12: Non-existent domain
> 172.16.100.12
Server: UnKnown
Address: 172.16.100.12
*** UnKnown can't find 172.16.100.12: Non-existent domain
> 172.16.100.12
Server: UnKnown
Address: 172.16.100.12
Name: dc2.domain.local
Address: 172.16.100.12
> 172.16.100.12
Server: UnKnown
Address: 172.16.100.12
Name: dc2.domain.local
Address: 172.16.100.12
Сегодня утром ещё один сервер перестал резолвить имена, но опять же не все. При запуске удаленного приложения, выходила ошибка, что не доступен сервер приложений, т.к. там зашито именно имя, длинное имя. Остановив клиента ДНС, разрешение снова заработало и приложение запустилось.
Как только опять включаю ДНС клиента имена разрешаются и короткие и длинные, НО пинг по короткому имени и по длинному не идёт! Только по адресу. И только на некоторые сервера так происходит. В данном случае на сервер приложений. Хотя они в одной подсети.
C:\Users\admin>ping app
Ping request could not find host app. Please check the name and try again.
C:\Users\admin>ping app
Ping request could not find host app. Please check the name and try again.
Pinging 172.16.100.2 with 32 bytes of data:
Reply from 172.16.100.2: bytes=32 time Reply from 172.16.100.2: bytes=32 time Reply from 172.16.100.2: bytes=32 time Reply from 172.16.100.2: bytes=32 time
C:\Users\admin>nslookup app
Server: dc2.domain.local
Address: 172.16.100.12
Name: ud4.domain.local
Address: 172.16.100.2
Aliases: app.domain.local
Ситуация следующая:
в локальной сети есть Windows 2003 Server, на нем работает служба DNS.
на все локальные машины по DHCP раздается его IP-адрес в качестве основного (и единственного) DNS.
Проблема:
Все машины, кроме собственно этого сервера, могут резолвить имена в ip-адреса.
Ответ от 213.180.204.8: число байт=32 время=270мс TTL=56
Ответ от 213.180.204.8: число байт=32 время=139мс TTL=56
.
Если же подобную операцию проделать на самом сервере, то МГНОВЕННО получаю ответ
server@C:\>ping -t comp1
При проверке связи не удалось обнаружить узел comp1. Проверьте имя узла и
повторите попытку.
Но по ip-адресу все прекрасно резолвится и, соответственно, пингуется:
C:\>ping -t 213.180.204.8
Обмен пакетами с 213.180.204.8 по с 32 байт данных:
Ответ от 213.180.204.8: число байт=32 время=141мс TTL=56
Ответ от 213.180.204.8: число байт=32 время=489мс TTL=56
.
Обмен пакетами с 192.168.0.1 по с 32 байт данных:
Ответ от 192.168.0.1: число байт=32 время Ответ от 192.168.0.1: число байт=32 время .
Вот конфигурация с сервера
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : server
Основной DNS-суффикс . . . . . . : lan
Тип узла. . . . . . . . . . . . . : неизвестный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : lan
NIC1 - Ethernet адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Generic Marvell Yukon Chipset based Gigabit Ethernet Controller
Физический адрес. . . . . . . . . : 00-0E-0C-3B-A0-3A
DHCP включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.0.253
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.0.254
DNS-серверы . . . . . . . . . . . : 192.168.0.253
Примечание: за день до появления этой проблемы на сервере пришлось сделать
netsh int ip reset
netsh winsock reset
и заново перенастроить ип-адреса.
Замечу также, что сам сервер с ДРУГИХ компьютеров резолвится по имени, т.е.
comp1@c:\>ping -t server
Обмен пакетами с server [192.168.0.253] по с 32 байт данных:
Ответ от 192.168.0.253: число байт=32 время Ответ от 192.168.0.253: число байт=32 время .
Команда nslookup, выполненная на сервере, тоже прекрасно работает:
server@C:\>nslookup
Default Server: server.lan
Address: 192.168.0.253
Также на сервере установлен mail-server (MDaemon), который прекрасно работает и отвечает как с и-нета, так и локально.
Просто в дальнейшем сетка полностью "перебазируется" на резолвинг только по DNS
Тут дело в другом - но в чём именно не ясно.
По идее такого быть не должно, но если работает у Jilted, тогда я вообще ничего не понимаю. Куда хоть копать?
Единственный момент, но о нём я упомянул еще в самом вопросе, так это
netsh int ip reset
netsh winsock reset
Я думаю что собака где-то здесь порылась и не признается
Там досутпно описано как это происходит, правда на английском. Но если в кратце, то поведение при резолве прямо зависит от Node Type. Но мы тут уже вяснили что в данном случае Node Type тут не при чем.
Здравствуйте. Есть машинка, на ней стоит свежая Win7 Максимальная x64, билд 7600 RU.
На ней с перебоями работает разрешение имен. Инет приходит через Ethernet от домашнего роутера (Acorp W422G_v3), к которому машинка цепляется по DHCP. DHCP наряду с айпишниками раздает клиентам адреса DNS-серверов в явном виде, то есть не relay самого роутера, а в моем случае OpenDNS (208.67.222.222, 208.67.220.220).
Аналогично не резолвятся имена в других приложениях.
Вывод ipconfig /all:
Я, если честно, не понимаю, как такое вообще возможно - разве механизм разрешения имен в ping и nslookup не один и тот же?
И да, пробовал прописать другие DNS (провайдерские, гугловский, и т.п.) - то же самое. Пробовал статически вписать DNS и айпишники - все равно то же самое.
Причем данная ситуация наблюдается случайным образом - иногда резолвинг работает, иногда нет. Подозреваю, что это что-то связанное со сбросом какого-либо кэша по времени (ARP, DNS), но не знаю куда копать. ipconfig /flushdns ничего не дает.
В Linux и WinXP все нормально работает.
Конфигурация компьютера | |
Процессор: Intel Core i7-3770K | |
Материнская плата: ASUS P8Z77-V LE PLUS | |
Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб) | |
HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб | |
Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS | |
Звук: Realtek ALC889 HD Audio | |
Блок питания: be quiet! Straight Power 11 650W | |
CD/DVD: ASUS DRW-24B5ST | |
Монитор: ASUS VG248QE 24" | |
ОС: Windows 8.1 Pro x64 | |
Индекс производительности Windows: 8,1 | |
Прочее: корпус: Fractal Design Define R4 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Петя, ю а май хиро.
В общем, дело не в ipv6 (ping -4 тоже не работает), дело в службе dnscache, которая, видимо, за каким-то дьяволом пытается резолвить имена через netbios, а не DNS.
По ссылке что вы дали, люди решили проблему, но у кого-то не работало, у кого-то работало. ну его нафиг.
Я поступил топорней - вырубил DNS-кэш нафиг (net stop dnscache), и пустил DNS-запросы через привычный dnsmasq на отдельной машине.
Проблема решена, хоть и костыльно, конечно.
Последний раз редактировалось mexico, 20-06-2010 в 01:08 .
mexico,
А серверов провайдера без всяких заморочек не хватает?
При чем тут netbios?
А серверов провайдера без всяких заморочек не хватает? » |
Не-а. Я и их ставил, не в них дело. Про UDP 53 не надо - азы же.
Поскольку у меня есть сторонний DNS-кэш на Linux, я не стал заморачиваться и искать причины (я не в ладах с вендой, да и время - деньги), а просто отключил виндовый кэш. Работает - и ладно.
Если предложите 100% работающий способ обойтись без этого костыля - буду только рад.
Последний раз редактировалось mexico, 20-06-2010 в 01:13 .
mexico,
Nslookup действительно кэш DNS не нужен.
2.Потом обычный запрос по имени www.yandex.ru получить IP адреса.
3.Получить полностью запись типа "А"
Вы получили -
При отключении windows кэша DNS вы заставляете лишний раз ПК клиента определять IP по мнемонике используя запросы по сети на ваш DNS (если они есть у него в кэше, то он просто их отправит), по времени это доли секунд.
Реестр по кэшу DNS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache
Здравствуйте. Есть машинка, на ней стоит свежая Win7 Максимальная x64, билд 7600 RU.
На ней с перебоями работает разрешение имен. Инет приходит через Ethernet от домашнего роутера (Acorp W422G_v3), к которому машинка цепляется по DHCP. DHCP наряду с айпишниками раздает клиентам адреса DNS-серверов в явном виде, то есть не relay самого роутера, а в моем случае OpenDNS (208.67.222.222, 208.67.220.220).
Аналогично не резолвятся имена в других приложениях.
Вывод ipconfig /all:
Я, если честно, не понимаю, как такое вообще возможно - разве механизм разрешения имен в ping и nslookup не один и тот же?
И да, пробовал прописать другие DNS (провайдерские, гугловский, и т.п.) - то же самое. Пробовал статически вписать DNS и айпишники - все равно то же самое.
Причем данная ситуация наблюдается случайным образом - иногда резолвинг работает, иногда нет. Подозреваю, что это что-то связанное со сбросом какого-либо кэша по времени (ARP, DNS), но не знаю куда копать. ipconfig /flushdns ничего не дает.
В Linux и WinXP все нормально работает.
Конфигурация компьютера | |
Процессор: Intel Core i7-3770K | |
Материнская плата: ASUS P8Z77-V LE PLUS | |
Память: Crucial Ballistix Tactical Tracer DDR3-1600 16 Гб (2 x 8 Гб) | |
HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб | |
Видеокарта: ASUS ROG-STRIX-GTX1080-O8G-11GBPS | |
Звук: Realtek ALC889 HD Audio | |
Блок питания: be quiet! Straight Power 11 650W | |
CD/DVD: ASUS DRW-24B5ST | |
Монитор: ASUS VG248QE 24" | |
ОС: Windows 8.1 Pro x64 | |
Индекс производительности Windows: 8,1 | |
Прочее: корпус: Fractal Design Define R4 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Петя, ю а май хиро.
В общем, дело не в ipv6 (ping -4 тоже не работает), дело в службе dnscache, которая, видимо, за каким-то дьяволом пытается резолвить имена через netbios, а не DNS.
По ссылке что вы дали, люди решили проблему, но у кого-то не работало, у кого-то работало. ну его нафиг.
Я поступил топорней - вырубил DNS-кэш нафиг (net stop dnscache), и пустил DNS-запросы через привычный dnsmasq на отдельной машине.
Проблема решена, хоть и костыльно, конечно.
Последний раз редактировалось mexico, 20-06-2010 в 01:08 .
mexico,
А серверов провайдера без всяких заморочек не хватает?
При чем тут netbios?
А серверов провайдера без всяких заморочек не хватает? » |
Не-а. Я и их ставил, не в них дело. Про UDP 53 не надо - азы же.
Поскольку у меня есть сторонний DNS-кэш на Linux, я не стал заморачиваться и искать причины (я не в ладах с вендой, да и время - деньги), а просто отключил виндовый кэш. Работает - и ладно.
Если предложите 100% работающий способ обойтись без этого костыля - буду только рад.
Последний раз редактировалось mexico, 20-06-2010 в 01:13 .
mexico,
Nslookup действительно кэш DNS не нужен.
2.Потом обычный запрос по имени www.yandex.ru получить IP адреса.
3.Получить полностью запись типа "А"
Вы получили -
При отключении windows кэша DNS вы заставляете лишний раз ПК клиента определять IP по мнемонике используя запросы по сети на ваш DNS (если они есть у него в кэше, то он просто их отправит), по времени это доли секунд.
Реестр по кэшу DNS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache
Читайте также: