LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 10-27-2007, 06:08 AM   #1
Jim44
Member
 
Registered: Feb 2006
Location: Atlanta, Georgia, USA
Distribution: Mint, Ubuntu, Centos
Posts: 52

Rep: Reputation: 15
Bind isn't forwarding my requests


I have a home network with a half dozen systems. I am trying to configure a bind server on one of them and it resolves all the local hosts fine, but it seems to have a problem forwarding the requests it can't resolve.

I have a Westell DNS modem followed by a Linksys router. The Westell at address 192.168.1.254 is resolving the dns requests externally and if I use it in my resolv.conf then all is well. The bind server is on 192.168.2.8 and the forwarder info in named.conf.options looks like:

forwarders {
# Replace the address below with the address of your providerís DNS server
192.168.1.254;
};

This is a ubuntu edgy server installation. If I attempt to resolve an external address from the .8 system, it sometimes finds it and sometimes doesn't. If I attempt to resolve an external address from another system on the 19.2168.2 network it only finds it if the .8 system has found it previously. Obviously it is cached. Also it takes a long time to resolve external references on the .8 system, when it is successful.

dpkg -l | grep bind
ii bind9 9.3.2-2ubuntu3 Internet Domain Name Server
ii bind9-host 9.3.2-2ubuntu3 Version of 'host' bundled with BIND 9.X
ii libbind9-0 9.3.2-2ubuntu3 BIND9 Shared Library used by BIND

I used this as a guide:
http://www.howtoforge.com/perfect_setup_ubuntu_6.10_p4

Any suggestions would be appreciated.

Thanks,
Jim
 
Old 10-27-2007, 02:16 PM   #2
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
I would suggest you not forward to your Westell modem. That is just another step in the chain, and a very unnecessary one at that.

Sign onto the Westell if you can, and see what DNS addresses it uses. It is 99.9% likely to just forward to your ISPs DNS servers, and you'll get their addresses off the Westell's page. Set that as your forwarder, or skip forwarding altogether (which is what I would do), and simply use your server to query down to the roots.

There could be many issues causing slowness, but I bet the multiple ask and tells that need to happen (Westell to ISP DNS, your server to Westell, client computer to your server) is part of the issue.

If you want help with the speed, please post the full named.conf file, (hide the rndc key if it has one in there) and any zones, like the forward and reverse for the 192.168.2 network.

Peace,
JimBass
 
Old 10-28-2007, 06:19 AM   #3
Jim44
Member
 
Registered: Feb 2006
Location: Atlanta, Georgia, USA
Distribution: Mint, Ubuntu, Centos
Posts: 52

Original Poster
Rep: Reputation: 15
Just to make things clear, the slowness is on the bind system and I'm not concerned about the slowness just yet. I'd really like to get the remote systems to be able to resolve host names without first manually resolving them on the bind server.

If I do a nslookup, ping, dig or whatever on another system (not the bind server) it comes back immediately with an unknown host name message or words to that effect, so nothing is even attempting to resolve the name.

Here are the pertinent files I hope:

named.conf

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };

// From the release notes:
// Because many of our users are uncomfortable receiving undelegated answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the "root-delegations-only" feature which applies delegation-only
// logic to all top level domains, and to the root domain. An exception list
// should be specified, including "MUSEUM" and "DE", and any other top level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";


named.conf.local

//
// Do any local configuration here
//
zone "localdomain.org" {
type master;
file "/etc/bind/zones/localdomain.org.db";
};

zone "2.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/rev.2.168.192.in-addr.arpa";
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

named.conf.options

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

// forwarders {
// 0.0.0.0;
// };
forwarders {
# Replace the address below with the address of your providerís DNS server
192.168.1.254;
};

auth-nxdomain no; # conform to RFC1035

// By default, name servers should only perform recursive domain
// lookups for their direct clients. If recursion is left open
// to the entire Internet, your name server could be used to
// perform distributed denial of service attacks against other
// innocent computers. For more information on DDoS recursion:
// http://cve.mitre.org/cgi-bin/cvename...=CVE-2006-0987

allow-recursion { localnets; };

// If you have DNS clients on other subnets outside of your
// server's "localnets", you can explicitly add their networks
// without opening up your server to the Internet at large:
// allow-recursion { localnets; 192.168.0.0/24; };

