DNS slave not synced after successfully zone transfer
Hi, I've got two bind9 servers, one master (192.168.2.251) and one slave (192.168.2.252). I've configured zone transfers, and after a change of a zone on the master, the slave gets the notification, downloads successfully the new zone file, but still has the old information in memory: nslookup 192.168.250.101 192.168.2.251 Server: 192.168.2.251 Address: 192.168.2.251#53 101.250.168.192.in-addr.arpa name = openerp-bold.xpto.com. nslookup 192.168.250.101 192.168.2.252 Server: 192.168.2.252 Address: 192.168.2.252#53 101.250.168.192.in-addr.arpa name = demoopenerp1.xpto.com. -- Log on the slave: 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa' 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source 192.168.2.252#0) deleted from unreachable cache 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia 24-Jul-2014 14:48:42.482 general: debug 3: request_render 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170: eref 1 iref 1 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request 0x8037eaea8: success 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old 2014070617 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170: eref 1 iref 0 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.484 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started. 24-Jul-2014 14:48:42.484 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from 192.168.2.251#53 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: connected using 192.168.2.252#51302 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: requesting IXFR for serial 2014070617 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request length prefix 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request data 24-Jul-2014 14:48:42.486 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: got nonincremental response 24-Jul-2014 14:48:42.486 general: debug 1: zone_settimer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.486 general: debug 3: removing journal file 24-Jul-2014 14:48:42.486 general: debug 3: replacing zone database 24-Jul-2014 14:48:42.486 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: zone transfer finished: success 24-Jul-2014 14:48:42.486 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: transferred serial 2014072417 24-Jul-2014 14:48:42.486 general: debug 1: zone_settimer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.486 xfer-in: info: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: Transfer completed: 1 messages, 12 records, 416 bytes, 0.001 secs (416000 bytes/sec) 24-Jul-2014 14:48:42.486 general: debug 1: zone_timer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
Re: DNS slave not synced after successfully zone transfer
On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone file look like? Also, what does your cache look like? Is 101.250.168.192.in-addr.arpa PTR cached? John On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, I've got two bind9 servers, one master (192.168.2.251) and one slave (192.168.2.252). I've configured zone transfers, and after a change of a zone on the master, the slave gets the notification, downloads successfully the new zone file, but still has the old information in memory: nslookup 192.168.250.101 *192.168.2.251* Server:192.168.2.251 Address:192.168.2.251#53 *101.250.168.192.in-addr.arpaname = openerp-bold.xpto.com http://openerp-bold.xpto.com.* nslookup 192.168.250.101 *192.168.2.252* Server:192.168.2.252 Address:192.168.2.252#53 *101.250.168.192.in-addr.arpaname = demoopenerp1.xpto.com http://demoopenerp1.xpto.com.* -- Log on the slave: 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa' 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source 192.168.2.252#0) deleted from unreachable cache 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia 24-Jul-2014 14:48:42.482 general: debug 3: request_render 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170: eref 1 iref 1 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request 0x8037eaea8: success 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old 2014070617 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170: eref 1 iref 0 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.484 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started. 24-Jul-2014 14:48:42.484 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from 192.168.2.251#53 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: connected using 192.168.2.252#51302 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: requesting IXFR for serial 2014070617 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request length prefix 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request data 24-Jul-2014 14:48:42.486 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: got nonincremental response 24-Jul-2014 14:48:42.486 general: debug 1: zone_settimer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.486 general: debug 3: removing journal file 24-Jul-2014 14:48:42.486 general: debug 3: replacing zone database 24-Jul-2014 14:48:42.486 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: zone transfer finished: success 24-Jul-2014 14:48:42.486 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: transferred serial 2014072417 24-Jul-2014 14:48:42.486 general: debug 1: zone_settimer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.486 xfer-in: info: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: Transfer completed: 1 messages, 12 records, 416 bytes, 0.001 secs (416000 bytes/sec) 24-Jul-2014 14:48:42.486 general: debug 1: zone_timer: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014
Re: DNS slave not synced after successfully zone transfer
Hi, It seems it's taking some time to sync after the transfer, because now it resolves ok with the new data. nslookup 192.168.250.101 192.168.2.251 Server: 192.168.2.251 Address: 192.168.2.251#53 101.250.168.192.in-addr.arpa name = openerp-bold.vi.pt. nslookup 192.168.250.101 192.168.2.252 Server: 192.168.2.252 Address: 192.168.2.252#53 101.250.168.192.in-addr.arpa name = openerp-bold.vi.pt. After the transfer i checked the new zone file and it was exactly the same as the master one. If i make a new change to the master how can i then check if 101.250.168.192.in-addr.arpa PTR is cached? On 24-07-2014 15:35, John Miller wrote: On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone file look like? Also, what does your cache look like? Is 101.250.168.192.in-addr.arpa PTR cached? John On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, I've got two bind9 servers, one master (192.168.2.251) and one slave (192.168.2.252). I've configured zone transfers, and after a change of a zone on the master, the slave gets the notification, downloads successfully the new zone file, but still has the old information in memory: nslookup 192.168.250.101 192.168.2.251 Server: 192.168.2.251 Address: 192.168.2.251#53 101.250.168.192.in-addr.arpa name = openerp-bold.xpto.com. nslookup 192.168.250.101 192.168.2.252 Server: 192.168.2.252 Address: 192.168.2.252#53 101.250.168.192.in-addr.arpa name = demoopenerp1.xpto.com. -- Log on the slave: 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa' 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source 192.168.2.252#0) deleted from unreachable cache 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia 24-Jul-2014 14:48:42.482 general: debug 3: request_render 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170: eref 1 iref 1 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request 0x8037eaea8: success 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old 2014070617 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170: eref 1 iref 0 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.484 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started. 24-Jul-2014 14:48:42.484
Re: DNS slave not synced after successfully zone transfer
To check your cache, just run rndc dump. It'll write a dump of the BIND cache to your data directory (wherever you've got it configured). John On Thu, Jul 24, 2014 at 10:51 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, It seems it's taking some time to sync after the transfer, because now it resolves ok with the new data. nslookup 192.168.250.101 192.168.2.251 Server:192.168.2.251 Address:192.168.2.251#53 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt. nslookup 192.168.250.101 192.168.2.252 Server:192.168.2.252 Address:192.168.2.252#53 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt. After the transfer i checked the new zone file and it was exactly the same as the master one. If i make a new change to the master how can i then check if 101.250.168.192.in-addr.arpa PTR is cached? On 24-07-2014 15:35, John Miller wrote: On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone file look like? Also, what does your cache look like? Is 101.250.168.192.in-addr.arpa PTR cached? John On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, I've got two bind9 servers, one master (192.168.2.251) and one slave (192.168.2.252). I've configured zone transfers, and after a change of a zone on the master, the slave gets the notification, downloads successfully the new zone file, but still has the old information in memory: nslookup 192.168.250.101 *192.168.2.251* Server:192.168.2.251 Address:192.168.2.251#53 *101.250.168.192.in-addr.arpaname = openerp-bold.xpto.com http://openerp-bold.xpto.com.* nslookup 192.168.250.101 *192.168.2.252* Server:192.168.2.252 Address:192.168.2.252#53 *101.250.168.192.in-addr.arpaname = demoopenerp1.xpto.com http://demoopenerp1.xpto.com.* -- Log on the slave: 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa' 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source 192.168.2.252#0) deleted from unreachable cache 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia 24-Jul-2014 14:48:42.482 general: debug 3: request_render 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170: eref 1 iref 1 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request 0x8037eaea8: success 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old 2014070617 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170: eref 1 iref 0 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.484 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started. 24-Jul-2014 14:48:42.484 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from 192.168.2.251#53 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: connected using 192.168.2.252#51302 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: requesting IXFR for serial 2014070617 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request length prefix 24-Jul-2014 14:48:42.484 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: sent request data 24-Jul-2014 14:48:42.486 xfer-in: debug 3: transfer of '250.168.192.in-addr.arpa/IN/vi_local_resolver' from 192.168.2.251#53: got nonincremental response 24-Jul-2014 14:48:42.486 general: debug 1:
Re: DNS slave not synced after successfully zone transfer
+1. Both Windows and Mac cache DNS records, so if you had the old one cached prior to making the change, you'd either have to flush your local cache or wait for the record's TTL to expire. On Linux, at least, nslookup is a deprecated tool: dig is better in many ways. In Windows, obviously, nslookup is all you've got by default :-( John On Thu, Jul 24, 2014 at 4:44 PM, Leonard Mills l...@yahoo.com wrote: You may be seeing additional buffering from nslookup. If you are using nslookup on a Windows platform, I'm 99.44% confident that you are observing M$ client-side buffering. DiG (or even host) are much better than nslookup for diagnostic purposes. hth On Thursday, July 24, 2014 8:00 AM, John Miller johnm...@brandeis.edu wrote: To check your cache, just run rndc dump. It'll write a dump of the BIND cache to your data directory (wherever you've got it configured). John On Thu, Jul 24, 2014 at 10:51 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, It seems it's taking some time to sync after the transfer, because now it resolves ok with the new data. nslookup 192.168.250.101 192.168.2.251 Server:192.168.2.251 Address:192.168.2.251#53 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt. nslookup 192.168.250.101 192.168.2.252 Server:192.168.2.252 Address:192.168.2.252#53 101.250.168.192.in-addr.arpaname = openerp-bold.vi.pt. After the transfer i checked the new zone file and it was exactly the same as the master one. If i make a new change to the master how can i then check if 101.250.168.192.in-addr.arpa PTR is cached? On 24-07-2014 15:35, John Miller wrote: On NS #2, if you run rndc freeze/rndc thaw, what does the actual zone file look like? Also, what does your cache look like? Is 101.250.168.192.in-addr.arpa PTR cached? John On Thu, Jul 24, 2014 at 10:25 AM, Ricardo Esteves maverick...@gmail.com wrote: Hi, I've got two bind9 servers, one master (192.168.2.251) and one slave (192.168.2.252). I've configured zone transfers, and after a change of a zone on the master, the slave gets the notification, downloads successfully the new zone file, but still has the old information in memory: nslookup 192.168.250.101 *192.168.2.251* Server:192.168.2.251 Address:192.168.2.251#53 *101.250.168.192.in-addr.arpaname = openerp-bold.xpto.com http://openerp-bold.xpto.com/.* nslookup 192.168.250.101 *192.168.2.252* Server:192.168.2.252 Address:192.168.2.252#53 *101.250.168.192.in-addr.arpaname = demoopenerp1.xpto.com http://demoopenerp1.xpto.com/.* -- Log on the slave: 24-Jul-2014 14:48:42.481 notify: info: client 192.168.2.251#61865: view vi_local_resolver: received notify for zone '250.168.192.in-addr.arpa' 24-Jul-2014 14:48:42.481 general: info: master 192.168.2.251#53 (source 192.168.2.252#0) deleted from unreachable cache 24-Jul-2014 14:48:42.482 general: debug 1: queue_soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 1: soa_query: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia 24-Jul-2014 14:48:42.482 general: debug 3: request_render 24-Jul-2014 14:48:42.482 general: debug 3: requestmgr_attach: 0x801f11170: eref 1 iref 1 24-Jul-2014 14:48:42.482 general: debug 3: mgr_gethash 24-Jul-2014 14:48:42.482 general: debug 3: req_send: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: dns_request_createvia: request 0x8037eaea8 24-Jul-2014 14:48:42.482 general: debug 3: req_senddone: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_response: request 0x8037eaea8: success 24-Jul-2014 14:48:42.483 general: debug 3: req_cancel: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_sendevent: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_getresponse: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 1: refresh_callback: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: serial: new 2014072417, old 2014070617 24-Jul-2014 14:48:42.483 general: debug 3: dns_request_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: req_destroy: request 0x8037eaea8 24-Jul-2014 14:48:42.483 general: debug 3: requestmgr_detach: 0x801f11170: eref 1 iref 0 24-Jul-2014 14:48:42.483 general: debug 1: queue_xfrin: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter 24-Jul-2014 14:48:42.484 general: info: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: Transfer started. 24-Jul-2014 14:48:42.484 general: debug 1: zone 250.168.192.in-addr.arpa/IN/vi_local_resolver: requesting IXFR from 192.168.2.251#53 24-Jul-2014 14:48:42.484 xfer-in: info: transfer of
Re: DNS slave not synced after successfully zone transfer
John Miller johnm...@brandeis.edu writes: On Linux, at least, nslookup is a deprecated tool: dig is better in many ways. In Windows, obviously, nslookup is all you#39;ve got by default :-(John in the latest Windows releases (8.1, 2012R2 Server), nslookup has been replaced by PowerShell Resolve-DnsName http://technet.microsoft.com/en-us/library/jj590781.aspx So even Windows Admins need to plan for a future without nslookup (which is a good thing, believe me). An there is dig for Windows as part of the BIND 9 for Windows package from ISC -- ftp://ftp.isc.org/isc/bi…-P2/BIND9.10.0-P2.x64.zip -- Carsten Strotmann Email: c...@strotmann.de Blog: dnsworkshop.org ___ 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
