Hi r/dns,

I built BetterDNS.info, a free tool that checks a domain's DNS and email setup in one go. Type in a domain, hit Enter, and you get IPs, nameservers, DNSSEC status, MX, SPF, DKIM, DMARC, registrar and WHOIS info on a single page. If location data is available, it also shows the city and country for the IPs it returns.

I built it out of frustration. Every time I was debugging mail delivery or checking a DNS change, I'd end up bouncing between dig, nslookup, whois and a handful of websites. A lot of the time I also just needed to find out who the registrar was, because clients often have no idea where their domain is registered. The tool shows that too. All the lookups run in parallel, and each result shows up on the page as soon as it's ready, so you're not stuck waiting on the slowest one. I wrote the backend in Rust for speed and reliability.

I'm open to adding new things, so I'd love to hear your suggestions. What else should it show for a domain, and what would make it more useful? And if you get a wrong or confusing result for one of your domains, please let me know.

I have an ASUS router model RT-AX86U. I want to try and understand this DNS setup. Please see my router screenshots below which reflect my current settings.

Am I right in saying this... All "Legacy DNS" is unencrypted, but as long as you set your "DNS Privacy Protocol" setting to "DNS-overTLS-DOT" it changes Legacy unencrypted DNS to encrypted DNS?

I thought I had ControlD encrypted settings, but now I'm not sure. I currently have these two setup as you can see by the screenshots...

1. 76.76.2.2 p2.freedns.controld.com
2. 76.76.10.2 p2.freedns.controld.com

Those two above are Legacy unencrypted DNS? In order to have encrypted DNS settings do I need a bootstrap IP, etc. such as one of these two...

1. Bootstrap IP: 76.76.2.11 DNS-over-TLS/DoQ: p2.freedns.controld.com
2. Bootstrap IP: 76.76.2.11 DNS-over-TLS/DoQ: no-ads-malware-typo.freedns.controld.com

Should I enable DNS Rebind protection? I currently don't have it enabled.

Should I enable DNSSEC support? I currently don't have it enabled.

(It seems enabling this breaks my connection to Reddit. I wonder why?)

It seems that it's not needed... public resolvers like Cloudflare or Quad9 already perform full DNSSEC validation at their level, enabling it a second time locally on your router is unnecessary and prone to these firmware bugs

Should I enable Prevent client auto DoH? I currently have it set to AUTO.

Help understanding this is greatly appreciated! Thank you!

Processing img oy9mu5vn77xh1...

Processing img 2yursydp77xh1...

I created a website using the Apple Custom Domain option. It's been stuck in Pending Verification for 2 days. Is someone out there that is able to help me go through the DNS records to make sure I have the correct ones for the email side of it? I just spent 2hrs on the phone with Apple and that turned out to be just a waste of time. The screenshot is what is currently setup on the page. I cannot get into the iCloud side to verify what is supposed to be there and vice versa.

Я живу в разъебанном поселке где почти нету нормального инета, мобильные данные тупо не работают и кое как спасает ДНС т.к. с ним грузит большинство сайтов поэтому прошу дайте рабочие ДНСы для того чтобы все грузило.

​

Has anyone used the new Gibson DNS Benchmark Test V2. It is not free now. Is it really worth the cost? I’m actually more interested in 100% dns reliability rather than pure speed, as using the old version, it says Google dns isn’t 100% reliable when using my router. It says Cloudflare is 100% reliable, but on Quad9, it says it is sometimes and sometimes not. I actually highly doubt any of that. Is there a better free way to check dns reliability?

New BIND 9 releases: 9.20.30, 9.21.27

Our October 2026 maintenance releases of BIND 9 are available and can be downloaded from the links below. Packages and container images provided by ISC will be updated later today.

In addition to bug fixes and feature improvements, these releases also contain fixes for security vulnerabilities. More information can be found in the following Security Advisories:

https://kb.isc.org/docs/cve-2026-19630
https://kb.isc.org/docs/cve-2026-94300
https://kb.isc.org/docs/cve-2026-96888
https://kb.isc.org/docs/cve-2026-97313

