Как настроить авторитативный сервер DNS?

Question

[Сергей Сахаров]

Дано: есть доменная зона, в ней несколько имен. Все поддомены крутятся на одном IP-адресе.
Кроме того, есть несколько других доменов, один из которых используется как резервный сервер DNS.
При этом основной сервер DNS крутится на другом адресе, а основной хост (и ещё один) на третьем адресе (два VDS)

До этого использовались серверы DNS Яндекса, но он в последнее время ведёт себя плохо и хочет денежку.
А регистратор отказывается принимать "родные" серверы для этого домена по причине:
Ответ DNS-сервера не является авторитативным.
В качестве серверов DNS используется связка UNBOUND+POWERDNS (в unbound прописана stub-zone)
Что нужно сделать, чтобы объявить эту связку авторитативным DNS-сервером?

Answer 1

[hint000]

Кеширующий сервер висит на порту 53 и все неизвестные запросы отправляет на сервера forwarders, а все запросы к основной зоне - на авторитативный сервер на порту 5353

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

Нужен непосредственный доступ извне к авторитативному серверу.

Comments

[Сергей Сахаров]

Но тогда он не сможет поддерживать другие домены, да и forwarders работать не будут.

[hint000]

Сергей Сахаров, почему? не улавливаю логику.

[Сергей Сахаров]

hint000, а почему авторитативный ставят в связке с кеширующим, да ещё и на одном айпи-адресе?
unbound+nsd
PowerDNS+recursor

только BIND обходится без подобных связок

[hint000]

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

Возможно, деление на две части сделано в целях безопасности:
снаружи остаётся доступен только авторитативный, но он ничего не кеширует и потому в принципе не подвержен атаке отравления кеша (DNS cache poisoning); в свою очередь, кеширующий не должен получать извне запросы, а значит может быть защищён от такой атаки файерволом, отбрасывающим приходящие снаружи пакеты в статусе new и invalid.
Если так, то деление на две части ещё не повышает безопасность автоматически, а только даёт возможность для правильной настройки файервола.

У меня в инфраструктуре нет доступного извне DNS (используется DNS хостера), а внутренние сразу и кеширующие, и авторитативные для локальных зон. Поэтому сейчас на ходу обдумывал смысл разделения. Надеюсь, что его (смысл) понял правильно. Потом погуглю, что об этом думает сообщество.

Итак, вам нужно входящие снаружи на 53/UDP перенаправить средствами NAT на 5353/UDP. Тогда внешние запросы будут попадать сразу на авторитативный сервер. Всё остальное вроде должно работать как и раньше.

[Сергей Сахаров]

hint000, поправка: у меня нет "внутри", все входящие - снаружи.
Так что я могу просто повесить PowerDNS на 53 порт
Надеюсь, Вы расскажете, как в нём прописать несколько других доменов и заставить работать forwarding

У меня в инфраструктуре нет доступного извне DNS (используется DNS хостера)

В моём случае для моих сайтов я сам себе хостер.

Я просто не хочу оплачивать услуги Яндекс.360 - для чего хочу использовать свои средства.
Две VDS у хостера и сервер виртуализации дома.

[hint000]

Сергей Сахаров, а зачем forwarding, если все входящие снаружи?
Ведь в таком случае на ваш сервер будут приходить запросы только относящиеся к вашей зоне, остальные запросы (которым нужен forward) будут нелегитимные, сервер не должен на них отвечать.

Надеюсь, Вы расскажете, как в нём прописать несколько других доменов

Не использовал PowerDNS. Но по смыслу нагугливается команда создания новой зоны create-zone здесь: https://doc.powerdns.com/authoritative/manpages/pd...

[Сергей Сахаров]

hint000, именно.
А как тогда в этом случае работают серверы DNS Яндекса? Они авторитативные для привязанных доменов, но в то же время разрешают и другие сайты, то есть отвечают на все запросы. Хотя Вы утверждаете, что не должны...

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

[hint000]

Сергей Сахаров,

А как тогда в этом случае работают серверы DNS Яндекса?

Я же не говорю, что это невозможно. Я говорю, что в вашем случае это не нужно и вредно.

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

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

Без примера тут непонятно. Но попробую сформулировать проще. У регистратора вы получили домен pushkin2024.ru, создали для него зону, можете насоздавать в этой зоне сколько угодно: pamyatnik.pushkin2024.ru, onegin.pushkin2024.ru, glava1.onegin.pushkin2024.ru, glava2.onegin.pushkin2024.ru,..

Но если вы у регистратора получили ещё другой домен gogol2024.ru, то его вы не впихнёте в ту же самую зону, нужно создавать новую зону. В то же время вам никто не запретит вынести в отдельную зону onegin.pushkin2024.ru (вместе с glava1.onegin.pushkin2024.ru, glava2.onegin.pushkin2024.ru), но это только если вы зачем-то захотите так сделать.

Короче, зависит не от того, единственная или не единственная будет запись, а от иерархии доменов. Если всё вписывается в единую иерархию, то достаточно одной зоны.

[Сергей Сахаров]

hint000, у меня есть одна своя зона с поддоменами и три других зоны без поддоменов. И всё же для них есть мысль завести mx-записи, чтобы не держать привязанные ПЯ на Яндексе.

Я же не говорю, что это невозможно. Я говорю, что в вашем случае это не нужно и вредно.

Давайте я сам разберусь, вредно это или нет.

Answer 2

[MVV]

Что нужно сделать, чтобы объявить эту связку авторитативным DNS-сервером?

Как минимум, заменить stub-зону полноценной вторичной зоной, содержащей все записи зоны. Возможно этого будет даже достаточно.

Comments

[Сергей Сахаров]

То есть выключить PowerDNS нахер и перенести все записи в unbound.conf как local-zone

Я правильно понимаю, держать зону в БД не получится?
Только текстовые файлы, только хардкор?

Или вообще вместо этой связки настроить BIND

[MVV]

Сергей Сахаров, я про эту вашу связку мало подробнойстей знаю. Я просто знаю, как работает DNS, а работал с BIND и Microsoft DNS (который входит в состав Windows Server). Они оба, кстати, позволяют это сделать.
Смысл держать вторичную зону в БД, вообще говоря, я не вижу: она все равно реплицируется с сервера, на котором размещена первичная зона. Разве что, эта зона очень велика.

[Сергей Сахаров]

MVV, не совсем понял, почему Вы считаете эту зону "вторичной"?
DNS-сервер делится на две части: авторитативный (PowerDNS) и кеширующий (undound)

С чего вдруг зона с авторитативного сервера стала считаться вторичной?

Кеширующий сервер висит на порту 53 и все неизвестные запросы отправляет на сервера forwarders, а все запросы к основной зоне - на авторитативный сервер на порту 5353