UPDATE: I have found where the changes to resolv.conf are coming from. Dhclient.conf and data coming from my ISP DHCP server.
I have managed to overide this behaviour with 'prepend' and 'supersede' and end up with a resolv.conf looking like this: search nimc1.on.cogeco.ca nameserver 192.168.1.254 nameserver 216.221.81.53 nameserver 24.226.1.47 nameserver 24.226.1.90 I'm still trying different things though...... 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
