Кэширование “Яндекс.DNS”

ScaleВажнейшая архитектурная особенность DNS – кэширование адресной информации. Рекурсивные кэширующие резолверы должны некоторое время сохранять полученные из DNS ответы и, – вместо того, чтобы снова отправлять запрос на авторитативный сервер, – отвечать данными из кэша. Это оптимизирует нагрузку на систему в целом. Организация “сквозного” кэширования для групп резолверов представляет собой непростую задачу. Я посмотрел, как обстоит дело с кэшем у широко анонсированной бета-версии “Яндекс.DNS“.

Методика проверки простая: заводим специальную доменную зону, вносим в неё отдельную запись, предназначенную для тестирования, после чего запрашиваем значение этой записи через сервис “Яндекса” и смотрим в логи авторитативного сервера имён (NS). Так как это тест, а зона третьего уровня, то авторитативный сервер – один. DNS так устроена, что хотя бы один раз какой-то сервер “Яндекса” должен прийти к нам с запросом.

Беда в том, что “Яндекс” пришёл далеко не один раз, не дождавшись истечения TTL (“время жизни” ответа, управляющее продолжительностью нахождения данных в кэше). Можно предположить, как всё это устроено на стороне “Яндекса”: используется группа серверов-резолверов (часть из них имеет адреса из диапазона 213.180.200.240/29), с раздельными кэшами, балансировка входящих запросов не учитывает состояние кэшей, взятое относительно источника запроса. То есть, пока каждый резолвер не загрузит данные, требуемые для ответа на запрос, вероятность попасть в кэш мала. Дело в том, что последовательные запросы отрабатывают разные резолверы: хорошо видно, как они повторно приходят на NS до истечения TTL.

Результат: кэширование реализовано вне традиций DNS. Одинаковые повторные запросы даже для одного и того же клиента, до истечения TTL, постоянно уходят на авторитативные серверы, что прямо противоречит смыслу существования подобного “кэширующего” резолвера (DNS-сервера), а в случае распространения “Яндекс.DNS”, создаёт ненужную дополнительную нагрузку, то есть заметно ухудшает ситуацию: вместо одного запроса провайдерского резолвера получаем несколько (пять-десять) запросов от “Яндекса”.

(Да, Google Public DNS кэширует правильно, повторно раньше времени не приходит.)

Думаю, в “Яндексе” есть объяснение, почему так сделано. Но сделано некрасиво. Даже для бета-версии.

Адрес записки: https://dxdt.ru/2013/04/05/5676/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 6

  • 1 <t> // 5th April 2013, 15:00 // Читатель jno написал:

    “авторитативный” по-русски – “авторитетный” :)

  • 2 <t> // 5th April 2013, 15:31 // Читатель Влад написал:

    Вполне нормально сделано, особенно для беты.

    Кэширование – не функциональное требование, а оптимизация, и может не производиться, если по каким-то причинам разработчик решит этого не делать.

    Москва не сразу строилась.

  • 3 <t> // 5th April 2013, 16:04 // Александр Венедюхин:

    Для подобного сервиса кэширование – именно строгое функциональное требование. И оно у них реализовано, я проверил. Но реализовано криво. Вот смотрите: клиент ходит на один сервисный IP-адрес A; внутри сервиса запросы клиента отправляются на один из узлов, который (сам или через посредника, не важно) дёргает авторитативный сервер, если нет данных в кэше; следующий запрос от того же клиента, отправленный на _тот_же_ входной IP-адрес А, попадает у них на другой внутренний узел, который опять дёргает авторитативный сервер, несмотря на то, что только что была возможность закэшировать ответ, ну и так далее. Это криво. На дворе 21-й век, а они кэш не могут объединить. (Да, понятно, конечно, что можно свалить кэширование на клиента. И, естественно, разработчик сервиса сам себе буратино, может и ответы портить, и не кэшировать, и вообще всячески развлекаться. Вот только печально, что это “развлечение” идёт со стороны “Яндекса”.)

  • 4 <t> // 5th April 2013, 18:20 // Читатель leo написал:

    То, как это работает сейчас, пока кэширование (или хеширование :) у яндекса не доделано, особых проблем не вызовет. Представим N клиентов сидящих через N провайдеров. Если клиенты обратяться к малопопулярной зоне – сервер, отвечающий за эту зону получит N запросов. Это нормально. И в случае с яндексом – сервер отвечающий за зону не получит больше запросов, чем количество клиентов, запросивших эту самую зону. При этом кэширование какое-никакое,но всё-таки есть – один и тот же сервер всё же использует инфу о ttl зоны.

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

  • 5 <t> // 28th April 2013, 21:33 // Читатель skystart написал:

    Действительно, меня тоже удивило качество работы Яндекс ДНС. Вроде бы не самое сложное из их проектов ).
    Еще одим момент. Сервис не переваривает поддомен new. Любой другой- пожалуйста, а этот добавляется но не резолвится. Такая вот развлекуха. По крайней мере, так обстоят дела на моем аккаунте. Супорт среагировал тоже неожиданным образом. Проблему увидели только попытки с третьей, решение не предвидится (ИМХО).

  • 6 <t> // 28th April 2013, 21:53 // Читатель skystart написал:

    …немного пардон за небольшой оффтоп. Постом выше я написал про использование Яндекса.DNS как авторитативного.