2

During the recent DDoS attack on Dyn servers, many websites couldn't be reached for quite a while. However, these websites were resolvable via Google's public DNS servers. I assume IP addresses were cached for a TTL amount of time since last check that was configured by domain owner via Dyn before it went down, is it correct? If so, does it mean that if someone would use Google's public DNS flush cache tool to flush, say, twitter.com, it would become unavailable for everyone who used Google public DNS as a backup to resolve that domain during the Dyn's downtime?

Sergey Lukin
  • 133
  • 2

2 Answers2

2

However, these websites were resolvable via Google's public DNS servers.

Not for long as and when cache TTL would expire, these DNS too would have to go to authoritative DNS to resolve the record.

is it correct?

Yes absolutely.

If so, does it mean that if someone would use Google's public DNS flush cache tool to flush, say, twitter.com, it would become unavailable for everyone who used Google public DNS as a backup to resolve that domain during the Dyn's downtime?

Spot on, these servers would render unusable in that case. But in any case there is a TTL attached even if you don't clear it(flush it) then also it can be used for a limited amount of time(whatever cache is left).

Another thing to note is Google public DNS have multiple instances running behind a LB(load balancer) I would guess so, if you would have noticed i.e. If you do queries quickly to the public DNS it gives different TTL in every reply. Which would mean the server instance with lowest TTL is the maximum time you can get the replies to your record seemlessly after that if you went to query that DNS at which TTL has expired, You won't get a reply.

The easiest way to overcome this is to have an entry in /etc/hosts of whichever website you want 100% availability.(and this is like going backwards ;) )

Hope this helps!

Anirudh Malhotra
  • 1,290
  • 7
  • 11
0

Your hypothesis is correct. If the caching nameserver no longer has a valid copy of the record you have requested (ie. it has been "flushed" or the TTL has been reached) then it must contact an upstream server to be able to handle the response.

In the event that the caching server queries authoritative servers directly, if the authoritative servers are not able to respond (as was the case with Dyn attack last week) then the only response the caching server can give back to the client is a failure.