DNS Reliability

Phil Fagan philfagan at gmail.com
Fri Sep 13 18:14:55 UTC 2013

Tolerance for failure; I like it.

Eric - I'm interested in an accepted norm of loss of queries made to the
cache tier. Yes, when I provide a 'service' to a client (don't really care
about SLA) i'm interested in what the accepted norm or guidance is on %
loss on queries -- because this drives my architecture, right?

Marco - I think 'lost queries' in this instance is simply, wait for
it.....the full UDP session. Yes yes, session is bad to say, but service
request completed through middle-boxes are tracked as sessions.

So thats what I'm looking for; what is the general consesus for reliability
all other things equal. Sure, you have the factor of UDP, retry, path, etc.
etc. etc.....but I think Larry hit the nail on the head - whats my
clients[aggregate of] tolerance before Evil ensues.

On Fri, Sep 13, 2013 at 8:00 AM, Larry Sheldon <LarrySheldon at cox.net> wrote:

> On 9/13/2013 2:14 AM, Marco Davids (Prive) wrote:
>> On 09/13/13 03:53, Larry Sheldon wrote:
>>> On 9/12/2013 3:25 PM, Phil Fagan wrote:
>>>> Its a good point about the anycast; 99.999% should be expected.
>>> A small choice of attitude-reflecting language.
>>> I expect 100.000%
>>> I'll accept 99.999% or better.
>> It depends... define 'lost queries'. For example; is RRL included here
>> or not (sometimes you want to deliberatly 'loose' queries).
> I do not ever set any amount of failure as an objective.  I usually have a
> specified tolerance for failure.  If for some odd circumstance I wan to
> discard queries, that would involve knowing exactly what happened to
> them--not loosing them.
> --
> Requiescas in pace o email           Two identifying characteristics
>                                         of System Administrators:
> Ex turpi causa non oritur actio      Infallibility, and the ability to
>                                         learn from their mistakes.
>                                           (Adapted from Stephen Pinker)

Phil Fagan
Denver, CO

More information about the NANOG mailing list