frequent queries to root servers

Robert Edmonds edmonds at mycre.ws
Wed Jan 27 00:27:01 UTC 2016


HONTVÁRI Levente wrote:
> I assumed that the root servers are only queried a few times a week
> (corresponding to the number of top level domains). The logs show a
> different picture, Queries to the root servers are quite frequent. What am I
> missing?
> 
> I have attached a dnstop screen (local network traffic was filtered out),
> after running for about 2 hours. I also attached a log extract about a
> single query from 10.0.3.44 resolved by 10.0.3.48, which involves a query to
> the root servers. I notice that there is a DS record query before the root
> server query, but otherwise I do not see anything strange.

You can't actually tell which queries went to root servers by just
looking at the query names in packets, or in the case of the dnstop
output you showed, parts of query names.

If you wanted to count traffic to root servers, you would need a BPF
expression that listed each of the 24 root server addresses, something
like:

    'host (198.41.0.4 or 192.228.79.201 or 192.33.4.12 or \
    199.7.91.13 or 192.203.230.10 or 192.5.5.241 or 192.112.36.4 or \
    198.97.190.53 or 192.36.148.17 or 192.58.128.30 or 193.0.14.129 or \
    199.7.83.42 or 202.12.27.33 or 2001:503:ba3e::2:30 or \
    2001:500:84::b or 2001:500:2::c or 2001:500:2d::d or \
    2001:500:2f::f or 2001:500:1::53 or 2001:7fe::53 or \
    2001:503:c27::2:30 or 2001:7fd::1 or 2001:500:3::42 or \
    2001:dc3::35)'

Maybe you could run two dnstop instances, one with the root-servers only
BPF, and one without, and compare the totals reported by each.

If you had a version of BIND compiled with dnst*a*p support (the version
you mentioned does not), you could turn on the RESOLVER_QUERY and/or
RESOLVER_RESPONSE message logging options and filter the resulting
output for messages having a 'query_zone' field set to the root label,
which is a little less awkward and more future-proof than enumerating
all of the root server addresses.

-- 
Robert Edmonds


More information about the bind-users mailing list