Также заметил эту проблему с моей UDM, когда клиентские устройства настроены на использование PiHole в качестве DNS-сервера. Первым признаком того, что дело в этом, стало то, что это работало в одной сети, где UDM по-прежнему использовался в качестве резолвера, в то время как в других – PiHole. Подтвердилось, когда я настроил все свои сети на использование DNS UDM, и потоки начали резолвиться, когда клиенты в конечном итоге переключились обратно на UDM для DNS. Я предполагаю, что это связано с тем, что UDM не резолвил адрес клиента при подключении, поэтому у него нет кэшированного резолва для аккуратной записи с данными потока. UDM пришлось бы отправлять новый DNS-запрос каждый раз, чтобы разрешить IP для завершения записи, что бы добавило определенные сетевые накладные расходы на дополнительный резолв для каждого подключения. Это может быть не дорого с точки зрения обработки данных на DNS-сервере, поскольку данные, скорее всего, кэшированы, но увеличение DNS-трафика между UDM и его вышестоящим DNS-сервером могло бы накапливаться в загруженных сетях. Вероятно, есть и другие проблемы, но это одна из тех, которые приходят в голову.

Проблема, когда я просто возвращаюсь к DNS UDM и использую PiHole в качестве вышестоящего резолвера, заключается в том, что DNS-сервер Unifi не хватает так много функций, что я замечаю странные ошибки и несоответствия на некоторых операционных системах – например, временные локальные сбои DNS в некоторых приложениях на MacOS и iOS из-за отсутствия поддержки HTTPS-записей в реализации DNS-сервера UDM. Отсутствие поддержки CNAME-записей также невероятно раздражает!

Похоже, я могу иметь либо немного сломанное локальное разрешение сети и рабочие данные потока, либо сломанные данные потока и рабочее локальное фильтрование плюс DNS-разрешение, но не могу иметь и то, и другое.

Вот пример неудачного поиска Safari для URL-адреса локального веб-сервера, в котором есть A-запись в DNS UDM, MacOS и iOS отправляют запрос на A-запись, а затем второй запрос на поиск HTTPS-записи, HTTPS-запись не возвращает допустимых данных и приводит к неудаче Safari при правильном разрешении URL-адреса, что приводит к неудаче подключения.

A-запись, которая прекрасно работает:
[Q190] Получен допустимый ответ размером 45 байт от 10.254.0.1 по UDP через any/0 -- id: 0x909C (37020), флаги: 0x8580 (R/Query, AA, RD, RA, NoError), счетчики: 1/1/0/0, pi.my.lan. IN A?, 0 IN A 10.254.0.2

Последующий запрос типа HTTPS-записи к UDM ломается и возвращает SOA, не указывает на сбой или отсутствие записи и т.д., что может указывать на то, что DNS-записи не существует. Safari затем не может подключиться к веб-серверу.

[Q32697] Получен допустимый ответ размером 104 байта от 10.254.0.1 по UDP через any/0 -- id: 0xBB76 (47990), флаги: 0x8580 (R/Query, AA, RD, RA, NoError), счетчики: 1/0/1/0, pi.my.lan. IN HTTPS?, . 1067 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2025070300 1800 900 604800 86400

Если я верну конфигурацию DNS клиента обратно к использованию DNS PiHole, оба запроса всегда разрешаются правильно и проблем нет. Именно такие странные проблемы заставили меня отказаться от DNS-сервера UDM, и похоже, что эти проблемы до сих пор не решаются.

Я бы хотел думать, что логи показывают все новые "соединения", но не уверен, что это действительно так. Недавно проводил тестирование и заметил, что некоторые DNS-запросы не фиксируются, но у меня пока не было времени разобраться, проблема в настройке или нет.