How do you calculate dns response time ??

Hi
i got few tools to calculate , like dnsstuff .
but i dont understand whats the theory behind to calculate dns repose time .

I know their ranking some times wrong. but on what theory they use to calculate that  

eample : if i do dig @fosiul.co.uk

i get 40 msec  to 43 msec query time..

but if i look at dnsstuff their  
Average of all 2 nameservers: 490ms (plus 360ms overhead).


so they are adding some other thing.. but whats those ???


note : here i want to know the theory of calculating

thanks for your help
LVL 29
fosiul01Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chris DentPowerShell DeveloperCommented:

As far as I know they simply take the time between sending the request and receiving the response. Network conditions / paths will obviously have an impact on that.

I would guess that the overhead may be chasing delegations from root.

Chris
0
fosiul01Author Commented:
ok I understand that.. when you do

dig @fosiul.co.cok or dig fosiul.co.uk

the response time it gives what ever 40 msec or 45 mese

does it not calculate from going to root server -> down bellow -> actual name server ??


also : is there any way to tell dig command not to show query from dns cache ??


0
Chris DentPowerShell DeveloperCommented:
> does it not calculate from going to root server -> down bellow -> actual name server ??

Generally no but "it depends".

In the case if the first you're asking for an answer directly from fosiul.co.uk as a DNS server. It won't include the lookup for fosiul.co.uk itself (the DNS server IP), only the query performed after that. In the second you're getting the answer from whatever you have in resolv.conf (or DHCP configured servers) and those may have part or all of the response cached.

You'll get a more accurate representation if you run:

dig fosiul.co.uk +trace

> also : is there any way to tell dig command not to show query from dns cache ??

Outside of trace, as above, no. You can't make a DNS server ignore it's cache (from the client), you would have to have access to the server. And even then you'll get variable results depending on whether it uses Forwarders or Root Hints.

Chris
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

fosiul01Author Commented:
ok trace ...

if i use that


dig fosiul.co.uk +trace

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> fosiul.co.uk +trace
;; global options:  printcmd
.                       339729  IN      NS      e.root-servers.net.
.                       339729  IN      NS      f.root-servers.net.
.                       339729  IN      NS      g.root-servers.net.
.                       339729  IN      NS      h.root-servers.net.
.                       339729  IN      NS      i.root-servers.net.
.                       339729  IN      NS      j.root-servers.net.
.                       339729  IN      NS      k.root-servers.net.
.                       339729  IN      NS      l.root-servers.net.
.                       339729  IN      NS      m.root-servers.net.
.                       339729  IN      NS      a.root-servers.net.
.                       339729  IN      NS      b.root-servers.net.
.                       339729  IN      NS      c.root-servers.net.
.                       339729  IN      NS      d.root-servers.net.
;; Received 272 bytes from 193.132.234.222#53(193.132.234.222) in 0 ms

uk.                     172800  IN      NS      nsc.nic.uk.
uk.                     172800  IN      NS      nsb.nic.uk.
uk.                     172800  IN      NS      ns3.nic.uk.
uk.                     172800  IN      NS      nsd.nic.uk.
uk.                     172800  IN      NS      ns4.nic.uk.
uk.                     172800  IN      NS      ns2.nic.uk.
uk.                     172800  IN      NS      ns5.nic.uk.
uk.                     172800  IN      NS      ns6.nic.uk.
uk.                     172800  IN      NS      nsa.nic.uk.
uk.                     172800  IN      NS      ns7.nic.uk.
uk.                     172800  IN      NS      ns1.nic.uk.
;; Received 492 bytes from xx.xx.xx.10#53(e.root-servers.net) in 219 ms

fosiul.co.uk.           172800  IN      NS      xx.xxxxx.com.
fosiul.co.uk.           172800  IN      NS      xxx.xxxxx.com.
;; Received 93 bytes from 156.154.102.3#53(nsc.nic.uk) in 45 ms

fosiul.co.uk.           60      IN      A       213.229.73.151
fosiul.co.uk.           60      IN      NS      xxx.xxxx.com.
fosiul.co.uk.           60      IN      NS      xxxx.xxxx.com.
;; Received 109 bytes from xx.200.140.xx#53(electab1.miniserver.com) in 23 ms

so its like

219 + 45 + 23  = what ever response time is ??

is that true ???


why there is a big time difference to solve     this address e.root-servers.net) in 219 ms  

0
Chris DentPowerShell DeveloperCommented:

In short... Network paths and server load.

