Comments 65
Вроде бы хотели как лучше, а получилось как бы специально о_О
Да вот так и есть и проблема в том, что уже давно есть ПО, которое тоже умеет параллельно слать запросы на несколько серверов для ускорения, да и вообще представляет из себя навороченный, пусть и ориентированный на кэширование DNS, но решение при этом полностью настраиваемое, т. е. оно шлёт запросы не абы куда, а только на те адреса, которые прописаны в конфиге. Называется Acrylic DNS Proxy.
Использовать странные dns сервера в организации вообще не есть гуд. А для домашнего пользователя 8.8.8.8 вполне нормально.
В win7 и меньше как раз было проблемой то, что отвечал только один DNS, и если например нужно обратиться к внутренним ресурсам, не публикующимся наружу, была проблема что внешний DNS не мог их резолвить, а внутренний DNS мог не резолвить что-то другое снаружи.
А если один из DNS отвечает что сервер не найден, к другому уже и не обращается — мне всегда казалось, что это неправильно.
Сейчас стало логичнее. Хотя было бы лучше поведение dns клиента при ошибках настраивать гибче.
В win7 и меньше как раз было проблемой то, что отвечал только один DNS, и если например нужно обратиться к внутренним ресурсам, не публикующимся наружу, была проблема что внешний DNS не мог их резолвить, а внутренний DNS мог не резолвить что-то другое снаружи.
А если один из DNS отвечает что сервер не найден, к другому уже и не обращается — мне всегда казалось, что это неправильно.
Сейчас стало логичнее. Хотя было бы лучше поведение dns клиента при ошибках настраивать гибче.
А для домашнего пользователя 8.8.8.8 вполне нормально.Я тоже так думал и довольно долго им пользовался, но очень часто разные сайты были недоступны — я грешил на сами сайты, пока вдруг несколько раз я не смог попасть на сайт Гугла, в то время как у всех остальных сайт Гугла был доступен. Сменил DNS на провайдерский, и проблемы исчезли. Возможно, 8.8.8.8 и 8.8.4.4 просто не справлялись с нагрузкой, не знаю.
Было такое, то перестает отвечать днс провайдера, то днс гугла, фигня какая то. То ли провайдер специально блочит днс гугла, то ли что, не знаю. Перешел на днс от яндекс. Проблема исчезла.
Google где-то писал, что эти адреса не для внешнего использования, они не рассчитаны на какую-либо нагрузку. А один из открытых проектов (dnsmasq?) использует их по умолчанию, поэтому нагрузка на них всегда есть.
Вообще то нет.
Но фраза типа одна бабка сказало, это хорошо.
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
Хотя, это еще тот источник знаний.
Но фраза типа одна бабка сказало, это хорошо.
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
Хотя, это еще тот источник знаний.
Да, я ошибся, речь вообще шла об ntp и о надёжности не гуглового сервиса. systemd по умолчанию использует серверы Google, народ обсуждал, на что бы переехать другое. Как оказалось, pool.ntp.org не рекомендуют ставить стандартным сервером — это меня удивило, а упоминание Google просто в голове отложилось.
github.com/systemd/systemd/issues/437
github.com/systemd/systemd/issues/437
Моя статистика показывает, что DNS сервера домашних мелких провайдеров глючат горазо чаще, чем гугловский.
Кстати, не очень понял за что заминусовали. Я считаю, что если один DNS сервер вернул ошибку, это еще не повод, что сайта действительно нет, и во многих случаях я бы хотел больше управлять поведением днс клиентом.
Он собственно и в Линукс себя также ведет — второй ДНС сервер опрашивает только в том случае, если первый ДНС не отвечает.
В нескольких крупных компаниях (200+ тыс.человек), где необходимо разделать внутренние и внешние ресурсы, проблема ресолва парочки адресов решилась исключительно через hosts файл, что неудобно. А было бы можно настроить поведение при ошибке, можно было бы просто два DNS сервера разных указать.
Кстати, не очень понял за что заминусовали. Я считаю, что если один DNS сервер вернул ошибку, это еще не повод, что сайта действительно нет, и во многих случаях я бы хотел больше управлять поведением днс клиентом.
Он собственно и в Линукс себя также ведет — второй ДНС сервер опрашивает только в том случае, если первый ДНС не отвечает.
В нескольких крупных компаниях (200+ тыс.человек), где необходимо разделать внутренние и внешние ресурсы, проблема ресолва парочки адресов решилась исключительно через hosts файл, что неудобно. А было бы можно настроить поведение при ошибке, можно было бы просто два DNS сервера разных указать.
Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
Ну и если ваше оборудование автоматом цепляется за любой вайфай без пароля с dhcp… При таком уровне безопасности утечка dns не самая критичная уязвимость имо.
Так что в нормальной сети проблем не будет, кмк. А там где будут — там и без этого дыра на дыре.
Ну и если ваше оборудование автоматом цепляется за любой вайфай без пароля с dhcp… При таком уровне безопасности утечка dns не самая критичная уязвимость имо.
Так что в нормальной сети проблем не будет, кмк. А там где будут — там и без этого дыра на дыре.
Дело не в DNS провайдеров, и не в автоматическом подключении к сетям. Даже если вы дома на роутере настроили сторонние DNS, но этот же роутер поднимает кеширующий DNS (как это обычно бывает) на интерфейсе локальной сети, вы же не будете прописывать эти DNS еще и на компьютере, ведь от этого, во-первых, пострадает кеширование, да и вообще, какой смысл тогда настраивать на роутере, верно? И вы ожидаете, что все в порядке, подключаете VPN, и — бах — все ваши DNS-запросы идут не так, как вы ожидаете.
Та же ситуация с Wi-Fi в кафе. Подключаетесь к Wi-Fi, используя DNS, предоставленный по DHCP, сразу подключаетесь по VPN и надеетесь, что все в порядке, а на деле, все ваши DNS-запросы могут быть подменены злоумышленником.
Та же ситуация с Wi-Fi в кафе. Подключаетесь к Wi-Fi, используя DNS, предоставленный по DHCP, сразу подключаетесь по VPN и надеетесь, что все в порядке, а на деле, все ваши DNS-запросы могут быть подменены злоумышленником.
Провайдеры могут подменять DNS, и подменяют. Не пользуйтесь DNS провайдеров — это, кажется, прописное.
На самом деле, всё ещё хуже. Они не только запросы к себе подменяют, но и к любым другим. У нас например, провайдер нагло изменяет все ДНС пакеты в которых упомянуты запрещённые имена. Даже 8.8.8.8 тут не поможет. (Зато через VPN всё как надо)
Я называю это «перенаправление DNS»
по моему вы имели в виду это :)
Вот Билайн так точно делает. Какое-то время назад столкнулся с проблемой, что 8.8.8.8 и тот же самый через VPN возвращают абсолютно разные данные.
Провайдеры могут подменять DNS, и подменяют.
И не всегда это плохо.
Перенаправить клиента, у которого отрицательный баланс, на страничку с информацией, ссылкой на личный кабинет и возможностью начисления обещанного платежа — вполне себе нормальное и более чем приемлемое, я считаю, использование этой возможности. Для «домашних» пользователей это проблемой не является.
Впрочем, практически весь трафик можно перенаправить куда нужно.
Хотел сказать «поднимите локальный ресолвер и закройте iptables всем, кроме него доступ к dns», но понял, что не знаю как это всё называется в виндах.
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?
Ну так в windows можно указать несколько ДНС, проблема же в другом. Оно тут и описана, что винда кладет болт на это и делает по своему.
Алсо, в линуксах есть resolv.conf и nsswitch.conf, управляющие порядком ресолвинга. В виндах аналогичного нет?nsswitch точно есть, и аналог resolv.conf через реестр можно сделать, но это все костыльно и неудобно, к сожалению.
Понятное дело, что локальный резолвер решает проблему, но нужно всегда помнить о необходимости убирать DNS на других интерфейсах, т.к. в Windows они привязаны к интерфейсам.
то есть для линукса можно настроить nsswitch что-то типа:
dns [NOTFOUND=continue] nis
и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
dns [NOTFOUND=continue] nis
и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
Насколько я знаю, как раз строго нет, от чего страдают всякие любители «альтернативных DNS через vpn», когда хочется, чтобы «не нашёл один — спроси у другого».
Вот у нас похожая проблема.
По vpn подключаемся к сети заказчика, внутри которой есть свой DNS, резолвящий эти внутренние ресурсы.
Но многие внешние ресурсы он не резолвит, и учитывая локацию заказчика сильно лагает. А если таких заказчиков со своими DNS-ами два, то уже совсем никак. Поэтому возможность опроса нескольких серверов удобно.
Единственное, что в статье действительно не описали что будет, если win10 делает запрос, и самый быстрый сервер отвечает отказом. Дождется ли оно ответа от других серверов, или сразу отлуп?
По vpn подключаемся к сети заказчика, внутри которой есть свой DNS, резолвящий эти внутренние ресурсы.
Но многие внешние ресурсы он не резолвит, и учитывая локацию заказчика сильно лагает. А если таких заказчиков со своими DNS-ами два, то уже совсем никак. Поэтому возможность опроса нескольких серверов удобно.
Единственное, что в статье действительно не описали что будет, если win10 делает запрос, и самый быстрый сервер отвечает отказом. Дождется ли оно ответа от других серверов, или сразу отлуп?
и если первый dns сервер из resolv.conf не нашел домен, оно будет запрашивать остальные по очереди?
Нет. Если DNS не нашел запись, ломиться в nis. А DNS опрашиваются по очереди из resolv.conf. Если первый не ответил — идем ко второму. Но если первый сказал, что записи нет (именно ответил «фигвам», а не отвалился по таймауту), то дальше опрос не проводится.
ValdikSS правильно ли я понимаю, что на примере OpenVPN директива конфига:
тоже не решает проблему? И даже при добавлении принудительного:
разумеется, что:
должен быть добавлен.
проблема останется? То есть верно ли я понимаю, что суть бага в том, что резольвер напрямую привязывает адреса DNS к интерфейсам, при этом полностью игнорирует правила маршрутизации?
push "redirect-gateway def1 bypass-dhcp"тоже не решает проблему? И даже при добавлении принудительного:
push "route 0.0.0.0 0.0.0.0"разумеется, что:
push "dhcp-option DNS xxx"должен быть добавлен.
проблема останется? То есть верно ли я понимаю, что суть бага в том, что резольвер напрямую привязывает адреса DNS к интерфейсам, при этом полностью игнорирует правила маршрутизации?
Упс, прочитал по диагонали пост, прошу прощения:
Ответ уже есть, ValdikSS благодарю.
Если вы используете OpenVPN, убедитесь, что он заменяет маршрут по умолчанию, а не добавляет два маршрута 0.0.0.0/1 и 128.0.0.0/1 (параметр redirect-gateway должен быть без def1), т.к. в этом случае Windows сможет привязать запрос к интерфейсу и успешно отправить его в незашифрованном виде.
Ответ уже есть, ValdikSS благодарю.
Чья идея изначально — роутить только половину интернета? Вы вкурсе же, что 0.0.0.0/1 это не 0.0.0.0/0?
Почему половину-то? Добавляются два маршрута — 0.0.0.0/1 и 128.0.0.0/1, так что маршрутизируется весь интернет.
Ну да, но зачем два маршрута то добавлять? Я не про этот комментарий сейчас. Просто встречал много OpenVPN серверов и документаций где маршрут указывают 0.0.0.0/1, а потом страдают, что только половина работает.
Затем, что если в Windows добавить default route и удалить старый, то старый через какое-то время (во время следующего DHCP renew) опять появится, причем с метрикой ниже, и весь ваш трафик чудным образом пойдет не через VPN, а в обход. Больше причин, в общем-то, нет, наверное.
И где вы такую документацию встречали, кстати? Обычно нигде не пишут добавлять маршруты вручную, а используют redirect-gateway def1, который как раз добавляет два маршрута.
И где вы такую документацию встречали, кстати? Обычно нигде не пишут добавлять маршруты вручную, а используют redirect-gateway def1, который как раз добавляет два маршрута.
Он не игнорирует правила маршрутизации, а делает bind к интерфейсу перед тем, как отправить запрос, поэтому если у вас есть маршрут через локальный интерфейс, который в обычной ситуации не используется (выше метрика, перекрывается более узкими сетями), то Windows сможет его использовать.
Самое противное, что проблема проявляется на самой распространенной конфигурации: подключаемся к роутеру, роутер выдает DNS на свой IP-адрес, и из этого же диапазона нам выдается адрес по DHCP. Маршрут до DNS, естественно, никак не убрать, т.к адрес next hop и DNS совпадают.
Самое противное, что проблема проявляется на самой распространенной конфигурации: подключаемся к роутеру, роутер выдает DNS на свой IP-адрес, и из этого же диапазона нам выдается адрес по DHCP. Маршрут до DNS, естественно, никак не убрать, т.к адрес next hop и DNS совпадают.
>> было проблематично для злоумышленника, т.к. ОС бы использовала подмененный ответ только в том случае, если не удалось получить правильный ответ от предпочитаемого DNS-сервера
Вот это раньше была безопасность т.е. стоит отвлечься основному DNS и на тебе дыра в безопасности. Если вы так беспокоитесь о безопасности, то у вас вообще не должны быть прописаны DNS, которым вы не доверяете.
>> не может ответить в отведенный ему таймаут (1 секунда по умолчанию)
2 секунды таймаут по умолчанию.
>> Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел
В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).
P.S. В групповых политиках настройка доступна здесь:
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolution
Вот это раньше была безопасность т.е. стоит отвлечься основному DNS и на тебе дыра в безопасности. Если вы так беспокоитесь о безопасности, то у вас вообще не должны быть прописаны DNS, которым вы не доверяете.
>> не может ответить в отведенный ему таймаут (1 секунда по умолчанию)
2 секунды таймаут по умолчанию.
>> Теперь ОС не только отправляет запрос через все интерфейсы, но и использует тот ответ, который быстрее пришел
В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).
P.S. В групповых политиках настройка доступна здесь:
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolution
2 секунды таймаут по умолчанию.Все же одна.
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 serversupport.microsoft.com/en-us/kb/2834226
В описание к функции говорится, что если получено несколько ответов, то для определения ответа используется порядок сетевых привязок (network binding order).Вот оно работает в Windows 8.1, но не работает в Windows 10, или у меня руки кривые.
Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.
И есть такие провайдеры, которые считают что нужно обязательно сделать свою доменную зону (доступную только из локальной сети и известную только DNS серверам провайдера), которые кроме того особо не заморачиваются с блокировками и фильтруют только по DNS, причём только на своих серверах. Соответственно для того, чтобы всё работало хорошо, первым DNS сервером указывается внешний (google public dns, например) сервер, а вторым уже DNS от провайдера. И если я правильно понимаю, то в десятке такая конфигурация будет работать корректно.
И есть такие провайдеры, которые считают что нужно обязательно сделать свою доменную зону (доступную только из локальной сети и известную только DNS серверам провайдера), которые кроме того особо не заморачиваются с блокировками и фильтруют только по DNS, причём только на своих серверах. Соответственно для того, чтобы всё работало хорошо, первым DNS сервером указывается внешний (google public dns, например) сервер, а вторым уже DNS от провайдера. И если я правильно понимаю, то в десятке такая конфигурация будет работать корректно.
>Наверное параноикам действительно есть за что переживать, а мне показалось что так даже лучше. Ведь раньше, когда было указано два DNS сервера и первый в ответ сообщал, что домен не существует, то второму запрос не отправлялся.
А чем сейчас лучше?
Отправилось на все известные днс, самый быстрый ответил, что сайта нет и на другие запрос не отправляется ;)
А чем сейчас лучше?
Отправилось на все известные днс, самый быстрый ответил, что сайта нет и на другие запрос не отправляется ;)
Извиняюсь за оффтоп, но у меня вопрос:
Обновил недавно Wireshark, и он перестал у меня сохранять последний фильтр захвата (Capture Filter), каждый раз сбрасывая его. Знатоки, не знаете, в чем может быть дело? На старой версии последний фильтр сам сохранялся как последний, без всяких пресетов и прочего. Дико бесит уже…
Обновил недавно Wireshark, и он перестал у меня сохранять последний фильтр захвата (Capture Filter), каждый раз сбрасывая его. Знатоки, не знаете, в чем может быть дело? На старой версии последний фильтр сам сохранялся как последний, без всяких пресетов и прочего. Дико бесит уже…
Вам на Тостер
Не очень понимаю суть проблемы. Хотите гарантировать, что трафик DNS не уйдет никуда, кроме сервера, прописанного на туннельном интерфейсе — вместе с поднятием туннеля включайте на файрволе соответствующие правила (как вариант — временно убивайте DNS с других интерфейсов).
Добрый день!
Хочу уточнить, вы на каком интерфейсе (-ах) собирали дамп пакетов?
Только на стороне самого клиента?
(само собой, надеюсь, при поднятом VPN-тоннеле?)
Из поста не ясны условия тестирования и выявления данной фичи.
Теме не менее, спасибо за информацию!
Хочу уточнить, вы на каком интерфейсе (-ах) собирали дамп пакетов?
Только на стороне самого клиента?
(само собой, надеюсь, при поднятом VPN-тоннеле?)
Из поста не ясны условия тестирования и выявления данной фичи.
Теме не менее, спасибо за информацию!
Теперь, кстати, другая проблема: Windows каждый раз добавляет default route от DHCP при обновлении lease, даже если OpenVPN его убирает, а метрика у него, как правило, ниже, и весь трафик через какое-то время начинает идти в обход VPN, так что мою рекомендацию по использованию redirect-gateway без def1 не нужно слушать, пост обновлен.
Проверил. Windows 10 Enterprise, свежеустановленная в виртуалке. 2 сетевых интерфейса, на каждом по паре разных DNS.
По умолчанию — действительно, параллельная отправка запросов с обоих интерфейсов.
Включил групповую политику Network\DNS Client\Turn off smart multi-homed name resolution (не забыть gpupdate и перезапуск службы dns client) — посылает только с одного.
P.S.
P.P.S. Для любителей хитрых настроек есть ещё NRPT.
По умолчанию — действительно, параллельная отправка запросов с обоих интерфейсов.
Включил групповую политику 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.
Эх, к сожалению, я делал то же самое на Windows 10 Pro и Enterprise. У меня не отключается эта функция, хотя те же действия в Windows 8.1 приводят к отключению. Может, вы что-то еще дополнительно делаете, о чем умалчиваете, и о чем я не знаю в силу неиспользования Windows?
Столкнулся с аналогичной проблемой сегодня на Windows 10…
Не появилось ли нормального решения как отличить эту «умную» работу с DNS?
Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него?? Что за бред вообще, в голове не укладывается.
Не появилось ли нормального решения как отличить эту «умную» работу с DNS?
Вообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него?? Что за бред вообще, в голове не укладывается.
Один добрый человек мне написал следующее на почту, но с 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" -PassThruВообще это все выглядит очень забавно — неужели в Microsoft считают, что если клиент поднимает туннель, то он хочет, чтобы хоть какие-то данные ходили мимо него??
В Microsoft как раз по умолчанию считают ровно наоборот — если клиент поднимает туннель, все данные идут туда. При условии, разумеется, если вы используете интегрированный в винду клиент (причем в теории там могут быть VPN-провайдеры от разных вендоров, под восьмерку они и были, под десятку, вероятно, надо ставить из маркетплейса), ибо о поведении стороннего софта MS заботиться не может. Все грабли начинаются только тогда, когда вы хотите использовать split tunneling.
Это не проверенные сведения. При использовании встроенного клиента DNS запрос внутрь сети проходит только в начале подключения, спустя время начинается гонка, которая в большинстве случае приводит к тому, что либо внутри туннеля не хватает 1 секунды на возврат имени, либо ответ с другого интерфейса приходит быстрее. Поэтому в целом, проблема как есть, так и осталась и пользоваться этим нормально невозможно.
Sign up to leave a comment.
Особенности резолвера DNS в Windows 10 и DNS Leak