531–540 of 695 posts
"Cloudflare's 1.1.1.1 DNS will respond very fast, but the big sites you access, the whole reason for resolving DNS, will be SLOWER ∵ no edns-client-subnet support, so no geolocation of results." - https://twitter.com/philpennock/status/980561009961299968
Earlier quoted context omitted.
0 , which is a shorthand for 0.0.0.0 is likely the most code-golf-y way to write localhost , as many [EDIT: Linux] systems alias 0.0.0.0 to 127.0.0.1: $ ping 0 PING 0 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms Of course, don't expect this to work universally. A lot of software will try to be clever with input validation, and fail. Tangentially related: https://fosdem.or…
Stays unaliased on macOS: My-MacBook-Pro:bottle mrkstu$ ping 0 PING 0 (0.0.0.0): 56 data bytes ping: sendto: No route to host
Anybody got a howto to get dnsmasq to makes its requests over https or tls?
Earlier quoted context omitted.
From a residential connection in New Zealand: $ ping 1.1.1.1 Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 Reply from 1.1.1.1: bytes=32 time=4ms TTL=60 $ ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=27ms TTL=60 Reply from 8.8.8.8: bytes=32 time=27ms T…
Fastest Bigpipe residential connection available in the middle of Auckland: $ ping -c 4 1.1.1.1 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=56 time=29.0 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=27.7 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=30.5 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=28.6 ms --- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 receiv…
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=59 time=7.65 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=8.53 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=10.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=8.04 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=7.92 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=7.85 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=7.88 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=7.73 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=7.73 ms$ 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=47 time=214.866 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=47 time=173.416 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=45 time=256.007 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=45 time=196.638 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=45 time=294.694 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=45 time=314.883 ms 64 bytes from 1.1.1.1: ic…
ping dig
----------------
1.1.1.1 3.2 4
1.0.0.1 2.9 4
8.8.8.8 36.5 40
8.8.4.4 36.3 42
And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2…
Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms. I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers…
Cloudflare:
64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=2 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=9 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=2 ms
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=12 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=11 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=13 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=45 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=14 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=11 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=34 ms
64 bytes from 9.9.9.9: icmp_seq=0 ttl=53 time=10 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=69 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=53 time=14 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=53 time=58 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=53 time=52 ms
64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=14 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=14 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=3 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=1 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=128 time=4 msEarlier quoted context omitted.
Really hoping this question gets answered. It seemed contradictory to me.
My strong impression is that they wouldn't give APNIC any data that can be used to identify users of their DNS service, but I'd definitely love a more detailed answer than what the site currently provides.
Earlier quoted context omitted.
It basically comes down to being insecure. It's all plain-text over UDP. This is easily exploited for various purposes: spoofing (DDoS attacks), surveillance (such as by ISPs), hijacking/tampering, censorship, privacy concerns, and so on. As everything else relies on DNS, the DNS must also be secure.
Are there replacement options being worked on? What about wrapping each request and unwrapping on the other end. Something like how Tor wraps requests in many layers?
For the Cloudflare folks hanging around: Please, please, please add some basic "features" (like Google does) that will help when troubleshooting resolution! For example, the following will show the unicast IP address of the server you're hitting when using 8.8.8.8: $ dig @8.8.8.8 txt o-o.myaddr.l.google.com. +short Additionally, with one other DNS query, we can get a list of what netblocks are being used (for Google…
I think i have questions to Google: [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.46.8" "edns0-client-subnet 92.223.114.166/32" [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.46.11" "edns0-client-subnet 176.36.247.0/24" [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.74.3" "edns0-client-subnet 94.181.44.185/32" [user@v-fed-1 ~]$ dig txt…
You might direct your questions at your ISP instead as it appears that someone may be intercepting your DNS requests.
---- To elaborate a bit, the differences in the (74.125.x.x) IP addresses being returned is somewhat normal and would usually be attributed to simple load balancing (as d33 pointed out). That is, 8.8.8.8 is actually a load balancer with several servers (including 74.125.46.8, 74.125.46.11, and 74.125.74.3) behind it.
The differences seen in the returned "edns0-client-subnet", however, are, well, "interesting".
As you've directed the requests to 8.8.8.8 directly (as opposed to your system's default resolver, whatever that is), the response returned for "edns0-client-subnet" should normally either be your own IP address or a supernet that includes it. (In my case, for example, the value is the static IP address (/32) of my own resolver.) When sending multiple requests such as you have, the "edns0-client-subnet" shouldn't really be changing from one request/response to the next; at the least, the values shouldn't change this much.
The fact that the responses are changing would seem to indicate that Google DNS servers are receiving the requests from different IP addresses when they should, in fact, all be coming from the same IP address (yours). These changes would lead me to suspect that someone (i.e., your ISP) is intercepting your DNS requests and "transparently proxying" them on your behalf.
If your ISP is using CGNAT (and issues you a private IP address) or something similar, that might explain it. Otherwise, I would be suspicious.