> Hello everybody, Phew.. I *think* I can answer most of this. Please slap me around a bit if I get something wrong. :)
> I have installed Vegadns (Version 0.9.9) successful and added a local > Test Zone. > TLD: test.org Assumption #1. You don't "own" test.org. > When I ask tinydns with the dig command I get the correct results. Since > it is a local domain, I want my internal dnscache to query this domain. > The internal dnscache is also used by people to surf the internet. Thats right. I want that my users resolve the test.org [only for testing] to my own webserver. Since my people use the DNS Cache 192.168.10.2 for queries I have told dns cache to look up at the DNS Server 192.168.10.3 when they are want to know which IP is test.org. Assumption #2, you did a dig, specifying the name server to ask... I did a dig on the Machine that is running both instances, tinydns [192.168.10.3] and dnscache [192.168.10.2] by typing dig @192.168.10.3 www.test.org ; <<>> DiG 9.2.3 <<>> @192.168.10.3 www.test.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25753 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.test.org. IN A ;; ANSWER SECTION: www.test.org. 3600 IN A 192.168.9.29 ;; AUTHORITY SECTION: test.org. 3600 IN NS a.ns.test.org. ;; ADDITIONAL SECTION: a.ns.test.org. 3600 IN A 192.168.10.2 So, you can see the DNS Server has the data and providing the correct internal IP's. But first of all, let me clarify, why I want that. Assume you own godshell.com... ;-) [You own it I know..] then people get the IP Address 204.10.167.1 Then assume your in your DMZ WEB Server has a external and a internal IP. i.E. 204.10.167.1 external and 192.168.9.2 as internal. So you map your Firwall with a static entry to map 204.10.167.1 to 192.168.9.2. (one to one NAT) The people in the Lan should surf the domains you have hosted on the webserver with the internal IP Address, so you implement a DNS Resolver to look up Internet Hosts and in addition to that you set up a DNS Server that provides the users with that information. (Don't wont use Split Horizon/security issuns) As you probably know, dnscache looks into the servers directory if a file is existent for godshell.org. When it is, it asks the DNS that is listet in that file. > So I have to put test.org manually in the dnscache /root/servers with the > IP Address of tinydns. Since you do not own test.org, yes. If you owned it, that would be another story. In that case, you'd have to tell dnscache that the 192.168.10.0 subnet is being handled by your tinydns instance. I did that manually and it work fine. But it should done automatically because my people can not add every time they create a new Domain with Vegadns a manual entry in the dnscache file (they have no clue about Unix). > My question is now, is it possible when I create a TLD with Vegadns that > the program also write the TLD entry to the DNSCACHE, Sure. Anything's possible. Of course, you'll need to add some code to vega... Could it be done? Sure. Will it? Not so sure.. That's really up to Bill... OR.. you could write a patch to add it, submit the patch, and Bill could either integrate the patch, or make it available via his website.. Both, of course, are at his discretion.. > I tried the following thing... > > I want to teach the dnscache that he should first query the internal DNS > for all queries. So I put 192.168.10.3 into the @ file under the > dnscache /root/servers. But when I use my dnscache to query the test.org > domain I get not my internal IP address. I get the official IP Address > of it. This is not good. It seems that my internal dnscache do not ask > my internal dns server for the ip and go directly outside to the TLD > root DNS servers.... Ahh.. you fell prey to the "random root server" ... :) Just because you add your IP to the top of the root servers file doesn't mean it will be asked first. I'm not sure if the servers are used sequentially, storing the last server used in memory, or randomly. It does not, however, walk through the list. So, you have a chance of it being right each time the ttl expires and the cache looks the entry up again via the root server. Jup, unfortunately I know. I try it now with a forwarding cache, with several servers in @. That means I want instruct the dns cache first to ask the tinydns server, then the isp server. I keep you informed if I succeed. > So is there a possibility to tell dnscache to always query the internal > dns server and if this zone is not present, try to reach another DNS > Cache (i.e. my Provider's one). Hrm... Honestly, I'm not sure.. However, you are kind of breaking the rules here.. See, you don't own test.org.. So, why are you trying to serve dns for it? I can think of a number of reasons for this myself, and many of them are valid. However, I can't see this being a common practice. So, yes. You'll need to add this manually to each dnscache. But you shouldn't have to do it often since there are only a few instances where you'd want to do this sort of domain hijacking anyways... as described above... > Can I do that by modifying the update-data.sh? (I am not so good at > scripting so I tried it with the forward DNS Cache) Hrm.. Yes.. and no.. You'd have to have a list somewhere of the domains you want to add this way. Ultimately, it'd be nice to have vega store that in its database, but that would take some code changes... > Is this assumption right?... Many many questions... I know.... :-) Semi-right, yeah.. :) Questions are good.. They make ya think and show that you are thinking.. :) > Best, and thanks for reading this long posting No problem.. Did I answer everything? :) > Robert Thanks for your answer Do you know right now my situation? Best greetings Rob --------------------------- Jason 'XenoPhage' Frisvold Engine / Technology Programmer [EMAIL PROTECTED] RedHat Certified - RHCE # 803004140609871 MySQL Pro Certified - ID# 207171862 MySQL Core Certified - ID# 205982910 --------------------------- "Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming." __________ NOD32 1.1228 (20050921) Information __________ Diese E-Mail wurde vom NOD32 antivirus system geprüft http://www.nod32.com
