Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

Post reply on HN
Print view View original

611–620 of 695 posts

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#611

Post by vavrusa »

jlgaddis wrote: post #399

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…

There's a public list of IP ranges on the website: https://www.cloudflare.com/ips/

There's troubleshooting utilities in the CHAOS class, e.g. dig @1.1.1.1 id.server ch txt

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#612

Post by kalleboo »

cleanbrowsing wrote: post #299

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…

I'm in a city in southern Japan (so most of my traffic needs to go to Tokyo first), on a gigabit fiber connection.

    --- 1.1.1.1 ping statistics ---
    rtt min/avg/max/mdev = 30.507/32.155/36.020/1.419 ms

    --- 8.8.8.8 ping statistics ---
    rtt min/avg/max/mdev = 19.618/21.572/23.009/0.991 ms
The traceroutes are inconclusive but they kind of look like Google has a POP in Fukuoka and CloudFlare are only in Tokyo.

edit: Namebench was broken for me, but running GRC's DNS Benchmark my ISP's own resolver is the fastest, then comes Google 8.8.8.8, then Level3 4.2.2.[123], then OpenDNS, then NTT, and then finally 1.1.1.1.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#614

Post by cpeterso »

alwillis wrote: post #579
cpeterso wrote: post #398

Here are instructions for testing DoH (DNS-over-HTTPS) in Firefox Nightly: https://gist.github.com/mcmanus/766a9564a51325b6543644983539...

DoH on Firefox nightly working great: Version: 61.0a1 (2018-04-01) OS: macOS High Sierra 10.13.4 (17E199)

According to the Firefox bug report, this was an Apple bug (related to TCP Fast Open) fixed in macOS 10.13.4. When I updated to 10.13.4, the panic went away.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#615

Post by DesertBattery »

jlgaddis wrote: post #539
DesertBattery wrote: post #440

Earlier quoted context omitted.

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…

Are you in .ru? 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…

I have static public /32. My ISP intercepting DNS traffic for censorship purposes. But i strongly doubt that this traffic is forwarded somewhere.

  [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
  "173.194.98.4"
  "edns0-client-subnet 94.181.44.185/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
  "173.194.98.4"
  "edns0-client-subnet 94.181.44.185/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
  "173.194.98.4"
  "edns0-client-subnet 94.181.44.185/32"

  [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
  "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656335.56','recursive':{'cc':'FI','srcip':'74.125.74.4','sport':'40964'}}"
  [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
  "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656336.4','recursive':{'cc':'US','srcip':'74.125.46.4','sport':'51510'}}"
  [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
  "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656337.96','recursive':{'cc':'US','srcip':'74.125.46.4','sport':'54992'}}"
127.1 is a DNS-over-HTTPS proxy.

  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
  "173.194.98.11"
  "edns0-client-subnet 94.181.44.0/24"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
  "173.194.98.11"
  "edns0-client-subnet 94.181.44.0/24"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
  "173.194.98.6"
  "edns0-client-subnet 193.151.48.130/32
Some story from other (business) connection.

  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.74.3"
  "edns0-client-subnet 37.113.134.30/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.46.4"
  "edns0-client-subnet 85.29.165.14/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "173.194.98.13"
  "edns0-client-subnet 77.234.25.49/32"

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#616

Post by karthikkolli »

Tree1993 wrote: post #549
matthberg wrote: post #536

Earlier quoted context omitted.

Ping from University of Rochester, over wifi: 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 Google: 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 t…

Beijing: PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=241.529 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=318.034 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=337.291 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=255.748 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=52 time=247.765 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=52 time=235.611 ms 64 bytes from 1.1.1.1: icmp_seq…

PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=61 time=15.860 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=61 time=15.799 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=61 time=15.616 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=15.769 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=15.431 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=16.459 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=61 time=15.860 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=61 time=15.930 ms

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#618

Post by djd20 »

predakanga wrote: post #601
bgdkbtv wrote: post #578

Earlier quoted context omitted.

Australia :( 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.580 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.025 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=17.780 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=18.231 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=17.906 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=18.447 ms

Interesting that they're announcing 1.1.1.1 in Australia, while their CDN traffic still goes via Hong Kong

Dubai: PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=48.728 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=48.450 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=47.266 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=45.320 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=46.470 ms

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#619

Post by vavrusa »

jlgaddis wrote: post #383

Is Cloudflare overriding TTLs on RRs? If I send a request to 1.0.0.1 for a specific RR that I'm 99.9% certain isn't cached (although I didn't check the query logs on the authoritative DNS servers to verify a request actually came in), the response contains the (expected) TTL of 14400. If I then send the same request to 1.1.1.1, I get a response that is identical except with a TTL of 3591 seconds. According to the tim…

Yes, there's a cap on both negative and positive cache lifetime. The reason is reducing the blast radius as accidents happen, and it hurts especially on long infrastructure records (mistake during repointing NSs, bad glue, expired DS etc.) We're going to be looking into making the cap more dynamic over time.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#620

Post by 6t6t6t6 »

matthberg wrote: post #536
chrissnell wrote: post #317

Earlier quoted context omitted.

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…

Ping from University of Rochester, over wifi: 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 Google: 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 t…

Tokyo, domestic 2Gbps FO but connected through Wifi:

    PING 1.1.1.1 (1.1.1.1): 56 data bytes
    64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=5.531 ms
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=4.420 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=5.450 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=5.438 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=4.231 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=5.933 ms



    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=6.440 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=4.574 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=4.684 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=4.992 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=5.942 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=5.955 ms
Post reply on HN