MagMike Опубликовано 4 октября, 2010 · Жалоба В последнее время часто стали обращаться пользователи, держащие свои домены второго уровня и переехавшие с одного хостинга на другой. Жалуются, что через день-два после переезда наш dns-сервер отдает старые адреса либо что вообще ничего не возвращает. При разборе обнаружил, что серверы, отвечающие за домен ru, во всех записях NS доменов второго уровня выдают TTL 345600 (4 суток). при этом авторитетные dns-серверы выдают гораздо меньший TTL. вот, для примера, dig +trace -t ns ya.ru ... ya.ru. 345600 IN NS ns5.yandex.ru. ya.ru. 345600 IN NS ns1.yandex.ru. ;; Received 98 bytes from 194.85.252.62#53(ns9.ripn.net) in 38 ms ya.ru. 7200 IN NS ns5.yandex.ru. ya.ru. 7200 IN NS ns1.yandex.ru. ;; Received 98 bytes from 213.180.193.1#53(ns1.yandex.ru) in 45 ms т.е. яндексовские dns-ы выдают TTL 7200, а ns9.ripn.net (один из 7ми серверов, обслуживающих .ru) сообщает 345600 Из-за такого дикого ТТЛ и возникают проблемы - мой dns, закешировав положительный ответ незадолго до миграции домена, продолжает обращаться за данными домена к старым днс еще в течение 4 суток, получая в ответ устаревшие данные или NXDOMAIN Раньше, насколько я помню, не было проблем при миграции доменов на другие серверы. предварительно можно было поставить достаточно небольшой TTL и миграция проходила быстро и безболезненно. кто-то уже сталкивался с этим? как-то можно повлиять на TTL на ru-шных DNS-ов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dewil Опубликовано 4 октября, 2010 · Жалоба Можете пояснить, что именно вы спрашиваете у dig? А я вам поясню, что вы делаете не так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 4 октября, 2010 · Жалоба смотрю TTL, который выдают серверы, обслуживающие зону .ru, и TTL, который указаны для NS-записей на dns-серверах, обслуживающих конкретную зону второго уровня. попробую более разжеванно. странно, но сейчас и ns5.yandex.ru отвечает с TTL 345600 Поэтому возьму другой домен - mail.ru. запрашиваю NS-запись для домена mail.ru у сервера ns9.ripn.net dig -t ns mail.ru @ns9.ripn.net получаю ;; AUTHORITY SECTION: mail.ru. 345600 IN NS ns5.mail.ru. mail.ru. 345600 IN NS ns1.mail.ru. mail.ru. 345600 IN NS ns3.mail.ru. mail.ru. 345600 IN NS ns.mail.ru. mail.ru. 345600 IN NS ns2.mail.ru. mail.ru. 345600 IN NS ns4.mail.ru. ;; ADDITIONAL SECTION: ns.mail.ru. 345600 IN A 94.100.178.70 ns1.mail.ru. 345600 IN A 94.100.179.159 ns2.mail.ru. 345600 IN A 94.100.186.189 ns3.mail.ru. 345600 IN A 94.100.178.66 ns4.mail.ru. 345600 IN A 94.100.178.64 ns5.mail.ru. 345600 IN A 94.100.178.54 т.е. если верить самому ns9.ripn.net, NS-записи ссылаются на ns[1-5].mail.ru. при этом TTL для этих записей - 345600. если тут же запросить непосредственно один из мэйлуршных DNS-серверов, dig -t ns mail.ru @ns1.mail.ru получаю ответы с TTL 3600: ;; ANSWER SECTION: mail.ru. 3600 IN NS ns4.mail.ru. mail.ru. 3600 IN NS ns.mail.ru. mail.ru. 3600 IN NS ns3.mail.ru. mail.ru. 3600 IN NS ns5.mail.ru. mail.ru. 3600 IN NS ns2.mail.ru. mail.ru. 3600 IN NS ns1.mail.ru. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 4 октября, 2010 · Жалоба Я тоже часто сталкиваюсь с такой же проблемой. При смене ns записей, они обновляются только на четвертые сутки. Как решить эту проблему пока не придумал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 4 октября, 2010 · Жалоба Я пока периодически вынужден делать принудительную очистку кеша - rndc flush. Раньше такой проблемы не было. а последние где-то пол-года-год - пользователи стали жаловаться... Может поменяли политику на "корневых" для домена ru серверах, никто не в курсе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 4 октября, 2010 · Жалоба По-моему TTL для .ru всегда в пределах 4 суток был Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dewil Опубликовано 4 октября, 2010 · Жалоба 1. TTL на корневых зонах уже 10 лет стоит на 4 суток. 2. По моему вы смотрите разные TTL. В корневой зоне, вы видите то, что прописано согласно WHOIS. Т.е. те записи, которые внесены в NS серверах у Регистратора домена. И TTL там выставляет администратор зоны RU. Когда вы запрашиваете непосредственно зону 2 уровня, то вы получаете TTL, который прописан у самого владельца этой зоны. Никто не обещал, что эти TTL должны совпадать. В связи с этим у меня был однажды очень серьезный казус. Важный клиент не успел продлить зону, и ru-center успел изменить NS записи на свои. Когда клиент продлил домен, то еще 4 дня сосал лапу, ибо домен был очень популярен и в кеши провайдеров успели сохраниться измененные записи. Было примерно в 2004 году. Если я не прав, поправьте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dewil Опубликовано 4 октября, 2010 · Жалоба Еще добавлю. NS записи в домене mail.ru носят чисто информационный характер и не более. Когда вы дергаете зону mail.ru, ваш клиент все равно лезет в RU, и только там получает списки NS для зоны mail.ru. Можете в самой зоне mail.ru вообще удалить упоминания об NS, но зона работать будет. Можете проверить на любой тестовой зоне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 4 октября, 2010 · Жалоба Это было, если не всегда, то лет 10 точно, если даже не больше, чем 4 дня. В зоне .ru TTL 4 дня. в .com 2 дня (раньше 100% в коме было больше) По хорошему, на старом месте надо бы выложить новую зону, а через недельку убрать совсем. И все будет чики поки. Но кто ж думает о последствиях при переезде. Народ умудряется при TTLе в сутки на www.домен.рю менять DNS и через 10 минут удивляться, что заходит на старый сервер... "Но я-ж поменял же-ж".. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 4 октября, 2010 · Жалоба Спорить не буду - возможно, что на серверах домена .ru всегда было 4 суток. не обращал внимание. Просто мне казалось, что таких проблем раньше не было и зоны можно было переносить на другие адреса вполне быстро и без простоя, если заранее выставить достаточно малый TTL. Наверное поэтому думал, что на .ru-шных серверах TTL-ы повторяли те, которые указывали у себя праймари сервера доменов второго уровня. С точки зрения управления анонсами и предупреждения проблем, подобных той, которая была у клиента dewil'а, это было бы вполне оправдано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 5 октября, 2010 · Жалоба Может быть кто-нибудь знает как переопределить(override) этот ttl в бинде? Т.е. чтобы bind при получении ttl больше суток, автоматически уменшьшал его до 24 часов, например. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fedusia Опубликовано 5 октября, 2010 · Жалоба В настройках BIND можно сказать так: max-cache-ttl 86400 И не надо будет делать постоянно rndc flush. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 5 октября, 2010 · Жалоба mschedrin Можно просто сбрасывать кеш каждую ночь, ничего страшного в этом нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 октября, 2010 (изменено) · Жалоба А причём ту сервера зоны ру!? http://www.netlab.linkpc.net/download/software...l/DNSLookup.exe Качаете, ставите RD, CD, Disable internal cache вбиваете домен и днс сервер, по умолчанию вроде один из коневых, жмёте квери и получаете полный лог в человечьем формате ответов от днс серверов, начиная с корневого/указанного и заканчивая сервером, который отвечает за указанное имя/зону. Корневая зона ссылается на зону ру, та ссылается на авторитетные сервера для конкретных имён. Иногда встречаются петли... Может быть кто-нибудь знает как переопределить(override) этот ttl в бинде? Т.е. чтобы bind при получении ttl больше суток, автоматически уменшьшал его до 24 часов, например. Если оно вам так мешает меняйте бинд на то что умеет, либо пусть бинд резолвит через то что умеет, если такового нет - смиритесь или сами напишите.Могу дать готовый "фреймворк"=набор функций который будет разбирать и собирать днс пакеты, на сях, с примерами. Эта программа на нём и написана. Тупо патчить биты/байты там не получится. PS: у сибирь телекома проблема тоже со старым кешем, недавно появилась. У меня DynDNS, там ттл минуту, а мне отдаются записи хз сколько дней назад давности. Я просто сменил ДНС на днс с рекрсией каких то американских провайдеров и вроде цискины, гугль не стал юзать, не внушает доверия, опенднс парит рекламой. Изменено 7 мая, 2011 пользователем Ivan_83 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ainy Опубликовано 5 октября, 2010 · Жалоба Есть такой хинт. Не использовать для клиентских доменов glue ns-ы. И все будет работать так как и должно. Траблы эти возникают, только если NS приклеен внутри домена, если NS - внешний по отношению к домену или даже к TLD, то никаких проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dewil Опубликовано 6 октября, 2010 · Жалоба Есть такой хинт. Не использовать для клиентских доменов glue ns-ы.И все будет работать так как и должно. Траблы эти возникают, только если NS приклеен внутри домена, если NS - внешний по отношению к домену или даже к TLD, то никаких проблем. Кстати, очень правильное замечание. Давно так сделал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
