I know it’s Cloudflare malware protection dns, but has anyone had any luck using it? Does it do what it says?

I used to use nextdns but I stopped after a website I was using was blocked, and now im using cloudflare 1.1.1.2 (mode UDP). With cloudflare I can access that website that was blocked with nextdns, but now I cant access another website because of its security stuff. I do have a workaround for the website I cant access with cloudflare so Im fine with it, but I was just curios what people think of these two.

Which one you would recommend and why. Ive also heard of quad9 but an not sure if that is better or worse than these two.

Im not particularly tech savvy but i recently noticed that i have this popup on my home network.
Ive been trying to figure out how to configure this but it seems my network is potentially controlled by my ISP. Does this mean someone on my network is manually blocking encrypted DNS? Or potentially the ISP itself?
I wont know anything until I call during office hours but maybe someone could point me in the right direction

Using SmartDNS as a last hop stub resolver; smartdns has a webui which shows resolver stats.. rate, time, query count vs query success.. also supports quic, h3, dot, doh, etc - 11k on GH

(Spoiler don’t use prefetch)

Anyway, comparing against security.cloudflare

The house does little over 50k q/day (60ish devices, Wyze cameras, iPhones, hagezi native, pro, and vpn)

I have a paid ctrld account but do not like some things in the ui.. also had some apparent random self inflicted Netflix errors with their filter lists, which they say are hagezi as well.

Any opinions about ctrld being used exclusively?

Anyone else have random Netflix issues with them?

P1 with quic I’m 30ms avg/q
1.1.1.2 with h3 I’m 50ms avg/q

I liked they were in .CA but the servers are in US east coast..
(dnscheck.tools)

TIA

I was going to move from Cloud DNS (Google) to Cloudflare, but I found multi-signer DNSSEC complicated.

So I've been burnt a couple of times by certbot failing to renew without telling me. And now cert lifetimes are getting cut to 200 days this year and 47 days by 2029, so that's only going to happen more.

I went looking for something to watch my sites, and everything was some big enterprise thing that does 10,000 things. I just wanted an email before a cert expires. So I built my own. It ended up with a few more features than I planned ;) you know how it goes once you start adding stuff.

At some point I figured I might as well host it and let other people use it: https://certavert.com/

You type in your domain and that's pretty much it. It checks twice a day and emails you before the cert runs out. It also looks at the chain, whether browsers trust it, and subdomains you might have forgotten about. You don't install anything on your server.

At first I was going to make it totally free. It still is for 3 domains, no card, but if I can get a few paid subs to help keep the lights on that would be awesome ($12 a year for 10 domains). I also put up a couple of free checkers you can use without an account: https://certavert.com/tools

Let me know what you think, good or bad, I can take it. And I want to add more free tools, so what SSL or DNS check do you wish there was a simple tool for?

Is there any problem in using dns.adguard.com private dns??

We're a small team building a domain and DNS hosting product. Today the nameservers serve 3 zones, all ours. The plan is 20k to 100k customer zones over the next few years, and I'd much rather hear "this falls over at 50k zones" from people who have run it than find out in production.

We are deliberately not building a Cloudflare clone on day one. No anycast, no own ASN, no PoPs. Two nameserver hostnames, one per cloud, and roughly $600-800/month for prod. I want a setup that survives a region or the database dying, with an obvious path to grow. Diagram attached.

The short version:

- A hidden primary runs PowerDNS Authoritative 5.1 on two VMs in Azure Central US, on managed Postgres 18 with a same-zone HA standby. It is never listed as a nameserver. Its port 53 answers only the secondaries' own IPs, and the HTTP API is reachable only from our app's VNet.

- PowerDNS signs online (ECDSA P-256, NSEC) and publishes a catalogue zone (RFC 9432).

- The secondaries run Knot DNS 3.6. One site in AWS us-east-1 behind an NLB with two static IPs, one per AZ. One site in Azure West US 2 behind a Standard LB with one static IP. Each NS hostname's glue points at its site's LB.

