На самом деле это можно сделать прямо на контроллере. Проверьте, изменился ли IP, и передайте эту информацию всем устройствам (unifi-устройствам) на контроллере. Так это произойдет мгновенно (ну, очень быстро), и не придется менять TTL. В общем, отправьте команду обновления DNS на оборудование с контроллера.

TTL для A-записи в DNS для «unifi.customdomain.com» установлен на короткий срок? Клиенты (и кэширующие резолверы) должны хранить ответы DNS столько, сколько указано в этом TTL, и не запрашивать заново, пока он не истечет. Если вы не уверены в значении TTL, его можно проверить следующими командами:  
Linux: dig unifi.customdomain.com  
Windows: nslookup -type=A -debug unifi.customdomain.com  
Обратите внимание, что нужно смотреть именно TTL для A-записи, а не для записи authority/SOA вверху (они важны только если вы меняли DNS-хостинг вашего домена).

Прошло два года, а проблема всё та же. Некоторые устройства настроены на информирование по адресу http://unifi.customdomain.com:1234/inform. IP-адрес customdomain.com изменился, но устройства всё равно пытаются использовать закешированный IP. Заходил по SSH на устройства и пингуя домен, подтвердил это. Есть какие-то новости по этому поводу?

Возможно, мой случай использования не такой уж и распространённый, как я думал. Я не очень хорошо знаком с Ubiquiti, но предполагал, что их в основном используют «просумеры» и малый бизнес. Думаю, контроллеры на динамическом DNS встречаются у таких пользователей довольно часто, но, с другой стороны, я не нашёл много людей с такой проблемой, так что, наверное, я ошибаюсь, и это скорее изолированный сценарий.

Согласен, что внедрение в обычную библиотеку было бы более аккуратным решением, но, наверное, у Ubiquiti было бы больше веса и влияния в этом плане, чем у меня!

Так почему мы не можем заставить контроллер обновлять запись DNS на устройствах? Отправить запрос на обновление только одной записи DNS — записи с именем и IP контроллера. В этот момент никакого запроса к DNS-серверу не происходит, вы просто меняете то, что хранится на AP. Тогда, когда он отправит информ, он отправит его на правильный IP-адрес.

Нет, вы на самом деле требуете, чтобы система предположила, что указанный TTL — это ложь. Это единственная причина, по которой она вообще должна повторно отправлять DNS-запрос. Если вы верите в TTL, то должны ожидать получить тот же самый ответ, что и раньше, и тогда зачем снова делать запрос? Этот TTL явно говорит, что запись A действительна минимум указанное время и не изменится раньше. Либо вы верите этому факту, либо нет. Пытаться решить проблему с TTL DNS, заставляя клиентов обходить это и повторно опрашивать «не кэширующий» DNS-резолвер, кажется абсурдом. А что вообще в этом контексте такое «не кэширующий» DNS-сервер? Он каждый раз выполняет полную рекурсию с root hints? У вас такой в сети есть? Если ваша основная идея в том, что DNS-серверы сейчас гораздо быстрее, почему бы тогда просто не поставить TTL равным 1 и не закончить с этим? Зачем вообще добавлять странные ухищрения на стороне клиента? Хотя я согласен, что стандарты довольно гибкие и часто нарушаются во имя функционала, у всего есть пределы. Я не ожидаю, что мой браузер при ошибке соединения с сайтом начнёт автоматически очищать запись из DNS-кэша. У вас есть примеры продуктов, которые делают то, что вы здесь предлагаете? Обычно разрешение DNS — это функция операционной системы, и ни Windows, ни Linux так не делают.

Странный аргумент. На самом деле это не нарушает принципы DNS. Есть высокоуровневые RFC (1034, 1035) и еще куча рекомендательных RFC (1591, 3071 и т.д.), которые настолько устарели, что вообще не похожи на современный интернет. Мне кажется, я прочитал все эти документы, но не вижу, как это противоречит каким-то актуальным принципам. Не стоит сразу думать, что это ложь. Лучше предположить, что раз информ (inform) несколько раз не сработал, то тут может быть что-то другое. Это просто разумное использование резервного варианта. Что тебе лучше: делать систему без резервных вариантов, и если что-то перестанет работать, можно будет указать на кого-то, кто нарушил стандарт? Я предпочитаю, чтобы системы работали. Да, это был один из изначальных принципов, но он давно устарел. DNS-серверы стали намного быстрее (частично за счет самого ПО и аппаратного обеспечения серверов, частично из-за архитектуры серверов и улучшений в архитектуре интернета в целом, особенно с развертыванием Anycast). Времени жизни (TTL) записей сильно сократились. Они могут быть даже 60 секунд, и всё будет нормально работать. Поэтому я и сказал, что сегодня почти нет таких принципов DNS, которые действительно применимы.

Как я писал в первом сообщении, можно сделать дополнительный запрос к некэширующему серверу имен. Это легко реализуется. Было бы лучше, если бы устройство доверяло DNS реализации ОС и не трогало ничего вне пользовательского пространства? Да, это была бы «чище» с точки зрения программирования, но выбираешь то, что лучше для пользователей, а не то, что чище.

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

Я знаю, как правильно использовать DNS, по крайней мере в своих продуктах. Но знаешь, не всегда сеть разворачивается в контролируемой среде. Случай, с которым я столкнулся, был в доме одного моего родственника, где я на время развернул систему в качестве услуги, и там просто невозможно иметь статический IP. Контроллер — это Cloud Key в их сети, но точкам доступа придется перемещаться между этим домом и другим объектом, поэтому я решил, что логичнее всего будет настроить информ-адрес на динамическое DNS-имя, хостящееся у них дома, чтобы при переносе точек доступа на удаленный объект всё продолжало работать.

Извини за длинный ответ, но твой комментарий, по-моему, заслуживал развернутого объяснения, потому что в нем было много неверных предположений. В завершение: если ты считаешь стандарты каким-то законом, то Facebook нарушает почти все стандарты подряд. Это всего лишь рекомендации — если нужно обойти стандарт, чтобы сделать что-то лучше или быстрее, так и делай. Ни одна хорошая инфраструктура не рассчитывает, что все третьи стороны будут строго соблюдать стандарты, иначе пользователи будут страдать.