There are many more dark secrets of DNS packets. Especially, in the context of internet providers and censorship industry - DNS Filtering, DNS Spoofing/Poisoning, Blocking Public DNS, etc
Instead of running local resolvers for caching, they should have used nscd DNS cache to decrease the volume of queries from those machines running the logs tasks. nscd is not designed for that, but is long known to have this best-use practice:
https://prefetch.net/blog/2011/03/27/configuring-nscd-to-cac...
Yes. Also, nscd is irrelevant in at least a few ecosystems. Java and (I think) Go try to do their own resolving instead of using libc. Java's resolver, in particular, is braindead in the default configuration: infinite record caching, ignoring TTLs.
systemd-resolved solves this, as does running unbound or similar as a local cache.
Yeah but then they not going to have a fancy blog about how they hit the AWS traffic limit to VPC resolver! Now days a tech blog like this is gonna be good tech PR for the company.
That's... quite the interpretation. Do you really think that Stripe's intention is to "encourage people with low skills to apply" by writing a blog post about monitoring DNS?
As an experienced developer, I would like to know: In the context of optimizing DNS resolution for latency-sensitive applications, what specific strategies or configurations does Stripe recommend implementing based on the insights from the blog post, and how do these strategies compare to traditional DNS setups in terms of performance and reliability?
> We realized we may be hitting the AWS limit for how much traffic can be sent to a VPC resolver
Never rely on an AWS service until you've understood it's quotas. They are reliable services, but to maintain that standard, they have to impose limits at many different levels of the plane. There are some good "quota surprises" tucked away in there.
