Вопрос правды не является техническим по своей сути, поэтому вы никогда не сможете полностью ответить на вопрос, такой как "Должен ли я доверять X", особенно если вы добавите «... не выполнять действие Y в некотором отдаленном будущем Z».
Тем более что в своем вопросе вы, похоже, не уверены как в самом поставщике, так и в том, что происходит на пути между ним и вами.
Если вы хотите лучше контролировать процесс разрешения, у вас нет другого выбора, кроме как запустить собственный рекурсивный кеширующий сервер имен, либо непосредственно на вашем хосте, либо на каком-либо другом, которому вы доверяете. Особенно, если вы хотите полностью убедиться, что используете функции, предоставляемые DNSSEC: если вы используете удаленный проверяющий сервер имен, вы доверяете ему, чтобы все вычисления DNSSEC выполнялись для вас правильно.
Поэтому я даже не буду пытаться оценить, будет ли 1.1.1.1 (CloudFlare) или 8.8.8.8 (Google) или 9.9.9.9 (IBM+PCH+GlobalCyberAlliance) или OpenNIC или любой другой на https://en.wikipedia.org/wiki/Public_recursive_name_server или еще один заслуживающий доверия или более надежный, чем другой. Это также очень личное мнение (которому вы доверяете), и оно меняется со временем.
Ваше утверждение "но оно определенно не подходит для каждой семьи". не так однозначно. Движение все больше и больше для людей, чтобы обрабатывать свое разрешение DNS в домашних условиях (или пересылать на один из предыдущих общедоступных), и корневые серверы имеют много возможностей. Обратите внимание, что проблема может не заключаться в действительности, поскольку этот файл зоны перемещается медленно, имеет небольшой размер и везде кэшируется. Проблема может быть гораздо больше на некоторых серверах имен TLD, например .COM , где файл зоны содержит как миллионы записей, так и регулярные изменения, которые могут быть не маленькими.
У вас есть различные варианты на столе, которые вы иногда можете смешивать и сочетать:
- Используйте минимизацию QNAME (поддерживаемую некоторыми из вышеперечисленных общедоступных сервисов) на используемых вами серверах имен. Это дает меньше информации каждому серверу имен, оставляя протокол DNS работать точно так же, как и раньше
- Вы можете использовать теперь стандартный DNS поверх TLS, чтобы иметь возможность запрашивать любой сервер имен, предлагающий вам (опять же, некоторые из общедоступного сервера делают или планируют сделать) или даже "скоро" DNS через HTTPS. Делая это, конечно, вы просто перемещаете проблему: вы защищены от угонщиков на пути, но вам нужно установить аутентификацию конечной точки, с которой вы обмениваетесь; Опять же, проще, если вы сами справитесь.
- Некоторые советуют просто использовать "несколько" общедоступных DNS-серверов случайным образом (чтобы ни один из них не получил весь ваш трафик) и даже сравнивать результаты.
- У вас также есть несколько более тонких инструментов, таких как Stubby (использующий API getdns), который пытается предоставить вам лучшие функции с точки зрения конфиденциальности, но также может быть настроен на использование ранее небезопасного механизма, если вы предпочитаете доступность над безопасностью. Программное обеспечение, такое как dnssec-trigger, также пытается сначала дать вам преимущества DNSSEC, используя ваши серверы имен по умолчанию и проверяя, что они действительно работают правильно, и собирается обрабатывать запросы самостоятельно, если это необходимо.
- Чтобы быть исчерпывающим, мне нужно перечислить DNSCrypt (открытый, но не стандартизированный), который направлен на предотвращение подмены. Однако вам нужны конкретные клиенты и серверы для связи по этому протоколу.
Чтобы расширить свои знания, эта вики может стать хорошим началом: https://dnsprivacy.org/wiki/
