Think you can only get aa if the the server is an authority.... I've been playing around with a local forward first caching server.... so I tried it.
First run: % dig mail.com ; <<>> DiG 9.9.2-rpz.066.22-P1 <<>> mail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20016 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.com. IN A ;; ANSWER SECTION: mail.com. 86400 IN A 213.165.66.221 ;; Query time: 183 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 15 13:16:06 2013 ;; MSG SIZE rcvd: 53 Second run: % dig mail.com ; <<>> DiG 9.9.2-rpz.066.22-P1 <<>> mail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51884 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.com. IN A ;; ANSWER SECTION: mail.com. 86395 IN A 213.165.66.221 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 15 13:16:11 2013 ;; MSG SIZE rcvd: 53 And, when I tried some of our normal caching servers...the results were similar, with Query times of up to 3 ms. Until I found one that hadn't cached yet it. ; <<>> DiG 9.6-ESV-R4-P1 <<>> mail.com @dns-6 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61026 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.com. IN A ;; ANSWER SECTION: mail.com. 86400 IN A 213.165.66.221 ;; AUTHORITY SECTION: mail.com. 86400 IN NS dns.gmx.net. mail.com. 86400 IN NS ns.gmx.net. ;; Query time: 377 msec ;; SERVER: 129.130.139.154#53(129.130.139.154) ;; WHEN: Fri Mar 15 13:17:49 2013 ;; MSG SIZE rcvd: 84 Subsequent dig took 0ms. Tried add +aaonly ; <<>> DiG 9.9.2-rpz.066.22-P1 <<>> +aaonly mail.com @dns-6 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44400 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.com. IN A ;; ANSWER SECTION: mail.com. 86215 IN A 213.165.66.221 ;; AUTHORITY SECTION: mail.com. 86215 IN NS dns.gmx.net. mail.com. 86215 IN NS ns.gmx.net. ;; Query time: 0 msec ;; SERVER: 129.130.139.154#53(129.130.139.154) ;; WHEN: Fri Mar 15 13:20:54 2013 ;; MSG SIZE rcvd: 95 but dig against one of the authority section servers.... ; <<>> DiG 9.9.2-rpz.066.22-P1 <<>> mail.com @ns.gmx.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2703 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.com. IN A ;; ANSWER SECTION: mail.com. 86400 IN A 213.165.66.221 ;; Query time: 120 msec ;; SERVER: 213.165.64.2#53(213.165.64.2) ;; WHEN: Fri Mar 15 13:21:05 2013 ;; MSG SIZE rcvd: 53 ----- Original Message ----- > On 15.03.13 15:25, Abdellatif ... wrote: > >I want to optimize the call to remote dns server to resolve domain > >names > > each time needed. What i want to do is that if the hostname is > >requested for the first time than call the remote dns (for example > >8.8.8.8) to resolve it, once called then recorded for later use in > >such > >way when next time the seem domain name is requested for resolve > >than > >the cached ip is grabbed without need to call remote dns to maximize > >speed to optimize network traffic. > > This is how BIND normally works. > > >It doesn't seem to use the cache, here is the call of dig mail.com : > > > >; <<>> DiG 9.8.1-P1 <<>> mail.com > [...] > >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > this is clearly a cached answer (aa flag is missing). How did you > come to > the conclusion that caching does not work? > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Save the whales. Collect the whole set. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
