Какая задержка в 50 мс может быть на моем несвязанном DNS-сервере (Fedora)?

У меня есть расхождение в задержке запроса. Это не проблема, это достаточно странно, чтобы беспокоить меня.

  • Клиентский компьютер (Fedora 18) работает unbound-1.4.19-1.fc18.x86_64.
  • Серверный компьютер (тестирование Debian 7) работает без ограничений 1.4.17-2.

Оба подключены к одному домашнему маршрутизатору. Однако сервер может обрабатывать некэшированные запросы почти в два раза быстрее. Это было совсем не то, что я ожидал! Сервер представляет собой ARM 1 ГГц (sheevaplug), а клиентский компьютер - Intel Core Duo 2,1 ГГц.

Оба экземпляра проверяют DNSSEC. Они возвращают SERVFAIL для www.dnssec-failed.org. Оба настроены на использование одного и того же восходящего кэша DNS от моего провайдера.

Пока я могу думать только о проблеме с NAT. Маршрутизатор настроен с сервером как "DMZ по умолчанию", то есть он получает любые пакеты, на которые никто не претендует, именно так я запускаю публичные сервисы, такие как SSH и bittorrent:). Или... может быть, в некотором смысле несовершеннолетняя версия 19 проверяется более строго, чем неосновная версия 17?

Методология тестирования: разрешение 10 несуществующих поддоменов.de. (Должно вызвать пропуски кеша провайдера)..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

Я знаю, что тест не выглядит великолепно, и моя статистика не может быть убедительным доказательством. Но я попробовал это еще несколько раз, и это не выглядит по-другому.

1 ответ

Ах! Я просто показал 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/

Другие вопросы по тегам