@alextang: "Hi All
Please help
how do i know dns is using which root server to query per request ? ( per transaction )
any log or option I need to config  to check it ?
my bind version is 9.3.2
Thx very much"
    @kcd: "<quote>
Your question is flawed, inasmuch as it seems to assume that a root
server is used for each query. In actuality, what happens is that named
gets the root-zone information at startup via a "priming" query, builds
up a whole hierarchy of cached information as queries come in and the
results are cached, and very rarely needs to go back up to the roots for
anything.
The real question is: why do you care what root server is or is not used
in the resolution of a particular query?
- Kevin"
    @alextang: "it is because our cache only dns was upgraded to 9.3.2 from bind 8, we want to find out that can it use the nearest root server to query ? We have a BGP session with a root server which is located in the local exchange. Therefore, we want to find out some log to show which root server will be use if the dns server need to query root server.
otherwise we need to use sniffer or snoop to obtain those information.
-Original Message-
From: <email_address> [mailto:<email_address>]On
Behalf Of Kevin Darcy
Sent: Thursday, March 09, 2006 12:32 AM
To: <email_address>
Subject: Re: Bind 9.3.2 - how do i know dns is using which root server
<quote>
Your question is flawed, inasmuch as it seems to assume that a root
server is used for each query. In actuality, what happens is that named
gets the root-zone information at startup via a "priming" query, builds
up a whole hierarchy of cached information as queries come in and the
results are cached, and very rarely needs to go back up to the roots for
anything.
The real question is: why do you care what root server is or is not used
in the resolution of a particular query?
- Kevin"
    @barmar: "<quote>
BIND keeps track of the response times of servers that it has queried in 
the past.  When it needs to query a server for a particular zone, it 
uses the one that had the best response time.  So if you have a very 
fast connection to one root server, it will usually be used.
You can enable debugging and it should log when it's querying outside 
servers.
Barry Margolin, <email_address>
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***"
    @alextang: "Dear Sir
I start the bind with a debug level 11 but cannot find out which root server replied the ns record of .jp or which root servers the cache server asked. would u help me where i can i find out those information ?
thx
 category client { query_file; };
 category unmatched { query_file; };
 category queries {  query_file; };
query file
=======
9-Mar-2006 18:33:28.896 client: debug 3: client 83.161.120.155#2716: UDP request
09-Mar-2006 18:33:28.897 client: debug 5: client 83.161.120.155#2716: using view '_default'
09-Mar-2006 18:33:28.910 client: debug 3: client 83.161.120.155#2716: query
09-Mar-2006 18:33:28.910 queries: info: client 83.161.120.155#2716: query: <url> IN MX +
09-Mar-2006 18:33:28.910 client: debug 10: client 83.161.120.155#2716: ns_client_attach: ref = 1
09-Mar-2006 18:33:28.911 client: debug 3: client 83.161.120.155#2716: replace
09-Mar-2006 18:33:28.912 client: debug 3: client @20cb18: udprecv
09-Mar-2006 18:33:29.983 client: debug 3: client 83.161.120.155#2716: send
09-Mar-2006 18:33:29.983 client: debug 3: client 83.161.120.155#2716: sendto
09-Mar-2006 18:33:29.983 client: debug 3: client 83.161.120.155#2716: senddone
09-Mar-2006 18:33:29.984 client: debug 3: client 83.161.120.155#2716: next
09-Mar-2006 18:33:29.984 client: debug 10: client 83.161.120.155#2716: ns_client_detach: ref = 0
09-Mar-2006 18:33:29.984 client: debug 3: client 83.161.120.155#2716: endrequest
 category resolver { event_file; };
 category network { event_file; };
 category delegation-only { event_file; };
 category lame-servers { event_file; };
