Как DNS-сервер работает?


14

В нашей записи NS есть два DNS-сервера. Прошлой ночью один из наших DNS-серверов вышел из строя. Как и ожидалось, некоторые DNS-серверы не разрешали наши имена хостов. Я предполагал, что это будет временно и начнет работать после истечения TTL наших записей NS (1 час).

Через час + я все еще получал тайм-ауты DNS от настольных компьютеров, которые использовали серверы Earthlink, Verizon и OpenDNS. Я проверил, отвечает ли другой DNS-сервер:

dig @ns2.example.com www.example.com +short

Это сработало.

Мои вопросы:

  1. У кого-нибудь есть ответ на вопрос, почему другие DNS-серверы не попали на наш другой DNS-сервер даже после истечения срока действия TTL?
  2. Предпочитают ли DNS-серверы основной DNS-сервер домена (из SOAзаписи)?
  3. Есть ли какой-нибудь алгоритм, используемый для выбора сервера имен из доступных записей NS? Я предполагаю, что это зависит от реализации, но, возможно, есть некоторые стандарты, которые применяются здесь.

TTL не имеет ничего общего с чем-либо. Поскольку никакие записи не были изменены, это не имеет соответствующего эффекта.
Дэвид Шварц

Ах, я вижу это сейчас. Doh.
Бельмин Фернандес

Ответы:


17

Это досадное раздражение. Предполагается, что несколько DNS-серверов должны повысить надежность, но на практике это часто имеет обратный эффект.

Проблема в том, что клиент только так долго ждет ответа, а сервер ждет примерно столько же времени. Скажем, у вас есть два DNS-сервера, A и B. Скажем, A работает, а B не удалось. Бывает:

  1. Клиент подключается к серверу имен Z и запрашивает информацию. Z выбирает B и отправляет запрос.

  2. Время ожидания клиента истекло, поскольку сервер имен Z не ответил.

  3. Клиент пытается сервер имен Y. Y выбирает B и отправляет запрос.

  4. Сервер имен Z отключается и пытается А. Он получает правильный ответ, но клиент больше не ждет.

  5. Время ожидания клиента истекло, поскольку сервер имен Y не ответил.

  6. Клиент сдается, и оба его сервера имен не отвечают.

  7. Сервер имен Y останавливается и пытается А. Он получает правильный ответ, но клиент больше не ждет.

И нет хорошего решения. Чем дольше вы ждете, чтобы увидеть, отвечает ли сервер имен, тем дольше вы должны ждать, потому что сам сервер имен, который вы ожидаете, ждет дольше. Возможно, проблема была в том, что Y и Z не сдавались достаточно быстро.

По сути, если какой-либо из ваших серверов имен не работает, некоторые клиенты, по чистой случайности, истекают, потому что они пробовали только плохие.

С другой стороны, если у вас есть два сервера имен и один отказывает, около 75% серверов имен получат ответ вместо 0%.


Я понимаю что ты имеешь ввиду. Ик. Таким образом, клиентский сервер имен ( Z) не будет кэшировать, какой сервер имен он использовал в последний раз, который работал?
Бельмин Фернандес

1
Некоторые серверы имен делают это, и иногда это помогает. Это часто зависит от того, каким именно образом произошел сбой сервера имен. Вы должны помнить, что все это происходит поверх UDP, поэтому неспособность получить ответ (даже после повторной передачи или двух) не доказывает, что с сервером имен что-то не так.
Дэвид Шварц

Я прочитал в своей копии DNS и BIND (Paul Albitz и Cricket Lui, O'Rielly p278), что серверы Bind 8.2.3 выбирают сервер, который быстрее всего отвечает из своего списка серверов пересылки, что означает, что если сервер в списке не работает, он в значительной степени автоматически отбрасывается. Bind 9 пока не реализует это, он запрашивает серверы пересылки в порядке списка. Кто-нибудь знает, изменилось ли это?
Джейди

Просто чтобы уточнить, для тех, кто менее разбирается в настройках DNS (мне потребовалось некоторое время, чтобы понять это), серверы имен DNS Z и Y в этом примере, скорее всего, являются рекурсивными серверами имен, основанными в сети клиента, например, DNS-серверами, которые предоставляет интернет-провайдер. своим клиентам через DHCP. И проблема возникает, когда эти серверы имеют более длительное значение тайм-аута, чем клиентский распознаватель DNS (например, операционная система устройства).
Джордан Ригер,

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.