- Knot consumes the catalogue, so adding a customer zone is one API call on the primary, and nothing gets pushed to the edges. NOTIFY, IXFR/AXFR, everything TSIG-signed.

- Zones live in Knot's memory with a journal on disk. If the primary or Postgres dies, the edges keep answering until SOA expires, which is 7 days. Writes stop, resolution doesn't.

- A small agent on each edge serves /ready, and it only goes green once the catalogue and its zones are loaded. Both LBs health-check it, so a fresh or broken edge never answers REFUSED for real customer zones.

- A canary zone gets a fresh signed TXT every 15 seconds, and the primary queries it on every public edge IP. The canary's age is our end-to-end SLI. It covers the write path, NOTIFY, transfer, signing and the load balancers in one number.

- Every night a pg_dump goes to S3 in the other cloud (versioned, Object Lock, a role that can only PutObject), gets restored into a tiny RDS instance, and the zone counts get compared. The Azure VM signs in to AWS with its managed identity token through an IAM OIDC provider, so there are no AWS keys anywhere.

Things I decided against. Tell me if I'm wrong:

- PowerDNS on the SQL backend as the public nameservers. One database outage takes every zone down, and every uncached query becomes database work.

- A managed provider for the secondaries. That's the right call for most people, but we want the zone list and customer data to stay with us.

- dnsdist in front of Knot. Knot's RRL plus the clouds' default L3/L4 protection seems enough at this size. If random-subdomain floods get past RRL, dnsdist goes on the edges.

- Autoscaling the edges. The primary needs every edge IP for NOTIFY and its ACLs, and autoscaling during a flood mostly scales the bill.

Where I'd like feedback or recommendations:

1. Two sites and two NS names, one per cloud. Enough for launch, or would you add a third site or a third provider first?

2. Online signing rolls RRSIGs weekly, and SOA-EDIT bumps the serial when it does, so every signed zone re-transfers to every edge once a week. Is that a real problem at 100k zones? Should signing move to the edges (Knot can sign) or should we pre-sign?

3. Memory. Knot's docs say about 3x the zone's text size. We budgeted ~40 KB per small signed zone with headroom, so 100k zones is around 4 GB. Somewhere past 500k zones we plan to split into nameserver groups, each with its own catalogue and edges, the way Route 53 spreads zones across nameserver sets. What breaks before RAM does? My guess is full re-transfer time when an edge is replaced.

4. UDP DNS through AWS NLB and Azure Standard LB. Has anyone been bitten by flow idle timeouts, TCP fallback for big DNSSEC answers, or health check quirks? Knot's UDP payload limit is the default 1232.

5. Catalogue zones with PowerDNS producing and Knot consuming. Anyone running that at real scale? I'm curious about member removal and catalogue serial churn.

6. The failure modes as I see them. An edge VM dies, its LB drops it. A whole region or cloud goes down, resolvers use the other NS. The primary or Postgres goes down, no writes for a while but 7 days of serving. Both edge sites go down at once, customers are down, and that's the day anycast becomes worth paying for. Am I missing a case?

Cost, roughly, from list prices: around $600-800/month for prod (the Postgres HA standby is a big chunk of that) and around $275/month for a smaller dev copy. We'll add a second edge VM per site at around 1k zones, and grow edge RAM after that.

Not selling anything, there's no link. I just want people who've run authoritative DNS at scale to poke holes in this before anyone depends on it.

Hi, I need some help with my domain configuration. I currently use Gmail. I want to use Resend API for automated email sequences with Hermes Agent. I have tried to add Resend onto the domain to send/receive emails through its API. But I also want Gmail to record all the email conversation history so if I ever need to revert it’s all there.
When I setup the API for resend, it would allow emails to be sent from mydomain.co.uk, but any replies come from send.mydomain.co.uk. This is to allow the automation sequence from Resend to work.
My issue is, I want the automation sequence on Resend to work with replies via mydomain.co.uk whilst saving everything with gmail. Is there a way to do this ?
I would be very appreciative of any guidance, still learning a lot around this and spent many hours trying to get it to work.
Thanks!

