Не в том дело, что лень инициализировать содержимое ipset. Может, просто невозможно сделать это полностью Если вы создаете правило блокировки netflix.com, который этот точный адрес мог бы и быть предварительно заполнен, но не заполнен, то правило фактически будет анализировать (и блокировать) все поддомены, такие как login.netflix.com, something.netflix.com, a1b2c3.netflix.com… и просто нет способа узнать все поддомены, которые содержатся в домене и которые пользователь будет использовать/вызывать.

Поэтому большая работа (умно) выполняется DNS-разрешением и ipset-наборами. Даже если UI мог бы предварительно заполнить набор, он бы включал только указанное точное имя хоста, которое может меняться время от времени, потому что много чего используют CDN, и поскольку это не заблокировало бы весь спектр имен хостов, это бы мало помогло.

Я бы сказал, что использование dnsmasq и ipset — это отличное решение с почти атомарными обновлениями ipset-наборов и работает абсолютно нормально. По-настоящему нет необходимости предварительно заполнять что-либо, потому что это бы очень мало (если вообще) помогло.

И все это действительно требует, чтобы клиенты использовали UniFi Gateway в качестве DNS-сервера, потому что, благодаря использованию CDN, IP-адреса могут меняться в процессе работы. Если клиент А, который использует ваш UniFi Gateway в качестве DNS, разрешил заблокированный домен в 200.200.200.200, этот IP-адрес попадет в ipset-набор и будет заблокирован. Если клиент Б использует Google DNS и разрешает заблокированный домен в 201.201.201.201, и UniFi Gateway об этом ничего не знает, ipset-набор не будет заполнен и доступ будет предоставлен.

Для надежной работы блокировки доменов на UniFi Gateway, действительно очень важно/обязательно, чтобы клиенты использовали UniFi Gateway в качестве DNS-сервера.

Итак, вот как, я думаю, это должно работать... Шлюз лениво инициализирует ipset с адресами из DNS-запроса, а брандмауэр использует этот ipset для сопоставления. В большинстве случаев клиентам не нужно использовать шлюз в качестве DNS-сервера, чтобы это работало. Одной проблемной ситуацией будет случай, если клиентский и шлюзовой ресолверы получат разные адреса, и клиент использует адрес, которого нет в ipset политики.