Re: [leaf-user] Using HOSTS file
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
Re: [leaf-user] Using HOSTS file
Ray Olszewski wrote (on Thu, Jun 06, 2002 at 11:38:09PM -0700): | 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). For windows 9x: \windows\hosts For NT, 2000, XP: \winnt\system32\drivers\etc\hosts Format is the same as /etc/hosts. -- _ Nachman Yaakov Ziskind, EA, LLM [EMAIL PROTECTED] Attorney and Counselor-at-Law http://yankel.com Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants ___ 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
Re: [leaf-user] Using HOSTS file
At 12:07 AM 6/6/02 -0500, guitarlynn wrote: On Wednesday 05 June 2002 21:54, John Mullan wrote: I have tried that as well. It allows the LEAF box to resolve mullan.dns2go.com to 192.168.1.128 (by using PING on the LEAF box) but nobody else on the network. They still get the external IP as resolved by DNS2GO's servers. By chance have any of you attempted to declare files before dns in /etc/nsswitch.conf??? By doing this, any host/network listed in nsswitch.conf should resolve according to the order listed in this .conf file. This change affects ONLY host resolution by the router itself, and John reports that it already works fine. Jeff's response is the right one here -- the router (or some other host on the LAN) needs to run a DNS server that resolves FQNs of hosts on the LAN to their private addresses and forwards all other requests to a real nameserver. The LAN hosts then need to be told (via manual setup or DHCP or whatever) to use that nameserver for their DNS inquiries. In practice, I find it easier here to do all of this on a host separate from my router ... but my DNS requirements are elaborate enough to call for using full-size BIND. -- ---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
RE: [leaf-user] Using HOSTS file
Hi At 09:33 06.06.2002, you wrote: Message: 9 From: John Mullan [EMAIL PROTECTED] To: 'Lee Kimber' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: [leaf-user] Using HOSTS file Date: Wed, 5 Jun 2002 22:54:53 -0400 At 08:38 PM 6/5/2002 -0400, you wrote: I use DNS2GO to handle my dynamic IP for the benefit of the outside world (one day I'll register my own domain). But for now, if anyone in the internal network trys to browse mullan.dns2go.com it won't work (of course). What I would like is for the LEAF box to recognize this DNS request and translate it to the internal IP (192.168.1.128). Can anyone tell me how to do this? I thought it might be the HOSTS file but that doesn't seem to work. You will have to implement your own DNS server to do that. This is not a trivial task because you don't own DNS2GO. It might be better to register your own domain and then you can basically do with it what you want. For exampe I own think.ch, it is hosted at zoneedit.com, but for my internal network I override it with my own DNS server. regards THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 ___ 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
Re: [leaf-user] Using HOSTS file
On Thu, 06 Jun 2002 00:09:38 PDT Ray Olszewski wrote: Jeff's response is the right one here -- the router (or some other host on the LAN) needs to run a DNS server that resolves FQNs of hosts on the LAN to their private addresses and forwards all other requests to a real nameserver. The LAN hosts then need to be told (via manual setup or DHCP or whatever) to use that nameserver for their DNS inquiries. In practice, I find it easier here to do all of this on a host separate from my router ... but my DNS requirements are elaborate enough to call for using full-size BIND. If you want to do it on your LEAF router, it's not *too* bad to setup using tinydns and dnscache. One setup that has worked for me is to run tinydns bound to the router's loopback interface and dnscache bound to the internal interface. Files in /etc/dnscache/root/servers/ are used to point dnscache to tinydns for the internal hosts. The names and addresses of those hosts (or just your firewall, if that's all you need) are set in /etc/tinydns-private/root/data. If you decide to pursue the tinydns/dnscache setup and need more detail or have specific questions, let me know (on-list) and I'll do my best to answer. The djbdns docs and the Bering tinydns.lrp and dnscache.lrp documents[1,2] might also be useful even if you are using a LEAF variant other than Bering. --Brad [1] http://leaf.sourceforge.net/devel/jnilo/tinydns.html [2] http://leaf.sourceforge.net/devel/jnilo/dnscache.html ___ 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
Re: [leaf-user] Using HOSTS file
On Thursday 06 June 2002 02:09, Ray Olszewski wrote: At 12:07 AM 6/6/02 -0500, guitarlynn wrote: By chance have any of you attempted to declare files before dns in /etc/nsswitch.conf??? By doing this, any host/network listed in nsswitch.conf should resolve according to the order listed in this .conf file. This change affects ONLY host resolution by the router itself, and John reports that it already works fine. Jeff's response is the right one here -- snip You're are right thx. for the correction. I don't know what I was thinking ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ 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
RE: [leaf-user] Using HOSTS file
OK Brad. I've put tinydns on. I left the tinydns option for internal IP at 127.0.0.1 Is this the proper loopback interface address? -Original Message- From: Brad Fritz [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 4:42 AM To: John Mullan Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Using HOSTS file On Thu, 06 Jun 2002 00:09:38 PDT Ray Olszewski wrote: Jeff's response is the right one here -- the router (or some other host on the LAN) needs to run a DNS server that resolves FQNs of hosts on the LAN to their private addresses and forwards all other requests to a real nameserver. The LAN hosts then need to be told (via manual setup or DHCP or whatever) to use that nameserver for their DNS inquiries. In practice, I find it easier here to do all of this on a host separate from my router ... but my DNS requirements are elaborate enough to call for using full-size BIND. If you want to do it on your LEAF router, it's not *too* bad to setup using tinydns and dnscache. One setup that has worked for me is to run tinydns bound to the router's loopback interface and dnscache bound to the internal interface. Files in /etc/dnscache/root/servers/ are used to point dnscache to tinydns for the internal hosts. The names and addresses of those hosts (or just your firewall, if that's all you need) are set in /etc/tinydns-private/root/data. If you decide to pursue the tinydns/dnscache setup and need more detail or have specific questions, let me know (on-list) and I'll do my best to answer. The djbdns docs and the Bering tinydns.lrp and dnscache.lrp documents[1,2] might also be useful even if you are using a LEAF variant other than Bering. --Brad [1] http://leaf.sourceforge.net/devel/jnilo/tinydns.html [2] http://leaf.sourceforge.net/devel/jnilo/dnscache.html ___ 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
Re: [leaf-user] Using HOSTS file
On Thu, 06 Jun 2002 20:40:25 EDT you wrote: OK Brad. I've put tinydns on. I left the tinydns option for internal IP at 127.0.0.1 Is this the proper loopback interface address? Yes, it is: $ cat /etc/tinydns-private/env/IP 127.0.0.1 --Brad ___ 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
RE: [leaf-user] Using HOSTS file
Thanks for you help so far Brad.. 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. If it helps, here are some configuration extracts, both what they are and what I have tried.. DNSCACHE: LRP Internal192.168.1.254 tried 127.0.0.1 Query Hosts 192.168 tried 127.0.0.1 FORWARDONLY NO tried YES TINYDNS: TypePRIVATE kept PRIVATE Internal DNS127.0.0.1 kept 127.0.0.1 Data records .1.168.192.in-addr.arpa::localhost +myrouter.private.network:192.168.1.254 =mullan.dns2go.com:192.168.1.254 Resolv.conf is.. search nimc1.on.cogeco.ca tried 127.0.0.1 and private.network nameserver 127.0.0.1no changes nameserver 216.221.81.53no changes nameserver 24.226.1.47 no changes nameserver 24.226.1.90 no changes Even when I did change resolv.conf it gets rewritten when I reboot. 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? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Fritz Sent: Thursday, June 06, 2002 9:13 PM To: John Mullan Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Using HOSTS file On Thu, 06 Jun 2002 20:40:25 EDT you wrote: OK Brad. I've put tinydns on. I left the tinydns option for internal IP at 127.0.0.1 Is this the proper loopback interface address? Yes, it is: $ cat /etc/tinydns-private/env/IP 127.0.0.1 --Brad ___ 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 ___ 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
Re: [leaf-user] Using HOSTS file
John Mullan wrote: Thanks for you help so far Brad.. 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. If it helps, here are some configuration extracts, both what they are and what I have tried.. DNSCACHE: LRP Internal192.168.1.254 tried 127.0.0.1 Query Hosts 192.168 tried 127.0.0.1 FORWARDONLY NO tried YES TINYDNS: TypePRIVATE kept PRIVATE Internal DNS127.0.0.1 kept 127.0.0.1 Data records .1.168.192.in-addr.arpa::localhost +myrouter.private.network:192.168.1.254 =mullan.dns2go.com:192.168.1.254 Resolv.conf is.. search nimc1.on.cogeco.ca tried 127.0.0.1 and private.network nameserver 127.0.0.1no changes nameserver 216.221.81.53no changes nameserver 24.226.1.47 no changes nameserver 24.226.1.90 no changes Even when I did change resolv.conf it gets rewritten when I reboot. 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 . . . hth -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ 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
Re: [leaf-user] Using HOSTS file
On Thu, 06 Jun 2002 23:01:43 EDT you wrote: Thanks for you help so far Brad.. Glad to help. 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. That's the approach that I am using. internal hosts - dnscache - tinydns for vmware.priv - tinydns for .70.168.192.in-addr.arpa - root DNS servers all other domains I had it setup under LEAF, but currently I am only running that configuration on my notebook. A masq'd set of vmware clients on 192.168.70.0/24 is my equivalent to your internal 192.168.1.0/24 net. If it helps, here are some configuration extracts, both what they are and what I have tried.. DNSCACHE: LRP Internal 192.168.1.254 tried 127.0.0.1 192.168.1.254 is correct. That allows the internal clients to reach dnscache. Query Hosts 192.168 tried 127.0.0.1 192.168 is correct, allowing hosts 192.168.*.* to access dnscache. FORWARDONLY NO tried YES NO is probably what you want. YES would be used to forward all of your requests to a single server, e.g. an upstream caching name server. TINYDNS: Type PRIVATE kept PRIVATE Internal DNS 127.0.0.1 kept 127.0.0.1 Both correct. Data records .1.168.192.in-addr.arpa::localhost +myrouter.private.network:192.168.1.254 =mullan.dns2go.com:192.168.1.254 I think there are two problems here. First: =mullan.dns2go.com:192.168.1.254 ^^^ should probably be =mullan.dns2go.com:192.168.1.128 ^^^ since you say mullan.dns2go.com is supposed to point to your web server at 192.168.1.128. Second: According to http://cr.yp.to/djbdns/tinydns-data.html, you need to add a line like .mullan.dns2go.com:192.168.1.254 to create a NS record that says 192.168.1.254 is the name server for mullan.dns2go.com. Otherwise, tinydns will ignore queries for mullan.dns2go.com. After making these adjustments and running the tinydns-data command[1], check to see if tinydns is working as expected. Ideally, you'd run dig @127.0.0.1 mullan.dns2go.com or an equivalent nslookup command. Since you probably don't have dig available on the leaf box, you can temporarily comment out all the nameserver lines in /etc/resolv.conf execpt for the one with 127.0.0.1 and ping mullan.dns2go.com. Ping should report the address for mullan.dns2go.com as 192.168.1.128. If it doesn't something is still wrong with the tinydns configuration. Once tinydns is resolving mullan.dns2go.com and 192.168.1.128 properly, you'll need to make sure dnscache has files /etc/dnscache/root/servers/mullan.dns2go.com /etc/dnscache/root/servers/1.168.192.in-addr.arpa with the text 127.0.0.1 in them to point dnscache to tinydns to resolve those domains. Not sure about the leaf packages, but there is a /etc/tinydns-private/env/DOMAINS file in the version I am using that automatically creates them when from /etc/init.d/tinydns when tinydns is started is restarted. Resolv.conf is.. search nimc1.on.cogeco.ca tried 127.0.0.1 and private.network nameserver 127.0.0.1 no changes nameserver 216.221.81.53 no changes nameserver 24.226.1.47no changes nameserver 24.226.1.90no changes You'll probably want the router to use dnscache to resolve names, so the first nameserver line should use 192.168.1.254. tinydns on 127.0.0.1 won't reply to queries for domains other than mullan.dns2go.com and 1.168.192.in-addr.arpa so you don't want to use it directly. You can keep the external nameserver lines if you want to use your ISPs name servers when 192.168.1.254 doesn't reply. Even when I did change resolv.conf it gets rewritten when I reboot. Sounds like Dachstein. There are variables in /etc/network.conf that control the nameserver 127.0.0.1 line and whether or not the other nameserver lines are added when the DHCP server hands them out. I don't remember the variable names off-hand, but the variable names and inline comments should make them obvious. 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? Hope the comments above help. The first step is to get tinydns working right, then move on to dnscache, and then the configuration of the machines in your LAN (if they don't already use 192.168.1.254 for name service). If you can't get tinydns or dnscache working, describe how they are failing and your configuration files and we should be able to get it worked out. --Brad [1] I'm not using tinydns on leaf, but I
RE: [leaf-user] Using HOSTS file
I have tried that as well. It allows the LEAF box to resolve mullan.dns2go.com to 192.168.1.128 (by using PING on the LEAF box) but nobody else on the network. They still get the external IP as resolved by DNS2GO's servers. John -Original Message- From: Lee Kimber [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 10:18 PM To: John Mullan Subject: Re: [leaf-user] Using HOSTS file I think you need /etc/network.conf - the main network config script. Looks for some lines about two thirds of the way down that deal with hosts and private.domain (unless you have changed it to something else already) The commented out host1 is an example of what you are looking for. At 08:38 PM 6/5/2002 -0400, you wrote: I use DNS2GO to handle my dynamic IP for the benefit of the outside world (one day I'll register my own domain). But for now, if anyone in the internal network trys to browse mullan.dns2go.com it won't work (of course). What I would like is for the LEAF box to recognize this DNS request and translate it to the internal IP (192.168.1.128). Can anyone tell me how to do this? I thought it might be the HOSTS file but that doesn't seem to work. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* John Mullan http://mullan.dns2go.com/ Personal: mailto:[EMAIL PROTECTED] Business: mailto:[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 ___ 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
RE: [leaf-user] Using HOSTS file
On Wed, 5 Jun 2002, John Mullan wrote: I have tried that as well. It allows the LEAF box to resolve mullan.dns2go.com to 192.168.1.128 (by using PING on the LEAF box) but nobody else on the network. They still get the external IP as resolved by DNS2GO's servers. Do a search on split dns ... you need to point your internal systems to a tinydns or BIND server inside your network. It becomes authoritative within that scope and intercepts dns requests from your internal machines and feeds back what you want them to use. tinydns/dnscache is a common team on LEAF routers for this. The private.domain thing in network.conf feeds into internal configuration on the router... it is not fed to the clients on the internal network. John -Original Message- From: Lee Kimber [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 10:18 PM To: John Mullan Subject: Re: [leaf-user] Using HOSTS file I think you need /etc/network.conf - the main network config script. Looks for some lines about two thirds of the way down that deal with hosts and private.domain (unless you have changed it to something else already) The commented out host1 is an example of what you are looking for. At 08:38 PM 6/5/2002 -0400, you wrote: I use DNS2GO to handle my dynamic IP for the benefit of the outside world (one day I'll register my own domain). But for now, if anyone in the internal network trys to browse mullan.dns2go.com it won't work (of course). What I would like is for the LEAF box to recognize this DNS request and translate it to the internal IP (192.168.1.128). Can anyone tell me how to do this? I thought it might be the HOSTS file but that doesn't seem to work. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* John Mullan http://mullan.dns2go.com/ Personal: mailto:[EMAIL PROTECTED] Business: mailto:[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 ___ 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 --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ 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
Re: [leaf-user] Using HOSTS file
On Wednesday 05 June 2002 21:54, John Mullan wrote: I have tried that as well. It allows the LEAF box to resolve mullan.dns2go.com to 192.168.1.128 (by using PING on the LEAF box) but nobody else on the network. They still get the external IP as resolved by DNS2GO's servers. By chance have any of you attempted to declare files before dns in /etc/nsswitch.conf??? By doing this, any host/network listed in nsswitch.conf should resolve according to the order listed in this .conf file. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ 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
