Údajně nejrychlejší DNS server 1.1.1.1 je už k dispozici i na Androidu a iOS

Názory k článku

13. 11. 2018 11:38 | Microsoft Windows 10 Chrome 70.0.3538.77

Mám nastaveno přímo v routeru, zejména protože můj poskytovatel unáší DNS požadavky na protu 53 ve prospěch Google DNS a servery od CZ NIC jsou bohužel pomalejší (16ms) / DNS Cloudflare (8ms). Mám u Cloudflare spravovanou i doménu, hlavně kvůli jednoduchému nastavení požadovaných TLS protokolů, firewallu a Comodo SSL certifikátu zdarma.

Souhlasím  |  Nesouhlasím  |  Odpovědi (2)Zavřít odpovědi  |  Odpovědět
avatar
13. 11. 2018 13:44 | Macintosh OS X Chrome 70.0.3538.77

Aplikace pro nastavení DNS? Šmankote...

Souhlasím  |  Nesouhlasím  |  Odpovědět
lukasmagi  |  13. 11. 2018 14:51  |  Microsoft Windows 10 Chrome 70.0.3538.77

Rychlost zpracovaní dotazu je jedna věc, ale dostupnost samotného serveru od vašeho poskytovatele je jiná....
Připojení t-mobile :
Ping 1.1.1.1 50ms avg.
Ping 8.8.8.8 20ms avg.Zkoušel i jiné připojení (domácí optika, WiFi u kamaráda)
Stále google vede :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
madloki  |  13. 11. 2018 15:37  |  Linux Chrome 65.0.3325.181

Marketing, a nepresvedcivy.ISP1:
google rtt min/avg/max/mdev = 9.542/10.231/11.349/0.462 ms
cloudflare rtt min/avg/max/mdev = 9.191/10.211/21.314/1.860 ms
AWS Frankfurt (elastic IP): rtt min/avg/max/mdev = 17.248/18.092/21.696/0.623 msISP2:
google rtt min/avg/max/mdev = 4.532/5.015/8.685/0.440 ms
cloudflare rtt min/avg/max/std-dev = 4.206/4.304/4.526/0.062 ms
AWS Frankfurt: rtt min/avg/max/mdev = 12.791/13.180/14.381/0.321 msISP3:
google rtt min/avg/max/std-dev = 3.865/3.970/4.279/0.076 ms
cloudflare rtt min/avg/max/std-dev = 4.206/4.304/4.526/0.062 ms
AWS Frankfurt: rtt min/avg/max/std-dev = 11.916/12.047/13.973/0.204 msGoogle vs ClouFlare:
ISP1 stejne, google lepsi jitter
ISP2 lepsi cloudflare (0.7 msec), i jitter
ISP3 lepsi google (0.4msec), cloudflare lepsi jitterPodstatne je neco jineho:Google public DNS znaj a tudiz pouzivaj masy po leta, je tedy extremne zatezovany i provereny. Narust provozu u nej tedy nehrozi, bezne jej pouzivam pro SLA monitor na Cisco a v obdobne roli na firewallech, pokud potrebuju overit dostupnost internetu via jednotlive ISP.CloudFlare by se asi rad dostal, kde je Google, ale to ukaze az cas (a narust provozu). Vedet, kam zakaznici pristupuji, je marketingove neocenitelne, a tudiz se asi budou snazit umerne profitu (pokud obchodne porazi Google, ktery roky vydelava na reklamach, pro jejichz analyzu je znalost DNS provozu sakra vyhodou).Technicky test na odezvu ICMP nic nerika o kvalite a odezve DNS, navic QoS nekterych ISP icmp na vybrane IP proste pousti prvni, i kvuli podobnym testum Ten Amazon do rajchu je spis vtip, ve virtualizaci radi a casto udp a icmp dropuji a nastavuji rate-limity, navic jde o T2.micro instanci.

Souhlasím  |  Nesouhlasím  |  Odpovědi (1)Zavřít odpovědi  |  Odpovědět
mungo  |  13. 11. 2018 17:50  |  Microsoft Windows 7 Chrome 70.0.3538.77

Co má společného operační systém (Android, iOS) se servery DNS?
To jako na těchto systémech nelze nastavit alternativní DNS?
Pěkná ptákovina.

Souhlasím  |  Nesouhlasím  |  Odpovědi (2)Zavřít odpovědi  |  Odpovědět
14. 11. 2018 00:15 | Microsoft Windows 7 Chrome 70.0.3538.102