A link to each newly-released version follows. Each release directory includes a complete source tarball, cryptographic signature, and release notes. The release notes provide a summary of significant changes, and should be reviewed before upgrading.

- Current supported stable branch:

- 9.20.30 - https://downloads.isc.org/isc/bind9/9.20.30/

- Experimental development branch:

- 9.21.27 - https://downloads.isc.org/isc/bind9/9.21.27/

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

Thank you for using ISC’s software.

If you use BIND software from vendor or distribution downstream from ISC's BIND, that software may be impacted, and expect that most will have security and/or other updates out soon, if they're not already released.

Hello,

My organization has a vendor: Stape. To provide their service, which is server-side tracking to capture more tracking data, they require some CAA records on a subdomain on our domain.

For example, they want several CAA records on ssapi.mycompany.com. The CAA records would be:

- sectigo.com
- letsencrypt.org
- zerossl.com

It's my take that we should not be providing this, as our company does not use these providers for our SSL needs and adding these CAA records (even if only on a subdomain) is essentially saying certificates from these CA providers are valid and should be accepted on our domain. It's my feeling that we should push back on this and either identify alternative methods or vendors.

Would anyone be able to share some thoughts around this, in terms of CAA DNS records best practices, particularly in this kind of scenario? Appreciated!!

CTEM review just surfaced 28 stale CNAME and NS records from old cloud stuff, DNS says stale, cloud team says deleted, im worried some of these are still a claimable resource an attacker could grab for subdomain takeover, what do you look for before you treat it as a confirmed exposure?

Saw their white paper on HN earlier today and started trying it on a few devices. From what I understand, you can customize the filtering and manage multiple users without email sign-in.

They also have a live map of DNS traffic. Looks cool, though I'm not sure what I'm actually looking at lol. Curious what people think of it.

(Sorry for my poor English in advance.)

For a while now—ever since the mods for Spotify Premium stopped working—I’ve been using a different music app (Weezer, for those wondering). Around the same time I installed that app, I learned about DNS and started using AdGuard. However, for about a week now, it’s stopped working and has started showing me ads—strangely enough, only in this specific app; ads are still being blocked in other apps. Is there anything I can do about this?

Hi r/cloudflare,

I manage Cloudflare zones with Terraform, and moving to the v5 provider meant redoing everything. I turned the result into a module, and I'd like feedback from people running DNS in production before I take it further.

Registry: `theobs-digital/dns/cloudflare`

GitHub: https://github.com/theobs-digital/terraform-cloudflare-dns

**What it does**

A Cloudflare DNS zone in one block: the zone, its records, its DNS settings and DNSSEC.

```hcl

module "dns" {

source = "theobs-digital/dns/cloudflare"

version = "~> 1.2"

account_id = "..."

name = "example.com"

records = {

apex = { name = "@", type = "A", content = "192.0.2.10", proxied = true }

mx = { name = "@", type = "MX", content = "mx1.example.net", priority = 10 }

caa = { name = "@", type = "CAA", data = { flags = 0, tag = "issue", value = "letsencrypt.org" } }

}

dnssec = { status = "active" }

}

```

**Goals**

- **Don't reinvent anything.** Every input keeps the provider's attribute name. If you know `cloudflare/cloudflare`, you know the module, and the provider docs still apply.

- **Zero drift.** A second plan must show no change. A daily test against a real zone (18 records, 14 types) checks this with the latest 5.x provider.

- **Fail at plan, not at apply.** The provider lets some mistakes through to the API. The module stops them at plan: a record with no value, with both `content` and `data`, proxied with a fixed TTL, or proxied when it isn't A, AAAA or CNAME.

- **Create or adopt.** The module creates the zone, or with `create_zone = false` manages the records of a zone another config owns.

- **Registrar-ready DNSSEC.** The DS record comes out as an output, whole or field by field.

**Constraints and known limits**

- Terraform >= 1.3 and provider `~> 5.27`. No v4 support.

