Sounds like I started something!! Just to add fuel to the fire (or more hopefully, slow it down), I do know that since 'mullan.dns2go.com' is a smaller 'chunk' of names to resolve that it is possible to have the server understand that DNS2GO.COM domain gets resolved out-of-house but MULLAN.DNS2GO.COM host doesn't. It kinda follows the IPFILTERing idea that IP chunks like 24.266.0.0/16 can come and visit but 24.226.2.123 cannot.
But anyway, enough of my newbie type visions..... I have made all the required changes. I even changed the network.conf. The variable you mention seems to be CONFIG_DNS=NO Resolv.conf still gets overwritten with 'nameserver 127.0.0.1' Further in the script (in the section marked 'requires CONFIG_DNS=YES') I made sure I changed the 127.0.0.1 entry to 192.168.1.254 and it still leaves my resolv.conf file without the 192.168.1.254 entry and puts in the 127.0.0.1. I did backup all packages (in case you were wondering :) There must be another spot in another script that changes this. I just don't know were to look. I have scanned the network.conf file for any other references to no avail. Also, I do not know how to 'reload' tinydns with the new info (to save rebooting and having files rewritten). John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Fritz Sent: Friday, June 07, 2002 6:38 PM To: Erich Titl Cc: [EMAIL PROTECTED] Subject: [leaf-user] Re: Using HOSTS file (was: leaf-user digest, Vol 1 #937 - 14 msgs) Boy, this seems to be the thread that never ends. :) I have to politely disagree on several of your statements, Erich. tinydns and dnscache config files for a working setup are included below as well. Re-quoted slightly for readability... On Fri, Jun 07, 2002 at 10:51:02PM +0200, Erich Titl wrote: > [EMAIL PROTECTED] wrote the following at 05:03 > 07.06.2002: jm> To recap: The plan is to force internal network to resolve jm> MULLAN.DNS2GO.COM to 192.168.1.128. External requests of course will jm> already find their way to 192.168.1.128 via the INTERN_SERVERS in jm> network.conf > You are trying to masq a HOST in a zone you don't own. This is critical to > your internal network because you will miss out all lot of unknown hosts in > the zone (unless you copy them all the time.) You are right about mullan.dns2go.com being a host (although it can also be a zone) and not owning the zone, but the part about missing out on resolution for the zone dns2go.com is not true. At least not if your internal name server is configured to be authorative for mullan.dns2go.com but to externally resolve queries for dns2go.com. For anyone who is curious, chapter 2 of "DNS and BIND" is posted at http://www.oreilly.com/catalog/dns3/chapter/ch02.html and does a good job of discussing hosts, domain names and zones. More comments and an example below... > As I pointed out in an earlier message you have to (somehow) _own_ the > zone. > For example if you _own_ the subdomain mullan.dns2go.com then you can place > any host you like into that subdomain, e.g. myhost.mullan.dns2go.com. Since we are talking about John's private network, I'm not sure how ownership is relevent. What is important is which name server you are using for the network and which [sub-]domains it resolves for, either via consulting internal data or by sending queries to othername servers. Also the "myhost" is unnecessary. Even though mullan.dns2go.com is a domain, it can have an A record (or a CNAME record) that allows address queries for mullan.dns2go.com to resolve to a numeric address. You can think of mullan.dns2go.com as a host in the mullan.dns2go.com domain. > This > way you are responsible for the entire mullan.dns2go.com namespace. But > imagine what happens if you put a _host_ mullan.dns2go.com at dns2go.com > DNS server and then override the dns2go.com zone in your own DNS server by > claiming authority (even just for internal use). How is your internal > client supposed to know that the host foodle.dns2go.com needs to be looked > up at dns2go.com whereas mullan.dns2go.com should be looked up on your > internal DNS server. The problem you describe would only happen if you misconfigure your name server to be locally authorative for "dns2go.com" rather than "mullan.dns2go.com". As proof, I've setup dnscache and tinydns on my notebook to illustrate: $ cat /etc/dnscache/env/IP 192.168.70.1 $ cat /etc/tinydns-private/env/IP 127.0.0.1 $ cat /etc/dnscache/root/servers/mullan.dns2go.com 127.0.0.1 $ cat /etc/dnscache/root/servers/70.168.192.in-addr.arpa 127.0.0.1 $ cat /etc/tinydns-private/root/data .70.168.192.in-addr.arpa:192.168.70.1 .mullan.dns2go.com:192.168.70.1 =mullan.dns2go.com:192.168.70.128 # let's make sure we're getting 192.168.70.128 for mullan.dns2go.com # on the private side of the horizon $ dig @192.168.70.1 +short mullan.dns2go.com 192.168.70.128 $ dig @192.168.70.1 +short -x 192.168.70.128 mullan.dns2go.com. # even though we get the real address on the public side of # the horizon $ dig @207.217.126.41 +short mullan.dns2go.com 24.150.100.156 # hmm... who else can we pick on on dns2go.com $ dig @192.168.70.1 +short jim.dns2go.com 12.248.236.251 As you can see I'm overriding the zone mullan.dns2go.com without resolution for other dns2go.com domain names. > I don't know if you can get an entire subdomain at dns2go or any other > dynamic dns provider. But you can always get your own domain which you can > park on one of the many dynamic DNS services which allow any doman name. Effectively he does. Even if publically mullan.dns2go.com does not have its own authorative name server, a properly configured internal name server can claim to be authorative for mullan.dns2go.com without affecting resolution of other dns2go.com domain names. --Brad > This is not really the direct answer to your question but watch out for > such a set up. > > Erich _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ------------------------------------------------------------------------ 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?source=osdntextlink ------------------------------------------------------------------------ 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
