У меня неточность в задержке запроса. Это не проблема, это достаточно странно, чтобы меня беспокоить.
Оба подключены к одному домашнему маршрутизатору. Однако сервер может обрабатывать некэшированные запросы почти в два раза быстрее. Я совсем не этого ожидал! Сервер представляет собой ARM (sheevaplug) с тактовой частотой 1 ГГц, а клиентский компьютер - это Intel Core Duo с тактовой частотой 2,1 ГГц.
Оба экземпляра проверяют DNSSEC. Они возвращают SERVFAIL для www.dnssec-failed.org. Оба настроены на использование одних и тех же кешей DNS в восходящем направлении от моего интернет-провайдера.
Все, о чем я могу думать до сих пор, - это проблема с NAT. Маршрутизатор настроен с сервером как «DMZ по умолчанию», то есть он получает все пакеты, на которые никто не претендует, именно так я запускаю общедоступные службы, такие как SSH и bittorrent :). Или ... может быть, второстепенная версия 19 каким-то образом проверяет более строго, чем второстепенная версия 17?
Методология тестирования: разрешение 10 несуществующих поддоменов .de. (Должен вызвать промахи кеша ISP). .De. TLD предварительно загружается путем запроса Yahoo.
Со стороны клиента
$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig twitter$i.de.) | grep Query; done
Result - mean 120ms, stddev 60ms
Со стороны сервера
$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig aldi$i.de. ) | grep Query; done
Result - mean 70ms, stddev 50ms
Я знаю, что тест выглядит не очень хорошо, и моя статистика не может служить убедительным доказательством. Но я попробовал еще несколько раз, и ничего не изменилось.
Ах! Я просто различал unbound.conf между двумя компьютерами. Кажется, что Fedora включает опцию ниже. Отключение позволяет избавиться от дополнительной задержки на машине Fedora.
# Harden the referral path by performing additional queries for
# infrastructure data. Validates the replies (if possible).
# Default off, because the lookups burden the server. Experimental
# implementation of draft-wijngaards-dnsext-resolver-side-mitigation.
harden-referral-path: yes
Придется поискать это и решить, хочу ли я его использовать :).
Ссылка на сайт: https://datatracker.ietf.org/doc/draft-wijngaards-dnsext-resolver-side-mitigation/