Comments 29
Таким образом, несмотря на восприятие многими DoH как панацеи, он оказывается неприменим без дополнительных (да и не нужных) усилий, ни для чего иного кроме, браузерных технологий.

Так ведь и DoT пока не панацея и, в целом, требует дополнительных усилий. Хотя в Android 9 он поддерживается ''из коробки''.

В общем, всё выглядит так, что мэйджоры спят и видят как заполучить ещё и данные с пользовательских DNS для улучшения своей аналитики (читай — повышения прибылей), и, поэтому, всячески форсят внедрение DoH.


и DoT пока не панацея

DoH требует модификации всего клиентского софта, в то время как DoT модификации системы и вообще не затрагивает прикладное программное обеспечение.

В данном случае тогда не понятно зачем весь этот оверхед с инскапсуляцией пакетов DNS в HTTP и затем в TLS (DoH), когда можно обойтись прямой DNS в TLS (DoT).
То есть в случае защиты DNS трафика на уровне сервера DoH избыточен и куда как лучше использовать DoT.

Кстати, читал где-то, что якобы DNSCrypt2 быстрее работает, т.к. использует UDP.

Сам DNS, вообще-то, по умолчанию использует UDP.
DNScrypt, несмотря на то, что он был первым относительно популярным решением по защите DNS трафика, я считаю классическим примером оверинжениринга, дурно скроенным и сложным в настройке и поддержке. Использование стандартных DNSSEC/DANE в связке с DoT делает его не нужным. Писать об этом здесь подробно вряд ли имеет смысл.

а проксирование DNS-запросов случаем не приводит к тому что CDN будут отдавать IP-шники поближе к прокси, а не к клиенту? или unbound транслирует исходный IP при обращении к вышестоящему DNS? я к сожалению не представляю формат запроса и что в нём передаётся…

constb
Unbound это кэширующий рекурсивный DNS сервер. Соответственно, запрос разворачивается от корневых DNS серверов через TLD непосредственно к DNS обслуживающим конкретный домен. Использование собственного DNS, в данном случае через DoH API, сервера это попытка избежать контроля всякого рода, в том числе и со стороны CDN, для повышения безопасности и приватности.

В случае настройки без forwarders в том, что вы получаете данные из первых рук, а не через DNS провайдера / CDN / Public DNS.
Шифрование это другой аспект, но Unbound умеет и его тоже (см.
Безопасность и защита DNS трафика). Вопрос в том, умеют ли его опрашиваемые сервера.
Безопасность ещё и может обеспечиваться через DNSSEC для доменов, его использующих. Unbound, разумеется, его поддерживает.

Подскажите, есть ли смысл дома поднять unbound? Я так понимаю идея в том, что бы упоковать DNS запросы в TLS и спрятать от провайдера как минимум. Но все равно придется форвардить трафик на публичные днс провайдеры. Выходит или полностью свой сервер поднимать как в статье. Или особо смысла нет выходит?
Но все равно придется форвардить трафик на публичные днс провайдеры

Не придётся. То есть можно, но зачем это делать при наличии собственного рекурсивного DNS да ещё и с кэшем?


Подскажите, есть ли смысл дома поднять unbound?

Смысл есть.
Схема зависит от вашего случая. Оптимально поднять Unbound локально (вар. — в локальной сети), а на нём использовать форвадинг к серверу(ам) с поддержкой DNS-over-TLS. Опять же, можете использовать второй Unbound расположенный в юрисдикции не столь высокодуховных стран, как, к примеру, Россия или Иран.

я тут погуглил, нашел вот такие примеры
calomel.org/unbound_dns.html
В частности «DNS over TLS, recursive caching DNS, TCP port 853 ENCRYPTED (example 2)»

Там в конфиге есть секция forward, я так понимаю, дабы избежать этого, нужно поднять еще свой unbound в роли сервера где нибудь на cloud уже

Да, всё верно. Локальный Unbound обращается по защищённому каналу к облачному.

