DNS slave not synced after successfully zone transfer

Thu Jul 24 14:59:57 UTC 2014

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140724/4dbe0897/attachment-0001.html>