Инвалидация адресов в ipset

[Danstiv]

Приветствую!
Настраивал по этой статье.
Всё вроде работало, но вчера случайно заметил, что google.com маршрутизируется через туннель.
После service firewall restart маршрутизация пошла через isp, в моём понимании произошло следующее.

1. Кто-то в локалке зарезолвил что-то гугловое, youtube.com например.
2. ip попал в ipset.
3. Через какое-то время случилась некая ротация, и google.com стал ссылаться на ip, который ранее был зарезолвлен, из-за чего он стал маршрутизировать его через туннель.

И если моя теория верна, то возникает вопрос, какая оптимальная стратегия инвалидации ip-шников в ipset?

[Danstiv]

Снова google пошёл через туннель.
Добавил в скрипт такую строчку.
nft flush set inet fw4 vpn_domains
Вот только есть одно но.
Я добавил в скрипт эту строчку, оно неделю крутилось, и где-то через 4 часа после последнего срабатывания скрипта я обнаружил, что google.com маршрутизируется через туннель.
Т.е. очистка ipset-а - не 100% решение.
Теоретически можно делать следующее:

1. При запросе сервера у dns запоминаем ip, домен и время добавления записи.
2. При отправке пакета на ip проверяем время добавления записи, если оно произошло более 10 минут назад, идём к dns, и ещё раз спрашиваем ip.
3. Если ip не изменился, обновляем время.
4. Если изменился, выбрасываем запись, а пакет отправляем через isp.

Но это лишь теория...

[Danstiv]

А ещё, в теории, google.com и youtube.com в один момент времени могут ссылаться на один и тот же ip, вот просто потому, что почему бы и нет?..
Им то пофиг, они по заголовку Host раскидают куда надо, а вот с роутера подлезть в туннель не так и просто.
Но тут уже совсем сложная схема должна быть, которая будет всё это учитывать.
Нужно либо эвристически угадывать, куда хочет сходить конкретный клиент, т.е. сопоставлять dns query и последующее открытие соединения на ip.
Либо залезать в туннель, как, например, adguard.
Вот только Adguard делает это на клиентском устройстве, а на роутере такое завести будет сложнее.