Root Servers will be busy. And, if the network path between you and the server is complex the UDP request and response will take longer.

There shouldn't be much more to it, you may take a number of requests and average those to rule out point-in-time failure.

Chris
0
fosiul01Author Commented:
hi thanks for the explanation

but i need little bit more to make it clear

you said "you may take a number of requests and average those to rule out  point-in-time failure."

how you actually do that ??? what kind of request you meant ??

0
Chris DentPowerShell DeveloperCommented:

If you run the same iterative query (+trace) several times over a period of time you will get small (hopefully) differences in the times. Take an average of those and it'll give you a better idea of performance.

The average can't account for the network path, but it can help account for network conditions (if the set you're averaging is taken over a long enough time-frame).

Whether it's any use depends on what you want to do with time now you have it.

Chris
0
fosiul01Author Commented:
and what you think for a average good dns response time ???

is there any guidance ??
0
Chris DentPowerShell DeveloperCommented:
It's subjective, you can pretty much make it up.

If you imagine that an average client may time-out a query in 2 seconds then you'd want to get yours over and done with before that.

Consider that a query for www.fosiul.co.uk may need 3 separate queries (1 to root, 1 to TLD, and one to your servers) that gives 600 milliseconds per query. You would hope not to take more than your fair share of that, so, in milliseconds perhaps you might say:

0 - 200 = Very good
200 - 400 = Good
400 - 600 = Okay
600 - 1000 = Poor
1000+ = Very poor

Chris
0
fosiul01Author Commented:
hahahaha

lol, its gues its poor!!

but can you make it faster from Bind point of view ?? or its depends on how speedy your network is and your ips and root server ?? [ 1 to root, 1 to TLD, and one to your servers

0
Chris DentPowerShell DeveloperCommented:

As far as I can see it's averaging the response from your name servers only. The rest of the lookup, root and TLD, are captured by the overhead (again, as far as I can see). So at 490ms it falls into the "Okay" category on my made up scale.

To make it faster you have to know where it's slowing down. Your own query demonstrates that your servers are able to respond quickly (23ms), so either the servers were under much greater load at the time, or network conditions (either local to your server, or between the client and your network borders) were less than favourable.

There's only so much you can do and you'd need a lot of monitoring in place to understand it properly.

Chris
0
arnoldCommented:
Chris explained quite well.
Caching speeds up subsequent lookups for the same information.
if you do not use cache, you would need to set the -noglue -nosearch which means that you would have to generate sequential queries.
i.e. "dig -noglue -nosearch fosiul.co.uk NS" will return the root servers
you have to pick one and generate the above request with @rootserrver
you then get a response for the authoritative name servers for either .co.uk or for the entire domai.
you have to pick one from the response and generate a request
Once you get to a point that you have the authoritative name servers for the domain fosiul.co.uk.
you pick one of the authoritative NS records and generate the lookup you want
dig -noglue -nosearch @authoritative_NS record fosiul.co.uk <Record_TYPE>
<Record_type> can be A, PTR, MX, INFO, ANY, TXT, CNAME, SRV etc.

The dig +trace does that for you.
lookups are often the least significant time used.
i.e. if you are accessing a web site, the retrieval of all the data and the rendering in the browser will be what the user will see and not how long it took their system to get an answer for the address?
I.e. if you are going on a trip does it really matter how long it takes you to lookup the address of the destination and develop a route to get there versus how long it actually takes you to get there?

A slow response for the lookup is the least of the issues while the retrieval and rendering are what most of the users wait time is for.  If this is not an interative user session, the lookup is of no significance.
i.e. email exchange between servers.
0
fosiul01Author Commented:
@arnold!!!

".e. if you are going on a trip does it really matter how long it takes  you to lookup the address of the destination and develop a route to get  there versus how long it actually takes you to get there?"

lol
its true..

but some nagios script for dns measure dns response time and put good , critical or warning

but they are using Perl:module or C modules   , none of them using dig or host command

so i wanted to know

yes it s clear to me.., how you guys calculating

but this command

dig -noglue -nosearch fosiul.co.uk NS

its does not work

i m trying from dig man
but its does not work

whats the right command?
0
arnoldCommented:
the noglue/nosearch are nslookup options which I should have checked prior to posting
the trace option Chris provided is the equivalent which tells dig to go through the process step by step.

The nagios DNS monitor should be directed to your own DNS server and lookup an authoritative datapoint since this is a check for your DNS functioning. Adding a parameter such as an external name to lookup, will lead to the issue you seem to want to address i.e. false positives.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.