LINUX.ORG.RU
Форум — Admin  

Странные проблемы с делегацией зоны DNS


0

0

Краткая предыстория: мой приятель переезжает со старого хостинга на новый. Чтобы самостоятельно разбираться с зоной, попросили переписать NS у регистратора на DNS-сервера нового хостинга, ну и на нем была заблаговременно создана соответствующая зона и настроен bind.

Теперь проблемы:

  • Уже четвертый день A разрешается в IP старого хостинга.
  • Если сначала запросить у любого dns-сервера SOA-запись, а затем A, то какое-то время отдается IP нового хостинга, затем опять старого.

Ну и собственно вопрос: Я правильно понимаю, что второе поле в описании зоны — это TTL, согласно которому DNS-сервера решают, сколько им кэшировать запись? Например: (выжимка из dig ya.ru +trace)

ya.ru.                  345600  IN      NS      ns5.yandex.ru.
ya.ru.                  345600  IN      NS      ns1.yandex.ru.
;; Received 98 bytes from 193.232.128.6#53(NS5.MSK-IX.NET) in 77 ms

означает, что должно пройти 345600 секунд (4 дня) прежде, чем из кэша серверов регистратора удалятся старые данные и вступят в силу новые? Просто, если это так, то именно этим проблемы и объясняются. Если нет, то помогите разобраться, пожалста.

★
← Загрузка сисетмы, после переноса её на новый диск.
opensuse 11.1 в виртуалке входит в домен, а на яву в домен не пускает требует рестарта винбинд. → 

Да, вот такой трейс сейчас:

$ dig +trace <domain>

; <<>> DiG 9.5.0-P2 <<>> +trace <domain>
;; global options:  printcmd
.                       415718  IN      NS      M.ROOT-SERVERS.NET.
.                       415718  IN      NS      D.ROOT-SERVERS.NET.
.                       415718  IN      NS      I.ROOT-SERVERS.NET.
.                       415718  IN      NS      H.ROOT-SERVERS.NET.
.                       415718  IN      NS      B.ROOT-SERVERS.NET.
.                       415718  IN      NS      G.ROOT-SERVERS.NET.
.                       415718  IN      NS      F.ROOT-SERVERS.NET.
.                       415718  IN      NS      A.ROOT-SERVERS.NET.
.                       415718  IN      NS      C.ROOT-SERVERS.NET.
.                       415718  IN      NS      L.ROOT-SERVERS.NET.
.                       415718  IN      NS      J.ROOT-SERVERS.NET.
.                       415718  IN      NS      K.ROOT-SERVERS.NET.
.                       415718  IN      NS      E.ROOT-SERVERS.NET.
;; Received 500 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms

ru.                     172800  IN      NS      NS9.RIPN.NET.
ru.                     172800  IN      NS      NS2.NIC.FR.
ru.                     172800  IN      NS      E.DNS.RIPN.NET.
ru.                     172800  IN      NS      SUNIC.SUNET.SE.
ru.                     172800  IN      NS      NS2.RIPN.NET.
ru.                     172800  IN      NS      NS.RIPN.NET.
ru.                     172800  IN      NS      NS5.MSK-IX.NET.
;; Received 324 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 264 ms

<domain>.               345600  IN      NS      ns2.<old_hosting>.
<domain>.               345600  IN      NS      ns1.<old_hosting>.
;; Received 101 bytes from 194.85.105.17#53(NS.RIPN.NET) in 73 ms

<domain>.               600     IN      A       <old_ip>
<domain>.               600     IN      NS      ns1.<new_hosting>.
<domain>.               600     IN      NS      ns2.<new_hosting>.
;; Received 89 bytes from 94.103.86.5#53(ns2.<old_hosting>) in 75 ms

xio ★
() автор топика
Ответ на: комментарий от xio

Если вы говорите о домене второго уровня в зоне ru, то при внесении изменний начинается тестирование, и пока оно не выполнится успешно, информация не меняется. То есть если опечатались в одном из доменных имен, или ns-сервера не в разных сетях класса-C или что ещё, информация не перепишется.

mky ★★★★★
()
Ответ на: комментарий от mky

