plagiat0r

Unfortunately bind is as buggy as it always been. I've tried to black hole entire ::/0 but it still eat its query counter without even sending out a single packet.

You need dual stack network and routing to both, or run it with -4 argument for IPv4 only network

And they closing any bug reports is typical "works for me". It's been like this for a long time.

Your should rather say - it's always bind (bugs). I wrote about bind eating their query counter on IPv6 even if you don't have IPv6 routing:

https://szafka.net/blog/bind9-as-resolver.html

Run bind with -4 arg or switch to unbound. Bind quality is the same it always has been. Nothing changed after those 25+ years.

Unpopular opinion: Maybe the way to go is to create a separate Show HNs only for bots and put some instructions for the bots to follow, identify themselves and give them separate category. Similar to moltbook. If we can't stop it, maybe we could contain it in a dedicated space.

I'm not a fan of moltbots / openclaws (and any clones that popped up in the last moth). I don't use them and try to discourage their use. That being said, millions of them are running anyway...

Back in the 90/2000 the was a very popular tool named rrdtool to store metrics in a round robin structure on disk, especially suited for network metrics. The goal of the storage was to have a fixed size and cover only last NNN days, circularly.

I use rrdtool to this day, as a building block, but this project looks much better.

And the link to vscode is now 404.

It's gone.

All I'm saying is that publishing final certificate is not required for the process, so just assuming it will be there is premature. User may end up putting precert on his https server and find the hard way.

Happy to see LE publish both, but others do not. Here is an example: https://crt.sh/?id=17293798014

Your won't find final certificate from digicert/globalsign in the CT logs.

Unless the owner publish it himself, API is opened for submission I think for everybody.

Most acmev2 clients create account on certificate request.

That is precisely why I wrote this: https://github.com/pawlakus/acmecli

This small tool will allow you to just create, rekey and deactivate your acmev2 account(s).

Thank you, this draft is literally perfect and I wish we had this years ago. Most people don't know about acmev2 account rekeying either. It is great you decided to use account uri instead of public key thumbprint.

Recently I wrote a simple acmev2 tool specifically for manual upfront acmev2 account creation, rekeying and getting TXT records on stout for dns-persist-01:

https://github.com/pawlakus/acmecli

It also helps with stateless http01 printing thumbprint...

X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key.

The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.

OP idea won't work unless OP will submit final certificate himself to CT logs.

X509 certificates published in CT logs are "pre-certificates". They contains a poison extension so you don't be able to use them with your private key.

The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.

Thanks for the service. Personally I would lower the TTL to 120 or less.

Dyndns is used for personal stuff. There is no point caching a FQDN almost nobody use. If anything, low TTL is a benefit for recursive resolvers like 1.1.1.1 or ISPs. Those FQDN should not be cached as there is zero benefit keeping them in their cached for one guy hitting it once per day.

Duplicate, it is submitted third time.

Duplicate of: https://news.ycombinator.com/item?id=45973177

Given the bind security and functional track record over the last 30 years, I would pick knot/nsd/yadifa/powerDNS/coredns/tinydns in a heartbeat for authoritative dns server.

Windows 10, 11 and most major OSes have ipv6 enabled and it is preferred. There is also a Happy eyeball algorithm browsers use to connect - RFC 8305.

However, the most important thing you need to understand are fundamentals. Today we have two independent internets. One is IPv4, other is IPv6. Your server/virtual machine must be connected to both internets at the same time - we call it dual stack. Those networks are independent of each other, so make sure you're connected to both, or face the consequences of not being connected to one of them. There is not one Internet, there are two Internets nowadays.

The thing is, they do not support wildcard TLS, no way to pass acme dns-01 challenge.

Sounds like divorce, you need a lawyer.

Spin up a vps in a different country, and VPN your entire traffic over this vps. Wireguard or OpenVPN.

Authoritative or resolver?

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 problem I have with the article is that gravity is not a force. Magnetic is a force, but gravity is not a force.

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).

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.