Scott wrote: > > Thanks for the thorough explanation.
No problemo. Some days I'm good. Other days.... not so good :) > I should clarify the reason for the > external IP which I added to the private dns data. 216.254.0.36 is the > ISP's webserver which hosts many different domains (including ours). > Before I added it to the private data file nobody internally could resolve > www.domainx.com. Nobody internally could resolve www.domainx.com because the ISP's dns that is responsible for your web server name lookups is not configured correctly. You must make the fixes on that end or the world will have the same problem. Do this: dig @isp.dns.ser.ver www.domainx.com That will force the dig program to talk to isp.dns.ser.ver which is your ISPs primary DNS ip address. Dig will get the information for www.domainx.com from the very system that is responsible for serving that info up to the world. If that doesn't work, the world will have the same trouble getting www.domainx.com resolved. I know this is important for you. I have ftp.schalit.net mapped on secondary.com to my external nic's ip address. When I had no entry for ftp.schalit.net in tinydns-private, and I did a dig ftp.schalit.net from my internal LAN, I would get the external IP returned from secondary.com. But when I put ftp.schalit.net in tinydns-private, my LAN digs for ftp.schalit.net were returned by tinydns as internal private IP as they should be. The same applies to you. If you don't have www.domainx.com in tinydns-private, then the lookup will be recursed out to the internet to find the name. If the name can't be found on the internet, the lookup fails (it did) because the internet dns config is wrong. That's my point. Fix the internet dns first. The world needs to be able to get the correct IP address for www.domainx.com. If they can't, nobody's going to find you. Like I said, try it or let us try out your dns. Don't be scarrrred, mister :) *Then* worry about aliasing names so that your internal net gets internal ip's and not the external nic ip. Don't try to make your internal net use the external nic to get back to an internally based www server (and do the loop de loop). It's not meant to work that way. >I added it and now they can resolve it correctly. A decent crutch, but the symptoms of great disarray :) > I have a vague idea why this happens, but I'm not dns-literate enough to go > into full detail. I expect it's because the tinydns server thinks it's in > charge of resolving all hosts of domainx.com. A good thought, but only would come into play if your name lookup left off the .domainx.com part and was only like this: dig www ping www Then .domainx.com would be automatically appended to www and a match searched for. But you specified the whole ip so this wasn't the reason your crutch worked. It worked because there was a mapping in the tinydns-private database for that exact name, www.domainx.com. Tinydns will return whatever address was next to it without checking that address for validity. > When I pinged www.domainx.com without the entry in tinydns I got the > result "ping: unknown host www.domainx.com", even though it exists. > Tinydns has no reason to look beyond it's own DNS data for hosts of > domainx.com because (I'm guessing here) it thinks it's the last > authority on that domain. I am figuring that you are using dachstein and tinydns in the usual way where you use dnscache also and the entire internal LAN is told to use the LEAF internal nic ip address as the LAN nameserver. All lookups go to the LEAF dnscache and tinydns, and anything those can't resolve are recursed out to the net. If your internal LAN is all told to use your ISPs dns instead, then how does it know to do any lookups to tinydns? It wouldn't. Tinydns is most likely your dns server for the lan, and it is built to recurse to the internet any name it doesn't know. Host not found is only returned if the internet can't find the hostname to ipaddress mapping, evidence of a broken ISP dns config. But you tell me how your lan gets names resolved exactly. > Anyway, it works with the entry for www, but I'd like to know a more robust > way in case I have only 1 internal address to resolve and 100 external. Could you explain that in detail. What do you want it to do and how do you forsee your network layout? It sounds like you want tinydns to start acting as tinydns-public, listening on eth0? If you're wondering how to list 100 computers that are all on the 192.168.1.0 network and robustly serve them to the internal LAN, then just put 100 '=' type listings in tinydns-private. > Is there a way I can forward un-resolvable names on domainx.com to another > mailserver? Highly illogical :) Try your question again. > btw, I'm paranoid about everything so please excuse my use of > a generic domain name. It doesn't really matter for this discussion anyway. Ok, just don't post someone else's ip address, like that ernie.speakeasy.net stuff. That's not fair to them. Regards, Matthew _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
