Почему я не могу иметь две записи для одного и того же имени с разными TTL?

Question

Я только что обновил свои сертификаты TLS, но я еще не установил новые. Я решил добавить новые записи TLSA, понизить TTL старых, подождать некоторое время, а затем обменять сертификаты и удалить старые записи. Однако BIND, похоже, не нравится иметь несколько записей с одним и тем же именем и разными TTL set to prior TTL : он записал TTL, установленный на предыдущий TTL, в свой журнал и теперь обслуживает обе записи с TTL, который я дал первой. Я записал зону быстрого тестирования и провел ее через named-compilezone с теми же результатами:

$TTL 1w

$ORIGIN foo.example.

@                       SOA     bar     hostmaster      (
                                2016020600      1d      3h      1w      1d
                                )

@                       NS      a.ns.example.
@                       NS      b.ns.example.

bar             1w      A       203.0.113.5
bar             1d      A       198.51.100.143

/dev/stdin:11: TTL set to prior TTL (604800)
zone foo.example/IN: loaded serial 2016020600
foo.example.            604800 IN SOA   bar.foo.example. hostmaster.foo.example. 2016020600 86400 10800 604800 86400
foo.example.            604800 IN NS    a.ns.example.
foo.example.            604800 IN NS    b.ns.example.
bar.foo.example.        604800 IN A     198.51.100.143
bar.foo.example.        604800 IN A     203.0.113.5
OK

Я искал RFC 1035 и руководство BIND, но не смог найти ничего, говорящего о том, что записи с одинаковым именем должны иметь одинаковый TTL. Так что же дает?

Answer 1

Прежде всего, я бы спросил, почему вы хотите это сделать, каков ваш вариант использования? Есть почти наверняка лучший способ ,,,

Это применяется в течение длительного времени, поэтому вы получаете сообщение журнала, в котором указано, какой TTL нормализовал обе записи (604800 в данном случае).

Простая причина этого - и имеет полное значение, если вы об этом думаете - в том, что обе записи одновременно удаляются из кэша на разрешающем DNS-сервере в Интернете, и обе они вновь извлекаются в следующий раз, когда В этом обширном месте спрашивают о записи. Это единственный контроль, который вы имеете как владелец домена над удаленными кешами DNS. Если этого не произойдет, то ваш TTL с более короткой записью будет сначала очищен, оставляя TTL с более длинной записью в кеше сам по себе. Если это для веб-сервера, то вы просто потеряли избыточность в этом далеком месте, потому что этот локальный DNS-сервер будет возвращать только одну запись A до конца недели. В конечном итоге это приводит к нестабильному поведению, которое трудно устранить.