What must I change in my fedora 8 dns server config files in order for it to access the internet?

My dns server is on a subnet with the following ip 192.168.110.1.  My dns server  needs to forward requests to the company dns at 192.168.1.1.  Currently my dns server is unable to reach the internet, what changes are necessary in my config files in order to correct this problem?

Hey,

Forwarders are set in Options:

options {
    listen-on port 53 { 127.0.0.1; 192.168.110.0/24; };
    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     { localhost; any; };
    recursion yes;
   forward only;    forwarders { 192.168.1.1; };
};

Setting "forward only" will tell your name server not to attempt to resolve queries using Root Hints (the "." zone) if the forwarder fails. If you prefer it to use the Forwarder, then fail back to root hints you would set "forward first".

HTH

Chris

Thanks Chris-Dent for the input.

 I will give it a try.

Chris-Dent

I made the addition to my named.conf file, unfortunately when I click on Firefox it still cant reach the Internet.  Do you have any other ideas I should try?

Firefox is a bit high up the chain for testing DNS :)

Does named load without ashowing errors? Depending on your system they might be in /var/log/messages.

You should have nslookup on the server, and possibly Dig as well. We can use those to see what it's up to (within reason).

I take it that at the moment you can't do "nslookup www.google.com" from that server? Assuming you've set it to use itself for DNS resolution in resolv.conf.

Chris

Chris,

I restarted the named service and then copied the log message below for you to see:

Jul 21 22:39:57 ccdc02 named[3162]: starting BIND 9.5.0-P1 -u named -t /var/named/chroot
Jul 21 22:39:57 ccdc02 named[3162]: found 1 CPU, using 1 worker thread
Jul 21 22:39:57 ccdc02 named[3162]: loading configuration from '/etc/named.conf'
Jul 21 22:39:57 ccdc02 named[3162]: the working directory is not writable
Jul 21 22:39:57 ccdc02 named[3162]: listening on IPv6 interface lo, ::1#53
Jul 21 22:39:57 ccdc02 named[3162]: listening on IPv4 interface lo, 127.0.0.1#53
Jul 21 22:39:57 ccdc02 named[3162]: listening on IPv4 interface eth0, 192.168.110.1#53
Jul 21 22:39:57 ccdc02 named[3162]: default max-cache-size (33554432) applies
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 127.IN-ADDR.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 254.169.IN-ADDR.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: D.F.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 8.E.F.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: 9.E.F.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: A.E.F.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: automatic empty zone: B.E.F.IP6.ARPA
Jul 21 22:39:57 ccdc02 named[3162]: default max-cache-size (33554432) applies: view _bind
Jul 21 22:39:57 ccdc02 named[3162]: command channel listening on 127.0.0.1#953
Jul 21 22:39:57 ccdc02 named[3162]: command channel listening on ::1#953
Jul 21 22:39:57 ccdc02 named[3162]: zone 0.in-addr.arpa/IN: NS '0.in-addr.arpa' has no address records (A or AAAA)
Jul 21 22:39:57 ccdc02 named[3162]: zone 0.in-addr.arpa/IN: loaded serial 0
Jul 21 22:39:57 ccdc02 named[3162]: zone 1.0.0.127.in-addr.arpa/IN: NS '1.0.0.127.in-addr.arpa' has no address records (A or AAAA)
Jul 21 22:39:57 ccdc02 named[3162]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Jul 21 22:39:57 ccdc02 named[3162]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: NS '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa' has no address records (A or AAAA)
Jul 21 22:39:57 ccdc02 named[3162]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Jul 21 22:39:57 ccdc02 named[3162]: zone localhost.localdomain/IN: loaded serial 0
Jul 21 22:39:57 ccdc02 named[3162]: zone localhost/IN: loaded serial 0
Jul 21 22:39:57 ccdc02 named[3162]: running

I've used both dig and nslookup but they time out.

I have moved the box to eliminate any other devices having an impact.  When I setup the box with 192.168.1.X IP address it doesn't have a problem accessing the internet.  When I change it to a different subnet such as 192.168.110.x it doesn't work.

The resolv.conf file contains the following:

search stx.rr.com
nameserver 127.0.0.1

I hope this helps.

Can you even route from your 110.x subnet to the 1.x subnet?

If you can, then it suggests you're falling foul of the same firewall rules that prevent Root Hints working on the server (that was your original configuration).

Chris

Chris,

I don't understand your question.

If your subnet mask is 255.255.255.0 then you will only be able to connect to devices on 192.168.110.x unless  you have a default gateway that knows the way to 192.168.1.x.

