If BIND is successfully restarting, it's probably not a syntax error. Given there's no forwarders you should be getting a NXDOMAIN instead of a SERVFAIL error. What changes did you make to your root hints file?
You can always increase the log level of bind, restart it, try a few queries and se if it prints anything more descriptive to /var/log/messages. More info on that process
Hello thmnetwork i also tried every main logging option and run named daemon with different debug level but nothing working.
I took one root dns server for testing
=> ping 198.41.0.4(root server) is working
=> dig -t A google.com@198.41.0.4 is working
=> named daemon is running
but not working local
dig -t A google.com@127.0.0.1 +trace (not working)
error no server could be reached
Now i think forwarders is the last option to use bind
The purpose of changing the logging levels is to generate more information for you to go off of. It won't (by itself) fix your problem, just point you in the right direction.
This is actually a different error than you were getting before. This is stating that it's not able to connect to the DNS server at all, whereas before you were able to connect to the DNS server it was just giving you a "SERVFAIL" error message.
It sounds like when you did a restart it shut down but didn't start back up properly. Is "named" in the line for port 53 if you do a "netstat -tuapn" ?
Some additional info via query-errors category log i.e set to debug
11-Jan-2013 23:57:40.773 query-errors: debug 1: client 192.168.3.10#44507 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:6733
11-Jan-2013 23:57:40.824 query-errors: debug 2: fetch completed at resolver.c:3218 for google.com/A in 10.051159: timed out/success [domain:.,referral:0,restart:1,qrysent:13,timeout:12,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
---------- Post updated 01-12-13 at 05:58 AM ---------- Previous update was 01-11-13 at 01:30 PM ----------
Hello thmnetwork
Now i understand the main problem
My ISP redirecting all 53 port traffic to thier dns server , they are forcing the user to use
thier dns server , it does not matter whether i use forwarders or not
I guess it would depend on how they're blocking it. On my home setup I have the following configuration:
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
recursion yes;
forwarders { 209.18.47.61; 209.18.47.61; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "trunkator.com." IN {
type master;
file "forwards/trunkator.com";
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "reverses/trunkator.com";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
The 209.* forwarders are the DNS servers for my ISP. The net effect is that a query for any zone for which it doesn't consider itself authoritative for (trunkator.com and it's reverse zone) it will forward to my ISP's DNS servers. The DNS requests to the ISP is identical to the type they would have to be supporting anyways so they don't have any criteria by which to differentiate the traffic.