pathetic piss kitten (@kitten)

pathetic piss kitten @kitten@elizabeth.cat

DNS server updates: I'm doubting between going with bind9 or CoreDNS

Kang @KiloKang@owo.cafe

@kitten Which use case?

pathetic piss kitten @kitten@elizabeth.cat

@KiloKang self-hosted authoritative nameservers

pathetic piss kitten @kitten@elizabeth.cat

@KiloKang PowerDNS also entered the battle

Kang @KiloKang@owo.cafe

@kitten We, at owo.cafe, are using PowerDNS in a stateless way pairing with externaldns

It gets all records from Kubernetes, directly from ingresses and load balancers.

The project is public: github.com/txqueuelen/stateless-dns

Pod writes everything to an emptydir and populates everything on each restart.

You can set up static records from the config: github.com/txqueuelen/stateless-dns/blob/ae0d8126d1f7f34a4a39147091a5119cd8238d28/charts/stateless-dns/values.yaml#L188-L200

It is (almost) mandatory to statically set up ns1, ns2, mx,...

But all A/AAAA records can be set directly from ingress statuses and LoadBalancer annotations.

Auto upgrade of images is not working (yet) and a good documentation is more than needed. But it should work out of the box.

I can paste you my config without any issue.

4 "back to setting fires" censord

@4censord@unfug.social

@kitten bind9 is quit good, its what my servers run

kloenk @kloenk@catcatnya.com

@kitten have some CPU core pinning bad experience with CoreDNS. Quite like knot

pathetic piss kitten @kitten@elizabeth.cat

@kloenk :neocat_think: what issues specifically?

kloenk @kloenk@catcatnya.com

@kitten it was some years ago, so might have been fixed. used it localy (not sure of the exact config anymore), and from time to time I had to restart as I noticed that it has 100% utilization on one CPU core. restart fixed it for multiplay days usually but rarely also only until the next day or something

dmiException 🎃 --> eth0 @domi@donotsta.re

@kitten why not PowerDNS?

pathetic piss kitten @kitten@elizabeth.cat

@domi I guess I didn't really se an advantage over bind9, which I have already used :neocat_think:

pathetic piss kitten @kitten@elizabeth.cat

@domi HTTP API is a big appeal, since it gives a lot of flexibility in case it's needed, but... tbh I don't really need it right now if I have RFC2136

dmiException 🎃 --> eth0 @domi@donotsta.re

@kitten you can’t do everything over RFC2136. regardless, powerdns excels at replication, and overall tool quality (both things we found quite lacking within bind when we first evaluated it)

4 "back to setting fires" censord

@4censord@unfug.social

@kitten @domi for me the disadvantages of powerdns boils down to "ah great now I also need to run a ha db cluster as well"

dmiException 🎃 --> eth0 @domi@donotsta.re

@4censord @kitten what? it works just fine on sqlite, for 450+ zones

some of our instances use postgres but at least a few are just plain old sqlite. KISS!

dmiException 🎃 --> eth0 @domi@donotsta.re

@4censord @kitten the high availability on DNS isn’t supposed to be done on the DB backend, rather on thee server side. if one of your servers fails, the resolver should fall back to the next one

(you can do both, but you still keep a SPoF of the pdns process, and your DB is likely running on the same box. why bother?)

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten then I might misremember docs, I though sqlite was not recommended for production use. though admittedly I last looked at it 5 ish years ago
(And never since because that was a huge downside)

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten also yes about the ha part on the having more of them side, but I needs authorative ones, then then I need a primary that everyone replicates/axfrs from
And to have the api be ha, I need the db to be ha

dmiException 🎃 --> eth0 @domi@donotsta.re

@4censord @kitten you don’t need the API to be HA

dmiException 🎃 --> eth0 @domi@donotsta.re

@4censord @kitten overcomplicating your life 100x for 5 minutes more of uptime of the control plane, not even the service itself: a comprehensive guide

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten I didnt make the contracts that where sold then
I just was a tech having to deal with it in the end

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten so what i'm getting from this is that i need to look into pdns again

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten that was an internal requirement, as we where providing slas with uptime guarantees that included the ability to change stuff

I mean, it worked quite well and pdns did that good. Just, yeah effort at least for homelab style use

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten let me look up what the exact setup was.

4 "back to setting fires" censord

@4censord@unfug.social

@domi @kitten so basically we had a MySQL replication hierarchy. On the top was two pdns servers doing api (load balanced and all that, how one would expect of a http service). These where not doing dns at all, just writing to the db.
On the downstream of that was $n pdns servers doing authorative dns, using the replication of the mysql (pdns in "native" replication mode). (This is the dns type "just have more servers ha)
This worked very well and was quite resilient actually