I can't stress enough this part in our code of conduct:
Do not report every post that upsets you.
Please report posts that violate our rules but for others that you may find distasteful, or just don’t like, use the tools available to you. You can block the user or mute the conversation or even filter out posts regarding to the subject you find off-putting.
Bubble Gum [ 03 September 2024 ]
#digitalart #pixelart #8bit #portrait #painting #digitalpainting #fediart #MastoArt #Krita
Little brother Sterling is on eager young intern mode again.
#Cats
#CatsOfMastodon
#CatsOfFediverse
#FediCats
#MastoCats
Watching my Unbound DNS cache statistics and sadly there’s plenty of Fediverse servers with TTL of A/AAAA records set to very low values. Why would anyone set TTL to 18, 30 or 300 seconds?
I get it, when you prepare for a migration, that’s something you want to do to speed up the transition. There’s some sophisticated load-balancing schemes where this may come handy, but most of those I see are simple unicast hosts. Resolvers worldwide are just pointlessly pounding the whole DNS tree to get the same IP over and over again…
RFC 1033, 1987:
Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value.
Okay, this is about default TTL in SOA and 86400 may be quite long for disaster recovery, but how about at least an hour (3600)?
None
Just in case: DMs/PMs simply don't exist on this instance as concept — don't use them, use the other instance if you absolutely have to, or send an email to any address at m0xEE.Net or .Com or .Org, but I prefer keep most communication public.