On 3/8/13 2:04 AM, Steven Carr wrote: > I'm having the same issues with zone transfers timing out, but I can > perform queries directly to the RPZ servers, so there is nothing wrong > from the network/firewall side of things. > > sjcarr@elmo:~ $ dig +vc 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org > @199.168.90.51 > > ; <<>> DiG 9.8.3-P1 <<>> +vc > 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org @199.168.90.51 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13663 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org. IN A > > ;; ANSWER SECTION: > 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org. 0 IN CNAME . > > ;; Query time: 100 msec > ;; SERVER: 199.168.90.51#53(199.168.90.51) > ;; WHEN: Fri Mar 8 00:56:46 2013 > ;; MSG SIZE rcvd: 77
This shows you're at least allowed to contact their server on TCP. What do you see if you run the axfr query manually *and* run a packet capture for it? Does the TCP handshake happen or not? If yes, maybe the problem could be caused by an MTU blackhole along the path, or something similar... _______________________________________________ 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
