331–340 of 695 posts
Earlier quoted context omitted.
The client sends SNI, so how could the server opt out?
You just solved your own question. Cloudflare creates an opensource client that users install locally.
DNS-over-HTTPS doesn’t make as much sense to me as DNS-over-TLS. They are effectively the same thing, but HTTPS has the added overhead of the HTTP headers per request. If you look at the currently in progress RFC, https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04 , this is quite literally the only difference. The DNS request is encoded as a standard serialized DNS packet. The article mentions QUIC as being…
One of the use cases for DNS-over-HTTPS given in the draft was to allow web applications access to DNS directly via existing browser APIs.
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…
ping 1.1.1.1: ~22ms
ping 8.8.8.8: ~19ms
dig @1.1.1.1: ~45ms
dig @8.8.8.8: ~70ms
Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see.
Disclosure: I work for Cloudflare, but not on DNS.
My ISP
Pinging 168.210.2.2 with 32 bytes of data:
Reply from 168.210.2.2: bytes=32 time=1ms TTL=58
Reply from 168.210.2.2: bytes=32 time=1ms TTL=58
Reply from 168.210.2.2: bytes=32 time=1ms TTL=58
Reply from 168.210.2.2: bytes=32 time=1ms TTL=58
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=18ms TTL=54
Reply from 8.8.8.8: bytes=32 time=18ms TTL=54
Reply from 8.8.8.8: bytes=32 time=18ms TTL=54
Reply from 8.8.8.8: bytes=32 time=18ms TTL=54
CloudFlare
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=22ms TTL=246
Reply from 1.1.1.1: bytes=32 time=22ms TTL=246
Reply from 1.1.1.1: bytes=32 time=22ms TTL=246
Reply from 1.1.1.1: bytes=32 time=21ms TTL=246
It's also a PITA to change this on each device.
$ 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 -c 10 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=64 time=1.15 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.15 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=1.04 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.03 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=1.01 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=1.02 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=1.07 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.00 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=64 time=0.848 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
rtt min/avg/max/mdev = 0.848/1.042/1.153/0.086 ms
~ ping -c 10 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=56 time=6.82 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=6.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=6.39 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=6.73 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=6.55 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=6.14 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=6.24 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=6.22 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=6.19 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=6.30 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 6.149/6.433/6.826/0.248 msAnd 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…
1) Level3
2) DynGuide
3) UltraDNS
4) OpenDNS
5) Quad9
6) CloudFlare
7) Google
Earlier quoted context omitted.
When we add TLS on top of the protocol, ISPs can only filter based on port at that point. We can run DNS on 443 if that helps, but as you said, static well-known IPs can then be blocked. > I imagine most of the benefit is surely to people who can spin up their own resolvers. There are already many easily run DNS resolvers available. Is there a benefit you see in operating them over HTTPS that improves on that?
> When we add TLS on top of the protocol, ISPs can only filter based on port at that point. And SNI… :(
Earlier quoted context omitted.
Don't try that in the wild, most sw out there would ignore spec and use some arbitrary regex to validate IP format. i.e python: octets = ip_str.split('.') if len(octets) != 4: raise AddressValueError("Expected 4 octets in %r" % ip_str)
What spec says that 127.1 and 127.0.0.1 are equivalent?
Earlier quoted context omitted.
When we add TLS on top of the protocol, ISPs can only filter based on port at that point. We can run DNS on 443 if that helps, but as you said, static well-known IPs can then be blocked. > I imagine most of the benefit is surely to people who can spin up their own resolvers. There are already many easily run DNS resolvers available. Is there a benefit you see in operating them over HTTPS that improves on that?
> When we add TLS on top of the protocol, ISPs can only filter based on port at that point. And SNI… :(