Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Within oblivion.tsp I am trying to setup a vps (using openVZ) as a caching nameserver and local DNS for my network following this article as a guide.
Code:
192.168.10.100 dns.tsp
All machines can ping each other via ip no problems.
dns.tsp has my isp's nameserver listed within its /etc/resolv.conf file while oblivion.tsp has the nameserver listed as 192.168.10.100
I am able to ping domains outside of my network (ie google) without any issue from oblivion.tsp.
However, trying to ping dns.tsp, firewall.tsp or any other machine on my network (by name) fails (unknown host).
Here are the files that make up my bind configuration on dns.tsp (they vary slightly from the guide because that is how debian etch has them setup by default).
named.conf
Code:
include "/etc/bind/named.conf.options";
// reduce log verbosity on issues outside our control
logging {
category lame-servers { null; };
category cname { null; };
};
// 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";
// added by thorpe
allow-update {
none;
};
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// add local zone definitions here
include "/etc/bind/named.conf.local";
I'll leave out db.root as it is maintained by InterNIC and is (as far as I'm aware) fine.
db.local
Code:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
db.127
Code:
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
named.conf.local
Code:
zone "tsp" IN {
type master;
file "db.tsp";
};
zone "10.168.192.in-addr.arpa" {
type master;
file "db.192.168.10";
};
db.tsp
Code:
$ORIGIN tsp.
$TTL 1D
@ IN SOA dns hostmaster (
200803132 ; serial
8H ; refresh
4H ; retry
4W ; expire
1D ; minimum
)
NS dns
localhost A 127.0.0.1
dns A 192.168.10.100
firewall A 192.168.10.1
oblivion A 192.168.10.2
toshi A 192.168.10.6
Ive looked around in /var/log but don't seem to be able to find any log file. If anyone can see any discrepancies or has any ideas it would be much appreciated. Thankyou.
I must confess that I did not read the entire article you referred to as your guide; perhaps there is something there that led you into extra complexity.
As far as I can see, your machine oblivion has the address 192.168.10.2. If it is to function as a local cacheing nameserver, then the other machines on your local net need the following resolv.conf content
Code:
nameserver 192.168.10.2
This will inform these machines that they need to consult oblivion for resolution of names that they cannot resolve themselves.
The rest of your config files look like they should be correct. You can always check whether that is true with the program nslookup on oblivion. That program will let you see the results of various DNS queries, aimed at particular DNS servers. I recommend starting it up, issuing the command
Code:
>nameserver 192.168.10.2
and seeing what the named daemon can resolve. It should be able to resolve not only the names in your local net, but also names like www.google.com.
Ok, thanks for the replies. Firstly, no there are no iptables rules enabled on any of these machines.
quote]As far as I can see, your machine oblivion has the address 192.168.10.2. If it is to function as a local cacheing nameserver, then the other machines on your local net need the following resolv.conf content[/quote]
Its not oblivion (the hardware node) I want configured as the dns but dns.tsp (192.168.10.100) which is a VE within oblivion.
Ive logged in and issued an nslookup, here is the result.
Well, the nslookup output is pretty explicit: it says that the server you are talking to has no idea about the address 192.168.10.100. That is not very surprising, since the server you are talking to (203.0.178.191) is not your cacheing nameserver (that would be 127.0.0.1), but some server out on the Internet. Public Internet routers are all set up to prohibit access to 192.168.x.y addresses, since those are a reserved block used exclusively for Private Networking; your network address translation, wherever it occurs, allows you to use these addresses locally. But no public DNS server is going to admit to knowing anything about such an address.
So the first problem is that oblivion (or the virtual whatever within it) needs to have its resolv.conf altered, so that it uses 127.0.0.1 as the nameserver. Then the experiment that you reported will give us some information that we can actually use to see if it is doing what your config files indicate.
Then, as I recommended in my last post, if you log onto a different machine and want to see what that machine's view of the resolution is, you start nslookup on that machine, and explicitly tell it to use 192.168.10.100 for consultation, by first giving the nameserver command to nslookup. Then that machine will subsequently report on what it hears from your daemon, rather than from wherever it normally gets its DNS replies. You can ask for either forward or reverse resolution, depending on whether you next input a text string or an IP address. I recommend the fine manpage for further reading.
By taking this stepwise approach, you can establish how much of the resolution is working the way it should, and then as a last step change the clients so that they use the (newly debugged) nameserver in their resolvers.
First make sure that you are really using your local dns as your default dns and not other foreign dns like your ISP dns then make sure you have configured your domain properly.
btw can you try to remove this from your db.tsp?
Code:
localhost A 127.0.0.1
restart your dns server then do
# dig dns.tsp.
# dig firewall.tsp. @dns.tsp.
show us the output if you like
Last edited by konsolebox; 03-14-2008 at 01:26 AM.
Sorry, just realised its not working. I still had firewall.tsp listed in oblivions /etc/hosts file, got a little excited.
Ok, so what I have done. I have removed my isp's nameserver from dns.tsp's /etc/resolv.conf file, replacing it with 127.0.0.1. I have also removed this....
Code:
localhost A 127.0.0.1
line form db.tsp and restarted the server. Here are the outputs of the dig commands, firstlt ran from oblivion.tsp then again from dns.tsp.
Code:
thorpe@oblivion ~ # sudo dig dns.tsp.
; <<>> DiG 9.3.4 <<>> dns.tsp.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11087
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dns.tsp. IN A
;; AUTHORITY SECTION:
. 3460 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2008031400 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 192.168.10.100#53(192.168.10.100)
;; WHEN: Sat Mar 15 11:38:48 2008
;; MSG SIZE rcvd: 100
thorpe@oblivion ~ # sudo dig firewall.tsp. @dns.tsp.
dig: couldn't get address for 'dns.tsp.': not found
thorpe@oblivion ~ #
Code:
root@dns / # dig dns.tsp.
; <<>> DiG 9.3.4 <<>> dns.tsp.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23413
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dns.tsp. IN A
;; AUTHORITY SECTION:
. 3182 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2008031400 1800 900 604800 86400
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Mar 15 11:43:26 2008
;; MSG SIZE rcvd: 100
root@dns / # dig firewall.tsp. @dns.tsp.
dig: couldn't get address for 'dns.tsp.': not found
root@dns / #
It appears from the DiG reports that there is some strangeness associated with your virtual whatever (which I still have not fathomed any reason for). When you actually got a response (for the name dns.tsp), you got it from a server responding to the address 192.168.10.100 (presumably DiG figured out to ask this address from your /etc/resolv.conf setup, maybe with some help from /etc/hosts). But when you asked it to speak explicitly to the server dns.tsp and ask for resolution of another name, that failed because DiG could not resolve the server name according to what was in /etc/resolv.conf.
So I stand corrected: you should not be using 127.0.0.1 as the nameserver address, but should rather be using 192.168.10.100. See if that does not solve your problem. And then I would recommend reviewing the reasons that led you to set up a virtual environment around a nameserver in the first place. It appears that this is causing you headaches, and I see no particular benefit. A nameserver is pretty much confined in what it can do by its configuration file; if you want extra protection against breakins, the chroot scheme has been proved to work pretty well without any change to how the rest of the operating system deals with the nameserver.
Oh well, free advice is worth every penny you pay for it.
seems to me that you're able to connect to your local dns but the local dns doesn't seem to have a data about your *.tsp. Probably it's a misconfiguration in your named.conf or your dns zonefiles that your local dns bypassed your files. this also happened to me before.
Code:
file "db.tsp";
file "db.192.168.10"
shouldn't these two in your named.local be something like
I created the two zone files "db.tsp" and "db.192.168.10" using copy/paste to a FC6 based test server running bind. I also appended the correspnding zone entries from the OP named.conf to the test servers named.conf file. After starting named, all queries for tsp and 192.168.10.x SOA, PTR, NS and A records worked fine. So the zone files and zone entries in named.conf are correct.
Based on the results above, I would check the following:
1) On server 192.168.10.100, /etc/resolv.conf should point to 127.0.0.1
2) On all other hosts, /etc/resolv.conf should point to 192.168.10.100
3) I have never used debian, so I do not know how they configure named to start (chroot'd or not). But I would check file permissions on the zone files db.tsp and db.192.168.10. On my test system, these files must be owned by named.named (owner.group). Otherwise they will not load.
4) Make sure the zone files are in the proper location. Based on the posted options file and the way you have the file name listed in the zone definition for tsp and 192.168.10 (relative to directory specifed in options section), it looks like they need to be in "/var/cache/bind"
5) Check /var/log/messages (or whatever file it is on debian) for named entries on startup
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.