4 ms·
The problem here lies with the authoritative nameservers. You have to retrieve the record from somewhere initially. The trouble here is that since these compani
by atom_enger 10y ago
The problem here lies with the authoritative nameservers. You have to retrieve the record from somewhere initially. The trouble here is that since these companies are using Dyn and only Dyn to be their Nameservers. When a dns request is made for github.com they're attempting to contact ns3.p20.dynect.net or another nameserver provided by Dyn. So yes caching will work for a little while, but only for the length of the TTL which your client is designed to respect. Once that TTL expires, your client and upstream DNS provider will attempt to contact that nameserver for a fresh record. Since you can't contact the nameservers, the website is effectively offline for all name resolution. Now if you know the record you can always forge the record locally in /etc/hosts or in a local dns resolver which allows for overrides. Hope this helps.
- indigomm 10y agoIt was true that one DNS nameserver record == one physical server even at large providers. But we're beyond that now. Each nameserver at a physical location can be a cluster of hosts. Beyond that, with the use of anycast that single nameserver record may map to different clusters positioned around the world. This is how the root servers work and why they are more difficult to attack. Of course small DNS providers will find it hard to run a system this way, but the larger providers follow the same architecture - anycast and multiple servers at each location. Google and OpenDNS for a start use this pattern - the famous 8.8.8.8 and 8.8.4.4 are in fact multiple server clusters all around the world.
- atom_enger 10y agoSure - I assumed that's what the large organizations were doing but for the sake of explanation to those who didn't understand why the problem existed in the first place I didn't want to complicate my answer with something even more complex :) Appreciate your help doing so