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

Проблемы с изменением домена BIND DNS для записи домена

В BIND у меня есть запись для домена, указывающего на старый сервер и IP. Этой машины больше не существует. Когда я делаю изменение, чтобы указать на новый сервер, nslookup по-прежнему показывает старое значение для предыдущего сервера. Я изменил запись www в прошлый четверг (это вторник на следующей неделе), но запись все еще не кэшируется / не распространяется и по-прежнему показывает старую запись. Я восстановил домен, удалив предыдущий, но я все еще вижу старую запись в NSLOOKUP. Я готов подождать некоторое время, чтобы позволить ему кэшироваться. Есть ли другой способ заставить это указывать на соответствующий рабочий адрес, а не на старый?

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

Общий порядок операций по внесению изменений в вашу службу имен и последующей проверке того, что все прошло по плану, выглядит примерно так (обратите внимание: список ниже не охватывает зоны с включенными динамическими обновлениями, которые дополнительно потребуют шагов замораживания и размораживания, если вы вручную редактируют главный файл зоны, а не используют nsupdate для внесения изменений)

  1. Сделайте резервные копии файлов старых зон на случай, если что-то пойдет не так.
  2. Внесите запланированные изменения в файл (ы) зоны, уделяя особое внимание убедитесь, что серийный номер в записи SOA правильно обновлен для каждой редактируемой зоны.
  3. Просмотрите изменения, внесенные вами в файл зоны. На этом этапе не помешает запустить named-checkzone, чтобы гарантировать отсутствие синтаксических ошибок при редактировании. Также, будьте начеку на случай непреднамеренно пропущенных конечных точек в конце FQDN, это наиболее распространенный тип ошибки редактирования зоны, и это допустимый синтаксис, поэтому named-checkzone и / или сервер не будет отмечать это за вас.
  4. Заставьте зону перезагрузиться, используя любой из «rndc reload», «rndc reconfig» или перезапуск с именем, который кажется наиболее подходящим для ваших обстоятельств.
  5. Проверьте контент, обслуживаемый главным сервером имен, с помощью целевого поиска (например, «dig @ masternameserver.example.org zone.name. Soa»), чтобы убедиться, что зона правильно загружена и обслуживаемая версия имеет новый серийный номер.
  6. Найдите в файлах журнала на главном и / или подчиненном устройстве доказательства того, что сообщения уведомления были отправлены подчиненным и что подчиненные устройства инициировали передачу содержимого новой зоны посредством AXFR или IXFR.
  7. Используйте целевое копание на подчиненных серверах, чтобы проверить, что подчиненные серверы теперь обслуживают правильную копию данных зоны (проверьте SOA и проверьте записи, которые вы добавили или удалили).
  8. Подождите, пока данные зоны полностью распространятся. Подчиненные серверы, которые не получают уведомления, могут ждать до $ refresh секунд, прежде чем проверять SOA, чтобы увидеть, доступны ли новые данные зоны. Другие серверы, находящиеся вне вашего контроля, могут кэшировать старые данные зоны в течение периода времени до значения TTL, установленного для зоны (и несоответствующие серверы имен могут установить минимальное значение, определяющее, насколько низкое значение TTL, которое они примут, которое выше, чем TTL вы действительно выбрали.)

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

С участием dig это делается так:

dig @ns1.example.com oldentry.example.com

С участием nslookup это делается так:

nslookup oldentry.example.com ns1.example.com

Что касается попытки решить вашу проблему, мы можем только догадываться, потому что все, что вы нам сказали, было: «Я изменил это, но это не изменилось».

Если вы добавите свою актуальную конфигурацию к вопросу, у нас может быть шанс. Если вы не можете этого сделать, Bind любит регистрировать ошибки и продолжать попытки загрузить остальные файлы зоны или записи. Например, удаление строки ns2 из файла зоны приводит к тому, что это регистрируется:

Feb 18 18:47:34 dns01 named[22465]: zone example.com/IN: NS 'ns2.example.com' has no address records (A or AAAA)
Feb 18 18:47:34 dns01 named[22465]: zone example.com/IN: not loaded due to errors.

Но Bind все равно запустится и загрузит все остальные файлы зоны. Я не совсем уверен, как он ведет себя при неправильном синтаксисе, игнорирует ли он эту запись или весь файл зоны. Просмотрите свои журналы (это было в daemon.log) для всего, что связано с named.)

Некоторые другие догадки:

  1. Вы перезапускали Bind?
  2. Вы забыли трейлинг. для записи CNAME?
  3. Вы дважды проверяли, действительно ли Bind использует файлы, которые вы редактировали?
  4. Вы просмотрели все файлы зоны с помощью команды grep для поиска IP-адреса?