Об ограничениях CNAME

Вчера ко мне обратился коллега, у него никак не получалось отредактировать файл зоны, точнее изменения никак не отображались в браузере. Записи не редактировались и не удалялись. Предположение о том, что офисный name-сервер что-то закэшировал было сразу откинуто, проблема была на сервере отвечающем за зону. В логах bind при вызове rndc reload появлялись подобные строки:

Jan 20 13:21:35 black named[8289]: dns_master_load: master/example.com:92: sub.example.com: CNAME and other data
Jan 20 13:21:35 black named[8289]: zone example.com/IN/default: loading master file master/example.com: CNAME and other data

После недолгих разбирательств выяснилось, что проблема была в CNAME-записи, для sub.example.com. После замены её на A-запись всё заработало. Отличался sub.example.com от других поддоменов наличием MX и TXT записей.

Почему же CNAME "конфликтует" с MX и TXT-записями? Ответ даёт RFC 1034, пункт 3.6.2:

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Т.е., при использовании CNAME, будут использованы ресурсные записи домена, на который ссылается запись. В примере ниже foo.example.com ссылается на ya.ru

$ dig ya.ru MX

;; QUESTION SECTION:
;ya.ru.                         IN      MX

;; ANSWER SECTION:
ya.ru.                  1844    IN      MX      10 mx.yandex.ru.

$ dig foo.example.com. MX

;; QUESTION SECTION:
;foo.example.com.               IN      MX

;; ANSWER SECTION:
foo.example.com.        86400   IN      CNAME   ya.ru.
ya.ru.                  7199    IN      MX      10 mx.yandex.ru.

С появлением DNSSEC (список RFC тут), ситуация немного изменилась, теперь вместе с CNAME могут использоваться RRSIG, NSEC и KEY

Век живи - век учись...