Мне интересно, что происходит, когда доменное имя в DNS имеет несколько записей MX с разным временем жизни (TTL)?
Например, что, если это записи MX для example.com?
Что произойдет, если агент пересылки почты отправляет сообщение в этот домен - где некоторые из серверов MX могут работать, а некоторые - нет - и результаты кешируются в течение 2 минут? два часа? 1,5 дня? 2,5 дня? Нужно ли использовать наименьшее значение TTL для всех записей MX (в данном случае 60 секунд) и выполнять повторный поиск всех записей MX, если прошло столько времени, игнорируя более длинные значения TTL для оставшихся записей MX? Или кеш действительно как-то учитывает все разные TTL? Если принять во внимание все значения TTL, не могли бы вы привести несколько примеров сценариев, как это может работать?
Описанный вами сценарий не является допустимым набором записей.
Один RRset (набор записей для определенного имени, класса, комбинации типов) не может иметь разные TTL для отдельных записей. Однако, если такой (недействительный) набор записей встречается при взаимодействии с авторитетным сервером, следует использовать наименьший TTL, в других случаях набор записей следует полностью игнорировать.
Из Разъяснения к спецификации DNS (с 1997 г.):
5.2. TTL RR в RRSet
Ресурсным записям тоже есть время жить (TTL). Для RR в RRSet могут быть разные TTL. Для этого не было найдено применений, которые нельзя было бы улучшить другими способами. Однако это может вызвать частичные ответы (не помеченные как «усеченные») от кэширующего сервера, где истек срок жизни TTL для некоторых, но не для всех RR в RRSet.Следовательно, использование разных TTL в RRSet не рекомендуется, TTL для всех RR в RRSet должны быть одинаковыми.
Если клиент получает ответ, содержащий записи RR от RRSet с разными TTL, он должен рассматривать это как ошибку. Если соответствующий RRSet поступает из неавторитетного источника этих данных, клиенту следует просто игнорировать RRSet, и, если значения были необходимы, стремиться получить их из авторитетного источника. Клиенты, настроенные на отправку всех запросов на один или несколько конкретных серверов, должны рассматривать эти серверы как авторитетные для этой цели. Если авторитетный источник отправляет такой искаженный RRSet, клиент должен обрабатывать RR для всех целей, как если бы все TTL в RRSet были установлены на значение самого низкого TTL в RRSet. Ни в коем случае сервер не может отправлять RRSet с не всеми TTL.