Description of problem: Some domains are not resolved on rhel5. For example: uci.cu Version-Release number of selected component (if applicable): bind-9.3.3-10.el5 How reproducible: dig uci.cu => returns "SERVFAIL" on rhel5 / bind-9.3.3-10.el5 Succeeds on any other platform ( rhel4 for instance ) Steps to Reproduce: 1. install caching-nameserver-9.3.3-10.el5 2. set resolv.conf to go to 127.0.0.1 3. dig uci.cu Actual results: ; <<>> DiG 9.3.3rc2 <<>> uci.cu ;; global options: printcmd ;; connection timed out; no servers could be reached Expected results: ; <<>> DiG 9.3.3rc2 <<>> uci.cu ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27898 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;uci.cu. IN A ;; AUTHORITY SECTION: uci.cu. 7598 IN SOA ns1.uci.cu. jorge.uci.cu. 200802 1800 28800 3600 2419200 10800 Additional info: This is not a firewall issue. 2 Serveurs behind the same firewall, one running rhel5, the other rhel4, the one running rhel5 can not resolv this domain, the one running rhel4 has no issue getting answers. I reproduced the problem with xen kernel, x86_64 kernel and i386 kernels
Are you able to query root servers from affected machine? (Try dig @a.root-servers.net uci.cu for example). Also please try comment out query-source and query-source-v6 options in /etc/named.caching-nameserver.conf and if this doesn't help try set "edns-udp-size 512;" option. System log will also help, would it be possible to attach it, please?
Created attachment 297420 [details] dig @a.root-servers.net uci.cu Here is the result of the query to the root name servers
Dig root nameservers: Attachment #297420 [details] Commenting out: "query-source port 53" solved the problem! edns-udp-size 512; => Did not solve the problem edns-enable no; => Did not solve the problem No particuliar error message in system log or named.run. When running tcpdump, it just looks like no answer packet is coming back after the queries. The "query-source" trick did solve the issue, so I suppose this is not a bug in bind itself, but on the firewall configuration on the other side? Thanks anyway, xx
There were bug opened for same issue (https://bugzilla.redhat.com/show_bug.cgi?id=209954) but we never discover where exactly problem is. I expect some misconfigured router or firewall somewhere which drops packets with source port 53. If you find where exactly problem is please write comment here. Closing as notabug