Если есть на чем — то стоит одназначно.
Например форварды с шифрованием:
Заголовок спойлера
    # Forward all queries to specified servers
    forward-zone:
        name: "."
        #DNS over TLS servers
        forward-addr: 1.1.1.1@853
        forward-addr: 1.0.0.1@853
        forward-addr: 8.8.8.8@853
        forward-addr: 8.8.4.4@853
        forward-ssl-upstream: yes

        #Quad9 (have TLS, but filter some malware domains)
        forward-addr: 9.9.9.9@853
        forward-addr: 149.112.112.112@853

        #Quadrant Information Security (no filter)
        forward-addr: 12.159.2.159@853

        #NO ENCRYPTION NEVER USE IT
#       forward-addr: 1.1.1.1
        # OpenDNS
#       forward-addr: 208.67.222.222
#       forward-addr: 208.67.220.220
#       forward-addr: 64.6.64.6
#       forward-addr: 64.6.65.6



+ блокировка рекламы.

Дурацкий вопрос. Столкнулся с перехватом у ряда провайдеров обмена по днс протоколу. И подмену ответов на свои ответы. Unbound эту проблему решает?

Решает защищённый канал до внешнего по отношению к провайдеру DNS.
DoH, DoT, DNScrypt, как раз, про это. Мы тут в дискуссии обсуждали уже.

Обещают добавить в него поддержку DoH и свой кэш. Но пока этого нет.

Ну обычно используют его в связке с Dnsmasq или Unbound, хотя последний и так умеет в DoT.

В случае Unbound нужда в дополнительных прокси, каковым и является Stubby, отсутствует.
Возвращаясь к теме статьи. Для DoH желательно иметь DNS ресолвер который будет максимально быстро отвечать на запросы и Unbound с его кэшем в памяти и, кстати, префетчем обновлений кэшированных данных, просто идеальный кандидат.

Разработчики Stubby так не считают, указывая на то, что unbound на данный момент "does not have all the TCP/TLS features that Stubby has".


И чем dnsmasq не годится? На openwrt он потребляет меньше ресурсов, а DoH в Unbound все равно нет.

И чем dnsmasq не годится

Например, тем, что, во-первых, он тоже не умеет полноценное кэширование (насколько я помню, он запоминает только негативные результаты), не говоря уже про префетч, и является только форвардером, а, во-вторых, имеет избыточный для данной задачи функционал.


DoH в Unbound все равно нет

И, скорее всего, не будет, потому что это больше про HTTP, чем про DNS. И слава богу.

является только форвардером, а, во-вторых, имеет избыточный для данной задачи функционал.

Так то, что unbound не 'является только форвардером' и есть 'избыточный для данной задачи функционал'. Или о каком функционале dnsmasq речь? Если о том, что это еще и DHCP-сервер, то на openwrt, это скорее преимущество, чем недостаток.


не будет, потому что это больше про HTTP, чем про DNS

Если эти фичи, в итоге, не уменьшают, а увеличивают приватность, тогда это только плюс.

Или о каком функционале dnsmasq речь?

О функционале DHCP/BOOTP, разумеется. Вообще, у него несколько иное назначение.


Если эти фичи, в итоге, не уменьшают, а увеличивают приватность, тогда это только плюс.

Безусловно. Только мне, как и разработчикам Unbound, не понятно зачем HTTP нужен в DNS сервере. Как показано в статье, при желании вопрос решается написанием простой прослойки при помощи любого удобного инструмента.

Но, если в итоге выходит, что dnsmasq — более легковесное решение, даже если нам и не нужен это функционал, то довольно странно о нем говорить.


Кстати, не могу найти информации о том, что у него неполноценное кэширование, мб уже доработалили? Наоборот, пишут, что dnsmasq позволяет сохранять кэш при перезагрузках, в отличии от unbound.

На тот момент, когда я смотрел dnsmasq кэшировать, как я и написал выше, он не умел.

Only those users with full accounts are able to leave comments. Log in, please.