Davey Song writes: > Normally end user have more than one configured resolvers. If only > one resolver experience the outage and serve the stale data, could > the user tell which resolver have more refreshed data ?
Not in the usual resolution process, no. Whether the user's system will fall back to the second resolver in a "reasonable" amount of time depends on local policy. Of course, it's entirely possible that the second resolver won't have any better answer anyway, either because the answer hasn't changed, it has changed but provides essentially the same service level, or the second resolver is experiencing the same network path problems as well. Even if it were communicated from the recursive resolver to the stub, then there is a further matter of communicating that to the end user. The complexity of this led to a clear sentiment in dnsop against including mechanisms to mark an answer that used stale data. So yes, serving stale data is not always the best result, but operational experience has shown that on balance the observed benefit has outweighed the possible negative by far. > 2) I notice it is proposed as a stand track document. If more people > here think its benefit outweighs its impacts, I prefer it published > as informational document This was discussed early on, and the rationale for standards track is that it is well within the scope of a standard to clear define acceptable data lifetime. While the details of each implementation are indeed informational, being clear that data can legitimately be used in an error condition beyond the time the TTL says it is normally valid is properly part of the definition of a TTL. > 3) A minor concern: in an thread in dns-operation mailing list last > week, it is said that the behavior of serve stale in some ISPs is > abused for reason of traffic hijack/tampering/spoofing. I'm afraid > it will be encouraged by this document. Two things are of note here: they're already doing it even without an RFC blessing it, and the document lays out pretty clearly that this is not the condition for which serve-stale should be used. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
