Допустим, я создаю файл обратной зоны для сети 192.0.2.0/24 на моем DNS-сервере, и мой DNS-сервер будет авторитетным для обратной зоны 2.0.192.in-addr.arpa. В этом обратном файле зоны я создаю запись Start of Authority со следующими параметрами:
$ dig @localhost -t SOA 2.0.192.in-addr.arpa. +noall +answer
2.0.192.in-addr.arpa. 604800 IN SOA primary-DNS-server secondary-DNS-server 2015010600 28800 7200 1209600 86400
$
Верно ли, что TTL DNS для этой обратной зоны составляет 86400 секунд? А это значит, что если рекурсивный (кеширующий) DNS-сервер запрашивает PTR-запись из этой зоны, то этот рекурсивный DNS-сервер будет кэшировать результат на 86400 секунд?
Еще в 1997 году это была бы одна правильная интерпретация нескольких записей SOA. :) Тогда все было немного более неоднозначно.
RFC 2308 реклассифицировал последнее поле записи SOA как отрицательный интервал кэширования, иначе известный как NCACHE поле. RFC2308 §4 является наиболее применимым здесь. Это не только переопределяет это как NCACHE поле, но также объясняет, почему кодирование TTL по умолчанию в записи SOA было бы ошибочным с самого начала. (последнее выделено жирным шрифтом)
4 - Минимальное поле SOA
Поле минимума SOA в прошлом было перегружено, чтобы иметь три разных значения: минимальное значение TTL для всех RR в зоне, TTL по умолчанию для RR, которые не содержали значения TTL, и TTL отрицательных ответов.
Несмотря на то, что это изначально определенное значение, первое из них, минимальное значение TTL для всех RR в зоне, на практике никогда не использовалось и поэтому не рекомендуется.
Второй, TTL по умолчанию для RR, которые не содержат явного TTL в файле главной зоны, актуален только на первичном сервере. После передачи зоны все RR имеют явные TTL, и невозможно определить, был ли TTL для записи установлен явно или получен из значения по умолчанию после передачи зоны. Если сервер не требует, чтобы RR явно включали значение TTL, он должен предоставить механизм, не являющийся значением поля MINIMUM записи SOA, из которого получаются недостающие значения TTL. Как это делается, зависит от реализации.
Формат основного файла [RFC 1035, раздел 5] расширен за счет включения следующей директивы:
$TTL <TTL> [comment]Все записи ресурсов, появляющиеся после директивы и явно не включающие значение TTL, имеют TTL, равный TTL, указанному в директиве $ TTL. Записи SIG без явного TTL получают свой TTL из «исходного TTL» записи SIG [RFC 2065, раздел 4.5].
Оставшееся из текущих значений TTL, которое будет использоваться для отрицательных ответов, - это новое определенное значение поля минимума SOA.
Разбивая это:
NCACHE) указывает, как долго удаленные серверы имен должны кэшировать отрицательный ответ, если запрос приводит к NXDOMAIN.$TTL директива для текстовых файлов зон. $TTL и семья не являются записями, поэтому вы не можете запросить их, и они не переживут перенос зоны. (вместо этого все отсутствующие TTL будут заменены этим значением во время передачи зоны)Как говорит Энди, значение TTL по умолчанию является спорным, если отдельные записи определяют свои собственные TTL.
Почти. Сама запись soa имеет TTL 86400 секунд и в зависимости от программного обеспечения на стороне сервера, которое будет ttl по умолчанию для этой зоны.
Отдельные записи в этой зоне, такие как PTR или NS, могут иметь переопределение TTL. Я считаю, что рекурсивный запрос для любой отдельной записи DNS вернется с собственным TTL, хотя я говорю, что это основано на наблюдении, а не на справочной документации.