3 ms·
I said resolvers, not servers. What client side dns libraries did source port randomization in 2006?
by justinsaccount 10y ago
I said resolvers, not servers. What client side dns libraries did source port randomization in 2006?
- JdeBP 10y agoResolvers are exactly what I told you about. You clearly don't know the jargon. The RFC terminology for in-application DNS client libraries is stub resolvers. RFC 1034 section 5.3.1. A resolver in contrast is the complete subsystem, sometimes implemented as a stub resolver together with a separate program that it makes remote procedure calls to, that does query resolution. RFC 1034 section 2.4. Yes, it's arcane terminology. It's not mine. I've been telling people to think of DNS like HTTP since the turn of the century. But if you use it, use it correctly. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-server-roles.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...
- justinsaccount 10y agoGreat... can you answer my question? What client side dns libraries did source port randomization in 2006? AFAIK it wasn't until 2008 when most things were fixed. People keep talking about the good old days before systemd where everything worked perfectly, but that ignores the fact that things were pretty broken. If you care about things like local caching and failover, things are still pretty broken. Most unix systems are horribly fragile out of the box. You either run something like dnsmasq or unbound locally or use a hack like https://github.com/kvz/nsfailover https://github.com/kvz/nsfailover. A large number of distributed systems completely grind to a halt when the primary name server fails (if only everyone used anycast...)