2

We have bind 9.8.1.dfsg.P1-4ubuntu0.13 in ubuntu 12.04, which is running on not heavily loaded server (load average: 0.19, 0.12, 0.13) and serving requests for small office network with macos and ubuntu workstations.

I ran some dns tests in script on container which is running as dns server and push results to influxdb.

#!/bin/bash
while true
do
        rndc flush

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=yes value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=yes value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=yes value=$yandex_timeout" &
        wait

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=no value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=no value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=no value=$yandex_timeout" &
        wait

        sleep 5
done

I found that bind responding on requests slowly than 8.8.8.8 and 77.88.8.8. This can be seen in the graphs:

Flushing cache before first request series with rndc flush. Bind uses google 8.8.8.8 and 8.8.4.4 as forwarders:

enter image description here

Never flush the cache of running bind. Bind uses google 8.8.8.8 and 8.8.4.4 as forwarders:

enter image description here

Flushing cache before first request series with rndc flush. Bind uses updated list of root servers as forwarders:

enter image description here

Never flush the cache of running bind. Bind uses updated list of root servers as forwarders:

enter image description here

Why max query time (about 5k on first graph and 2.5k on third graph) with google public dns is larger than root servers ?

Why query throught bind is slowly than direct query of public dns servers ?

May be something wrong in my tests?

UPDATE 1

There is 20 sec TTL on the graphs - it is wrong. TTL for redhat.com is 60 sec.

  • Hey, Tim from debian-russian thread here, add your config file to the description. That might help with the answer :) – stimur Sep 24 '15 at 16:33
2

Your tests are measuring the total time for performing your query, including

  • network delay from and to the machine running your test script
  • processing time on the name server under test
  • time the name server under test spends waiting for answers from other name servers, ie. time for performing any recursive subqueries

The results are pretty much as expected.

  • If you query your local BIND server without flushing the cache, the answer will come from the cache most of the time. Even if the TTL for the A RR has expired, the NS RR will still be in the cache so only the A RR itself has to be requested externally.
  • If you query your local BIND server after flushing the cache and have not configured forwarders, your local BIND server will perform a recursive query starting from a root server downward.
  • If you query your local BIND server after flushing the cache and have configured the Google servers as forwarders, your local BIND server will forward the query as-is to one of the Google servers which will then in turn either answer the query from its cache or perform a recursive query. Note that you have no control over the cache of the Google servers.

Consequently, queries to your local BIND server without clearing the cache first are fastest, and not influenced by the forwarder configuration. Queries to your local BIND server after clearing the cache and with the Google servers configured as forwarders are slower than direct queries to the Google servers because they add to the latter the overhead of passing through your local BIND server first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.