If you're going through a router or firewall it is possible you're running into port blocking that's stopping your server sending DNS traffic to the main DNS server.

It's also likely that the same firewall is blocking your outbound connection, preventing you from using Root Hints. It's something you need to discuss with your Network Admin, if that's not you :)

Chris

Network Admin - I'm it.

I don't have a router or firewall between my dns server and the main dns server, just a switch.

Is there a way to configure the DNS server to route the traffic from 192.168.110.x to 192.168.1.x?  With a 2k3 dns server I can configure routing on the server, add an extra nic and the problem is solved.  

Regarding the DNS Server performing the routing. It would have to have an interface on both networks, but if it has a connection on both networks it doesn't have to route (both are local).

Bear in mind that you don't even need a separate physical NIC in the above scenario, if both networks share the same infrastructure the server can host both IPs on the same interface.

Is there really a need to do this? What are you aiming to achieve here?

Chris

Chris

Are you monitoring the site right now?

Slightly behind, but yep.

Chris

Great!

I would like to walk through both options.  I've added a second NIC and assigned it a static IP 192.168.1.50 from the second network.  MY first NIC still has 192.168.110.1  When I run dig www.google.com I get a response in 37msec.  When I run dig @localhost www.google.com it times out.
My resolv.conf file has 127.0.0.1 as the nameserver.  What should I look at to get the second dig cmd to run?

Hmm interesting, there shouldn't have been a difference between the two there if you have that in resolv.conf.

Does it respond correctly when you run dig @ with each of the IPs bound to the server?

Chris

Sorry Chris, I made a mistake.  My resolv file had another nameserver.  I cleaned it out and ran several dig cmd's but none of them worked.  See the output below:

[root@ccdc02 ~]# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search stx.rr.com
nameserver 127.0.0.1
[root@ccdc02 ~]# dig www.google.com

; <<>> DiG 9.5.0-P1 <<>> www.google.com
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]# dig @localhost www.google.com

; <<>> DiG 9.5.0-P1 <<>> @localhost www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]# dig @192.168.1.50 www.google.com

; <<>> DiG 9.5.0-P1 <<>> @192.168.1.50 www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]# dig @192.168.110.1 www.google.com

; <<>> DiG 9.5.0-P1 <<>> @192.168.110.1 www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

Chris,  

Below you will find a printout of my named.conf file which contains the forward option you recommended

// named.caching-nameserver.conf
//
// Provided by Red Hat caching-nameserver package to configure the
// ISC BIND named(8) DNS server as a caching only nameserver
// (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// DO NOT EDIT THIS FILE - use system-config-bind or an editor
// to create named.conf - edits to this file will be lost on
// caching-nameserver package upgrade.
//

options {
        listen-on port 53 { 127.0.0.1; 192.168.110.0/24; };
        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     { localhost; any; };
        recursion yes;

        forward first;
        forwarders {
                24.93.41.127;
                24.93.41.128;
        };

};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";

I'd be tempted to say get rid of these first (which will default it to listening on all interfaces and ports):

        listen-on port 53 { 127.0.0.1; 192.168.110.0/24; };
        listen-on-v6 port 53 { ::1; };

Can you definitely reach the two forwarders from the server now? Should be able to test that with Dig too, dig @ each of the forwarders.

Chris

Chris,

When I add our ISP to the resolv file the dig www.google.com works but the others don't:

[root@ccdc02 ~]# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search stx.rr.com
nameserver 127.0.0.1
nameserver 24.93.41.127
[root@ccdc02 ~]# dig www.google.com

; <<>> DiG 9.5.0-P1 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20754
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         11544   IN      CNAME   www.l.google.com.
www.l.google.com.       163     IN      A       74.125.47.147
www.l.google.com.       163     IN      A       74.125.47.99
www.l.google.com.       163     IN      A       74.125.47.103
www.l.google.com.       163     IN      A       74.125.47.104

;; AUTHORITY SECTION:
l.google.com.           77104   IN      NS      e.l.google.com.
l.google.com.           77104   IN      NS      d.l.google.com.
l.google.com.           77104   IN      NS      a.l.google.com.
l.google.com.           77104   IN      NS      g.l.google.com.
l.google.com.           77104   IN      NS      b.l.google.com.
l.google.com.           77104   IN      NS      f.l.google.com.
l.google.com.           77104   IN      NS      c.l.google.com.

