Назад | Перейти на главную страницу

Неверный ответ DNS с CNAME и записью A одновременно

У нас был клиент, который установил запись CNAME для своего домена. Каким-то образом ему удалось установить запись A, что должно быть невозможно и запрещено DNS. Но результат был:

$ dig @ns1.your-server.de tippspiel-bl1.unternehmen-frische.de 
...
;; ANSWER SECTION:
tippspiel-bl1.unternehmen-frische.de. 7200 IN CNAME www.kicktipp.de.
tippspiel-bl1.unternehmen-frische.de. 7200 IN A 78.46.10.156

Вторая запись незаконна. Но это привело к некоторой путанице с другим кеширующим DNS-сервером, который возвращал 78.46.10.156 когда их спросили о www.kicktipp.de. Но это совершенно неверно.

Другой DNS-сервер использовал оба ответа и смешивал их. Конечный результат: пользователи, посещающие www.kicktipp.de, были отправлены на 78.46.10.156 который является IP unternehmen-frische.de

Кажется, что я могу захватить домен при настройке DNS для домена с CNAME и A-записью. Это известная ошибка? Как я могу защитить свой домен от этого?

Есть специальная проверка, которую вы можете включить для защиты таких вещей, если вы сами управляете своим DNS-сервером. Пожалуйста, прочтите приведенный ниже пункт, который взят непосредственно из RFC. Это просто человеческая ошибка, и ее можно предотвратить с помощью какого-либо сценария или проверки перед перезагрузкой конфигурации зоны.

Записи CNAME

Запись CNAME не может сосуществовать с другими данными. Другими словами, если suzy.podunk.xx является псевдонимом для sue.podunk.xx, у вас также не может быть записи MX для suzy.podunk.edu, записи A или даже записи TXT. Особенно не пытайтесь так комбинировать CNAME и NS записи !:

   podunk.xx.      IN      NS      ns1
                   IN      NS      ns2
                   IN      CNAME   mary
   mary            IN      A       1.2.3.4

Это часто делается неопытными администраторами как очевидный способ разрешить вашему доменному имени также быть хостом. Однако DNS-серверы, такие как BIND, увидят CNAME и откажутся добавлять какие-либо другие ресурсы для этого имени. Поскольку никакие другие записи не могут сосуществовать с CNAME, записи NS игнорируются.

Не используйте CNAME в сочетании с RR, которые указывают на другие имена, такие как MX, CNAME, PTR и NS. (PTR является исключением, если вы хотите реализовать бесклассовое делегирование in-addr.) Например, это настоятельно не рекомендуется:

       podunk.xx.      IN      MX      mailhost
       mailhost        IN      CNAME   mary
       mary            IN      A       1.2.3.4

[RFC 1034] в разделе 3.6.2 сказано, что этого делать не следует, и [RFC 974] прямо заявляет, что записи MX не должны указывать на псевдоним, определенный CNAME. Это приводит к ненужному косвенному обращению к данным, и DNS-преобразователи и серверы должны работать больше, чтобы получить ответ. Если вы действительно хотите сделать это, вы можете сделать то же самое, используя препроцессор, такой как m4, в файлах хоста.

Кроме того, связывание записей, таких как CNAME, указывающих на CNAME, может облегчить проблемы с администрированием, но, как известно, вызывает ошибки в некоторых преобразователях, которые не могут правильно проверять циклы. В результате некоторые хосты не могут распознавать такие имена.

Наличие NS-записей, указывающих на CNAME, плохо и может сильно конфликтовать с текущими серверами BIND. Фактически, текущие реализации BIND будут игнорировать такие записи, что может привести к неправильному делегированию. В BIND выполняется определенная проверка безопасности, чтобы предотвратить подделку записей DNS DNS. Кроме того, старые серверы BIND, как сообщается, попадут в бесконечный цикл запросов, пытаясь выяснить адрес для сервера имен с псевдонимом, что приведет к отправке непрерывного потока DNS-запросов.

Чтобы конкретно ответить на ваш вопрос (ы):

  • Нет, это не часто встречающаяся проблема. Тем не менее, отравление делает случаются, но обычно используются поддельные ответы, а не A запись жизни рядом с CNAME. DNSSEC был разработан с учетом атак отравления.
  • Если бы здесь был реализован DNSSEC, для проверяющих преобразователей было бы ясно, что A запись не была подписана вами. Нет ничего другого, что вы могли бы сделать в своей зоне, что могло бы повлиять на эту проблему.

Поскольку у вас нет дополнительной информации, вам придется обсудить этот вопрос со своим интернет-провайдером. Наиболее применимый стандарт, определяющий RFC для цитирования: RFC2181 поскольку это менее двусмысленно, чем RFC1034 по поводу сосуществования CNAME с другими данными. (RFC1034 осуждает это, RFC2181 запрещает это, если записи не связаны с DNSSEC)

Все это говорит о том, что я несколько скептически отношусь к тому, чтобы проблема была именно такой, как вы описали. Это было бы действительно неприятной ошибкой для tippspiel-bl1.unternehmen-frische.de. IN A вызвать столкновение с www.kicktipp.de. IN A.