Help us test a new version of 1.1.1.1: Public DNS resolver

Short version:
Help us test a new version of 1.1.1.1: Public DNS resolver.

The new version that the team is working on will make 1.1.1.1 faster. Note that this version of resolver is less stable than the version of 1.1.1.1 that you use today and may run into bugs or edge cases for resolving some domains.

Change your DNS resolver settings to use the following IP addresses:

  • 1.0.0.2
  • 2606:4700:4700::1002

If you find any issues please add a reply to this thread.

(This is the same product as 1.1.1.1:Public DNS resolver and has the same privacy commitments )


Long version:

Hello good people of Cloudflare Community,

We are asking for your help to test a new version of the 1.1.1.1: Public DNS resolver. This new version of 1.1.1.1 is faster. However, it is not as stable as the 1.1.1.1 that you are used to using everyday. Your help will help our team to find all the edge cases and bugs for the new version of the public DNS resolver. This is the same product as 1.1.1.1: Public DNS resolver and has the same privacy commitments.

Here’s how you can start testing:

Change your DNS resolver settings to use the following IP addresses:

  • 1.0.0.2
  • 2606:4700:4700::1002

(DoH/DoT is not available for testing yet)

Note that this version of resolver is less stable than the one that you are used to using and may run into bugs or edge cases for resolving some domains, As you run into issues (which we think you may), please add a reply to this thread and our team will investigate the issue. When you are posting a reply please paste the information we need to debug the problem. Details are pasted in this thread (replace the IP addresses from Cloudflare with 1.0.0.2 and 2606:4700:4700::1002 ).

Thank you so much for helping our team improve 1.1.1.1: Public DNS resolver.

5 Likes

Cool. Can you discuss what has changed?

2 Likes

Is DoH supposed to work?

curl --resolve cloudflare-dns.com:443:1.0.0.2 'https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=AAAA' -vs

* Added cloudflare-dns.com:443:1.0.0.2 to DNS cache
* Hostname cloudflare-dns.com was found in DNS cache
*   Trying 1.0.0.2...
* TCP_NODELAY set
* Connected to cloudflare-dns.com (1.0.0.2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com
*  start date: Jan 28 00:00:00 2019 GMT
*  expire date: Feb  1 12:00:00 2021 GMT
*  subjectAltName: host "cloudflare-dns.com" matched cert's "cloudflare-dns.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert ECC Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x7fffe697c580)
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
> GET /dns-query?name=cloudflare.com&type=AAAA HTTP/2
> Host: cloudflare-dns.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
< HTTP/2 400
< date: Wed, 18 Dec 2019 01:50:20 GMT
< access-control-allow-origin: *
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 546d7c403cf7e73c-EWR
<
* Connection #0 to host cloudflare-dns.com left intact

Looks like it requires SNI, so a direct request to https://1.0.0.2/dns-query fails as well:

curl --resolve cloudflare-dns.com:443:1.0.0.2 'https://1.0.0.2/dns-query?name=cloudflare.com&type=AAAA' -vs

* Added cloudflare-dns.com:443:1.0.0.2 to DNS cache
*   Trying 1.0.0.2...
* TCP_NODELAY set
* Connected to 1.0.0.2 (1.0.0.2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* stopped the pause stream!
* Closing connection 0

cURL version:

curl -V

curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PS
1 Like

No. Just UDP (I will update the post to reflect that)

4 Likes

I’m seeing TCP working as well.

Edit: The edit you made to the first post explicitly states no DoH/DoT rather than UDP-only. Makes sense now. :slight_smile:

I guess these share the DNS cache:

$ dig dfgiohewrg.judge.sh @1.0.0.2

;; Query time: 94 msec
;; SERVER: 1.0.0.2#53(1.0.0.2)
;; WHEN: Tue Dec 17 23:28:21 EST 2019

$ dig dfgiohewrg.judge.sh @1.0.0.1

;; Query time: 12 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Tue Dec 17 23:28:24 EST 2019

1 Like

They definitely don’t share a cache; initial lookups are often slower on 1.0.0.2 since fewer people use it and less data is cached. Subsequent lookups are usually faster than or similar to 1.1.1.1 and 1.0.0.1, from what I’ve seen.

1 Like

Changing my resolvers now. Will report my experience. Thank-you; I enjoy beta testing.

3 Likes

They almost definitely do not share a cache based on some casual testing.

Difficult to be certain thanks to the anycast nature of both services, but I can show fresh query data from 1.0.0.2 after repeated queries to 1.0.0.1 from a few different IPs to prime their cache (to attempt to beat any preferential load balancing based on source IP, which I also do not believe is happening, but also cannot prove).

Is the testing phase over?
Is 1.1.1.1 even faster now?

We are still continuing the testing? Have you found any issues with the test IPs?

1 Like

I experienced no issues with 1.0.0.2, except slightly slower uncached DNS resolves.

I have using it for a few days here in north India. Seems to be faster then 1.1.1.1 no issues so far.

1 Like

So, are you still testing?
Any conclusions?

No issues. Using it on mobile devices and within wireless router.