TL;DR: DNS-резолвер в Windows 10 отправляет запросы на все известные системе адреса DNS-серверов параллельно, привязывая запрос к интерфейсу, и использует тот ответ, который пришел быстрее. В случае, если вы используете DNS-сервер из локального сегмента, такое поведение позволяет вашему провайдеру или злоумышленнику с Wi-Fi-точкой подменять записи DNS, даже если вы используете VPN.
Современные версии Windows добавляют головные боли активным пользователям VPN. DNS-резолвер до Windows 7 включительно имел предсказуемое поведение, совершая запросы к DNS-серверам в порядке очереди и приоритета DNS-серверов, в общем-то, как и все остальные ОС. Это создавало так называемый DNS Leak (утечка DNS-запроса через внешний интерфейс при подключенном VPN) только в том случае, если DNS-сервер внутри VPN-туннеля не ответил вовремя, или ответил ошибкой, и, в целом, не являлось такой уж вопиющей проблемой.
Windows 8
С выходом Windows 8, Microsoft добавила весьма интересную функцию в DNS-резолвер, которая, как я могу судить по Google, осталась совершенно незамеченной: Smart Multi-Homed Name Resolution. Если эта функция включена (а она включена по умолчанию), ОС отправляет запросы на все известные ей DNS-серверы на всех сетевых интерфейсах параллельно, привязывая запрос к интерфейсу. Сделано это было, вероятно, для того, чтобы уменьшить время ожидания ответа от предпочитаемого DNS-сервера в случае, если он по каким-то причинам не может ответить в отведенный ему таймаут (1 секунда по умолчанию), и сразу, по истечении таймаута, отдать ответ от следующего по приоритету сервера. Таким образом, в Windows 8 и 8.1 все ваши DNS-запросы «утекают» через интернет-интерфейс, позволяя вашему провайдеру или владельцу Wi-Fi-точки просматривать, на какие сайты вы заходите, при условии, что ваша таблица маршрутизации позволяет запросы к DNS-серверу через интернет-интерфейс. Чаще всего такая ситуация возникает, если использовать DNS-сервер внутри локального сегмента, такие DNS поднимают 99% домашних роутеров.Данную функциональность можно отключить, добавив в ветку реестра:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClientПараметр типа DWORD с названием:
DisableSmartNameResolutionи любым значением, отличным от нуля, что возвращало старое поведение резолвера.
Windows 10
Хоть Windows 8 и 8.1 отправляли все ваши запросы без вашего ведома через публичный интерфейс, совершить подмену DNS-ответа таким образом, чтобы перенаправить вас на поддельный сайт, было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера, коим является сервер внутри шифрованного туннеля.Все изменилось с приходом Windows 10. Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел, что позволяет практически всегда вашему провайдеру перенаправить вас на заглушку о запрещенном сайте или злоумышленнику на поддельный сайт. Более того, способ отключения Smart Multi-Homed Name Resolution, который работал в Windows 8.1, не работает на новой версии.
Единственный приемлемый (хоть и не самый надежный) способ решения проблемы — установить DNS на интернет-интерфейсе вне локального сегмента, например, всем известные 8.8.8.8, однако, он не поможет в случае с OpenVPN. Для OpenVPN единственным (и некрасивым) решением является временное отключение DNS на интернет-интерфейсе скриптами.
UPD: ранее в статье рекомендовалось использовать параметр
redirect-gateway без def1 для OpenVPN. Оказывается, Windows возвращает маршрут по умолчанию от DHCP-сервера при каждом обновлении IP-адреса, и через какое-то время весь ваш трафик начинал бы ходить в обход VPN. На данный момент, красивого решения не существует.
Комментарии (61)
saboteur_kiev
11.08.2015 00:21-4Использовать странные dns сервера в организации вообще не есть гуд. А для домашнего пользователя 8.8.8.8 вполне нормально.
В win7 и меньше как раз было проблемой то, что отвечал только один DNS, и если например нужно обратиться к внутренним ресурсам, не публикующимся наружу, была проблема что внешний DNS не мог их резолвить, а внутренний DNS мог не резолвить что-то другое снаружи.
А если один из DNS отвечает что сервер не найден, к другому уже и не обращается — мне всегда казалось, что это неправильно.
Сейчас стало логичнее. Хотя было бы лучше поведение dns клиента при ошибках настраивать гибче.
Goodkat
11.08.2015 01:46А для домашнего пользователя 8.8.8.8 вполне нормально.
Я тоже так думал и довольно долго им пользовался, но очень часто разные сайты были недоступны — я грешил на сами сайты, пока вдруг несколько раз я не смог попасть на сайт Гугла, в то время как у всех остальных сайт Гугла был доступен. Сменил DNS на провайдерский, и проблемы исчезли. Возможно, 8.8.8.8 и 8.8.4.4 просто не справлялись с нагрузкой, не знаю.
Klaster
11.08.2015 02:36Было такое, то перестает отвечать днс провайдера, то днс гугла, фигня какая то. То ли провайдер специально блочит днс гугла, то ли что, не знаю. Перешел на днс от яндекс. Проблема исчезла.
JIghtuse
11.08.2015 06:00-4Google где-то писал, что эти адреса не для внешнего использования, они не рассчитаны на какую-либо нагрузку. А один из открытых проектов (dnsmasq?) использует их по умолчанию, поэтому нагрузка на них всегда есть.
icCE
11.08.2015 06:10+4Вообще то нет.
Но фраза типа одна бабка сказало, это хорошо.
developers.google.com/speed/public-dns
Более старый вариант: web.archive.org/web/20110830223912/http://code.google.com/intl/ru/speed/public-dns/docs/intro.html
geektimes.ru/post/77199
Ну итд итп.
В конце концов wikipedia
ru.wikipedia.org/wiki/Google_Public_DNS
Хотя, это еще тот источник знаний.JIghtuse
11.08.2015 17:39+1Да, я ошибся, речь вообще шла об ntp и о надёжности не гуглового сервиса. systemd по умолчанию использует серверы Google, народ обсуждал, на что бы переехать другое. Как оказалось, pool.ntp.org не рекомендуют ставить стандартным сервером — это меня удивило, а упоминание Google просто в голове отложилось.
github.com/systemd/systemd/issues/437
saboteur_kiev
11.08.2015 16:15+2Моя статистика показывает, что DNS сервера домашних мелких провайдеров глючат горазо чаще, чем гугловский.
Кстати, не очень понял за что заминусовали. Я считаю, что если один DNS сервер вернул ошибку, это еще не повод, что сайта действительно нет, и во многих случаях я бы хотел больше управлять поведением днс клиентом.
Он собственно и в Линукс себя также ведет — второй ДНС сервер опрашивает только в том случае, если первый ДНС не отвечает.
В нескольких крупных компаниях (200+ тыс.человек), где необходимо разделать внутренние и внешние ресурсы, проблема ресолва парочки адресов решилась исключительно через hosts файл, что неудобно. А было бы можно настроить поведение при ошибке, можно было бы просто два DNS сервера разных указать.
vanxant
11.08.2015 01:49+11Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
Ну и если ваше оборудование автоматом цепляется за любой вайфай без пароля с dhcp… При таком уровне безопасности утечка dns не самая критичная уязвимость имо.
Так что в нормальной сети проблем не будет, кмк. А там где будут — там и без этого дыра на дыре.
ValdikSS
11.08.2015 10:11Дело не в DNS провайдеров, и не в автоматическом подключении к сетям. Даже если вы дома на роутере настроили сторонние DNS, но этот же роутер поднимает кеширующий DNS (как это обычно бывает) на интерфейсе локальной сети, вы же не будете прописывать эти DNS еще и на компьютере, ведь от этого, во-первых, пострадает кеширование, да и вообще, какой смысл тогда настраивать на роутере, верно? И вы ожидаете, что все в порядке, подключаете VPN, и — бах — все ваши DNS-запросы идут не так, как вы ожидаете.
Та же ситуация с Wi-Fi в кафе. Подключаетесь к Wi-Fi, используя DNS, предоставленный по DHCP, сразу подключаетесь по VPN и надеетесь, что все в порядке, а на деле, все ваши DNS-запросы могут быть подменены злоумышленником.
kacang
11.08.2015 19:19+1Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
На самом деле, всё ещё хуже. Они не только запросы к себе подменяют, но и к любым другим. У нас например, провайдер нагло изменяет все ДНС пакеты в которых упомянуты запрещённые имена. Даже 8.8.8.8 тут не поможет. (Зато через VPN всё как надо)
virtustilus
12.08.2015 21:22Вот Билайн так точно делает. Какое-то время назад столкнулся с проблемой, что 8.8.8.8 и тот же самый через VPN возвращают абсолютно разные данные.
ValdikSS
12.08.2015 21:23Мобильный МТС еще.
NickKolok
18.08.2015 16:26И есть ли какое-нибудь решение? Сгодится и технический вариант (юзабелен ли сейчас DNSCrypt на Linux?), и юридический (выдать дружных люлей за модификацию трафика, хотя вряд ли получится).
А вообще провайдер должен быть трубой в пространство IP/IPv6. Всё остальное его не касается.
klikalka
19.08.2015 10:17+1Провайдеры могут подменять DNS, и подменяют.
И не всегда это плохо.
Перенаправить клиента, у которого отрицательный баланс, на страничку с информацией, ссылкой на личный кабинет и возможностью начисления обещанного платежа — вполне себе нормальное и более чем приемлемое, я считаю, использование этой возможности. Для «домашних» пользователей это проблемой не является.
Впрочем, практически весь трафик можно перенаправить куда нужно.
amarao
11.08.2015 05:37Хотел сказать «поднимите локальный ресолвер и закройте iptables всем, кроме него доступ к dns», но понял, что не знаю как это всё называется в виндах.
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?icCE
11.08.2015 06:06+4Ну так в windows можно указать несколько ДНС, проблема же в другом. Оно тут и описана, что винда кладет болт на это и делает по своему.
IRainman
11.08.2015 07:24У меня стойкое ощущение, что это всё таки баг 10, а не фича и настройку для отключения либо потеряли, либо изменили, но нормально не задокументировали.
ValdikSS
11.08.2015 10:15Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
nsswitch точно есть, и аналог resolv.conf через реестр можно сделать, но это все костыльно и неудобно, к сожалению.
Понятное дело, что локальный резолвер решает проблему, но нужно всегда помнить о необходимости убирать DNS на других интерфейсах, т.к. в Windows они привязаны к интерфейсам.
saboteur_kiev
11.08.2015 16:27то есть для линукса можно настроить nsswitch что-то типа:
dns [NOTFOUND=continue] nis
и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?amarao
11.08.2015 18:01Насколько я знаю, как раз строго нет, от чего страдают всякие любители «альтернативных DNS через vpn», когда хочется, чтобы «не нашёл один — спроси у другого».
saboteur_kiev
11.08.2015 18:12Вот у нас похожая проблема.
По vpn подключаемся к сети заказчика, внутри которой есть свой DNS, резолвящий эти внутренние ресурсы.
Но многие внешние ресурсы он не резолвит, и учитывая локацию заказчика сильно лагает. А если таких заказчиков со своими DNS-ами два, то уже совсем никак. Поэтому возможность опроса нескольких серверов удобно.
Единственное, что в статье действительно не описали что будет, если win10 делает запрос, и самый быстрый сервер отвечает отказом. Дождется ли оно ответа от других серверов, или сразу отлуп?
Merlyel
14.08.2015 20:53и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
Нет. Если DNS не нашел запись, ломиться в nis. А DNS опрашиваются по очереди из resolv.conf. Если первый не ответил — идем ко второму. Но если первый сказал, что записи нет (именно ответил «фигвам», а не отвалился по таймауту), то дальше опрос не проводится.
IRainman
11.08.2015 07:32ValdikSS правильно ли я понимаю, что на примере OpenVPN директива конфига:
push "redirect-gateway def1 bypass-dhcp"
тоже не решает проблему? И даже при добавлении принудительного:
push "route 0.0.0.0 0.0.0.0"
разумеется, что:
push "dhcp-option DNS xxx"
должен быть добавлен.
проблема останется? То есть верно ли я понимаю, что суть бага в том, что резольвер напрямую привязывает адреса DNS к интерфейсам, при этом полностью игнорирует правила маршрутизации?IRainman
11.08.2015 07:43Упс, прочитал по диагонали пост, прошу прощения:
Если вы используете OpenVPN, убедитесь, что он заменяет маршрут по умолчанию, а не добавляет два маршрута 0.0.0.0/1 и 128.0.0.0/1 (параметр redirect-gateway должен быть без def1), т.к. в этом случае Windows сможет привязать запрос к интерфейсу и успешно отправить его в незашифрованном виде.
Ответ уже есть, ValdikSS благодарю.
Zelgadis
12.08.2015 21:29Чья идея изначально — роутить только половину интернета? Вы вкурсе же, что 0.0.0.0/1 это не 0.0.0.0/0?
ValdikSS
12.08.2015 21:39Почему половину-то? Добавляются два маршрута — 0.0.0.0/1 и 128.0.0.0/1, так что маршрутизируется весь интернет.
Zelgadis
12.08.2015 21:41Ну да, но зачем два маршрута то добавлять? Я не про этот комментарий сейчас. Просто встречал много OpenVPN серверов и документаций где маршрут указывают 0.0.0.0/1, а потом страдают, что только половина работает.
ValdikSS
12.08.2015 21:42Затем, что если в Windows добавить default route и удалить старый, то старый через какое-то время (во время следующего DHCP renew) опять появится, причем с метрикой ниже, и весь ваш трафик чудным образом пойдет не через VPN, а в обход. Больше причин, в общем-то, нет, наверное.
И где вы такую документацию встречали, кстати? Обычно нигде не пишут добавлять маршруты вручную, а используют redirect-gateway def1, который как раз добавляет два маршрута.
ValdikSS
11.08.2015 10:18+1Он не игнорирует правила маршрутизации, а делает bind к интерфейсу перед тем, как отправить запрос, поэтому если у вас есть маршрут через локальный интерфейс, который в обычной ситуации не используется (выше метрика, перекрывается более узкими сетями), то Windows сможет его использовать.
Самое противное, что проблема проявляется на самой распространенной конфигурации: подключаемся к роутеру, роутер выдает DNS на свой IP-адрес, и из этого же диапазона нам выдается адрес по DHCP. Маршрут до DNS, естественно, никак не убрать, т.к адрес next hop и DNS совпадают.
kuber
11.08.2015 08:33+4>> было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера
Вот это раньше была безопасность т.е. стоит отвлечься основному DNS и на тебе дыра в безопасности. Если вы так беспокоитесь о безопасности, то у вас вообще не должны быть прописаны DNS, которым вы не доверяете.
>> не может ответить в отведенный ему таймаут (1 секунда по умолчанию)
2 секунды таймаут по умолчанию.
>> Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел
В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).
P.S. В групповых политиках настройка доступна здесь:
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolutionValdikSS
11.08.2015 10:252 секунды таймаут по умолчанию.
Все же одна.
If no response is received after 1 second, client queries the second DNS server of the list and at the same time queries again the first DNS server
support.microsoft.com/en-us/kb/2834226
В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).
Вот оно работает в Windows 8.1, но не работает в Windows 10, или у меня руки кривые.kuber
11.08.2015 10:44>> Все же одна.
Ох, ты. Там оказывается все много сложнее, чем казалось.
>> но не работает в Windows 10, или у меня руки кривые.
Описание взял из Windows 10.
PsyHaSTe
11.08.2015 10:57Практически уверен, что это просто баг. Стоит попробовать зареквестить его, наверняка скажут, что поправят.
DarkByte
11.08.2015 12:29-1Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.
И есть такие провайдеры, которые считают что нужно обязательно сделать свою доменную зону (доступную только из локальной сети и известную только DNS серверам провайдера), которые кроме того особо не заморачиваются с блокировками и фильтруют только по DNS, причём только на своих серверах. Соответственно для того, чтобы всё работало хорошо, первым DNS сервером указывается внешний (google public dns, например) сервер, а вторым уже DNS от провайдера. И если я правильно понимаю, то в десятке такая конфигурация будет работать корректно.icCE
11.08.2015 16:50>Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.
А чем сейчас лучше?
Отправилось на все известные днс, самый быстрый ответил, что сайта нет и на другие запрос не отправляется ;)DarkByte
11.08.2015 16:54Если это действительно так, то обидно, ибо других плюсов в данной фишке я не вижу.
AlexBin
11.08.2015 12:53-3Извиняюсь за оффтоп, но у меня вопрос:
Обновил недавно Wireshark, и он перестал у меня сохранять последний фильтр захвата (Capture Filter), каждый раз сбрасывая его. Знатоки, не знаете, в чем может быть дело? На старой версии последний фильтр сам сохранялся как последний, без всяких пресетов и прочего. Дико бесит уже…
ildarz
11.08.2015 20:25Не очень понимаю суть проблемы. Хотите гарантировать, что трафик DNS не уйдет никуда, кроме сервера, прописанного на туннельном интерфейсе — вместе с поднятием туннеля включайте на файрволе соответствующие правила (как вариант — временно убивайте DNS с других интерфейсов).
ValdikSS
11.08.2015 20:29Я хотел предупредить людей о таком новом поведении. Если раньше утечки DNS случались относительно редко и в ожидаемых ситуациях, то сейчас они не только происходят постоянно, но и гарантированно позволяют злоумышленнику подменить ответ.
Keiichi
12.08.2015 12:53Добрый день!
Хочу уточнить, вы на каком интерфейсе (-ах) собирали дамп пакетов?
Только на стороне самого клиента?
(само собой, надеюсь, при поднятом VPN-тоннеле?)
Из поста не ясны условия тестирования и выявления данной фичи.
Теме не менее, спасибо за информацию!ValdikSS
12.08.2015 13:33Но, вообще, это стало очевидно сразу — провайдер подменяет A-записи и перенаправляет на свою заглушку, которая не уходила даже при включенном VPN, хотя на предыдущих версиях Windows работало.
ValdikSS
12.08.2015 12:56Теперь, кстати, другая проблема: Windows каждый раз добавляет default route от DHCP при обновлении lease, даже если OpenVPN его убирает, а метрика у него, как правило, ниже, и весь трафик через какое-то время начинает идти в обход VPN, так что мою рекомендацию по использованию redirect-gateway без def1 не нужно слушать, пост обновлен.
ildarz
12.08.2015 17:33Проверил. Windows 10 Enterprise, свежеустановленная в виртуалке. 2 сетевых интерфейса, на каждом по паре разных DNS.
По умолчанию — действительно, параллельная отправка запросов с обоих интерфейсов.
Включил групповую политику Network\DNS Client\Turn off smart multi-homed name resolution (не забыть gpupdate и перезапуск службы dns client) — посылает только с одного.
P.S.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient] "DisableSmartNameResolution"=dword:00000001
P.P.S. Для любителей хитрых настроек есть ещё NRPT.ValdikSS
12.08.2015 17:51Эх, к сожалению, я делал то же самое на Windows 10 Pro и Enterprise. У меня не отключается эта функция, хотя те же действия в Windows 8.1 приводят к отключению. Может, вы что-то еще дополнительно делаете, о чем умалчиваете, и о чем я не знаю в силу неиспользования Windows?
ildarz
12.08.2015 18:17Вот же блин забавно — теперь у меня после всяких экспериментов с настройками тоже не работает. :( Ладно, будем копать…
IRainman
15.08.2015 11:00Вероятнее всего это баг. В 10 уже много подобного нашли, гейзенбажье какое то. У меня вообще до сих пор SRP криво работает на релизе 10, в причинах пока так разобраться и не удалось.
artyums
26.08.2015 21:16Столкнулся с аналогичной проблемой сегодня на Windows 10…
Не появилось ли нормального решения как отличить эту «умную» работу с DNS?
Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него?? Что за бред вообще, в голове не укладывается.ValdikSS
31.08.2015 08:54Один добрый человек мне написал следующее на почту, но с OpenVPN это не работает:
Add-VpnConnection -Name myvpn -ServerAddress "vpn.myorg.com" -PassThru Set-VpnConnection -Name myvpn -TunnelType pptp -AuthenticationMethod MSChapv2 -EncryptionLevel Required -RememberCredential $true -SplitTunneling $true -DnsSuffix "myorg.local" -PassThru Add-VpnConnectionRoute -ConnectionName myvpn -DestinationPrefix 10.100.0.0/16 -PassThru Get-VpnConnectionTrigger -ConnectionName myvpn | fl Add-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffix myorg.local -PassThru #тут powershell ругается с ошибкой, я повторяю команду и она выполняется (внезапно) Set-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffix myorg.local -DnsIPAddress 10.100.0.1, 10.100.0.2 -PassThru -Force Set-VpnConnectionTriggerDnsConfiguration -ConnectionName myvpn -DnsSuffixSearchList myorg.local -PassThru Add-VpnConnectionTriggerTrustedNetwork -ConnectionName myvpn -DnsSuffix myorg.local -PassThru Add-VpnConnectionTriggerApplication -ConnectionName myvpn -ApplicationID "%windir%\system32\mstsc.exe" -PassThruildarz
31.08.2015 11:02Как в OpenVPN feature request делаются? :) Всего-то нужно запилить интегрированный vpn-провайдер для win8/win10.
ValdikSS
31.08.2015 11:11О, а там плагинная система есть? Тогда конечно, это нужная фича. Нужно создать feature request на багтрекере, лучше с каким-нибудь денежным вознаграждением.
ildarz
31.08.2015 11:00Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него??
В Microsoft как раз по умолчанию считают ровно наоборот — если клиент поднимает туннель, все данные идут туда. При условии, разумеется, если вы используете интегрированный в винду клиент (причем в теории там могут быть VPN-провайдеры от разных вендоров, под восьмерку они и были, под десятку, вероятно, надо ставить из маркетплейса), ибо о поведении стороннего софта MS заботиться не может. Все грабли начинаются только тогда, когда вы хотите использовать split tunneling.
AleksandrFox
Вроде бы хотели как лучше, а получилось как бы специально о_О
IRainman
Да вот так и есть и проблема в том, что уже давно есть ПО, которое тоже умеет параллельно слать запросы на несколько серверов для ускорения, да и вообще представляет из себя навороченный, пусть и ориентированный на кэширование DNS, но решение при этом полностью настраиваемое, т. е. оно шлёт запросы не абы куда, а только на те адреса, которые прописаны в конфиге. Называется Acrylic DNS Proxy.