pathetic piss kitten (@kitten)

pathetic piss kitten @kitten@elizabeth.cat

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

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