Вопросы Теги

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

У нас был клиент, который установил Рекорд CNAME для его домена. Так или иначе он управлял им для установки Рекорда также, который должен быть не возможным и запрещается 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 и Запись. Действительно ли это - известная ошибка? Как я могу защитить свой домен от него?

3
задан 1 September 2014 в 11:41
2 ответа

Для конкретного ответа на ваш вопрос(ы):

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

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

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

.
4
ответ дан 3 December 2019 в 05:12

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

CNAME-записи

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

 podunk.xx. НС № 1
 IN NS ns2
 в ХРАНИЛИЦЕ Мария
 Мария В А 1.2.3.4

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

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

 podunk.xx. В MX mailhost
 почтальон в Канаме Мария
 Мария В А 1.2.3.4
В разделе 3.6.2

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

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

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

3
ответ дан 3 December 2019 в 05:12

Теги

Похожие вопросы