Interesting that https://dnsleaktest.com/ does not work with Cloudflare's DNS... that's a first one for me.
1.1.1.1: Fast, privacy-first consumer DNS service
51–60 of 695 posts
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#52Cloudflare, are you planning to support the OpenNIC initiative with this later on, rather than just being a regular, alternative DNS resolver?
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#53Today I learned that it is possible to request a certificate for an IP address.
Yup, the Subject Alternative Name (often misunderstood as an alias, but "Alternative" here is meant in the sense of this is the Internet's _Alternative_ way to name things versus the X.500 series directory hierarchy that the X.509 certificates are originally intended for) can be one of several distinct types, the two relevant for servers are dnsName and ipAddress. dnsName can be any er, name, in the DNS hierarchy, or…
Thanks for the clarification. I did know it was possible when setting up CA's for VPN servers, they can use certificates with DNS and/or IP as identifiers. Somehow I never thought about certificates for public IP addresses.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#54I am getting ERR_CERT_AUTHORITY_INVALID because my ISP-provided router is intercepting the connection and trying to show me a "helpful" configuration wizard. No Cloudflare DNS for me.
To be explicit: This is not Cloudflare's fault and we should blame the manufacturer of the router, or the ISP for deploying their custom "friendly" settings. But it is what it is.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#55$ 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…
Tokyo, Japan:
[mason@iMac-Pro-No-5 fubastardo (master)]$ 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=56 time=2.310 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.287 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.103 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=2.785 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=2.276 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=2.646 ms
^C
--- 1.1.1.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.103/2.401/2.785/0.236 ms
[mason@iMac-Pro-No-5 fubastardo (master)]$
[mason@iMac-Pro-No-5 fubastardo (master)]$
[mason@iMac-Pro-No-5 fubastardo (master)]$ 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=56 time=2.217 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=1.837 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1.838 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=2.010 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=1.827 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=2.056 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=1.807 ms
^C
--- 8.8.8.8 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.807/1.942/2.217/0.145 ms
[mason@iMac-Pro-No-5 fubastardo (master)]$Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#56$ 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…
Both are not fast in China. :(
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#57Today I learned that it is possible to request a certificate for an IP address.
Edit: I had not realised what the parent comment here meant, that you can coonect to an IP address without getting an error by adding the IP to the SAN. My explanation bellow is about finding certs installed for a given IP/hotname, typically with openssl.
Yes, but...
This only works if they don't use SNI[1]. If they use SNI then you just get the default cert. They might have more certs for other hostnames served on that IP address.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#58Just curious: can somebody shed light on how they got the 1.1.1.1 IP address?
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#59If everyone* just ran a full recursing resolver would that cause undue load on the root-servers? Seems like a sane way to decentralise. * Actually only ~1% of internet users, the kind of people that install openwrt
Well, OpenWRT, DD-WRT, pfSense and OPNSense eh.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#60uhm how can you get an ssl cert for an IP?
Apparently, you need to provide it as a Subject Alternative Name (SAN). This is the entry for the cert used: DNS Name=*.cloudflare-dns.com IP Address=1.1.1.1 IP Address=1.0.0.1 DNS Name=cloudflare-dns.com IP Address=2606:4700:4700:0000:0000:0000:0000:1111 IP Address=2606:4700:4700:0000:0000:0000:0000:1001
SAN is the only correct way to write any kind of name for servers on the Internet in a certificate. The "Common Name" was left as a compatibility feature like 20 years ago when SANs were invented and then it rusted into place, but is no longer examined by current Firefox or Chrome browsers for "real" certificates from the public Internet. Chrome shipped releases for a while with a bug where they'd complain the server's cert had the wrong "Common Name" when actually they never checked CN at all, and so it might even have the right Common Name, but they really meant "Your SANs don't match fool" and hadn't updated the error text.
Because crappy software (looking at you here OpenSSL) makes writing SANs into a Certificate Subject Request way harder than it needs to be, a lot of CAs (including Let's Encrypt) will take a CSR that says "My Common Name is foo.example" and sigh, and issue a cert which adds SAN dnsName foo.example, because they know that's what you want. Really somebody should fix the software, one of these days.
In older Windows versions, SChannel (Microsoft's implementation of SSL/TLS) doesn't understand ipAddress, and thinks the correct way to match an ipAddress against a certificate is to turn the address into ASCII text of dotted decimals and compare that to the dnsName entries. This, unsurprisingly, is not standards compliant.
It's good to see a CA not trying to fudge this, but the consequence is probably that if you have older Windows (XP? Maybe even something newer) these certs don't check out as valid for the site. Eh. Upgrade already.