Michael, I think you have confused the issue for John. There is nothing magic about the last two pieces of a domain name; a DNS server can assert it is authoritative for a domain name that has 3 or 4 or 5 pieces. (Examples are fairly common in TLDs that end in country codes; for example, here in the USA, someone is authoritative for ca.us but delegates various_things.ca.us to other authoritative servers; surely domains like co.uk work the same way.)
What he is trying to do is perfectly proper -- claim to be (locally) authoritative for the [sub-]domain mullan.dns2go.com, without also claiming to be authoritative for the larger domain dns2go.com. He should be able to do this, in principle. If he were using BIND, I'd be able to tell him how to do it; since he uses tinydns and dnscache, I can't give him the recipe, but if he can't do it, it is a limitation of the apps (either alone or working together), not a "feature" (or even a bug) of DNS. In a non-trivial sense, DNS is just a big lie. It works because we all agree to pretend that the same lie is true (by pointing our DNS servers to the same root servers). Or at least we do most of the time, and the exceptions tend to be on private networks, where any problems are hidden from the larger world. Or eccentrics like alternet (are they still around?), who try to popularize new TLDs by offering different root servers. This is a case where John should be able to tell his local machines a slightly different lie than the one we all agree on. If he can't do it, then either he is doing something wrong or the apps he is using are too inflexible. One low-tech solution that should work, BTW, is to add the hostname/IP address pair to the hosts file on each workatation (/etc/hosts for Linux workstations; I don't know the WinXX analog, though I do know there is one). Adding it to /etc/hosts on the Linux router should be enough for most apps actually running on the router itself to get it right -- the important exceptions are DNS and (usually) SMTP, apps that (usually) do not make use of the /etc/hosts file. As to tinydns, you suggest a candiate approach of >adding this: > > private.network > >to this: > > /etc/tinydns-private/env/DOMAINS I assume there is a typo in what you wrote, and that you meant to suggest adding "dns2go.com" rather than "private.network". If you are right that that would work, then so should adding "mullan.dns2go.com" ... only without the nasty side effects. But perhaps someone more expert than I with tinydns can comment; I am reasoning by analogy to what I would do with BIND. At 10:40 PM 6/6/02 -0500, Michael D. Schleif wrote: >John Mullan wrote: >[...] > > I'm sure I'm missing something, but no luck. I had tried to set it up > > so that dnscache watches 192.168.1.254 and looks to tinydns. Not sure > > if that is what is supposed to happen or if I even got it that way in > > any of my attempted combinations. >[...] > > To recap: The plan is to force internal network to resolve > > MULLAN.DNS2GO.COM to 192.168.1.128. External requests of course will > > already find their way to 192.168.1.128 via the INTERN_SERVERS in > > network.conf > > > > So any ideas? > >Actually, this is the way dns _should_ work -- you do *NOT* own the >domain dns2go.com, so dnscache will always look to the internet >nameservers for that domain. The real problem is that, even though your >dns queries _are_ being directed toward your external ip, *NO* port >forwarding is allowed from internal to external and back to internal ;> > >Now, if you really want to do what you say and if you do *NOT* care >about resolving anything else in the domain dns2go.com, you can try >adding this: > > private.network > >to this: > > /etc/tinydns-private/env/DOMAINS > >and then: > > svi tinydns restart > svi dnscache restart > >I cannot guarantee the results; but, it seems likely that you will be >telling dnscache that, indeed, you do have bailiwick for the domain >dns2go.com -- instead of that domain's rightful nameservers -- and you >maybe able to fool some of the people some of the time . . . > >I do _NOT_ recommend this approach, since I cannot know whether or not >this tomfoolery will lead to other, less impressive results. Instead, I >recommend that you tell your internal boxen to look for whatever >192.168.1.128's legitimate .private.network name really is . . . [...] -- -----------------------------------------------"Never tell me the odds!"-------------- Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] ------------------------------------------------------------------------------------------- _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
