Thanks for the thorough explanation. 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. I added it and now they can resolve it correctly.
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. 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. 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. Is there a way I can forward un-resolvable names on domainx.com to another mailserver? 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. Matt Schalit said: > Scott Ecker wrote: >> >> Actually, I just figured it out. I had to restart dnscache to clear >> out the invalid IP from before. I'd appreciate any other input if >> anyone sees a way I can clean up my rules or something. >> >> -Scott >> > > > Ok. Comments inline.... > > > >> -----Original Message---------------------------------------------- > >> I have been having trouble with tinydns on DCD 1.0.2. I installed >> tinydns.lrp, djbutils.lrp (do I need this?) and dnscache.lrp. My >> private DNS server data file looks like this: >> >> .domainx.com::ns1.domainx.com >> .1.168.192.in-addr.arpa::ns1.domainx.com >> =firewall.domainx.com:192.168.1.1 > > > What's the ip address of the DCD firewall? 192.168.1.1? > > >> +ns1.domainx.com:127.0.0.1 > > Very nice, very nice. > > > >> +mail.domainx.com:192.168.1.254 >> +intranet.domainx.com:192.168.1.254 > > > Change both those to start with an = rather than a +. > The = sign make tinydns create name-to-address and > address-to-name mappings. With +'s you only get > name-to-address mappings. > > Proof: Go to one of your internal LAN computers > and run dig or host: > > host 192.168.1.254 > dig -x 192.168.1.254 > > > will not return mail.domainx.com unless you use > the = sign as I mention. > > > > >> +www.domainx.com:216.254.0.36 (added later) > > What is this ip address? Is it your external IP address? > Your tinydns-private is responsible for this zone: > >> .domainx.com::ns1.domainx.com >> .1.168.192.in-addr.arpa::ns1.domainx.com > > and you're the one who made that so. Given that fact, > you can't expect your 216.any.th.ing entry to be correct. > Lost it. That zone is handled by somebody else: > > $ host 216.254.0.36 > 36.0.254.216.IN-ADDR.ARPA domain name pointer ernie.speakeasy.net > > apparently ns1.speakeasy.net and ns2.speakeasy.net. > Fix that. You want something that distributes your > name lookups across two different name serving systems. > Here's an example where I use granitecanyon and > secondary.com. That way if one goes down, I can still > resolve my domain name via the other company. > > > schalit.net. 12H IN NS ns1.granitecanyon.com. > schalit.net. 12H IN NS ns2.secondary.com. > schalit.net. 12H IN NS ns2.granitecanyon.com. > schalit.net. 12H IN NS ns1.secondary.com. > > > >> which Is based on the template at jnilo's tinydns page >> (http://leaf.sourceforge.net/devel/jnilo/tinydns.html). > > > There was a thread here about the = sign. I figured > he would have updated his docs to reflect that. Not > critical, but certainly important. > > > >> mail.domainx.com >> and intranet.domainx.com are hosted behind the firewall. I have >> entered the interal address so that clients inside can resolve them. >> However, they suddenly are unable to resolve www.domainx.com which is >> hosted off-site, so I put in an entry for that. > > > > See above. Offsite dns went down and you had both primary > and secondary name servers run by the same company putting > you at risk of this exact problem. > > Regards, > Matthew > > > >> After doing a /etc/init.d/tinydns restart they >> still can't resolve www. The results of restarting tinydns: >> >> Stopping private DNS server listening on 127.0.0.1 without >> daemontools... Starting private DNS server listening on 127.0.0.1 >> without daemontools >> >> What am I doing wrong here and how do I fix it? >> >> -Scott > > _______________________________________________ > Leaf-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