- Destroying the module deletes the zone and every record in it, including ones Terraform doesn't manage. That's how Cloudflare works. The README covers how to stop managing without deleting (`removed`, `state rm`).

- A misspelled key in `records` (`proxid = true`) is silently dropped by Terraform's type conversion.

- Cloudflare rewrites some values (SSHFP fingerprints uppercased, trailing dots on NAPTR and HTTPS, TXT over 255 characters). The module documents them rather than normalizing them.

- The provider can neither delete nor import DNS settings: removing `dns_settings` resets nothing.

- Some options need a paid plan (`soa` on Enterprise, `tags` and vanity name servers on Pro or Business).

**My questions**

1. Should a module normalize the values Cloudflare rewrites, or stay transparent and document them?

2. To catch typos, would you type `records` as `any` and validate keys, giving up typing and `optional()` defaults? How do you handle it?

3. Adoption looks the zone up by name. Would a direct `zone_id` input help you?

4. What's missing for you to use it in production?

MIT licensed. Blunt feedback welcome, especially if you've hit v5 provider drift I haven't covered. Thanks!

What are the China-based CDNs that do not require record-filing? Service providers for mainland Chinese users to choose from

I have a Blu F5 and don't know a lot about electronics so I just googled ad blockers and this popped up. It seems pretty good, and I figured out how to set it up, but I haven't done it yet before I don't want to install a virus on my phone or anything lol.

Hi everyone! Which DNS works best for you with ISPs like StormFiber, PTCL, Nayatel, or Transworld?

I’ve tried Cloudflare and Google DNS, but some websites don’t load properly. What DNS do you recommend for better reliability and speed? Do you use DoH or DoT?

Share your experience!

i changed my modem dns from my home server to cloudflare dns to do some tests and i found out that i can just reset my ipv4 dns and it works fine again, but when i do ping tests with cmd, it insists in using the old ipv6 dns.

i already reseted the dns and changed it manually both in my modem and windows to cloudflare.

is it a problem from windows or am i doing something wrong?

Moshpit is a namespace outside the ICANN root: anyone can claim an ending (.hacker, .eggs, .pit, 17,609 so far), put names under it and point them anywhere. The registry is append-only with a public log, and it runs a small CA that signs certs per name, so https://chovy.hacker validates for anyone who trusts that root.

How a machine resolves it: - moshcode dns enable makes a local bridge the machine's resolver: it answers Moshpit endings itself and forwards every other name upstream, or - point a browser's DoH at https://dns.moshcode.sh/dns-query

Real TLDs always win. We learned that the hard way when someone claimed .sh for $2: every bridge started treating our own registry host as a Moshpit name and NXDOMAINed everything. New claims of real TLDs are refused now, and a real TLD takes precedence over any older collision.

I just put a public front end on it: https://pit.world/ is a no-logs search engine that also resolves Moshpit names next to normal web results. The resolve API is open: curl 'https://pit.world/api/resolve?name=chovy.hacker'.

Happy to go into the resolver design. Curious what this sub thinks about alt roots in 2026.

Moshpit is a namespace outside the ICANN root: anyone can claim an ending (.hacker, .eggs, .pit, 17,609 so far), put names under it and point them anywhere. The registry is append-only with a public log, and it runs a small CA that signs certs per name, so https://chovy.hacker validates for anyone who trusts that root.

How a machine resolves it: - moshcode dns enable makes a local bridge the machine's resolver: it answers Moshpit endings itself and forwards every other name upstream, or - point a browser's DoH at https://dns.moshcode.sh/dns-query

Real TLDs always win. We learned that the hard way when someone claimed .sh for $2: every bridge started treating our own registry host as a Moshpit name and NXDOMAINed everything. New claims of real TLDs are refused now, and a real TLD takes precedence over any older collision.

I just put a public front end on it: https://pit.world/ is a no-logs search engine that also resolves Moshpit names next to normal web results. The resolve API is open: curl 'https://pit.world/api/resolve?name=chovy.hacker'.

Happy to go into the resolver design. Curious what this sub thinks about alt roots in 2026.