Версія даної теми для друку

Автор: nikelong Sep 19 2008, 21:24

У кого глючат ДНС (а это 98% пользователей ОГО) советую ознакомится с нижеследующим списком.

Открытые DNS - сервера:

Cisco (San Jose, CA, US)

64.102.255.44
128.107.241.185


Level 3 Communications (Broomfield, CO, US)

4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6


Verizon (Reston, VA, US)

151.197.0.38
151.197.0.39
151.202.0.84
151.202.0.85
151.202.0.85
151.203.0.84
151.203.0.85
199.45.32.37
199.45.32.38
199.45.32.40
199.45.32.43


GTE (Irving, TX, US)

192.76.85.133
206.124.64.1


SpeakEasy (Seattle, WA, US)

66.93.87.2
216.231.41.2
216.254.95.2
64.81.45.2
64.81.111.2
64.81.127.2
64.81.79.2
64.81.159.2
66.92.64.2
66.92.224.2
66.92.159.2
64.81.79.2
64.81.159.2
64.81.127.2
64.81.45.2
216.27.175.2
66.92.159.2
66.93.87.2


Sprintlink (Overland Park, KS, US)

199.2.252.10
204.97.212.10
204.117.214.10

Автор: Bard Sep 19 2008, 21:35

А OpenDNS где?
208.67.222.222
208.67.220.220

Автор: Death Sep 19 2008, 22:17

есть смысл их все в дополнительные подобавлять?

у тебя сколько их стоит?

Автор: nikelong Sep 19 2008, 22:50

У меня? Ни одного, юзаю УТКшные...

Типа труъ- огошник

Автор: Bard Sep 19 2008, 23:24

Я лично юзал только OpenDNS. До сего времени: у домосети нашей свои DNS-сервера. Также поднял небольшой (2000 записей) локальный DNS-запасник.

Автор: nikelong Sep 21 2008, 22:04

Bard,
http://vladimirdmitriev.com/2008/08/09/pochemu-ne-nado-ispolzovat-opendns/

В последнее время, особенно после появления Kaminsky DNS Vulnerability, стало популярным советовать сменить в настройках сети адреса DNS серверов на «безопасные и быстрые» сервера OpenDNS. Если по поводу безопасности претензий нет, то вот по быстроте хочется отметить одну важную проблему.

Вначале несколько абзацев простой теории. Многие CDN провайдеры, Google, Yahoo и другие крупные сайты обслуживают запросы пользователей сразу с помощью нескольких датацентров, для распределения нагрузки. Технически это можно реализовать четырьмя способами. Первый — использовать отдельное доменное имя для каждой зоны обслуживания датацентра. Т.е. хост www.sitename.com укажет на центральный датацентр, но на HTTP запрос (например, из России) сервер выдаст 302 редирект на russia.sitename.com. Недостаток такого решения — зависимость от центрального датацентра, некрасивые URL в строке браузера, лишний HTTP запрос и обращение к DNS. На практике такой метод не применяется.

Второй способ балансировки нагрузки — использование нескольких A записей для хоста, каждая из которых будет указывать на отдельный датацентр. Это решение может применяться в пределах города или небольшой страны, но когда ваши сервера расположены по всему миру может случиться так, что клиент из США выберет в качестве IP адрес датацентра в лондоне, увеличив задержку при обращении к серверу на 50-100 мс. На практике такой способ тоже не применяется.

Третий способ — т.н. Geo DNS. Сервера DNS, авторитетные за домен sitename.com указывают в ответе ближайший датацентр, сверяясь с базой данных по местоположению клиентского IP. Таким образом, запросы с восточного побережья США не пойдут в Европу и даже в датацентр на западном побережье, сохраняется минимальное время доступа к ресурсу. Именно такой способ балансировки применяется почти всеми крупными компаниями.

Наконец, четвертый вариант балансировки, он основывается на маршрутизации IP адресов в сети Интернет. Для определения кратчайшего маршрута от IP x.x.x.x до y.y.y.y провайдеры используют специальный протокол BGP. Для заинтересованных читателей принцип работы подробно изложен в приведенной ссылке, в кратце же, Интернет поделен на т.н. автономные системы (AS), которые соединены между собой. Каждой AS принадлежит одна или несколько IP сетей, и кратчайший путь маршрутизаторы рассчитывают по количеству промежуточных автономных систем до точки назначения. BGP, кстати, имеет кучу недостатков и проблем, но об этом уже в другой раз, пока вернемся к балансировке. Компания, владеющая сайтом sitename.com получает автономную систему, и анонсирует свою сеть одновременно во всех датацентрах. Таким образом, маршрутизатор в Европе, скорее всего, будет отправлять пакеты на IP адрес хоста www.sitename.com не в США, а скажем к ближайшему серверу в Лондоне. Почему скорее всего? Потому что как я указывал выше, BGP маршрутизация основана на определении кратчайшего маршрута по количеству промежеточных автономных систем, но не по географическому принципу. На практике может оказаться и так, что от клиента в России меньше промежуточных AS до датацентра в США, но не в Лондоне. Но в принципе, более-менее такая балансировка работает. Применяет ли кто такой способ для распределения нагрузки на веб-сервера не знаю, но вот OpenDNS использует его для распределения запросов к своим DNS, будучи подлключена напрямую к NTT (Tier 1 carrier).