;; ADDITIONAL SECTION:
a.l.google.com.         16580   IN      A       209.85.139.9
b.l.google.com.         16580   IN      A       64.233.179.9
c.l.google.com.         16580   IN      A       64.233.161.9
d.l.google.com.         16580   IN      A       66.249.93.9
e.l.google.com.         16580   IN      A       209.85.137.9
f.l.google.com.         16580   IN      A       72.14.235.9
g.l.google.com.         12162   IN      A       64.233.167.9

;; Query time: 28 msec
;; SERVER: 24.93.41.127#53(24.93.41.127)
;; WHEN: Wed Jul 23 10:38:53 2008
;; MSG SIZE  rcvd: 340

[root@ccdc02 ~]# dig @localhost www.google.com

; <<>> DiG 9.5.0-P1 <<>> @localhost www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]#
[root@ccdc02 ~]#
[root@ccdc02 ~]# dig @192.168.1.50 www.google.com

; <<>> DiG 9.5.0-P1 <<>> @192.168.1.50 www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]# dig @192.168.110.1 www.google.com

; <<>> DiG 9.5.0-P1 <<>> @192.168.110.1 www.google.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[root@ccdc02 ~]#

Yeah, it's unable to make a port connection to your DNS Service. It's UDP so we can't check that with Telnet or anything like that.

I did wonder if it was just handing in something it didn't like for the listen-on filters. Or are those removed now?

I take it you have no errors for the DNS service in /var/log/messages?

Chris

Chris,

When I comment out both of those lines each of the commands work.  Whats going on?

I think it might be because it can't parse the Listen-On for the subnet. That's this one:

listen-on port 53 { 127.0.0.1; 192.168.110.0/24; };

Listen On defines interfaces to listen on rather than clients to listen to. To be honest I've never tried working with listen-on so I'm not quite sure if I'm right there.

The alternative is the server was attempting to connection with the source address as 192.168.1.x and wasn't having any luck with a return path from there (across the interfaces).

Chris

Chris,

When I remove just the 192.168.110.0-24 reference, the dig www.google.com and dig @localhost www.google.com both work.  However, the dig cmd's with the ip addresses don't.

Later I will research and experiment with the listen-on port 53 option in oder to better understand its functionality.

Moving on, with the lines commented out I can reach the internet from the dns server.  When I run dig @192.168.110.1 www.google.com from a client machine it works.  However, when I try to access the internet with Firefox it hangs.  

Any ideas?

Proxy Server configured on the client?

And perhaps try "telnet www.google.com 80". HTTP is TCP, so we can use Telnet to verify a Port connection like that. It'll give back a blank screen if it works. Type GET in there and it'll give you a 404 page or default page back (in raw HTML in the console).

If you can't connect it suggests Firewall rules are blocking access to the web.

Chris

I don't understand what you mean by Proxy Server configured on the client?

When I type the telnet command it states:

Trying 74.125.47.103 . .

After a while it times out and then tries another address.

When I go to System > Admin > Firewall it indicates that it is disabled.

Okay, forget the proxy server then, something is blocking your access. Try:

tracert 74.125.47.103

We need to see that it goes down the right network path. If it does, then you have a firewall either locally or on the borders of your network that's preventing it gaining access on TCP Port 80 (HTTP).

Chris

Chris

The command runs fine on the dns server, however it doesn't work on the client.

Okay, need to split the problem up a bit, because you have two :)

First the DNS bit. As long as the client can get a public IP address back from a name from your DNS server then that bit is working.

Then there's a potential network issue where you can't make outbound HTTP connections. That's going to be down to firewalling somewhere along the way (possibly at the border).

In many cases like this it's because a Proxy server is used. Then you'd block outbound HTTP connections from clients because you don't want them avoiding the Proxy server.

Chris

Chris,

On my DNS server I have 2 NIC cards.  One connected to my local network with an IP address of 192.168.110.1.  The other NIC is connected to the second network and has a 192.168.1.50.  Both NIC's have been configured to use 192.168.1.1 as the gateway, which is the address of my firewall/proxy server.

My client is configured with a 192.168.110.5 and points to my DNS server at 192.168.110.1

So, let me see if I understand this correctly, since my DNS has a foot in the 1.x network the firewall is allow port 80 traffic to and from the DNS server.  However, since my client is only in the 110.x network it can get an IP from the DNS server via the 110.x subnet but the firewall won't allow port 80 traffic to and from my client because its not in the 1.x subnet.

Thanks for all your help Chris.  I really appreciate the time you have given to my question.  I plan to continue to explore more of the DNS settings going forward.  

I hope you manage to get it all sorted out :)

Chris