Jump to content
Калькуляторы

TTL на корневых DNS-серверах не соответствует желаемым

В последнее время часто стали обращаться пользователи, держащие свои домены второго уровня и переехавшие с одного хостинга на другой. Жалуются, что через день-два после переезда наш 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-ов?

 

Share this post


Link to post
Share on other sites

Можете пояснить, что именно вы спрашиваете у dig?

А я вам поясню, что вы делаете не так.

Share this post


Link to post
Share on other sites

смотрю 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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Я пока периодически вынужден делать принудительную очистку кеша - rndc flush.

Раньше такой проблемы не было. а последние где-то пол-года-год - пользователи стали жаловаться...

Может поменяли политику на "корневых" для домена ru серверах, никто не в курсе?

 

Share this post


Link to post
Share on other sites

1. TTL на корневых зонах уже 10 лет стоит на 4 суток.

2. По моему вы смотрите разные TTL.

В корневой зоне, вы видите то, что прописано согласно WHOIS. Т.е. те записи, которые внесены в NS серверах у Регистратора домена. И TTL там выставляет администратор зоны RU.

Когда вы запрашиваете непосредственно зону 2 уровня, то вы получаете TTL, который прописан у самого владельца этой зоны.

Никто не обещал, что эти TTL должны совпадать.

 

В связи с этим у меня был однажды очень серьезный казус. Важный клиент не успел продлить зону, и ru-center успел изменить NS записи на свои. Когда клиент продлил домен, то еще 4 дня сосал лапу, ибо домен был очень популярен и в кеши провайдеров успели сохраниться измененные записи. Было примерно в 2004 году.

 

Если я не прав, поправьте.

Share this post


Link to post
Share on other sites

Еще добавлю.

NS записи в домене mail.ru носят чисто информационный характер и не более.

Когда вы дергаете зону mail.ru, ваш клиент все равно лезет в RU, и только там получает списки NS для зоны mail.ru.

Можете в самой зоне mail.ru вообще удалить упоминания об NS, но зона работать будет.

 

Можете проверить на любой тестовой зоне.

Share this post


Link to post
Share on other sites

Это было, если не всегда, то лет 10 точно, если даже не больше, чем 4 дня. В зоне .ru TTL 4 дня. в .com 2 дня (раньше 100% в коме было больше) По хорошему, на старом месте надо бы выложить новую зону, а через недельку убрать совсем. И все будет чики поки. Но кто ж думает о последствиях при переезде. Народ умудряется при TTLе в сутки на www.домен.рю менять DNS и через 10 минут удивляться, что заходит на старый сервер... "Но я-ж поменял же-ж"..

Share this post


Link to post
Share on other sites

Спорить не буду - возможно, что на серверах домена .ru всегда было 4 суток. не обращал внимание.

Просто мне казалось, что таких проблем раньше не было и зоны можно было переносить на другие адреса вполне быстро и без простоя, если заранее выставить достаточно малый TTL. Наверное поэтому думал, что на .ru-шных серверах TTL-ы повторяли те, которые указывали у себя праймари сервера доменов второго уровня. С точки зрения управления анонсами и предупреждения проблем, подобных той, которая была у клиента dewil'а, это было бы вполне оправдано.

 

 

Share this post


Link to post
Share on other sites

Может быть кто-нибудь знает как переопределить(override) этот ttl в бинде? Т.е. чтобы bind при получении ttl больше суток, автоматически уменшьшал его до 24 часов, например.

Share this post


Link to post
Share on other sites

В настройках BIND можно сказать так:

max-cache-ttl 86400

И не надо будет делать постоянно rndc flush.

Share this post


Link to post
Share on other sites

mschedrin

Можно просто сбрасывать кеш каждую ночь, ничего страшного в этом нет

 

Share this post


Link to post
Share on other sites

А причём ту сервера зоны ру!?

 

http://www.netlab.linkpc.net/download/software...l/DNSLookup.exe

Качаете, ставите RD, CD, Disable internal cache

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

 

Корневая зона ссылается на зону ру, та ссылается на авторитетные сервера для конкретных имён. Иногда встречаются петли...

 

 

Может быть кто-нибудь знает как переопределить(override) этот ttl в бинде? Т.е. чтобы bind при получении ttl больше суток, автоматически уменшьшал его до 24 часов, например.
Если оно вам так мешает меняйте бинд на то что умеет, либо пусть бинд резолвит через то что умеет, если такового нет - смиритесь или сами напишите.

Могу дать готовый "фреймворк"=набор функций который будет разбирать и собирать днс пакеты, на сях, с примерами. Эта программа на нём и написана.

Тупо патчить биты/байты там не получится.

 

 

PS: у сибирь телекома проблема тоже со старым кешем, недавно появилась.

У меня DynDNS, там ттл минуту, а мне отдаются записи хз сколько дней назад давности.

Я просто сменил ДНС на днс с рекрсией каких то американских провайдеров и вроде цискины, гугль не стал юзать, не внушает доверия, опенднс парит рекламой.

Edited by Ivan_83

Share this post


Link to post
Share on other sites

Есть такой хинт. Не использовать для клиентских доменов glue ns-ы.

И все будет работать так как и должно.

Траблы эти возникают, только если NS приклеен внутри домена, если NS - внешний по отношению к домену или даже к TLD, то никаких проблем.

 

Share this post


Link to post
Share on other sites
Есть такой хинт. Не использовать для клиентских доменов glue ns-ы.

И все будет работать так как и должно.

Траблы эти возникают, только если NS приклеен внутри домена, если NS - внешний по отношению к домену или даже к TLD, то никаких проблем.

Кстати, очень правильное замечание.

Давно так сделал.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this