event_file
========
09-Mar-2006 18:33:28.911 resolver: debug 1: createfetch: <url> MX
09-Mar-2006 18:33:28.911 resolver: debug 3: fctx 233d60(<url> create
09-Mar-2006 18:33:28.912 resolver: debug 3: fctx 233d60(<url> join
09-Mar-2006 18:33:28.912 resolver: debug 3: fetch 223918 (fctx 233d60(<url> created
09-Mar-2006 18:33:28.912 resolver: debug 3: fctx 233d60(<url> start
09-Mar-2006 18:33:28.913 resolver: debug 3: fctx 233d60(<url> try
09-Mar-2006 18:33:28.913 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:28.913 resolver: debug 3: fctx 233d60(<url> getaddresses
09-Mar-2006 18:33:28.917 resolver: debug 3: fctx 233d60(<url> query
09-Mar-2006 18:33:28.917 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> send
09-Mar-2006 18:33:28.917 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> sent
09-Mar-2006 18:33:28.918 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> senddone
09-Mar-2006 18:33:29.309 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> response
09-Mar-2006 18:33:29.310 resolver: debug 10: received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:   6760
;; flags: qr ; QUESTION: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 10
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<url>               IN      MX
;; AUTHORITY SECTION:
jp.                     172800  IN      NS      f.dns.jp.
jp.                     172800  IN      NS      d.dns.jp.
jp.                     172800  IN      NS      e.dns.jp.
jp.                     172800  IN      NS      a.dns.jp.
jp.                     172800  IN      NS      b.dns.jp.
;; ADDITIONAL SECTION:
f.dns.jp.               172800  IN      A       83.161.120.155
f.dns.jp.               172800  IN      AAAA    888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4153
d.dns.jp.               172800  IN      A       83.161.120.155
d.dns.jp.               172800  IN      AAAA    888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a453
e.dns.jp.               172800  IN      A       83.161.120.155
e.dns.jp.               172800  IN      AAAA    888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a44
a.dns.jp.               172800  IN      A       83.161.120.155
a.dns.jp.               172800  IN      AAAA    888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a41
b.dns.jp.               172800  IN      A       83.161.120.155
09-Mar-2006 18:33:29.310 resolver: debug 3: fctx 233d60(<url> noanswer_response
09-Mar-2006 18:33:29.310 resolver: debug 3: fctx 233d60(<url> cache_message
09-Mar-2006 18:33:29.311 resolver: debug 3: fctx 233d60(<url> cancelquery
09-Mar-2006 18:33:29.311 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.314 resolver: debug 3: fctx 233d60(<url> try
09-Mar-2006 18:33:29.314 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.314 resolver: debug 3: fctx 233d60(<url> getaddresses
09-Mar-2006 18:33:29.316 resolver: debug 3: fctx 233d60(<url> query
09-Mar-2006 18:33:29.316 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> send
09-Mar-2006 18:33:29.317 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> sent
09-Mar-2006 18:33:29.317 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> senddone
09-Mar-2006 18:33:29.775 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> response
09-Mar-2006 18:33:29.776 resolver: debug 10: received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  36148
;; flags: qr ; QUESTION: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<url>               IN      MX
;; AUTHORITY SECTION:
yahoo.co.jp.            86400   IN      NS      ns10.yahoo.co.jp.
yahoo.co.jp.            86400   IN      NS      dnsg01.yahoo.co.jp.
;; ADDITIONAL SECTION:
ns10.yahoo.co.jp.       86400   IN      A       83.161.120.155
dnsg01.yahoo.co.jp.     86400   IN      A       83.161.120.155
09-Mar-2006 18:33:29.776 resolver: debug 3: fctx 233d60(<url> noanswer_response
09-Mar-2006 18:33:29.776 resolver: debug 3: fctx 233d60(<url> cache_message
09-Mar-2006 18:33:29.777 resolver: debug 3: fctx 233d60(<url> cancelquery
09-Mar-2006 18:33:29.777 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.778 resolver: debug 3: fctx 233d60(<url> try
09-Mar-2006 18:33:29.778 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.779 resolver: debug 3: fctx 233d60(<url> getaddresses
09-Mar-2006 18:33:29.779 resolver: debug 3: fctx 233d60(<url> query
09-Mar-2006 18:33:29.779 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> send
09-Mar-2006 18:33:29.780 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> sent
09-Mar-2006 18:33:29.780 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> senddone
09-Mar-2006 18:33:29.980 resolver: debug 3: resquery 1ef868 (fctx 233d60(<url> response
09-Mar-2006 18:33:29.980 resolver: debug 10: received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  18074
;; flags: qr aa ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<url>               IN      MX
;; AUTHORITY SECTION:
yahoo.co.jp.            900     IN      SOA     yahoo.co.jp. postmaster.yahoo.co.jp. 2006030908 1800 900 86400 900
09-Mar-2006 18:33:29.981 resolver: debug 3: fctx 233d60(<url> noanswer_response
09-Mar-2006 18:33:29.981 resolver: debug 3: fctx 233d60(<url> ncache_message
09-Mar-2006 18:33:29.981 resolver: debug 3: fctx 233d60(<url> clone_results
09-Mar-2006 18:33:29.981 resolver: debug 3: fctx 233d60(<url> cancelquery
09-Mar-2006 18:33:29.981 resolver: debug 3: fctx 233d60(<url> done
09-Mar-2006 18:33:29.982 resolver: debug 3: fctx 233d60(<url> stopeverything
09-Mar-2006 18:33:29.982 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.982 resolver: debug 3: fctx 233d60(<url> sendevents
09-Mar-2006 18:33:29.982 resolver: debug 3: fetch 223918 (fctx 233d60(<url> destroyfetch
09-Mar-2006 18:33:29.983 resolver: debug 3: fctx 233d60(<url> shutdown
09-Mar-2006 18:33:29.984 resolver: debug 3: fctx 233d60(<url> doshutdown
09-Mar-2006 18:33:29.984 resolver: debug 3: fctx 233d60(<url> stopeverything
09-Mar-2006 18:33:29.985 resolver: debug 3: fctx 233d60(<url> cancelqueries
09-Mar-2006 18:33:29.985 resolver: debug 3: fctx 233d60(<url> destroy
-Original Message-
From: <email_address> [mailto:<email_address>]On Behalf Of Barry Margolin
Sent: Thursday, March 09, 2006 1:16 PM
To: <email_address>
Subject: Re: Bind 9.3.2 - how do i know dns is using which root server
<quote>
BIND keeps track of the response times of servers that it has queried in 
the past.  When it needs to query a server for a particular zone, it 
uses the one that had the best response time.  So if you have a very 
fast connection to one root server, it will usually be used.
You can enable debugging and it should log when it's querying outside 
servers.
Barry Margolin, <email_address>
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***"
{'source': 'USENET', 'other_information': '{"reply_count": 4, "forum_name": "comp.protocols.dns.bind.20140613.mbox"}', 'file': 'data/output/usenet-comp.protocols.parquet'}