CDS-запись

Самое неудобное место в DNSSEC — связь с родительской зоной. Цепочка доверия держится на DS-записи, которую публикует реестр, а попадает она туда через регистратора. Пока сменить ключ можно было только вручную, через форму в личном кабинете, многие просто не меняли ключи годами или ошибались при копировании хеша.

CDS описана в RFC 7344 вместе с родственной записью CDNSKEY. Идея простая: дочерняя зона сама публикует, какой DS она хочет видеть у родителя. Реестр или регистратор периодически опрашивает подписанные зоны, проверяет подпись записи действующим ключом и, если всё сходится, обновляет DS у себя.

Как выглядит запись

example.com. 3600 IN CDS 2371 13 2 (
    1F987CC6583E92DF0890718C42A4F1B4
    3A4B0E5A1E2D3C4B5A69788766554433 )

Формат полностью повторяет DS: тег ключа, номер алгоритма (13 — ECDSA P-256 с SHA-256), тип хеша (2 — SHA-256) и сам хеш открытого ключа. Отдельный случай описан в RFC 8078: запись с алгоритмом 0 означает просьбу удалить DS и выключить DNSSEC для домена.

Зачем это владельцу домена

При ротации ключа подписи ключей оператор DNS публикует новую CDS, и через некоторое время родительская зона обновляется без участия человека. Ошибки копирования исчезают, а смена ключей перестаёт быть событием, которого боятся.

Ограничения

• Механизм поддерживают не все реестры и регистраторы. Где поддержки нет, DS по-прежнему меняют вручную.
• Первоначальное включение DNSSEC обычно всё равно требует ручного шага: родителю нечем проверить подпись зоны, пока цепочки доверия ещё нет.
• CDS должна совпадать с реально опубликованной DNSKEY-записью, иначе обновление приведёт к ошибкам проверки.