Как и большинство организаций, мы поддерживаем различные разделенные домены по разным причинам. Из-за того, что мы делаем, мы часто используем одно и то же имя в разных экземплярах домена, чтобы указывать на разные версии вещей, и это требование, которое мы должны поддерживать. В последнее время выяснилось, что это становится препятствием для доступа между разделениями. В простейшем случае мы хотим иметь возможность предоставить внутренним пользователям доступ к example.com, который существует как внутри, так и снаружи.
Мы хотели бы иметь доступ к внутренней версии как example.com и внешней версии как ext.example.com. У нас есть доступ для передачи внешней зоны на наш внутренний сервер BIND от внешнего провайдера.
Я настроил представление на сервере BIND, не указав ни одного представления для совпадений клиентов, поэтому все, что он делает, - это предварительная передача зоны для зоны. Затем я попытался использовать тот же файл во «внутреннем» виде в качестве мастера под именем ext.mypna.com. Когда это будет сделано, все записи будут признаны недействительными путем привязки как «данные вне зоны».
Просматривая файл зоны на внутреннем сервере и внешнем провайдере, я обнаружил, что переданная зона помечена как «$ ORGIN external.com» и «external.com IN SOA». Возврат к @ позволяет BIND снова использовать файл зоны, но он просто удаляется после обновления.
Есть ли стандартный способ реализовать такую архитектуру?
Если я правильно вас понял, вы запускаете отдельные независимые DNS-серверы, и каждый набор (я действительно надеюсь, что у вас более одного экземпляра на подсеть или сетевое расположение) серверов содержит различную нескоординированную информацию. Это неустойчиво. Я действительно унаследовал нечто подобное несколько лет назад, и это было нашим самым большим источником раздражения, ошибок и сбоев, пока мы не вырвали его и не построили совершенно новую настройку DNS.
Вместо того, чтобы поддерживать нескольких мастеров, ответственных за свои собственные зоны, создайте единого мастера, содержащего все зоны, с несколькими видами. Устанавливайте подчиненных устройств везде, где они будут иметь смысл (еще один в том же месте, больше в других физических местах, поместите их физически и логически близко к тому месту, где находятся ваши пользователи). Реплицируйте все представления на все ведомые устройства или только на некоторые представления, если вы знаете, что некоторые из ваших ведомых устройств не будут обслуживать запросы из определенных сетей. Как только это будет сделано, все ваши серверы будут иметь одинаковые данные. Вам нужно только убедиться, что ваши представления определены правильно, и все клиенты получат именно те результаты, которые им нужны, независимо от того, какой сервер они используют.
Пара подсказок по реализации:
Используйте $ INCLUDE в своих файлах зоны, чтобы отдельные файлы представлений имели только записи, которые различаются для разных представлений (например, ваш ext.example.com, вероятно, будет разрешать один и тот же IP-адрес независимо от представления, поэтому он войдет в общий включаемый файл, а example.com будет специфичным для каждого файла представления).
Для репликации вы можете дать каждому DNS-серверу несколько IP-адресов - по одному для каждого представления. Это сделано, потому что представления используют IP-адрес клиента, чтобы определить, что обслуживать - и это также включает запросы XFER, поступающие от ведомых устройств. Итак, вы должны: 1) для каждого ведомого устройства добавить один и только один его IP-адрес в каждое представление; 2) на ведомых устройствах используйте директиву передачи-источника в named.conf, чтобы XFER отправлялись с правильного IP-адреса. Вот та же идея, объясненная более подробно: http://coding.infoconex.com/post/2010/04/26/Bind-DNS-e28093-Configuring-multiple-views-on-primary-and-secondary-DNS-servers.aspx
Также узнайте, сможете ли вы получить помощь от сетевых администраторов. В некоторых ситуациях перезапись DNS может сделать ненужными отдельные представления.