RTT: how it works

Kevin Darcy kcd at daimlerchrysler.com
Tue Apr 30 02:16:37 UTC 2002


jefferson.f.moreira at hsbc.com.br wrote:

> >What is this "75s" timeout you're referring to? That sounds more like a
> client
> >timeout, e.g. a time it takes a browser to fail over to another web server
> >address.
>
> Exactly...the resolver delay. I figure RTT has nothing to do with client
> side,
> but still ask if the resolver would behave like that, i.e., in the case a
> NS
> failing, will it send a request to the failed NS...and wait?? How long?
>
> I wond if this behavior could ruin the entire solution, or not...

Yes, resolvers will typically fail over to another nameserver, but understand
that *nameserver* failover is not the same as *address* failover. Stub
resolvers have a list of nameservers to try, and if they time out trying to
get an answer from one nameserver, they'll try another.
ONCE THEY GET AN ANSWER, however, they won't try any other nameserver. If the
answer happens to be a multiple-address answer, then they will work through
that list to try and connect to a server, timing out and retrying as
necessary. The timeout and retry strategies for nameserver failover and
address failover may be totally different from each other, particularly since
different parts of the system are usually involved -- nameserver failover is
typically a function of system routines/libraries, whereas address failover is
typically implemented by application code.


- Kevin
> Hi all.

> >
> > I have a doubt on DNS servers behavior regarding RTT.
> >
> > Consider the following diagram:
> >
> >       cwb.somenet.net.br                  cwb.somenet.net.br
> >             [cs1]                                [cs2]
> >               |                                    |
> >               |                                    |
> >      +------[Sw1]------+                  +------[Sw2]-----+
> >      /      /   \       \                /       /   \      \
> >     /      /     \       \              /       /     \      \
> >  (NS1)  [Srv1]   [Srv2]   \            /    [Srv3]   [Srv4]  (NS2)
> >                            \          /
> >                         (Router)---(Router)
> >                              \      /
> >                               \    /
> >                              (Router)
> >                                 |
> > [ Corp NS ]---------------------+
> >
> > CS1/2 =3D Content Service Switches with DNS service
> > Sw1 =3D Switches
> > NS1/2 =3D Two Win2k Name servers. They=B4re not primary and secondary,
> > but two servers with the same db.
> >
> > These questions apply to a query from an external NS (let=B4s say, a
> > corporate NS)querying NS1 that will delegate it to CS1.
> >
> > q1: (this applies to the CSSs)
> > When there are 2 name servers (SOAs) for one domain, how is calculated
> > the Round Trip Time? At exactly what moment will be calculated this RTT
> > and how often?
>
> The RTT will be recalculated every time the nameserver is used. In the
> event
> that a particular nameserver doesn't answer (this leads into your next
> question), the RTT value for that nameserver will be severely penalized.
> But
> that nameserver will still be tried occasionally, in case it has recovered.
>
> > q2: in the event of one of the CSx failing, will we have that 75s time
> > out? How to overcome that? What is the default behavior?
>
> As long as both of your nameservers are published nameservers for the zone,
> then other nameservers should quickly fail over when one of them becomes
> unavailable for whatever reason.
>
> What is this "75s" timeout you're referring to? That sounds more like a
> client
> timeout, e.g. a time it takes a browser to fail over to another web server
> address. Hopefully you realize that the RTT calculations only apply to
> nameserver-to-nameserver interactions and have *nothing* to do with
> client/server interactions. The CSS technology (which I'm vaguely familiar
> with, since we use them here) sometimes tends to blur the distinction
> between
> the two...
>
> - Kevin
>
>



More information about the bind-users mailing list