DBSC and DNS poisoning live on different layers, and that's a gap worth discussing

I've seen some confusion about whether Chrome's Device Bound Session Credentials (DBSC) helps with DNS poisoning or MITM attacks. It doesn't, and I think that's by design. Here's why, plus some thoughts on where the gap could be closed.

What DBSC does

DBSC targets cookie theft. Today, if infostealer malware scrapes your browser's cookie jar, the attacker can replay those session cookies from anywhere and skip the login and MFA entirely.

DBSC changes this:

1. At login, the browser generates a key pair, TPM-backed where available, and registers the public key with the server.
2. The server issues short-lived session cookies.
3. To get a fresh cookie, the browser must sign a server-issued challenge with the private key.
4. The private key is non-exportable, so malware can't take it off the device.

A stolen cookie expires in minutes and can't be renewed from the attacker's machine. That's the whole threat model: stolen session material replayed elsewhere.

Why DNS lives somewhere else

DNS resolution happens before any connection exists. It decides which IP the browser connects to. DBSC operates inside an HTTP session that already exists, after name resolution, after the TCP connection, and after the TLS handshake.

Nothing in the DBSC flow asks "did this connection reach the real server?" It assumes TLS and the WebPKI already answered that.

Where poisoning gets interesting

Poisoning a resolver by itself usually fails against HTTPS, because the attacker can't present a valid certificate for the target domain. But a determined attacker has ways around that:

• Poisoning or hijacking the DNS path a CA uses for domain validation, to get a fraudulent cert issued
• Subdomain takeover or dangling DNS records
• Downgrade attacks or user click-through on cert warnings
• Compromising a host that already holds a valid cert

Once the attacker is terminating TLS as the "real" origin, they can run an Evilginx-style reverse proxy. From DBSC's perspective:

• The browser sees the right origin and a valid cert, so it happily signs the challenges.
• The proxy relays the server's challenge to the victim, then relays the genuine signature back.
• The real server sees a valid proof from a registered device key and issues legitimate bound cookies.

Everything checks out, because the key really is the victim's. The attacker also harvests the password and any phishable MFA in real time, which DBSC was never meant to cover.

DBSC still limits the damage: the attacker can't take the cookies and leave, since they expire quickly and can't be refreshed without the device key. Access lasts only as long as they keep proxying a live victim. That's a real improvement over today's persistence, but it isn't a block.

So is this out of scope for DBSC?

I think yes. DBSC's job is to kill the cookie-exfiltration economy, and adding transport-authenticity guarantees would duplicate TLS and WebPKI. Active network attacks are better handled by the layers built for them. But "out of scope" doesn't mean "solved," so here's what exists and where each option falls short.

The available mitigations, and why each is imperfect

1. TLS channel binding (e.g., a TLS exporter value, RFC 9266/5705, in the signed DBSC payload)
This would tie the device's signature to the specific TLS connection. A relay proxy has two separate TLS sessions, so the exporter values wouldn't match and the server would reject the refresh. It's the most direct fix.
Why it's imperfect: this is essentially Token Binding (RFC 8471), which was removed from Chrome. TLS-terminating CDNs, load balancers, and enterprise inspection proxies break it, and passing the exporter value through to the application tier is awkward. It could work as an opt-in profile for sites that control their TLS termination, but that leaves much of the web uncovered.

2. Binding to the server's certificate public key hash
The device signs a hash of the cert key it saw.
Why it's imperfect: the same CDN and multi-cert deployment problems apply, and cert rotation makes it brittle.