Кстати говоря, да! Обе NS записи указывают на один и тот же ip-адрес... Изменения вносил не я, проверить другие детали вряд ли возможно. В .org просто разрешают 2 одинаковых ns, например, я как-то даже не подумал про это.

Если дело действительно в этом, где можно взять второй ns?

xio ★
() автор топика
Ответ на: комментарий от chocholl

ah, okay. Я хотел избежать конкретностей, ну да ладно.

домен: ukk29.ru, старый нс: ns[12].mchost.ru, новый нс: ns[12].ungrund.org

xio ★
() автор топика
Ответ на: комментарий от xio

жди

пока секонд левел сервера знают старое описание зоны
изменения не вступают в силу мгновенно не из-за кеша, а из за регламента работы регистратора.

andrey@wk3:~$ dig @a.root-servers.net +recurse +trace -t ns ukk29.ru

; <<>> DiG 9.5.0-P2 <<>> @a.root-servers.net +recurse +trace -t ns ukk29.ru
; (1 server found)
;; global options: printcmd
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
;; Received 500 bytes from 198.41.0.4#53(198.41.0.4) in 196 ms

ru. 172800 IN NS e.dns.ripn.net.
ru. 172800 IN NS ns.ripn.net.
ru. 172800 IN NS ns2.nic.fr.
ru. 172800 IN NS ns2.ripn.net.
ru. 172800 IN NS ns5.msk-ix.net.
ru. 172800 IN NS ns9.ripn.net.
ru. 172800 IN NS sunic.sunet.se.
;; Received 324 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 184 ms

ukk29.ru. 345600 IN NS ns1.mchost.ru.
ukk29.ru. 345600 IN NS ns2.mchost.ru.
;; Received 101 bytes from 193.232.142.17#53(e.dns.ripn.net) in 82 ms

ukk29.ru. 600 IN NS ns1.ungrund.org.
ukk29.ru. 600 IN NS ns2.ungrund.org.
;; Received 73 bytes from 94.103.80.5#53(ns1.mchost.ru) in 6 ms

chocholl ★★
()
Ответ на: комментарий от chocholl

ну и в чем же регламент? мне тут выше подсказали, что дело может быть в одинаковых ip у ns серваков -- в таком случае я могу еще долго ждать.

xio ★
() автор топика
Ответ на: комментарий от chocholl

근데... В данном конкретном выводе dig, почему NS ukk29.ru появляется 2 раза? А TTL 345600 у ns1.mchost.ru разве не означает 4 дня кэша, в принципе?

xio ★
() автор топика
Ответ на: комментарий от xio

TTL 345600 тут ни при чем.
а вот одинаковые ip адреса ns-ов действительно могут остановить процесс/проверку/регламент как хочешь называй.

chocholl ★★
()
Ответ на: комментарий от chocholl

ok, просто другие аспекты непонятны несколько

xio ★
() автор топика

Зарегистрировал slave на twisted4life.com, посмотрим, как пойдет дело дальше.

xio ★
() автор топика
Ответ на: комментарий от xio

Т.е. теперь у 2 ns'а для зоны с двумя разными адресами.

xio ★
() автор топика
Ответ на: комментарий от xio

twisted4life.com нафиг, ибо не поддерживает notify -- сделал на afraid.org, который, к тому же, еще и ixfr умеет.

Между делом нашел заслуживающий упоминания список бесплатных сервисов secondary dns: http://networking.ringofsaturn.com/Unix/freednsservers.php

xio ★
() автор топика

Ну что же, одни кхм... не очень грамотные люди из старого хостинга не знают, что нужно менять NS у регистратора, а не на своих серверах, не знают, как это сделать, даже если их об этом попросить, ошибаются при вводе 'nic.ru' в буке 'i' и забывают пароли от сервисов регистратора.

Так или иначе, теперь все нормально работает. Delay при изменении NS составляет 6 часов для зоны .ru, после чего свежие данные становятся видны по whois, а также начинает обновляться кэш остальных серверов.

xio ★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Загрузка сисетмы, после переноса её на новый диск.
Admin
opensuse 11.1 в виртуалке входит в домен, а на яву в домен не пускает требует рестарта винбинд. →