Так вот проблема заключается в том, что сервера OpenDNS расположены всего в пяти датацентрах, а у Google, Yahoo и CDN провайдеров их гораздо больше. Указывая сервер OpenDNS в настройках сети на своем компьютере, IP адреса запрашиваемых хостов для пользователя определяет ближайший к нему сервер OpenDNS. Тот, в свою очередь, обращается к серверу, авторитетному для запрашиваемой зоны. И в случае использования Geo балансировки авторитетный DNS сервер вернет IP адрес датацентра, ближайшего к OpenDNS, но не пользователю! Для примера возьмем хост www.yahoo.com. Первый пинг запущен с Linux машины с локальным DNS клиентом, второй — с Windows машины с OpenDNS в качестве DNS.


debian:/tmp> ping -c 10 -n www.yahoo.com
PING www.yahoo-ht3.akadns.net (87.248.113.14) 56(84) bytes of data.
64 bytes from 87.248.113.14: icmp_seq=1 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=2 ttl=54 time=72.5 ms
64 bytes from 87.248.113.14: icmp_seq=3 ttl=54 time=68.6 ms
64 bytes from 87.248.113.14: icmp_seq=4 ttl=54 time=68.8 ms
64 bytes from 87.248.113.14: icmp_seq=5 ttl=54 time=72.3 ms
64 bytes from 87.248.113.14: icmp_seq=6 ttl=54 time=87.5 ms
64 bytes from 87.248.113.14: icmp_seq=7 ttl=54 time=69.8 ms
64 bytes from 87.248.113.14: icmp_seq=8 ttl=54 time=87.4 ms
64 bytes from 87.248.113.14: icmp_seq=9 ttl=54 time=71.7 ms
64 bytes from 87.248.113.14: icmp_seq=10 ttl=54 time=74.7 ms

--- www.yahoo-ht3.akadns.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9131ms
rtt min/avg/max/mdev = 68.647/74.353/87.547/6.811 ms

C:\Documents and Settings\vvd>ping -n 10 www.yahoo.com

Обмен пакетами с www.yahoo-ht3.akadns.net [69.147.76.15] по 32 байт:

Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=137мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=172мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=149мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=139мс TTL=53
Ответ от 69.147.76.15: число байт=32 время=138мс TTL=53

Статистика Ping для 69.147.76.15:
Пакетов: отправлено = 10, получено = 10, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 137мсек, Максимальное = 172 мсек, Среднее = 145 мсек

Таким образом, получили разницу в RTT в 70 миллисекунд. Много это или мало, и каким образом влияет на загрузку страницы? Технически, каждый HTTP запрос к сайту Yahoo будет отрабатываться на 70 мс медленнее, что для тяжелой страницы должно дать заметное замедление. Я проверил это с помощью Firebug, и получил среднюю скорость загрузки головной страницы с OpenDNS в 6-7 секунд и 4-5 секунд с DNS местного провайдера. Каждый элемент закружается примерно на 150-200мс медленнее, и спасает только Firefox 3, поддерживающий большее чем по стандарту количество HTTP подключений к серверу.

Какой из всего написанного вывод? Используйте DNS вашего интернет провайдера! Если он уязвим к атакам, звоните и требуйте чинить. Можно поставить и свой собственный DNS клиент, но делать это стоит лишь в случае если вы не выключаете ПК на ночь или имеете домашний сервер. В противном случае, при каждом перезапуске компьютера DNS будет терять кеш и делать лишние запросы к авторитетным серверам. Это замедлит первональное обращение к сайтам и создаст дополнительную совсем не нужную нагрузку на сервера, ответственные за зоны первого уровня.

Автор: Death Oct 24 2011, 13:54

Domain Name Speed Benchmark



http://www.grc.com/files/DNSBench.exe

Но самая полезная фича это то что можно проверисть список из 4000 днс серверв на скорость и найти самые быстрые для вас!
Для маджа это будет очень полезно!

Автор: Rilian Oct 24 2011, 14:11