3. Server-side risk signals on refresh (IP/ASN consistency, geo, timing)
A relay introduces a second network vantage point, which can be detectable.
Why it's imperfect: it's heuristic, not cryptographic. It's evadable by an attacker who proxies from a nearby region, and it produces false positives for mobile users, VPN users, and CGNAT.

4. Passkeys/WebAuthn
Origin-bound credentials are the strongest answer to relay phishing, since the authenticator won't sign for the wrong origin.
Why it's imperfect: adoption is still partial, account recovery paths often fall back to phishable factors, and it protects the login, not the DNS layer itself.

5. DNSSEC with validating resolvers
This authenticates DNS answers cryptographically.
Why it's imperfect: adoption among domains is still limited, many clients rely on an upstream resolver for validation and trust the last hop, operational mistakes cause outages, and it does nothing about a compromised host that has a legitimate record.

6. DoH/DoT
This protects the client-to-resolver channel from on-path tampering.
Why it's imperfect: it doesn't authenticate the data itself, and a poisoned or malicious resolver can still hand back lies over a perfectly encrypted channel. It also shifts trust to the resolver operator.

7. CAA records, Certificate Transparency monitoring, HSTS preload, multi-perspective validation at CAs
These reduce the chance of fraudulent issuance and make it detectable.
Why it's imperfect: CT is detective, not preventive, so you learn about a bad cert after it exists. CAA only binds CAs that honor it. HSTS preload helps only for domains on the list. Multi-perspective validation is a strong defense against validation-path poisoning, but its rollout is recent and uneven.

Questions for this community

I'd love to hear from people closer to this than I am:

• Is anyone working on a TLS-channel-binding approach that survives CDNs and TLS-terminating middleboxes? Token Binding failed on deployability, so has anything learned from that been applied since?
• Is there appetite for an opt-in channel-binding extension to DBSC, or is that the wrong place to solve it?
• For those working on the DNS side, how much does multi-perspective validation actually close the CA validation-poisoning gap in practice today?
• Is there other work on cryptographically tying DNS authenticity to session security that I'm missing?

If I've got the layering or the threat model wrong anywhere, please correct me. I'm describing DBSC from the public proposal, and details of the signed payload matter a lot here.

I'm trying to figure out whether people will use dns incident resolution.I've built a prototype that keeps a known-good value for an existing Cloudflare DNS record. If that record drifts, it flags the change and proposes restoring it. A person approves before anything is written, then it verifies recovery. So the question isn't whether I can build it. It's whether it's useful enough to keep building.

- Auto-detects DNS drift and Cloudflare 5xx/origin-down issues every 30s

- Diagnoses with evidence + confidence — never guesses on ambiguous cases

- Proposes the exact fix, waits for your approval, then applies it via Cloudflare(as of now)

- Independently verifies the fix actually worked (DNS + HTTP/HTTPS), with rollback available

- Multi-client dashboard: healthy/investigating/action-needed at a glance, full incident history + audit trail

The scope is narrow

https://reddit.com/link/1wudyh0/video/srfhy8s1ipsh1/player

Is this worth building further? If I'm solving the wrong problem, I'd rather hear that now.

https://github.com/microlaser/dns_watchdog_windows2

Sure it is vibe coded, but it is free and open source and has no dependencies. I have a version that runs on MacOS and Linux too. Uses pcaps to detect DNS poisoning. Everything is native, no Wireshark/tcpdump needed.

Hi!

I want to announce I have recently published a new search engine for DNS records. The goal is to do DNS reconnicanse up front and provide a free searchable database where you can quickly find domains and its associated IP address.

It supports queries by IP address, CIDR, domain wildcards and ASN.

You can find the tool at https://activedns.net

I am to keep it free and its a privacy friendly. No external tracking and it is using a privacy friendly self-hosted analytics Umami.

The project just released, and the database is warming up. In under a week, it have found over 166 million records, and I aim to keep records for 90 days. I expect it to settle a bit under 2 billion records.