But when setting up a full recursive resolver, you should avoid using root servers directly for queries, but rather mirror the root zone locally:

https://datatracker.ietf.org/doc/html/rfc8806

I've checked the site, it looks very nice on mobile.

However, some checks have bugs or they makes no sense:

1. SPF missing ?all is broken, it report missing when it is there

2. Checking SOA records makes no sense in 2025. Their serial formats is irrelevant in modern DNS services that don't even use AXFR/IXFR

3. Checking for SOA TTL or minimal is also useless, unless the TTL is higher than 7 days. Really, it is up to the DNS admin to set very low TTL

4. Checking if different record types have different TTL makes zero sense, again it is up to the domain owner

5. DMARC/DKIM well, debatable. It has nothing to do with DNS per see and a lot of SMTP admins find them useless. A proper SPF with "-all" is enough to prevent using your domain for mail spoofing. DKIM and DMARC is usually a waste of time, and spammers always get it right anyway. I would go as far as to say that if you operate SMTP server, don't bother to check or add DKIM and definitely ignore DMARC.

> But up to this point, that's what the author has been doing. They've setup bind to run on IPv4 and IPv6 but not really the latter, instead blackholing all such requests.

Well, Linux kernel is dual-stacked for more than 30 years now. Every linux VM is dual-stacked unless you deliberatelly disable IPv6 with a kernel boot parameter. And while Linux, and every other modern OS today, is dual-stack, it does not mean that the network you boot Linux with, is dual-stacked. The main criticism is that the algorithm fails to notice that entirely. It is not the "lame-delegation", it is bind9 not being aware of the fact that certain network family is not available, due to outage or just as a starting point.

So while my advice stands, that you should not run any recursive resolver on IPv4 or IPv6 only - sometimes, you have no choice but to do so, as this is the network you are working on. In such cases, this article may help engineers to correctly run bind with either -4 or -6, or abandon it altogether.

This article summarize my findings on what I believe to be a buggy recursive algorithm. Main actors: BIND-9.18, BIND-9.20 and wireshark.

The best document to properly run a private root zone dns server is this: https://datatracker.ietf.org/doc/html/rfc8806

Just read it quickly and you're good to go.

This article looks like being generated with the LLM model.

Focus on Linux, Linux networking (NAT), containers and kubernetes and basic git understanding.

DNS, well, don't invest to much in it. If anything, DNS is just a networking helper, allowing most protocols to connect "to a string", as opposed to a network address (ip, ipv6).

What do you consider linx networking. I am having a hard time finding relevant resources to learn it. (Pls don't share beej's guide lol)

Very surprised to see that bind9 did the best job picking the fastest NS and to abandon query within 10 seconds.

Very disappointing unbound results, as all servers falls into 400ms round trip time, so it just pick NS randomly.

As for public resolvers, they run a farm of resolvers so it is hard to assume we end up at the same resolver process every time. Nonetheless, the results are just like a random pick.

Is there a way to submit a tool without registering? I would like to add offline browser jpeg resizer and minimizer

https://squoosh.app/