для мака есть? если оно поможет выбрать самый лучший ДНС - очень хорошо для маджестика

Автор: Death Oct 24 2011, 15:07

для мака нет )

лучше всего поднять BIND локально и использовать свой днс.



ну или выбери какие-нить из тех что на рисунке. они побыстрее гугловских восьмёрок.

Автор: nikelong Oct 30 2011, 13:12

https://dns.norton.com/dnsweb/huConfigureRouter.do

Секурные ДНС от Нортона:

A - Security (malware, phishing sites, scam sites and web proxies)

Preferred DNS: 198.153.192.40
Alternate DNS: 198.153.194.40

B - Security + Pornography
Preferred DNS: 198.153.192.50
Alternate DNS: 198.153.194.50

Preferred DNS: 198.153.192.60
Alternate DNS: 198.153.194.60

Автор: Badgerdash Oct 30 2011, 13:21

ДНС от Гугла уже вспоминали?
8.8.8.8
8.8.4.4

Автор: Death Dec 8 2011, 22:49

Среди возможного множества решений для "детской" цензуры (родительского контроля) есть вариант со специальным DNS-резолвером.

Один из держателей такого рода сервиса поделился с вашим покорным слугой инсайдерской информацией. После того, как на их услуги подписалось достаточно много клиентов, пришли товарищи из Откуда-Надо. И попросили имплементировать для них ма-а-аленькую фичу. Чтобы можно было удалённо внести в чёрный список до 99 новых доменных имён. Но чтоб резолвер отправлял их не на общую заглушку, а на указанный внешний IP-адрес.

Товарищи Откуда-Надо пояснили, что фича требуется исключительно для народного блага. В день В-Случае-Чего запросы с блогов и ресурсов подстрекател
ей и вражеских агентов перемаршрутизируются на сайты-двойники. Дальше – понятно.
Разумеется, контент будет подменён не для всего народа. Разумеется, обман через какое-то время вскроется. Очевидно, стоит задача "нам бы только ночь простоять, да день продержаться". Массовая контрпропаганда на 12 кризисных часов может решить исход всей борьбы.
http://infowatch.livejournal.com/268382.html

Автор: smilesvua Dec 8 2011, 22:58

Вполне логично, но это не обазятельно делать в таком виде. В россии у всех магистральных (у некоторых домашних тоже) провайдеров стоят специальные коробочки (СОРМ-2) которые не только собираются инфу но и являются маршрутиризаторами которыми управляют сами-знаете-кто. И легим нажатием на клавиатуру весь рунет поворачивается куда надо. Кстати в Украине это тоже есть но в намного меньших масштабах, но хотят пропихнуть как в Белоруси или в Китае.

Автор: Death Dec 8 2011, 23:12

только 14.88! то есть хотел сказать 4488 и 8888

Автор: nikelong Dec 8 2011, 23:25

Дык эти тоже управляются "теми-кому-надо", только там, гдесейчас день . И в промышленных масштабах! Разве не так!?

Алсо, есть еще 156 154 70 22. Хотя кто и этих знает...

Автор: Death Dec 9 2011, 10:26

ну нащот сотрудничества гугли и цру непонятно.

Автор: smilesvua Dec 9 2011, 12:42

ЦРУ со всеми ИТ дружат

Автор: Death Mar 5 2014, 14:30

http://www.aqualab.cs.northwestern.edu/projects/151-namehelp

Автор: T@r@s_Bulb@ Mar 6 2014, 19:39

Для чого це?
Розкажіть для "чайника"...

Автор: whynot Mar 8 2014, 21:23

Все это вертится вокруг DNS.

История проблемы. Компутеры юзверей пользуются DNS провайдеров. Но провайдеры (в силу внешних причин) криворуки чуть реже чем всегда (tell me about it; Когда переехал с пиплов в укралтелеком, так пинг на DNS пиплов *из* укралтелекома был меньше чем из пипловской сети). Это проблема разрешается использование всяких разных левых DNS (гугель, opendns -- тысячи их; я сам такой).

Суть проблемы. Проблема в доставке котиков (нет котиков -- нет интернетов). Котики, скажем, выставленные в вконтактике, доставляются не из в вконтактика. Котики доставляются из, внезапно, сети доставки котиков (СДК -- content delivery networks). Которых немного. Но! Раньше можно было сконфигурировать DNS (вконтактика, что важно; это именно так и работает) таким образом чтобы выбирался сервер (в СДК) поближе к юзверю. Теперь, забугорный левый DNS может отправить туда же -- в левое забугорье.

Решение проблемы. Собсно namehelp. Выполняются какие-то хитрые измерения которые позволяют отправится на сервер (в СДК) где-нибудь поближе.

Are you enlightened now?