1.1.1.1 and Cloudflare DNS Are Two Different Products: Recursive vs Authoritative, Explained

The short version: When you set your laptop’s DNS to 1.1.1.1, you’re using Cloudflare’s recursive resolver. When you point your domain example.com at ns1.cloudflare.com, you’re using Cloudflare’s authoritative DNS. They share a logo, but they’re different products that do opposite jobs in a DNS lookup. Most confusion about DNS comes from collapsing the two into one mental model. They aren’t.

Two DNS products, one company

Cloudflare runs both of these. They show up in different places in the company’s product catalog and they’re built for completely different customers:

• Cloudflare DNS (authoritative). You sign up, add a domain, and Cloudflare gives you two nameservers like ns1.cloudflare.com and ns2.cloudflare.com. You point your registrar at those, and now Cloudflare answers the world’s questions about your domain. This is for domain owners.
• 1.1.1.1 (recursive). You configure your laptop, phone, or home router to use 1.1.1.1 as its DNS server. Now when you try to load example.com, your device asks Cloudflare’s resolver to figure out the IP for you. This is for end-users and ISPs.

Same company, same brand, totally different jobs. Understanding which side of the lookup each one is on is the entire point of this post — and it’s the foundation for understanding DNS in general, not just Cloudflare’s products.

Side note: Cloudflare also operates as a domain registrar — separate from both products above. That’s its own topic and gets its own post; here we’re staying focused on the recursive vs authoritative split.

Every DNS lookup has two halves

When your browser needs to load https://travteks.com, two distinct kinds of servers cooperate to turn that name into an IP address:

• The recursive resolver — works on your behalf. Your device asks it “what’s the IP for travteks.com?” and the resolver does the legwork. It calls other DNS servers, follows referrals, validates responses, caches the answer, and finally hands a single result back to you. Your device typically has a short list of resolvers configured (a primary plus one or two fallbacks), either set manually in network preferences or learned from a DHCP server.
• The authoritative server — answers for a specific zone. It doesn’t go ask anyone else. It just knows the records for the domain it’s responsible for, because the domain owner configured them there. Each domain has its own authoritative servers (usually 2–4 of them).

A useful mental model: the recursive resolver is your librarian. The authoritative server is the publisher of a specific book. You ask the librarian “where’s the copy of Moby Dick with the Rockwell Kent illustrations?” The librarian tracks down which publisher made that edition, calls them, gets the answer, and tells you. You don’t talk to the publisher directly. The publisher only knows about the books they themselves printed.

That’s exactly how recursive and authoritative DNS divide their work.

Cloudflare’s authoritative DNS, concretely

When someone “uses Cloudflare for their DNS,” what they almost always mean is: they signed up at the Cloudflare dashboard, added their domain, and changed the nameservers at their registrar to Cloudflare’s.

From that point on, Cloudflare’s authoritative nameservers — globally anycast, hundreds of locations — are the source of truth for that domain’s records. Anyone in the world who asks “what’s the A record for travteks.com?” will eventually have their question routed to one of those nameservers, which will respond with whatever the domain owner has configured.

What this product does:

• Stores the zone records (A, AAAA, CNAME, MX, TXT, NS, CAA, SRV, etc.) for domains the customer adds.
• Responds to queries from any recursive resolver in the world that comes asking about those domains.
• Signs the zone with DNSSEC if the customer enables it (covered in DNSSEC explained and implementing DNSSEC in Cloudflare).
• Does not look anything up on your behalf. It only answers for what’s loaded into its zones.

What this product is not: it is not the thing you put in your laptop’s network settings. Configuring ns1.cloudflare.com as your laptop’s DNS server doesn’t work — it’ll refuse to recurse for you, because that’s not what authoritative servers do.

1.1.1.1, concretely

1.1.1.1 (and its IPv6 sibling 2606:4700:4700::1111) is Cloudflare’s public recursive resolver. Launched in 2018, jointly with APNIC, it’s a free service that anyone can use as their DNS resolver — no account, no signup, no Cloudflare relationship required.

What this product does:

• Accepts DNS queries from any device on the internet.
• Doesn’t itself know what travteks.com resolves to. To answer, it does the iterative walk against the global DNS hierarchy on your behalf.
• Caches every answer it learns, respecting each record’s TTL, so the next person asking the same question gets an instant response without repeating the walk.
• Validates DNSSEC signatures where the zone is signed, returning SERVFAIL if a signature fails to validate.
• Strips EDNS Client Subnet by default, so authoritative servers don’t see your IP — they only see the resolver’s IP.
• Runs anycast across 300+ Cloudflare data centers, so your packets hit the closest one.

What this product is not: it doesn’t host your domain’s records. Adding an A record at 1.1.1.1 is a category error — there’s no UI for that because it’s not that kind of server. To host your domain on Cloudflare, you use Cloudflare DNS (the authoritative product).

A real lookup, walked through

Let’s trace what happens the first time 1.1.1.1 is asked for travteks.com. Assume nothing is cached anywhere.

