Сегодня на первое апреля Cloudflare запустила свой DNS сервис. Говорят, что он будет способствовать ускорению и анонимности вашего доступа. Сайт у сервиса без домена, но он, видимо, и не нужен -
https://1.1.1.1/Сервис обещает, что логи будут вытираться каждые сутки. Таким образом они делают ставку на приватность пользователей.
Сотрудничество с APNIC позволило использовать 1.1.1.1 и 1.0.0.1 для своего DNS сервиса.
Вкратце, они предложили APNICу использовать сеть Cloidflare для изучения мусорного трафика (который генерится пользователями, ставящими эти сети как dummy), за что и получили красивые адреса.
Подробнее тут:
https://blog.cloudflare.com/announcing-1111/
inetnum: 1.1.1.0 - 1.1.1.255
netname: APNIC-LABS
descr: APNIC and Cloudflare DNS Resolver project
descr: Routed globally by AS13335/Cloudflare
descr: Research prefix for APNIC Labs
inetnum: 1.0.0.0 - 1.0.0.255
netname: APNIC-LABS
descr: APNIC and Cloudflare DNS Resolver project
descr: Routed globally by AS13335/Cloudflare
descr: Research prefix for APNIC Labs
Запуск на первое апреля объясняется тем, что адрес сервиса 1.1.1.1 содержит четыре единицы, соответственно и запуск первого числа четвертого месяца.
Кстати, Gmail тоже запустили на первое апреля, правда в далеком 2004 году.
По поводу приватности - поддерживается DNS-over-TLS и DNS-over-HTTPS.
По поводу скорости - есть данные DNSperf:
Пока что, самый быстрый резолв.
таки да, очень шутро отвечает. + задержки до самого сервера в 2 раза меньше чем до ГуглДНС.
Правда странно, что небольшой прирост в скорости ответа по доменам которые размещены на НС серверах Cloudflare.
Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=33мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Сколько это в два раза? от нас 12-14 мс
От меня так же. А до ГуглоДНС меньше 30 не видел...
В цивилизованом мире практически одинаково.
С серверов в Германии по 5мс, в Штатах по 9.
Ровно в 2 раза пинг лучше на 1.1.1.1
Не дурственно отвечает, это от нас.
root@gorod:~ # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=4.492 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=4.614 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=4.679 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=4.460 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=4.561 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=4.500 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=4.549 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=4.559 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=4.488 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=4.497 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=59 time=4.587 ms
^C
--- 1.1.1.1 ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.460/4.544/4.679/0.062 ms
и гугловские "восьмерки"
root@gorod:~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=16.194 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=16.013 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=16.069 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=16.169 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=16.231 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=16.285 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=16.074 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=54 time=16.022 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=54 time=16.018 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=54 time=16.114 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=54 time=16.061 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=54 time=16.143 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=54 time=16.192 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=54 time=16.091 ms
^C
--- 8.8.8.8 ping statistics ---
14 packets transmitted, 14 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 16.013/16.120/16.285/0.082 ms
Разница практически в 4 раза по отклику.
через Dtel влетает в Wnet
1ms - круто
Добавлю свои трасировки...
1.1.1.1
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. rt2.kyivlink.com 0.0% 14 0.0 0.1 0.0 0.2 0.0 2. 185.1.50.68 0.0% 14 3.9 1.0 0.2 3.9 1.0 3. 1dot1dot1dot1.cloudflare-dns.com 0.0% 13 0.3 0.3 0.2 0.5 0.08.8.8.8
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. rt2.kyivlink.com 0.0% 24 0.1 0.1 0.0 0.3 0.0 2. google-to-rt2.kyivlink.com 0.0% 24 0.4 0.4 0.2 2.0 0.3 3. 108.170.248.131 0.0% 24 1.1 0.9 0.4 3.3 0.7 4. 209.85.248.105 0.0% 24 14.2 14.5 14.2 16.1 0.3 5. 209.85.246.99 0.0% 24 32.2 32.0 31.8 32.3 0.0 6. 216.239.40.246 0.0% 24 32.3 32.9 32.3 39.8 1.5 7. ???8.8.8.8 отсекает пакеты трасировки, добавлю результат ping:
>ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=50 time=32.344 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=32.454 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=32.594 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=50 time=32.464 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=50 time=32.357 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=50 time=32.628 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=50 time=32.593 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=50 time=32.378 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=50 time=32.457 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=50 time=32.571 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=50 time=32.339 msCloudflare рулит...
Надо ждать когда станет популярным. Потому что 8.8.8.8 нагружены оч хорошо.
Плюс они распределенные ж вроде как, так же как GGC.
Не дурно
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=0.508 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=0.474 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=0.517 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=0.490 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=0.497 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=60 time=0.498 ms
бляха, клевый днс
сколько пинг до собственного рекурсора?
у вас там cloudflare че, в соседней стойке стоит?
До своего 0.2мс
Ну почти в соседней
через 1?
Та на самом деле не близко
Host Loss% Snt Last Avg Best Wrst StDev
1. 0.0% 13 0.2 0.2 0.2 0.5 0.0
2. 0.0% 12 0.3 0.4 0.3 0.7 0.0
3. 0.0% 12 0.8 1.6 0.7 10.5 2.7
4. cloudflare-ix.giganet.ua 0.0% 12 1.1 0.9 0.5 1.8 0.3
5. 1dot1dot1dot1.cloudflare-dns.com 0.0% 12 0.5 0.5 0.5 0.5 0.0
Странно, у меня прямой стык с гиганет, но бегаю я пока не прямо через них.
А у меня даже анонса такого нет от них.
Ну нас сразу на кацапию само выруливает :-)
root@gorod:~ # traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
1
2 10.10.13.138 (10.10.13.138) 5.119 ms 5.058 ms 5.125 ms
3 msk-ix.cloudflare.com (195.208.209.7) 9.884 ms 6.901 ms 7.712 ms
4 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 5.666 ms 4.467 ms 5.536 ms
Интересный у вас пиринг))))
У меня провайдер по этому адресу (1.1.1.1) сделал доступ к личному кабинету в его локальной сети. И теперь только гугловый DNS...
Печалька.
Дать по голове за такое. Всё что не арендовано\куплено и не в rfc1918/rfc6598 не должно использоваться по собственному усмотрению.
Пускай ещё возьмут ипишки гугловской ASN. А че, весело же.
Или пускай сами себе доступ в ripe наебнут, что б больше не смогли прописывать import/export для route object/as-set.
Возможно они и не знали когда делали редирект на личный кабинет. Провайдер новый...
Но с другой стороны как говорится - "не знание законов - не освобождает от ответственности".
Так напишите им в саппорт.
Вам нужно поднять прямую бгп-сессию с клаудфларой. Они анонсируют на роутсерверы небольшой список своих префиксов, но охотно строят приватную сессию на обменных IP. Напишите им на peering@cloudflare.com, однако будьте готовы создать или актуализировать запись своего провайдера на peeringdb, и указать её им в запросе на пиринг.
Вот оригинал письма Cloudflare, предлагающего строить прямые сессии:
Dear GigaNET members, We Cloudflare/AS13335 are live on GigaNET IX in Kiev, we have an open peering policy.
We only provide a subset of our routes via route servers. A direct peering session between our ASNs will provide all our routes.
We do not require BGP MD5 passwords (however we will accept your MD5 password, if you require one). We request max-prefix sizes of 500 for IPv4 and 100 for IPv6.
Our full peering information can be found in PeeringDB at https://www.peeringdb.com/asn/13335 We require you to have an up-to-date PeeringDB entry, as we provision our configuration automatically from this data. Please email peering@cloudflare.com to request a peering session with us.
Да, реально поближе, чем гугл
1 <1 мс <1 мс <1 мс core
2 10 ms 10 ms 10 ms dtel-ix.cloudflare.com [193.25.181.201]
3 10 ms 10 ms 10 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
1 <1 мс <1 мс <1 мс core
2 10 ms 10 ms 10 ms dtel-ix-2.google.com [193.25.181.62]
3 11 ms 10 ms 10 ms 108.170.248.131
4 24 ms 25 ms 24 ms 209.85.248.105
5 44 ms 44 ms 66 ms 216.239.50.255
6 45 ms 42 ms 42 ms 216.239.56.216
7 * * * Превышен интервал ожидания для запроса.
спасибки, буду знать
Ну и тогда выложу свои результаты:
Start: 2018-04-02T09:52:02+0300 HOST: gate Loss% Snt Last Avg Best Wrst StDev 1.|-- cloudflare-ix.giganet.ua 0.0% 1 7.6 7.6 7.6 7.6 0.0 2.|-- 1dot1dot1dot1.cloudflare-dns.com 0.0% 1 6.4 6.4 6.4 6.4 0.0Какой биллинг ?
В документации N+ как раз 1.1.1.1 в качестве примера указан.
В других тоже встречал такие приколы.
Это от моего домашнего бестолкового монополиста. От норм провайдеров реально меньше мс (через Когент)
Красавцы.
>ping 8.8.8.8
Обмен пакетами с 8.8.8.8 по с 32 байтами данных:
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=54
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=54
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=54
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=54
>ping 1.1.1.1
Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=1мс TTL=63
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=63
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=63
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=63
>tracert 1.1.1.1
Трассировка маршрута к 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
с максимальным числом прыжков 30:
1 4 ms 12 ms <1 мс 192.168.0.1
2 1 ms <1 мс <1 мс 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
Трассировка завершена.
Круто)
Можно назначать как резервный ДНС микротик сервере?
почему резервный - основный, а гуггл резервным.
Основной магистрального провайдера, там меньше 1мс отклик.
127.127.127.127 еще меньше пинг ))
Ну, это классика, само собой ;-)
везет людям...
в дыре наеборот
гугля пинг 18 на клауд 32...
А теперь посмотри с какой скоростью резолвит один и другой.
И сразу все айда меряться пингами.
Да, неплох этот днс
НАКАРКАЛЫ - БОБИК НАЧАВ КАШЛЯТЬ
ВАМ ЖЭ НЫЧОГО ДАВАТЬ НЫЗЗЯ - УСЭ ПОЛАМАЕТЭ
NoDeny+
это говорит о квалификации админов, его устанавливающих
Вот именно.
ну, в нодени использовать 1.1.1.1 - это в инструкции по установке написано
http://nodeny.com.ua/wiki/index.php/Установка_NoDeny
Логику разработчиков, дающих такую инструкцию - ну никак не могу понять
Инструкция на то и инструкция чтобы приводить пример, но никак не тупо скопировать все что в ней указано. Тем более на таком то уровне ответственности.
Обе стороны хороши:
https://tools.ietf.org/html/rfc5737
Это не отменяет факт сознательной или не очень, блокировки общедоступного ресурса.
Для целей 1 провайдера небольших размеров, адресного пространства rfc1918/rfc6598 должно быть более чем предостаточно.
Это что ж получается, провайдер выдал мне ДНС-ы (свои), и они дальше чем 1.1.1.1 - прописал в свой роутур 1.1.1.1 - тестирую
Так есть же ещё 1.0.0.1
Есть. Но адрес 1.1.1.1 все равно не должен быть заблокирован редиректом на личный кабинет или чем другим либо, до тех пор, пока не преобретен/арендован в его(провайдера) собственность.
P.S - Уже исправили. Все отлично бегает.
На Куевстаре праздник закончился:
бмен пакетами с 1.1.1.1 по с 32 байтами данных: Ответ от 1.1.1.1: число байт=32 время=33мс TTL=58 Ответ от 1.1.1.1: число байт=32 время=33мс TTL=58 Ответ от 1.1.1.1: число байт=32 время=33мс TTL=58 Ответ от 1.1.1.1: число байт=32 время=33мс TTL=58C:\Users\iamxr>tracert cloudflare.com
Трассировка маршрута к cloudflare.com [2400:cb00:2048:1::c629:d7a2]
с максимальным числом прыжков 30:
1 <1 мс <1 мс <1 мс 2001:67c:2128:754c:c256:27ff:fe63:92bc
2 1 ms 1 ms 1 ms 2001:67c:2dfc:fff5:ffff:ffff:ffff:ffff
3 1 ms 1 ms 1 ms 2001:67c:2dfc:fff2::209
4 23 ms 23 ms 24 ms 2a02:2518:0:44:0:4800:4:1
5 31 ms 31 ms 30 ms 2a02:2518:1:a:544::1
6 31 ms 33 ms 33 ms 2a02:2518:0:b2:0:1:3335:2
7 34 ms 34 ms 34 ms 2400:cb00:2048:1::c629:d7a2
вы трассу смотрите для начала
там вроде гиганет валялся как раз
Из временно оккупированного Крыма
C:\Users\Дмитрий>ping 1.1.1.1 -t
Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=33мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=31мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=31мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=31мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=32мс TTL=57
C:\Users\Aleksandr>ping 1.1.1.1
Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=11мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=12мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=12мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=11мс TTL=60
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_req=1 ttl=58 time=4.59 ms
64 bytes from 1.1.1.1: icmp_req=2 ttl=58 time=4.46 ms
64 bytes from 1.1.1.1: icmp_req=3 ttl=58 time=4.58 ms
64 bytes from 1.1.1.1: icmp_req=4 ttl=58 time=4.56 ms
64 bytes from 1.1.1.1: icmp_req=5 ttl=58 time=4.66 ms
64 bytes from 1.1.1.1: icmp_req=6 ttl=58 time=4.60 ms
64 bytes from 1.1.1.1: icmp_req=7 ttl=58 time=4.60 ms
64 bytes from 1.1.1.1: icmp_req=8 ttl=58 time=4.63 ms
64 bytes from 1.1.1.1: icmp_req=9 ttl=58 time=4.53 ms
64 bytes from 1.1.1.1: icmp_req=10 ttl=58 time=4.59 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 4.469/4.585/4.664/0.072 ms
Можно ставить 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4
DNS клиент согласно протокола отправляет запросы всем.
Скорость обработки определяется наименьшим временем ответа любого DNS-а.
ps. Хех... не срабатывает!
Выставил /etc/resolv.conf
nameserver 1.1.1.1 nameserver 1.0.0.1 nameserver 8.8.4.4 nameserver 8.8.8.8Ответ
# dig a.ua ; <<>> DiG 9.10.4-P1 <<>> a.ua ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35837 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;a.ua. IN A ;; ANSWER SECTION: a.ua. 86400 IN A 91.195.52.26 ;; Query time: 10 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: сб вер 29 16:51:36 EEST 2018 ;; MSG SIZE rcvd: 49Выставил
nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 1.0.0.1 nameserver 1.1.1.1Ответ
# dig a.ua ; <<>> DiG 9.10.4-P1 <<>> a.ua ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15045 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;a.ua. IN A ;; ANSWER SECTION: a.ua. 20121 IN A 91.195.52.26 ;; Query time: 41 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: сб вер 29 16:54:36 EEST 2018 ;; MSG SIZE rcvd: 49Фигня какая то!
поднимите у себя в сети кеширующий с форвардом на гугловские и клаудовские.
Клиент будет получать ответ куда бістрее
# traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets 1 xyz (10.1.1.1) 0.696 ms 0.855 ms 0.779 ms 2 92-244-99-53 (92.244.99.53) 1.661 ms 1.730 ms 2.472 ms 3 CORE-MX80-10G (92.244.96.21) 1.023 ms 1.405 ms 1.001 ms 4 MX80-10G-UA (92.244.96.125) 0.946 ms 0.947 ms 0.915 ms 5 185.1.50.68 (185.1.50.68) 1.147 ms 1.123 ms 1.173 ms 6 one.one.one.one (1.1.1.1) 1.012 ms 1.023 ms 1.111 msНе факт.
DNS он и в Африке DNS.
Если у тебя до гугловск 40ms, клаудовского 10ms, а до собственного 2ms, то это всего лишь время доступа к DNS серверам.
Процедура резолвинга происходит аналогично на любом DNS-е из трех, каскадный опрос зон и на это уходит практически одинаковое время.
Любой DNS является кеширующим.
Вот теперь можно и считать что будет быстрее.
Использовать левые DNS стоит когда не хочется заниматься своими и когда пров банит вражеские сайты на уровне DNS.
Ну если зона меняется по 100 раз на час, то да. А так только первый запрос будет идти на гугл/Клауд. Последующие уже будут идти с Кеша. А кеш внутри сети быстрее. Это факт.
>traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets 1 gate (195.12.59.33) 0.918 ms 0.261 ms 0.277 ms 2 185.1.50.68 (185.1.50.68) 5.111 ms 4.645 ms 27.527 ms 3 one.one.one.one (1.1.1.1) 0.444 ms 0.329 ms 0.320 msНикакой фигни а непонимание.
Список DNS адресов обрабатывает по очереди, активным всегда будет первый пока не перестанет отвечать. Тогда активность перейдет следующему.
Никаких проверок по rtt нет в принципе.
Ноконец то, а я уже начал подозревать, что земля сделалась плоской.
Может в линуксах и последовательно, но Винда берет в случайном порядке. При чем это сама система так работает, nslookup берет всегда первый сервер. По крайней мере так было на 7ке.
Так в Венгрии кэш где-то. По крайней мере именно эти IP адреса видно через dnsleaktest.. У Киевстара стык с Cloudflare в DTEL-IX. весь трафик идёт через dtel и только до 1.1.1.0/24 почему-то через Telia.
Ваше мнение ошибочно. Гугл кеш не работает на основе ДНС
Перевіряв від декількох операторів. Паритет з Google теж не рятує.
https://www.securitylab.ru/news/496428.php
Вы должны войти