Отображение неизвестных поддоменов в одну точку в файле зоны с DNAME
Я обнаружил, что могу редактировать файл зоны следующим образом
$ORIGIN us.example.com.
@ IN DNAME another.example.com.
Но что, если я заранее не знаю всех поддоменов, возможно ли сделать что-то подобное:
$ORIGIN *.example.com.
@ IN DNAME another.example.com.
В основном я хотел бы перенаправить с каждого поддомен в одну точку.
Это возможно / правильно? Я нашел это RFC 6672 советует не использовать подстановочные знаки. Почему так? И это о моем случае выше?
Изменить: Если выше не правильно, могу ли я сделать это:
*.example.com. IN DNAME example.com.
example.com. A 192.168.1.1
или это
*.example.com. A 192.168.1.1
2 ответа
Отложить в сторону $ORIGIN вопрос (по которому Василий прав на 100%), RFC, определяющий DNAME Тип записи ( RFC6672) активно препятствует этому.
3.3. Wildcards
Использование DNAME в сочетании с подстановочными знаками не рекомендуется [RFC4592]. Таким образом, записи вида "*.example.com DNAME example.net" НЕ ДОЛЖНЫ использоваться.
Взаимодействие между расширением подстановочного знака и перенаправлением DNAME является недетерминированным. Из-за того, что обработка является недетерминированной, проверяющие распознаватели DNSSEC могут не иметь возможности проверить DNAME с подстановочными символами.
Сервер МОЖЕТ дать предупреждение о том, что поведение не определено, если загружен такой DNAME с подстановочными символами. Сервер МОЖЕТ отказать в этом, отказать в загрузке зоны или отказать в динамических обновлениях.
Хотя язык "НЕ ДОЛЖЕН" и "МОЖЕТ" не запрещает вам делать это, вы действительно не должны этого делать. Следуя этой ссылке RFC4592, мы сталкиваемся с этим:
4.4. DNAME RRSet для доменного имени с подстановочными знаками
Право собственности на DNAME [RFC2672] RRSet с использованием доменного имени с подстановочными знаками представляет угрозу для согласованности DNS и должна быть исключена или полностью отклонена. Такой DNAME RRSet представляет недетерминированный синтез правил, передаваемых в разные кэши. По мере того, как кеши заполняются различными правилами (непредсказуемым образом), кеши перестают быть связными. ("По мере заполнения кэшей" означает хранение в кэше записей, полученных в ответах рекурсивными или итеративными серверами.)
Эти стандартные определения RFC не только предоставляют технические причины того, почему это плохая идея, но и активно поощряют программное обеспечение DNS не поддерживать эту функцию, в то же время явно не запрещая ее. Этих причин более чем достаточно, чтобы я дважды подумал о том, чтобы когда-либо пытаться это осуществить.
Это просто не будет работать, так как $ORIGIN должен содержать действительное имя зоны. Подстановочный знак не является допустимым именем зоны.
В лучшем случае вы можете рассчитывать на создание сценариев для создания всех зон, которые вам требуются в конфигурации BIND, и указывать все они в одном и том же файле общих зон.