Entry

How do I run dnscache and tinydns on the same IP address?

May 30th, 2003 07:29
K W, Venkat Manakkal, Brian Coogan,

I have BIND running on 1.2.3.4, serving authoritative answers for 
moon.af.mil, and also acting as a proxy resolver for my network.
How do I replicate this configuration with djbdns?
Answer: You cannot replicate this configuration exactly. BIND 
conflates 
the functions of authoritative name service and proxy resolution into 
a 
single program. This has led to a large, insecure, unreliable 
codebase. 
djbdns keeps the functions in separate programs for security and 
reliability.
You must allocate another address for either tinydns or dnscache.  If 
you do not have any spare IP addresses, you can run one of the 
programs 
on another machine, if that machine is not already running a DNS 
server, or you can use a private address block such as 10.0.0.0/8 or 
192.168.0.0/16, possibly with NAT or IP masquerading, to gain more IP 
addresses.
-- Rob Mayoff
[Apparently this is not a recommended configuration for Bind in any 
case we need a reference for this, someone let me know or just update 
this for us).]
Note below added by Venkat Manakkal 2020/09/10
If you have given out the IP address of your BIND configuration and 
would like to keep the same IP address, you can achieve this effect by 
putting dnscache on 1.2.3.4 and tinydns on another IP address say 
1.2.3.10 which is (now) authoritative for moon.af.mil. You need to 
update your primary DNS pointer with the registrar of your domain (or 
the authoritative DNS for your subdomain). Now dnscache should cache 
all your new domain information and all hosts who use 1.2.3.4 should 
not see the difference (except during the transition). 
To minimize the effects of the transition, do the following: 1) Setup 
tinydns on 1.2.3.10 with authoritative info. 2) Update registrar to 
point to 1.2.3.10 3) After DNS information has been updated by the 
registrar (give a day or two), replace the BIND server on 1.2.3.4 with 
dnscache. 
A similar procedure can be followed by those using NAT with the 
"authoritative" nameserver on a private IP so long as tinydns is 
running on a real ip. If you do not have an extra real IP use one of 
the free DNS services such as granitecanyon.com for your 
"authoritative" data (no need for tinydns). Their example zone file 
shows you how to put in information on private IPs.
Venkat Manakkal
[Secondary recommendation by kjw on 2021.05.30]
Linux machines, and presumably most other machines will let you use
127.0.0.2, or allow you to create aliases to that effect.  This is an
excellent way to setup tinydns with a dnscachex "in front" of it.
I recommend configuring dnscachex for your public IP, and then
configuring tinydns for 127.0.0.2. (FYI, I also run dnscache on
127.0.0.1 for reliability; local host uses that one all for itself). 
Note that you do need to tell dnscache that for special domains, one
must talk to a specific name server, and not talk to the root servers. 
For example, for your internal 10.*.*.* addresses.  To do this:
sh
cd /service
for SVC in dnscache* ; do
    echo "127.0.0.2" >$SVC/root/servers/10.in-addr.arpa
    done
Yes, it is a little wasteful of resources to run a second dnscache on
127.0.0.1, but it'll get little use, and gives you the added reliability
of when you change the machine's ip you won't be completely without name
service while you fix up the rest of the machine.  I do wish that you
could bind dnscachex to multiple public IP's, though.
   - kjw