334 karma · joined March 6, 2013
(One is on their keychain with an AirTag, one is stored securely in their home. One is stored offsite.)
Every site I’ve registered them with has allowed me to register all three keys. Nobody has lost a key yet (thanks AirTag) but it wouldn’t be a huge ordeal if they did. Just delete that key from their services and use a backup.
You have draw the line somewhere and degrading the majority’s experience for the minority’s benefit is an unusual trade-off.
Whatever happened to, “Design for the expert user”?
Authoritative nameserver selection by recursive resolvers is extremely unreliable and implementation specific. This method may actually be worse than health checked records and low TTLs and could leave your site completely unconnectable for uncomfortably long periods of time.
See this paper for more details about nameserver selection of common recursive resolvers, and so called SRTT : https://irl.cs.ucla.edu/data/files/papers/res_ns_selection.p...
Also this presentation, https://youtu.be/z7Jl1sjr9jM
One of the best and most robust solutions for GSLB/GTM is pointing your main entrypoint IP (e.g. apex record/www/api) at an anycasted proxy (Cloudflare/Fastly/Google/AWS, etc), and using the active health check features of that service to the static unicasted (and firewalled!) load balancer IPs of your origin.
These services are not expensive but if you can’t afford them, the second best method would be to round robin A/AAAA records with low (60s) TTLs of a large pool of ingress load balancer IPs—which is exactly how AWS ALB/ELB/NLB operate!
When loadbalancing via DNS, you’ll still contend with misbehaving recursive resolvers (JVM clients for example) but you’ll strand less traffic for less time than you would when withdrawing authoritative nameservers due to unpredictable and chaotic resolver implementations.
Wow. This is a brilliant. Did you come up with this?