Что происходит, когда несколько записей MX в имени DNS имеют разные TTL?
Мне интересно, что происходит, когда доменное имя в DNS имеет несколько записей MX с разным временем существования (TTL)?
Например, что, если это записи MX для example.com ?
- TTL = 3 дня, приоритет = 1, результат = mx1-slow.example.com
- TTL = 60 секунд, приоритет = 1, результат = mx1-fast.example .com
- TTL = 1 день, приоритет = 2, результат = mx2.example.com
- TTL = 1 час, приоритет = 3, результат = mx3-hour.example.com
- TTL = 60 секунд, приоритет = 3, результат = mx3-fast.example.com
- TTL = 2 дня, приоритет = 3, результат = mx3-slow.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 для некоторых, но не для всех РР. в РРРСет истек срок годности.Следовательно, использование различных ВТУ в РРРСетах настоящим является Если клиент получает ответ, содержащий РР в РРСПет, то СУД всех РР должны быть одинаковыми.
Если клиент получает ответ, содержащий РР в РРСПет, то СУД всех РР должны быть одинаковыми. с различными TTL, он должен рассматривать это как ошибку. Если Соответствующий RRSet получен из неавторизованного источника этих данных, клиент должен просто игнорировать RRSet, и если бы значения были требуют, стремятся получить их из авторитетного источника. Клиенты которые настроены на отправку всех запросов на один, или более, конкретный серверы должны относиться к этим серверам как к авторитетным для этой цели. Если авторитетный источник посылает такой некорректный RRSet, то клиент должен относиться к РР для всех целей так, как если бы все СУД в RRSet был установлен на значение самой низкой TTL в RRSet. На сайте . ни в коем случае сервер не может послать RRSet с TTL, которые не все равны.