DNS slave not synced after successfully zone transfer

Thu Jul 24 21:06:39 UTC 2014

+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 <lenm at 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 <johnmill at 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.pt at 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.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.pt at 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
> <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.arpa    name = 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 14:48:42.486 general: debug 1: zone_maintenance: zone
> 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
> 24-Jul-2014 14:48:42.486 general: debug 1: zone_dump: zone
> 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
> 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 1: zone_gotwritehandle: zone
> 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
> 24-Jul-2014 14:48:42.490 general: debug 1: dump_done: zone
> 250.168.192.in-addr.arpa/IN/vi_local_resolver: enter
> 24-Jul-2014 14:48:42.490 general: debug 3: zone
> 250.168.192.in-addr.arpa/IN/vi_local_resolver: dns_journal_compact: not
> found
>
> --------------------
>
> Anyone has any idea what could be wrong?
>
> Best regards,
> Ricardo Esteves.
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>
> --
> John Miller
> Systems Engineer
> Brandeis University
> johnmill at brandeis.edu
> (781) 736-4619
>
>
>
>
>
> --
> John Miller
> Systems Engineer
> Brandeis University
> johnmill at brandeis.edu
> (781) 736-4619
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>

-- 
John Miller
Systems Engineer
Brandeis University
johnmill at brandeis.edu
(781) 736-4619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140724/e0367c7e/attachment.html>