// If your name server is only listening on 127.0.0.1, consider:
// allow-recursion { 127.0.0.1; };

};

/etc/bind/zones/localdomain.org.db

$TTL 86400
localdomain.org. IN SOA bind9.localdomain.org. ns.localdomain.org. (
2007031001
28800
3600
604800
38400
)

localdomain.org. IN NS bind9.localdomain.org.

gw IN A 192.168.2.1
ns IN A 192.168.2.8
www IN A 192.168.2.50
bind9 IN A 192.168.2.8
dev25 IN A 192.168.2.25
blackie IN A 192.168.2.90
asterisk IN A 192.168.2.51
dom50 IN A 192.168.2.102
image33 IN A 192.168.2.33


/etc/bind/zones/rev.2.168.192.in-addr.arpa

$TTL 86400 ; 1 day
@ IN SOA bind9.localdomain.org. ns.localdomain.org. (
2007031001;
28800;
604800;
604800;
86400
)

NS ns.localdomain.org.

1 PTR gw.localdomain.org.
25 PTR dev25.localdomain.org.
90 PTR blackie.localdomain.org.
51 PTR asterisk.localdomain.org.
102 PTR dom0.localdomain.org.
33 PTR image33.localdomain.org.
8 PTR ns.localdomain.org.
8 PTR bind9.localdomain.org.

8 IN PTR localdomain.org


Thanks for the help.

Jim.
 
Old 10-28-2007, 10:26 AM   #4
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
Quote:
I'd really like to get the remote systems to be able to resolve host names without first manually resolving them on the bind server.
That's not possible. That's like saying, "I'd like to go three houses down the street, but not go past the second." The BIND server has to be able to resolve and cache the answer for the domain before it can be pushed on to the client.

The line that I don't like in your configs is this:
Code:
allow-recursion { localnets; };
I just checked google, and it seems to think that is ok. Since the localnets are never defined as an acl, I don't see how the server can do that. All my machines know localhost is 127.0.0.1, but not a single one of them has a definition or address for localnets. It makes sense that it would be anything on the same subnet as the server, but that isn't defined anywhere. I'd replace the localnets; with { 192.168.2.0/24; localhost; }; that should do what the localnets directive is intending. Once that is done, please see if the server can dig remote sites, and then if the other computers on the LAN can either dig (if linux) or nslookup (if other) domains that you wouldn't have cached.

I still suggest that you not forward to your westell. That is a backbreaker. Just comment out the forward line completely, and then your servers will go to the roots and work up.

Peace,
JimBass
 
Old 10-28-2007, 10:58 AM   #5
Jim44
Member
 
Registered: Feb 2006
Location: Atlanta, Georgia, USA
Distribution: Mint, Ubuntu, Centos
Posts: 52

Original Poster
Rep: Reputation: 15
OK I did as you suggested and it all seems to work as advertised. I've learned something today. BTW, I use nslookup and dig both on Linux. I know dig is preferred, but having come from SunOS, SOlaris and Irix I still remember the old ways.

Thanks until you're better paid!

Jim.
 
Old 10-28-2007, 11:15 AM   #6
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
No problem man, I'm glad I was able to help.

I know plenty of folks who still prefer nslookup to dig, largely because it gives an answer quickly, and the output is small. I've had plenty of dig queries return screens and screens of info, but if all I want is an IP address, it is overkill. Also for programs, it is much easier to cut the output of nslookup and "just get your answer."

All that being said, when I'm troubleshooting, dig all the way. The excessive output very much helps in those cases.

Peace,
JimBass
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
stopping dns forwarding requests in BIND shreeram.vk Linux - Server 3 07-10-2008 06:40 AM
BIND9 not forwarding DNS requests lordbressers Linux - Server 8 05-19-2007 12:06 AM
Forwarding dhcp requests through a Linux router fr_laz Linux - Networking 1 05-19-2005 08:14 AM
Port Forwarding not working for Internal requests angelgw Linux - Networking 2 06-29-2003 12:42 AM
BIND Forwarding rules Infamous Tim Linux - Networking 1 10-27-2001 06:07 AM


All times are GMT -5. The time now is 03:55 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration