☰

Почему bind медленнее, чем публичные DNS-провайдеры

tag-icon • tag-icon bind
Почему bind медленнее, чем публичные DNS-провайдеры

У нас есть bind 9.8.1.dfsg.P1-4ubuntu0.13 в Ubuntu 12.04, который работает на не сильно загруженном сервере (средняя нагрузка: 0,19, 0,12, 0,13) и обслуживает запросы для небольшой офисной сети с рабочими станциями MacOS и Ubuntu.

Я запустил несколько тестов DNS в скрипте на контейнере, который работает как сервер DNS, и отправил результаты в influxdb.

#!/bin/bash
while true
do
        rndc flush

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=yes value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=yes value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=yes value=$yandex_timeout" &
        wait

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=no value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=no value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=no value=$yandex_timeout" &
        wait

        sleep 5
done

Я обнаружил, что bind отвечает на запросы медленнее, чем8.8.8.8и77.88.8.8. Это можно увидеть на графиках:

Очистка кэша перед первой серией запросов с помощью rndc flush. Bind использует google8.8.8.8и8.8.4.4в качестве экспедиторов:

введите описание изображения здесь

Никогда не очищайте кэш запущенного bind. Bind использует google8.8.8.8и8.8.4.4в качестве экспедиторов:

введите описание изображения здесь

Очистка кэша перед первой серией запросов с помощью rndc flush. Bind использует обновленный список корневых серверов в качестве пересылок:

введите описание изображения здесь

Никогда не очищайте кэш запущенного bind. Bind использует обновленный список корневых серверов в качестве пересылок:

введите описание изображения здесь

Почему максимальное время запроса (около 5 тыс. на первом графике и 2,5 тыс. на третьем графике) с общедоступными DNS-серверами Google больше, чем у корневых серверов?

Почему запрос через bind медленнее, чем прямой запрос к публичным DNS-серверам?

Может быть, в моих тестах что-то не так?

ОБНОВЛЕНИЕ 1

На графиках указано TTL 20 сек. - это неверно. TTL для redhat.com составляет 60 сек.

решение1

Ваши тесты измеряют общее время выполнения вашего запроса, включая

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

Результаты во многом соответствуют ожиданиям.

  • Если вы запрашиваете локальный сервер BIND без очистки кэша, ответ в большинстве случаев будет приходить из кэша. Даже если TTL для A RR истек, NS RR все еще будет в кэше, поэтому только сам A RR должен быть запрошен извне.
  • Если вы делаете запрос на локальный сервер BIND после очистки кэша и у вас естьнетнастроенных пересылок, ваш локальный сервер BIND будет выполнять рекурсивный запрос, начиная с корневого сервера и далее вниз.
  • Если вы запрашиваете ваш локальный сервер BIND после очистки кэша и настроили серверы Google как пересылающие, ваш локальный сервер BIND перешлет запрос как есть на один из серверов Google, который затем, в свою очередь, либо ответит на запрос из своего кэша, либо выполнит рекурсивный запрос. Обратите внимание, что вы не можете контролировать кэш серверов Google.

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

Связанный контент