Финтех-платформа, предоставляющая субдомены арендаторов, должна выбрать зону DNS, принадлежащую платформе, для предсказуемой активации. И наоборот, зона, принадлежащая клиенту, предпочтительнее, когда делегированный контроль является договорной необходимостью или требованием безопасности. Крайне важно явно определить готовность DNS как отдельное состояние, а не предполагать, что успешные запросы означают завершение. TTL DNS-записей играет значительную роль, поскольку его снижение не изменяет ретроактивно существующие кэшированные записи в резолверах.В зоне, принадлежащей платформе, платформа управляет как TTL, так и записями, что облегчает автоматическое создание субдоменов арендаторов и упрощает диагностику, четко различая авторитетные состояния и состояния резолвера. Зона, принадлежащая клиенту, предоставляет клиенту контроль над изменениями на стороне родителя, что необходимо для требований делегированного владения, но усложняет диагностику из-за возможной устарелости данных между административными границами. Основная проблема с изменениями DNS заключается в множестве точек наблюдения: авторитетные серверы по сравнению с рекурсивными резолверами и клиентскими кэшами.Одного успешного запроса недостаточно; сначала необходимо отдельно запросить авторитетный путь и несколько рекурсивных резолверов. Терпение — ключ к успеху; если кэшируется старый TTL с большим значением, эффективным действием является измерение оставшегося срока его действия и ожидание, а не перенастройка записи. Процесс онбординга арендатора должен моделировать "запись создана" и "безопасно активировать" как отдельные состояния, поскольку запись плоскости управления может быть быстрой, в то время как резолверы могут все еще хранить старые, кэшированные данные.Зоны, принадлежащие клиенту, подходят, когда контроль над пространством имен имеет первостепенное значение, но это требует активации, основанной на доказательствах, между административными границами. Зоны, принадлежащие платформе, идеально подходят для автоматического выпуска субдоменов для каждого арендатора, когда платформа может владеть пространством имен. В конечном итоге, проектируйте с учетом расхождений, наблюдая за завершением изменений DNS, а не полагаясь на декларации. Храните доказательства, отображайте ожидающие состояния и четко разграничивайте границы владения, чтобы уменьшить количество слепых повторных попыток и быстрее выявлять неисправности.