Troubleshooting DNS over TLS
I have been using DNSCrypt and DNS over HTTPS for a bit of time, but decided to give a try to the new DNS over TLS protocol today. The first problem I faced was the lack of software support and documentation on how DNS over TLS works and how to troubleshoot it.
I will try to fill this gap and talk a bit about DNS over TLS this article.
unEncrypted DNS
DNS is one of the most critical protocols for the Internet. Almost everything you do online starts first with a DNS request. The problem with DNS is that it is a clear-text protocol and everyone that is watching the traffic between you and your DNS provider, can see (and some times modify) the requests you are doing. It is actually common for ISPs and Hotels to hijack DNS requests to their own servers.
DNS over TLS
We all have learned (I hope) that we should not enter our passwords or personal information on sites without the padlock (known as HTTP:// sites). Google, Lets Encrypt, Mozilla and others are pushing the web to go to HTTPS:// only — encrypt everything. Google is even ranking HTTPS sites higher than the ones that are non-encrypted.
TLS (aka SSL) is the protocol we use on HTTPS. It wraps our HTTP requests into an encrypted form, so nobody can see our data. And the same TLS protocol can be used to wrap and encrypt our DNS requests.
I am over summarizing TLS here, but you can read about how it can be implemented with DNS on the RFC 7858.
DNS Server Support
DNS over TLS does not have a wide range of server support yet, but DNSDist , from the PowerDNS team, added support for it in their latest version. That's a great start for anyone looking to implement it themselves.
Also, 3 public DNS providers support DNS over TLS on port 853, allowing pretty much anyone to use it today:
-
9.9.9.9: Anycast DNS — filters malicious domains. 1.1.1.1: Anycast DNS — unfiltered 185.228.168.168 — Anycast DNS — filters malicious and adult/porn domains.
Troubleshooting DNS over TLS
The beauty of DNS over TLS is that it is the same DNS protocol, just wrapped around the TLS layer. That makes it very easy to debug and troubleshoot.
1- Using OpenSSL
Using the OpenSSL command line tool, we can easily check if a server has DNS over TLS support and see if the server is responding (this is specially important for 1.1.1.1 that is blocked in some location). In this example, I am using the s_client option to connect to port 853 on the CleanBrowsing IP:
$ echo | openssl s_client -connect ‘185.228.168.168:853’ |grep -B 2 -A 5 “Certificate chain”
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
CONNECTED(00000003)
— —
Certificate chain
0 s:/CN=cleanbrowsing.org
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
As you can see, they use Lets Encrypt and the server is replying properly. I can do the same thing for CloudFlare to verify my connectivity:
$ echo | openssl s_client -connect ‘1.1.1.1:853’
0 s:/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
2- Using the DNS over TLS PHP client
OpenSSL is a great tool to test, but doesn't allow you to send and receive responses easily. DNS is a binary protocol, and we will use the lightweight PHP over TLS client to simplify it for us.
To start we need to clone the repository:
$ git clone https://github.com/dcid/dns-over-tls-php-client
Cloning into ‘dns-over-tls-php-client’…
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 13 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (13/13), done.
Once that is cloned, you will see the dns-over-tls-php-client directory with the PHP file dnstls.php. That's the one we will use to test and send our queries.
To do a DNS request, you can run the command as:
$ php dnstls.php google.com cloudflare
google.com has address 74.125.24.100
google.com has address 74.125.24.101
If DNS over TLS is not supported (or you have the CloudFlare IP blocked), you will get this error:
Warning: stream_socket_client(): unable to connect to ssl://1.1.1.1:853 (Operation timed out) in /Users/nyk/dns-over-tls-php-client/dnstls.php on line 234
The tool supports CloudFlare, Quad9 and CleanBrowsing by default, but you can specify any IP address you wish. If you do not have the proper certificates installed on your server , you might get the following error:
Warning: stream_socket_client(): Peer certificate CN=`*.cloudflare-dns.com’ did not match expected CN=`1.1.1.1' in /Users/nyk/dns-over-tls-php-client/dnstls.php on line 234
That can be solved by upgrading OpenSSL locally on your server (or desktop). Note that if you are trying it against CleanBrowsing, it will return "domain not found" (NX) for domains that it blocks:
$ php dnstls.php pornhub[.]com cleanbrowsing
Host pornhub[.]com not found: 3(NXDOMAIN)
If you are using a custom resolver for DNS over TLS, you need to verify that its certificate is valid or you may get one of the errors I mentioned before.
DNS Privacy
And that's pretty much it for troubleshooting. DNS privacy is as important as HTTP privacy (HTTPS), so I recommend that everyone try DNS over TLS out and see if that works for you. You can also use DNSCrypt as it has more client support as this point.
Google Public DNS тихо включили поддержку DNS over TLS
Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.
Зачем это нужно
При использовании классической схемы DNS, провайдеры могут лезть своими грязными лапами в ваши DNS-пакеты, просматривать, какие домены вы запрашиваете, и подменять ответы как угодно. Этим же занимаются мошенники, подменяя резолверы на взломанных роутерах, чтобы направить пользователя на поддельный сервер.
C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.
А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.
Как это работает
На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.
К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.
Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).
Настройка на macOS
Установка
По умолчанию knot будет работать как обычный рекурсивный резолвер, подобно dnsmasq.
Редактируем конфиг
И добавляем в конец файла:
В итоге мой конфиг выглядит так:
Параметр hostname в данном случае — Common Name (CN) или Subject Alt Name (SAN) сертификата. То есть, доменное имя, для которого выпущен сертификат. По нему проверяется подлинность сертификата сервера.
Вот какие значения SAN у сертификата, который используется при подключении на 8.8.8.8:853
Любое из этих значений можно использовать в качестве параметра hostname. Если же вы будете разворачивать собственный публичный рекурсивный резолвер, у вас вряд ли получится выпустить X.509-сертификат на IP-адрес, поэтому в параметре hostname придется указывать доменное имя.
Запуск демона
Проверить, успешно ли запустился демон, можно командой:
процесс kresd должен слушать порт 53 на localhost.
Если что-то пошло не так, смотрим лог ошибок:
Проверка работы резолвера
Проверяем, что локальный резолвер отвечает корректно.
Установка в качестве системного резолвера
Если все работает правильно, можно назначить системный резолвер в свойствах сетевого адаптера:
В чем разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS.
DNSCrypt может работать по UDP и TCP. Подключение на порт 443. Для шифрования используется собственный протокол, который отличается от HTTPS. Может быть легко выделен с помощью DPI. Это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором, времени он будет полностью вытеснен последними.
DNS over TLS (DoT) — TCP-подключение происходит на порт 853, внутри тоннеля передается обычный DNS-запрос. Провайдер видит, что это DNS запрос но не может в него вмешаться. При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос, чем в over HTTPS.
DNS over HTTP (DoH) — TCP-подключение на порт 443, подобно обычному HTTPS. Внутри другой формат запроса, с HTTP-заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS-подключение. Полагаю, этот протокол был придуман на случай, когда DNS-запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А также, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.
По сути, DNS over HTTPS и over TLS — одно и то же, с немного отличающемся форматом запросов. Оба эти протокола приняты в качестве стандартов и имеют RFC. Вероятнее всего, в ближайшее время мы увидим массовое распространение их обоих.
DNSSEC — протокол цифровой подписи DNS-записей. Не имеет отношения к шифрованию, так как все запросы передаются в открытом виде. Может работать как по старому классическому протоколу DNS, то есть UDP/TCP на порту 53, так и внутри DNS over TLS/HTTPS. Целью DNSSEC является подтверждение подлинности DNS-записи. Владелец домена может добавить публичный ключ на корневые сервера своей доменной зоны и подписывать все записи на мастер NS-серверах. По сути, к каждой DNS записи, например, A-записи или MX-записи, добавляется еще одна запись типа RRSIG, содержащая подпись. Процедура валидации DNSSEC на рекурсивном резолвере позволяет установить, действительно эта запись была создана владельцем домена.
Улучшаем приватность – шифруем DNS трафик в системах GNU/Linux
Стандартный протокол DNS во время передачи трафика не использует шифрование, что тем самым делает его уязвимым. Подобная передача трафика может использоваться в атаках и также является уязвимой.
Для решения данной проблемы стоит использовать шифрование. На данный момент активно применяется шифрование DNS с помощью следующих методов: DNS поверх TLS (DoT), DNS поверх HTTPS (DoH) и DNSCrypt-proxy.
Методы шифрования DNS трафика используются как для шифрования всего DNS трафика, так и отдельно только для определенных браузеров, например: DNS over HTTPS в Firefox и DNS-over-HTTPS в Google Chrome. В этой статье мы рассмотрим достаточно легкий способ использования шифрования всего DNS трафика с помощью метода DNS поверх TLS в операционных системах GNU/Linux.
Для шифрования DNS трафика установим программу Stubby. Stubby — программа с открытым исходным кодом, которая работает в качестве локального приватного DNS резолвера. Для шифрования трафика использует метод DNS поверх TLS.
Перейдем к установке программы.
Для Ubuntu и подобных дистрибутивов:
Для ArchLinux и подобных дистрибутивов
По умолчанию используется шифрование через резолверы Sinodun и другие. Если мы хотим поменять резолверы например на Cloudflare или Comss.one DNS, то нам нужно будет отредактировать конфигурационный файл.
Перейдем к редактированию конфигурационного файла программы:
В строке upstream_recursive_servers заккоментируем строчки резолверов по умолчанию, перед строками добавим знак #.
Спускаемся чуть ниже и в строке OPTIONAL UPSTREAMS расскоментируем (убираем знак #) нужный нам резолвер.
А в случае Comss.one DNS добавляем следующие строки:
Сохраняем изменения комбинацией клавиш ctrl+o и ctrl+x.
Затем переходим в параметры сети и меняем DNS на следующее значение: 127.0.0.1
Если вы не используете systemd-resolved, и отключили его, например из-за утечки DNS в OpenVPN, то тогда вам нужно внести изменения в файл resolv.conf:
Заменяем строку nameserver на следующие две строки:
Сохраняем изменения комбинацией клавиш ctrl+o и ctrl+x. А так же сохраняем файл от дальнейшей перезаписи:
Запускаем приложение Stubby и включаем его службу:
Как проверить шифрование DNS трафика в GNU/Linux
Проверить шифрования DNS трафика в GNU/Linux можно с помощью следующих утилит Wireshark и Termshark. Мы воспользуемся Termshark.
Для работы Termshark необходимо установить следующий пакет:
для Ubuntu и подобных дистрибутивов:
для ArchLinux и подобных дистрибутивов:
Добавляем себя в группу wireshark:
Где username это имя пользователя.
Теперь можно скачать архив с файлом, который доступен по ссылке ниже.
Разархивируем архив, открываем терминал в папке с файлом и запускаем программу:
В строке Filter вводим слово DNS и нажимаем на кнопку Apply.
How to query for DNS over HTTPS/DNS over TLS using command line?
I’m writing a script that needs to query DNS record with a user specified DNS server. The DNS server may be in any protocol, including UDP, TCP, DNS over HTTPS (DoH), and DNS over TLS (DoT).
I know dig is able to handle DNS for UDP and TCP (with +tcp flag). Is there a way I can use dig or other tool to query DoH and DoT server?
I prefer already existing popular tools like curl so my script would be more portable, but other suggestions are welcomed as well.
6 Answers 6
I didn’t find a single tool for both the purpose, but I did find ways to use them.
There are two ways to query DoH:
For DoT, you can use kdig tool provided by knot . The command line is similar to dig :