Hi all, I'm running BIND 9.1.3 and the accompanying `dig and nslookup' on a vanilla Redhat 7.2 Linux box.

I've produced all of my Zone data and config files (I used h2n with some manual tweaks to do this, as some >= v8.2 BIND features aren't properly supported as far as I can see).

Im my resolv.conf I have I have the following 2 lines (the hostname is dns1a.company.com and it's IP address is 123.123.123.123):

domain company.com
namerserver 123.123.123.123

When I try to do a lookup, say`dig www.yahoo.com` I get the error message:

;; connection timed out; no servers could be reached

My question is this: is this error message refering to the fact that nslookup cannot find my newly-installed local named, or that it can't being querying *other* nameservers for information about www.yahoo.com

Any help would be appreciated. I'm here to learn, so hints would be helpful (although answers are always nice :-).

Thanks in advance... Sam.

nslookup would query all name servers in resolv.conf, if you have just your name server over there, then it means your server fails to resolve addresses

Perhaps I'm missing something fundemental to DNS name resolution here. If I've only got my own local Nameserver in the resolv.conf and that has no information about www.yahoo.com (or anything else for that matter), why does it not transcend all the way down to the root nameservers (which it knows about through the root hints file - the addresses are valid I can ping them) and get me a valid answer by issuing iterative queries to Nameservers until it finds an authoritative answer?

...Yeap, you're right. I guess something is wrong ether with DNS configuration (zone files are not loaded - check permitions for DNS directories) or with network configuration.

Good luck

Network is ok.There must be wrong with the configuration,Just the zone files and named.conf
Also you can verify if the named service is existing.

Thanks. At least I know where to start now. I presumed that h2n would give me some valid files but obviously not

I've located the source of the problem: IPCHAINS.

When I stop my firewalling on the Linux box local and remote DNS resolution are both fine.

My ipchains rules are as such (assuming that the IP address of my box is 123.123.123.123):

:input DENY
:forward DENY
:output ACCEPT

-A input -p icmp -j ACCEPT

# dns
-A input -d 123.123.123.123 53 -p udp -j ACCEPT
-A input -s 123.123.123.123 53 -p udp -j ACCEPT
-A input -d 123.123.123.123 53 -p tcp -j ACCEPT
-A input -s 123.123.123.123 53 -p tcp -j ACCEPT

# ssh
-A input -d 123.123.123.123 22 -p udp -j ACCEPT
-A input -s 123.123.123.123 22 -p udp -j ACCEPT
-A input -d 123.123.123.123 22 -p tcp -j ACCEPT
-A input -s 123.123.123.123 22 -p tcp -j ACCEPT

which in my mind would allow all ssh trafic (which it does) and all DNS traffic, regardless of whether it travelled over udp (usual) or tcp (rarely). The connection should also be allowed both ways, surely.

Can anyone spot any obvious mistakes? Thanks again.