Назад | Перейти на главную страницу

DNS сломан после включения очистки

В прошлую пятницу я включил очистку DNS на одном из контроллеров домена. Это было сделано с целью удаления старых неиспользуемых записей A со списанных компьютеров. Однако оказалось, что наш DHCP (предоставляемый оборудованием Meraki) был неправильно настроен и не передавал информацию обратно в DNS, поэтому компьютеры обычно создавали записи A только при первом присоединении к домену. В связи с этим после субботней уборки было удалено 600 из 900 записей A. Но я спрашиваю не об этом.

Фактическая проблема заключается в том, что после запуска DNS Scavenging ряд компьютеров не смогли получить доступ к внутренним ресурсам по имени. В основном это коснулось ноутбуков удаленных сотрудников, которые подключаются к нашей VPN, но у нас также были ноутбуки, которые никогда не покидали нашу корпоративную сеть, а также один сервер. Некоторые более точные симптомы:

Затронутые компьютеры не могут пинговать ни один из наших серверов по имени, возвращая сообщение об ошибке «Запрос Ping не может найти хост x. Проверьте имя и повторите попытку». Запуск wirehark показывает, что ping инициирует запрос DNS, который возвращает результат «стандартный ответ на запрос 0x8182, сбой сервера». Затронутые компьютеры могут запускать nslookup на любом из наших серверов, получая обратно свое имя и IP-адрес. Затронутые компьютеры могут пинговать любой из наших серверов по IP-адресу. У затронутых компьютеров записи A были удалены из DNS, но у многих компьютеров были удалены записи A, и они продолжали нормально работать. Внешний DNS отлично работает на пораженных компьютерах. Запуск ipconfig / registerdns с пораженного компьютера не создает новую запись зоны прямого просмотра A.

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

Попытки исправить:

Выполнение различных команд для очистки сетевых настроек от затронутых компьютеров: ipconfig / flushdns, ipconfig / registerdns, ipconfig / release, ipconfig / refresh, netsh winsock reset catalog, netsh int ip reset reset.log, route / f. Помимо перезапусков, ничего из этого не изменило проблему. Перейдите к зараженному компьютеру в AD и нажмите Сбросить учетную запись. Это тоже не изменилось. Многократный перезапуск контроллеров домена - без изменений. Включение ведения журнала отладки DNS - это показывает, что внутренние запросы DNS от затронутых компьютеров возвращают сообщения с RCODE, равным 2, что указывает на сбой сервера. См. В конце полный пример пакета. Обновлены динамические обновления зоны прямого просмотра, чтобы разрешить небезопасные и безопасные обновления. - Без изменений. Мы создали новый контроллер виртуального домена server 2016 в Azure и перенастроили DHCP, чтобы некоторые затронутые компьютеры использовали его в качестве основного DNS-сервера. - После этого зараженные компьютеры, использующие его в качестве своего DNS-сервера, создают новые записи A в DNS. Они по-прежнему не могут получить доступ к сетевым ресурсам по имени.

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

Пример возврата DNS-пакета:

5/15/2018 9:11:07 AM 17CC PACKET 00000211E32038A0 UDP Snd 10.2.151.35   aa53 R Q [8281 DR SERVFAIL] A     (7)dcazure(0)
UDP response info at 00000211E32038A0
  Socket = 724
  Remote addr 10.2.151.35, port 50641
  Time Query=40319, Queued=0, Expire=0
  Buf length = 0x0fa0 (4000)
  Msg length = 0x0019 (25)
  Message:
    XID     0xaa53
    Flags   0x8182
      QR       1 (RESPONSE)
      OPCODE   0 (QUERY)
      AA       0
      TC       0
      RD       1
      RA       1
      Z       0
      CD       0
      AD       0
      RCODE   2 (SERVFAIL)
    QCOUNT   1
    ACOUNT   0
    NSCOUNT 0
    ARCOUNT 0
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name     "(7)dcazure(0)"
      QTYPE A (1)
      QCLASS 1
    ANSWER SECTION:
      empty
    AUTHORITY SECTION:
      empty
    ADDITIONAL SECTION:
      empty

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