1. Your device → 1.1.1.1. “What’s the A record for travteks.com?”
2. 1.1.1.1 → a root server. Cloudflare’s resolver picks one of the 13 root server letters (a.root-servers.net through m.root-servers.net) and asks the same question. The root doesn’t answer with the IP — it answers with a referral: “I don’t know, but the .com TLD is handled by these nameservers: a.gtld-servers.net, b.gtld-servers.net, etc.”
3. 1.1.1.1 → a .com TLD server. “What’s the A record for travteks.com?” The TLD server also doesn’t answer with the IP — it answers with another referral: “travteks.com is delegated to these nameservers: [whichever ones the registrar configured].”
4. 1.1.1.1 → travteks.com’s authoritative servers. “What’s the A record for travteks.com?” This server is configured to answer for that zone, so it returns the actual IP.
5. 1.1.1.1 → your device. Hands back the final answer.

That whole chain — root → TLD → authoritative — is called iteration, and it’s what the recursive resolver does on your behalf. Your device only ever talks to the resolver. The resolver does all the round-trips with all the other servers.

After that first lookup, 1.1.1.1 caches the answer for as long as the TTL says, so the next million people asking about travteks.com get an instant response without anyone touching the root or TLD again.

You can watch this exact process happen with the DNS Delegation Trace tool — it walks the chain from root → TLD → authoritative and shows you each level’s referrals. The whole iterative-walk concept stops being abstract once you see it laid out.

What 1.1.1.1 specifically does that’s worth knowing

Beyond just being “another resolver,” 1.1.1.1 has a few choices baked in that are worth understanding:

Privacy. Cloudflare publicly committed to not logging the IP-address-and-query pairs of users for more than 24 hours. They commission KPMG audits annually to verify this. Compare with your ISP’s resolver, which can usually log everything you query and in many jurisdictions has been compelled to share that data with advertisers, regulators, or both.

DNSSEC validation by default. When a zone is signed and the signature is bad — say, an active man-in-the-middle is forging responses — 1.1.1.1 returns SERVFAIL rather than passing the forged answer through. Many ISP resolvers don’t validate, which means a bad signature just looks like a normal answer.

EDNS Client Subnet stripped. By default, recursive resolvers can pass a truncated version of your IP (/24 for IPv4) to authoritative servers so they can geo-target responses. Cloudflare strips this. The trade-off: CDNs that do geo-DNS see Cloudflare’s resolver IP instead of yours, so the answer they give might not be the closest edge to you specifically. For privacy-conscious users that’s the right trade-off; for people optimizing for latency to a non-Cloudflare CDN it’s worth knowing.

Encrypted transport. Beyond traditional UDP/TCP port 53, 1.1.1.1 supports DNS-over-HTTPS at https://cloudflare-dns.com/dns-query and DNS-over-TLS on port 853. Both encrypt your DNS queries so your local network and ISP can’t see what you’re looking up. You can poke at this directly with our DoH Tester.

Anycast network. The IP 1.1.1.1 is announced from every Cloudflare data center. Your packet to 1.1.1.1 doesn’t go to “Cloudflare HQ” — it goes to whichever Cloudflare data center is closest to you on the BGP topology. That’s why it feels fast everywhere.

The “wait, what?” misconception

Here’s the moment of confusion most people hit:

“I added my domain to Cloudflare. Does that mean my DNS is 1.1.1.1 now?”

No. Adding your domain to Cloudflare puts it on Cloudflare’s authoritative DNS, with nameservers like ns1.cloudflare.com and ns2.cloudflare.com. 1.1.1.1 is a separate product, on a separate path through the lookup, doing the opposite job.

When someone visits your site:

• Their device’s resolver (which might be 1.1.1.1, or 8.8.8.8, or their ISP’s, or whatever) does the iterative walk.
• That resolver eventually lands on your domain’s authoritative servers (which, if you’re a Cloudflare DNS customer, are Cloudflare’s authoritative anycast nodes, not 1.1.1.1).
• Those authoritative servers hand back the records you’ve configured.

If your laptop happens to also be configured to use 1.1.1.1 as its resolver, you’ve got Cloudflare on both halves of the lookup — but that’s coincidence. The two products are unrelated and serve different roles.

Try it yourself

The fastest way to make this stick is to actually run a few queries. From a terminal:

# Ask 1.1.1.1 directly — recursive query, full answer
dig @1.1.1.1 travteks.com

# Ask the .com TLD directly — referral only, no answer
dig @a.gtld-servers.net travteks.com

# Ask Cloudflare's auth DNS directly for a domain it hosts
dig @ns1.cloudflare.com cloudflare.com

Notice how the second query returns referral data in the AUTHORITY section but no actual A record — because TLD servers don’t know the answer, they only know who does.

Or skip the CLI and use the site’s DNS tooling:

• DNS Record Lookup — pull every record type for any domain.
• DNS Delegation Trace — walk the chain root → TLD → authoritative.
• DoH Tester — issue a query against any DoH endpoint, including 1.1.1.1’s.
• Reverse DNS Lookup — verify PTR records the same way.

Quick reference

Bottom line

When someone says “DNS,” they usually mean one of these two things — and they almost always mean it without realizing there’s a distinction. Once you’ve internalized which side does which job, every other DNS topic gets easier: how DNSSEC chains of trust work, why anycast helps both sides differently, why TTLs matter on the authoritative side and TTL respect matters on the recursive side, why a DoH endpoint lives on a recursive resolver and not an authoritative server.

1.1.1.1 is a great recursive resolver. Cloudflare DNS is a great authoritative service. They’re not the same thing. They don’t even talk to each other directly. And once you can sketch out the lookup chain on a napkin and put both products in the right boxes, you’ve crossed the line from “DNS user” to “DNS-literate.”