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