양지은 부재중 자동응답: RE: bind-users Digest, Vol 1896, Issue 2
NAVER - http://www.naver.com/ 양지은(jieun.yang@navercorp...) 님은 현재 부재중입니다./br 보내신 메일 bind-users Digest, Vol 1896, Issue 2 은 저장되어 있으므로 다시 보내실 필요는 없습니다./br 양지은(jieun.yang@navercorp...) 님이 남기신 메시지 입니다. 아카마이 유니버시티 Kona 과정 참석으로 인한 부재입니다.br급하신 용무는 유선연락부탁드립니다. ___ 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
Re: Process size versus cache size.
On Wed, Jul 23, 2014 at 02:15:34PM -0400, Thomas Schulz wrote: In investigating an out of memory error on a Solaris 8 Sparc machine (compiled as a 32 bit executable), I find that the process size increase due to the cache does not make sense. Over about a week the process size had grown to 257 MB, up from an initial size of 36 MB. But when I dumped the cache with rndc dumpdb -cache, the resulting named_dump.db file was only 6 MB in size. Given the way the file is formatted, I would expect that the in memory version would be smaller than that. But when I did a 'rndc flush', the process stopped growing for about the same number of days that it took to reach 257 MB. That indicates that the increase in process size really is due to the cache. The increase in process size from 36 MB to 257 MB does not make sense given that the cache dump is only 6 MB. What version of BIND is this? And do you use statistics-channel? I'd be interested to see what the memory stats look like on a running server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. I have tried both BIND 9.9.5-P1 and 9.9.6b1. The figures given above were for 9.9.6b1. I do not have a statistics-channel set up or anything having to do with logging set up. I have since rebuilt BIND as a 64 bit executable, so I expect that I will not have out of memory errors again. But I am seeing the same unexpected increase in process size. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ 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
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:
BUG report, BIND crash when dlz postgresql driver receives error from database server.
I attempted to submit this bug report via the online form, but that failed
(Failed to send your message. Please try later or contact the
administrator by another method.)
Bind, configured with dlz postgresql, successfully connects to the
database, but crashes (or corrupts the heap, randomly) on the very first
query submitted, if the find zone query receives a permission denied
error from Postgresql.
The problem goes away when I correct the permissions on the table. :)
However, BIND should not crash or corrupt its heap on a database query
error. I have not reviewed the DLZ postgresql driver code, but I suspect
that the error handler needs some tender loving care. :) Stack trace
included (see below):
CREATE TABLE dns_records
(
zone text,
host text,
ttl integer,
type text,
mx_priority integer,
data text,
resp_person text,
serial integer,
refresh integer,
retry integer,
minimum integer,
expire integer
)
WITH (
OIDS=FALSE
);
ALTER TABLE dns_records
OWNER TO pgsql;
(no additional grants, and BIND is configured to connect as the user/role
dns, which does NOT have select permission on the table (yet)).
Relevant bind config:
# http://bind-dlz.sourceforge.net/postgresql_example.html
# http://bind-dlz.sourceforge.net/postgresql_driver.html
dlz postgres zone {
database postgres 2
{host=REDACTED port=5432 dbname=dns user=dns}
{select zone from dns_records where zone = '$zone$'}
{select ttl, type, mx_priority, case when lower(type)='txt' then '\' ||
data
|| '\' else data end from dns_records where zone = '$zone$' and
host = '$record$'
and not (type = 'SOA' or type = 'NS')}
{select ttl, type, mx_priority, data, resp_person, serial, refresh,
retry, expire,
minimum from dns_records where zone = '$zone$' and (type = 'SOA' or
type='NS')}
{select ttl, type, host, mx_priority, data, resp_person, serial,
refresh, retry, expire,
minimum from dns_records where zone = '$zone$'}
{select zone from xfr_table where zone = '$zone$' and client =
'$client$'};
};
Below is a stack trace, followed by other relevant config bits.
(ran /usr/sbin/named -u named -g -d5 inside gdb, then send a request
for A aisd-7.test.local via dig):
24-Jul-2014 10:18:38.262 client 127.0.0.1#50111: UDP request
24-Jul-2014 10:18:38.262 client 127.0.0.1#50111: using view '_default'
24-Jul-2014 10:18:38.262 client 127.0.0.1#50111: request is not signed
24-Jul-2014 10:18:38.262 client 127.0.0.1#50111: recursion available
24-Jul-2014 10:18:38.262 client 127.0.0.1#50111: query
24-Jul-2014 10:18:38.262
Query String: select zone from dns_records where zone = 'aisd-7.test.local'
*** Error in `/usr/sbin/named': double free or corruption (!prev):
0x08168828 ***
Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7a3298f in raise () from /lib/libc.so.6
#2 0xb7a341a3 in abort () from /lib/libc.so.6
#3 0xb7a74115 in __libc_message () from /lib/libc.so.6
#4 0xb7a7a732 in malloc_printerr () from /lib/libc.so.6
#5 0xb7a7b490 in _int_free () from /lib/libc.so.6
#6 0xb7d40546 in PQclear () from /usr/lib/libpq.so.5
#7 0x080b3686 in postgres_findzone ()
#8 0xb7f06e82 in dns_sdlzfindzone () from /usr/lib/libdns.so.100
#9 0xb7e3d546 in dns_dlzfindzone () from /usr/lib/libdns.so.100
#10 0x0807cdb4 in query_getdb ()
#11 0x08082bc6 in query_find ()
#12 0x0808e701 in ns_query_start ()
#13 0x0806e91d in client_request ()
#14 0xb7d8f0d0 in isc__taskmgr_dispatch () from /usr/lib/libisc.so.95
#15 0xb7d93224 in evloop () from /usr/lib/libisc.so.95
#16 0xb7d939ea in isc__app_ctxrun () from /usr/lib/libisc.so.95
#17 0xb7d93e6d in isc__app_run () from /usr/lib/libisc.so.95
#18 0x08067c8d in main ()
(gdb) quit
mad-dns-3 net-dns # named -V
BIND 9.9.5 (Extended Support Version) id:f9b8a50e built by make with
'--prefix=/usr' '--build=i686-pc-linux-gnu' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--libdir=/usr/lib' '--sysconfdir=/etc/bind' '--localstatedir=/var'
'--with-libtool' '--enable-full-report' '--disable-threads' '--with-dlopen'
'--with-dlz-filesystem' '--with-dlz-stub' '--with-dlz-postgres'
'--without-dlz-mysql' '--with-dlz-bdb' '--without-dlz-ldap'
'--without-dlz-odbc' '--with-openssl=/usr' '--with-ecdsa' '--without-idn'
'--disable-ipv6' '--without-libxml2' '--disable-newstats'
'--without-gssapi' '--disable-rpz-nsip' '--disable-rpz-nsdname'
'--disable-linux-caps' '--without-gost' '--disable-filter-'
'--disable-fixed-rrset' '--disable-rrl' '--without-python'
'--without-readline' '--with-randomdev=/dev/random'
'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-O2
-march=i686 -pipe -I/usr/include/db4.8' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 4.7.3
using OpenSSL version: OpenSSL 1.0.1h 5 Jun 2014
mad-dns-3 ~ # dig @127.0.0.1 A aisd-7.test.local
; DiG 9.9.5
Re: BUG report, BIND crash when dlz postgresql driver receives error from database server.
Hi Dennis On Thu, Jul 24, 2014 at 10:51:00AM -0500, Dennis Jenkins wrote: Bind, configured with dlz postgresql, successfully connects to the database, but crashes (or corrupts the heap, randomly) on the very first query submitted, if the find zone query receives a permission denied error from Postgresql. Thank you for the bug report. I've forwarded it to our (internal) bug tracker. Mukund pgpb9Z4ZiowqT.pgp Description: PGP signature ___ 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
Re: One question about 'Stealth servers'
On 24.07.14 10:38, 许腾 wrote: As a beginner of BIND, I'm writing to ask one question about 'Stealth servers'. To avoid the access failures arising from the broken down of Authoritative Name servers, I'd like to run Stealth servers as back up. My question is how could I set the Stealth servers as non-priority so that these Stealth servers could not be accessed unless the Authoritative Name servers are broken down? The 'forward' configuration item could set the servers as priority, is there another configuration item could do the contrary thing? Looking forward to your reply! In what way are you going to use those stealth servers? If your recursive nameservers use ordinary resolution, they will never use stealth servers. If you point all stealth zones on your recursive servers to any servers, they will be used in semi-random order, not as primary-backup. If you load the zones on your recursive nameservers, they will use it locally. -- 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. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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
Re: One question about 'Stealth servers'
I know of no way to do this within BIND itself, but if you Anycast your nameservers, and carefully tweak route preferences and whatnot, you could ensure that some instances (call it set A) only get used if all of the members of another set of instances (call it set B) stop advertising the route(s). Of course, that only works if the box is sufficiently down that it stops advertising the route(s). Other failure modes (e.g. zone expired, misconfigured, busying out, nameserver process dead) wouldn't necessarily trigger failover at the routing level. If you want finer control, you'd probably have to use a dedicated load-balancer-type device. - Kevin On 7/23/2014 10:38 PM, 许腾 wrote: Dear all, As a beginner of BIND, I'm writing to ask one question about 'Stealth servers'. To avoid the access failures arising from the broken down of Authoritative Name servers, I'd like to run Stealth servers as back up. My question is how could I set the Stealth servers as non-priority so that these Stealth servers could not be accessed unless the Authoritative Name servers are broken down? The 'forward' configuration item could set the servers as priority, is there another configuration item could do the contrary thing? Looking forward to your reply! Best wishes, Teng ___ 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 ___ 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
Bind and ZSK-Rollovers: Changing salt automatically?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I read quite a bit on DNSSEC in the last couple of weeks, and found that BIND can automatically rollover the ZSK without manual intervention. I also found the recommendation, to change the NSEC3 salt each time the key is rolled over. What I did not find is, if BIND can also automatically change the salt each time it does a ZSK rollover. Cos that would be quite handy... Thanks in advance. Regards, Johannes - -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. (Benjamin Franklin, 1759) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlPRQ2IACgkQzi3gQ/xETbLdFACgizonyyL+xE4w8cEhH/j7wNGV iPEAni0dzUNcZsKhL1daU33o8tdjr659 =r3tG -END PGP SIGNATURE- ___ 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
Re: Bind and ZSK-Rollovers: Changing salt automatically?
Hello Johannes, Johannes Kastl m...@ojkastl.de writes: Hi everyone, I read quite a bit on DNSSEC in the last couple of weeks, and found that BIND can automatically rollover the ZSK without manual intervention. I also found the recommendation, to change the NSEC3 salt each time the key is rolled over. What I did not find is, if BIND can also automatically change the salt each time it does a ZSK rollover. Cos that would be quite handy... I'm not aware that BIND 9 can do a ZSK rollover all on its own, it is however possible to set the timing values on the ZSK key files in a away that BIND 9 will execute the rollover at the set times. It is also possible to create a direct successor ZSK from an existing ZSK. But the creation of the new ZSK, as well as setting the timing values, need to be done outside BIND 9. It is relaive strightforward to script this in a cron job, and there are ready-made tools that can help. In the same cron job, it is then possible to create a new NSEC3 salt and inject that into the zone. Doing so at the exact moment of the ZSK key rollover (to prevent unecessary re-generation of all RRSIGs) is tricky. If the zone is no too big (e.g. re-generating all RRSIGs is not a problem), I would recommend to roll the salt in the same intervals, but independent from the ZSK rollover. -- 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
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
Re: Bind and ZSK-Rollovers: Changing salt automatically?
Actually it is useless to change the salt regularly. Changing the salt provides no real benefit against discovering the names in a zone which is the reason people were saying to change the salt. The attacker uses cached NSEC3 records. When it gets a cache miss it asks the servers for the zone, puts the answer in the cache and continues. When the salt changes it just maintains multiple nsec3 chains eventually discarding the old nsec3 chain eventually. I would wait until the new NSEC3 chain has as many cached records as the old NSEC3 chain. Changing the salt slows things up miniminally for a very short period of time after the change. Additionally once you have some names you ask for those names for a non-exisisting type to quickly pull in part of the new NSEC3 chain you know exists. The only reason to change the salt is if you have a collision of the hashed names. This will be a very very very rare event. Mark In message 8661imr6cq@strotmann.de, Carsten Strotmann writes: Hello Johannes, Johannes Kastl m...@ojkastl.de writes: Hi everyone, I read quite a bit on DNSSEC in the last couple of weeks, and found that BIND can automatically rollover the ZSK without manual intervention. I also found the recommendation, to change the NSEC3 salt each time the key is rolled over. What I did not find is, if BIND can also automatically change the salt each time it does a ZSK rollover. Cos that would be quite handy... I'm not aware that BIND 9 can do a ZSK rollover all on its own, it is however possible to set the timing values on the ZSK key files in a away that BIND 9 will execute the rollover at the set times. It is also possible to create a direct successor ZSK from an existing ZSK. But the creation of the new ZSK, as well as setting the timing values, need to be done outside BIND 9. It is relaive strightforward to script this in a cron job, and there are ready-made tools that can help. In the same cron job, it is then possible to create a new NSEC3 salt and inject that into the zone. Doing so at the exact moment of the ZSK key rollover (to prevent unecessary re-generation of all RRSIGs) is tricky. If the zone is no too big (e.g. re-generating all RRSIGs is not a problem), I would recommend to roll the salt in the same intervals, but independent from the ZSK rollover. -- 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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