Ping (az) 10ms? No na Google to mam rychleji, a to jsem to ted testoval z docela "hnusnych" mist.
PS: Tak oni to DNS maji sifrovane jo? A jak prosim sifrovane? Jako ze se k tomu neda dostat? Nebo uplne stejne jako vsichni ostatni?[root@france reboot]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=4.31 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=4.17 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=4.13 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=4.16 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=122 time=4.16 msC:\Users\O2>ping 8.8.8.8
Příkaz PING na 8.8.8.8 - 32 bajtů dat:
Odpověď od 8.8.8.8: bajty=32 čas=9ms TTL=119
Odpověď od 8.8.8.8: bajty=32 čas=9ms TTL=119
Odpověď od 8.8.8.8: bajty=32 čas=10ms TTL=119
Odpověď od 8.8.8.8: bajty=32 čas=8ms TTL=119[root@forpsicz ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=124 time=12.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=124 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=124 time=12.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=124 time=12.3 ms

Souhlasím  |  Nesouhlasím  |  Odpovědi (1)Zavřít odpovědi  |  Odpovědět
ladesn  |  15. 11. 2018 16:35  |  Microsoft Windows 10 Chrome 70.0.3538.77

Kazdy kdo se trosku pohybuje v tematu WAN, vi ze srovnavat neco icmp testem je nic nerikajici. icmp ma nulovou prioritu, da se porovnavat vysledek 30ms vs 300ms ale ne 15ms vs 30ms... Porovnavani jitteru mi taky moc nedava smysl. Zkuste taky vic nez jen ping pres vaseho O2, Internet neni jen relativne slusna CZ(evropska) infrastruktura. Mnozi by se divili, jak jsou na tom dal na vychod od Evropy, treba Google v Cine..

Souhlasím  |  Nesouhlasím  |  Odpovědět
vit20  |  15. 11. 2018 20:34  |  Microsoft Windows 8.1 Chrome 70.0.3538.102

U mě je to následovné:SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 121 23ms
1 8.8.8.8 56 121 18ms
2 8.8.8.8 56 121 22ms
3 8.8.8.8 56 121 30ms
sent=4 received=4 packet-loss=0% min-rtt=18ms avg-rtt=23ms max-rtt=30ms SEQ HOST SIZE TTL TIME STATUS
0 217.31.204.130 56 57 18ms
1 217.31.204.130 56 57 24ms
2 217.31.204.130 56 57 15ms
3 217.31.204.130 56 57 15ms
sent=4 received=4 packet-loss=0% min-rtt=15ms avg-rtt=18ms max-rtt=24ms SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 58 48ms
1 1.1.1.1 56 58 34ms
2 1.1.1.1 56 58 14ms
3 1.1.1.1 56 58 29ms
sent=4 received=4 packet-loss=0% min-rtt=14ms avg-rtt=31ms max-rtt=48ms ... a už jen z důvodu nejnižší odezvy používám CZ.NIC :)

Souhlasím  |  Nesouhlasím  |  Odpovědi (2)Zavřít odpovědi  |  Odpovědět
remetremet  |  21. 11. 2018 10:52  |  Microsoft Windows 10 Chrome 70.0.3538.102

Vim, ze samotny ICMP ping neni vypovidajici, ale treba mi nekdo vysvetli zahadu s VF LTE...64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=1.958 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=4.184 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=3.073 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=1.933 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=0.812 ms
round-trip min/avg/max/stddev = 0.678/2.400/4.428/1.224 msRychlosti odezvy to odpovida lokalnimu routeru. To na nem kradou ICMP pro 1.1.1.1?Jinak pokud srovnam cely DNS dotaz pres VF LTE, tak to vypada takhle:
host root.cz 1.1.1.1 = 49-101ms
host root.cz 8.8.4.4 = 102-164ms
host root.cz 217.31.204.130 = 78-127ms
host root.cz = 95-132msPres T-mobile LTE to vypada takhle:
host root.cz 1.1.1.1 = 132-174ms
host root.cz 8.8.4.4 = 60-105ms
host root.cz 217.31.204.130 = 65-84ms
host root.cz = 58-90msPres me standardni WiFi pripojeni, tak to vypada takhle:
host root.cz 1.1.1.1 = 29-54ms
host root.cz 8.8.4.4 = 28-104ms
host root.cz 217.31.204.130 = 28-48ms
host root.cz = 29-62msPro srovnani jeste ze serverovny:
host root.cz 1.1.1.1 = 5-6ms
host root.cz 8.8.4.4 = 5-32ms
host root.cz 217.31.204.130 = 10-18ms
host root.cz = 12-20ms
Celkem mi prijde, ze vsechny vysledky jsou srovnatelne a moc se tim neziska. Spis jestli neni lepsi lokalni resolver, zvlast tam, kde ma clovek pomale pripojeni (tj. cokoli nad 20ms), protoze sice prvni dotaz bude treba nejakych 100ms, ale kazdy dalsi uz cca. 10-20ms, coz je pak vyrazne rychlejsi nez jakekoli vnejsi DNS.

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
24. 11. 2018 16:38 | Microsoft Windows 10 Chrome 70.0.3538.102

Údajně nejrychlejší DNS, které odmítá připojení. V google jsem si vyhledal 1 1 1 1 dns a našlo mi to přímo odkaz na 1.1.1.1, které ovšem odmítá připojení.. Výpadek?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Velký test Wi-Fi mesh

Nejlepší hodinky pro všechny aktivity

Důležité aplikace na cesty

Jak streamovat video na Twitch