Answer: This answer assumes that your boot scripts are already running svscan in a /service directory. tinydns relies on svscan to start it and to restart it at boot time.
You will have to make three decisions:
tinydns-conf tinydns dnslog /etc/tinydns 1.2.3.5Tell svscan about the new service:
ln -s /etc/tinydns /servicesvscan will start the service within five seconds.
Now tell tinydns to answer questions about the heaven.af.mil and 3.2.1.in-addr.arpa domains, and to advertise 1.2.3.5 as the DNS server address for each domain:
cd /service/tinydns/root ./add-ns heaven.af.mil 1.2.3.5 ./add-ns 3.2.1.in-addr.arpa 1.2.3.5 makeYou can also add host addresses and mail-server addresses, as described below.
Finally, tell the administrator of af.mil to delegate heaven.af.mil to the server a.ns.heaven.af.mil running on IP address 1.2.3.5. Similarly, tell the administrator of 2.1.in-addr.arpa to delegate 3.2.1.in-addr.arpa to the server a.ns.3.2.1.in-addr.arpa running on IP address 1.2.3.5.
Answer:
cd /service/tinydns/root ./add-host lion.heaven.af.mil 1.2.3.4 ./add-host tiger.heaven.af.mil 1.2.3.5 ./add-host bear.heaven.af.mil 1.2.3.6 makeThe ./add-host scripts edit the file /service/tinydns/root/data, which is in tinydns-data format. make runs the tinydns-data program to tell tinydns about the new information. If anything goes wrong, tinydns-data prints an error message, and tinydns continues providing the old information.
As an alternative to ./add-host, you can edit data manually, adding the following lines:
=lion.heaven.af.mil:1.2.3.4 =tiger.heaven.af.mil:1.2.3.5 =bear.heaven.af.mil:1.2.3.6But the ./add-host scripts will prevent you from accidentally reusing a previous host name, or reusing a previous host IP address. They're also very careful in how they write the new file to disk, so nothing can go wrong if there's a sudden power outage.
Answer:
cd /service/tinydns/root ./add-alias www.heaven.af.mil 1.2.3.4 makeAs an alternative to add-alias, you can edit data manually, adding the following line:
+www.heaven.af.mil:1.2.3.4
Answer:
cd /service/tinydns/root ./add-mx heaven.af.mil 1.2.3.4 make(mx stands for ``mail exchanger.'') As an alternative to add-mx, you can edit data manually, adding the following line:
@heaven.af.mil:1.2.3.4:aIf you add several mail servers for heaven.af.mil, use a for the first, b for the second, etc. add-mx handles this automatically.
Answer: First, use tinydns-conf to configure tinydns on 1.2.3.6:
tinydns-conf tinydns dnslog /etc/tinydns 1.2.3.6 ln -s /etc/tinydns /service
Next, use your favorite file-management tools in /service/tinydns/root/Makefile on 1.2.3.5 so that changes in /service/tinydns/root/data.cdb are automatically copied to 1.2.3.6:
remote: data.cdb rsync -az -e ssh data.cdb 1.2.3.6:/service/tinydns/root/data.cdb data.cdb: data /usr/local/bin/tinydns-data
Now tell tinydns about the new server:
cd /service/tinydns/root ./add-ns heaven.af.mil 1.2.3.6 ./add-ns 3.2.1.in-addr.arpa 1.2.3.6 make
Finally, tell the administrator of af.mil to add a delegation of heaven.af.mil to the server b.ns.heaven.af.mil running on IP address 1.2.3.6. Similarly, tell the administrator of 2.1.in-addr.arpa to add a delegation of 3.2.1.in-addr.arpa to the server b.ns.3.2.1.in-addr.arpa running on IP address 1.2.3.6.
Answer: It is essential for your parent servers and your child servers to provide the same names for your child servers. Otherwise you will encounter a disastrous bug in BIND caches around the Internet; a BIND cache that receives a nasty sequence of queries, accidentally or deliberately, will then be unable to contact your servers for a few days.
You can edit data manually to match the names provided by your parent servers:
.heaven.af.mil:1.2.3.5:dns1.heaven.af.mil .heaven.af.mil:1.2.3.6:dns2.heaven.af.milOmit the IP addresses for dns1 and dns2 if they appear elsewhere in data:
.heaven.af.mil::dns1.heaven.af.mil .heaven.af.mil::dns2.heaven.af.mil +dns1.heaven.af.mil:1.2.3.5 +dns2.heaven.af.mil:1.2.3.6
Answer:
cd /service/tinydns/root ./add-childns elysium.heaven.af.mil 1.2.3.144 makeAs an alternative to add-childns, you can edit data manually, adding the following line:
&elysium.heaven.af.mil:1.2.3.144:aIf you delegate heaven.af.mil to several IP addresses, use a for the first, b for the second, etc. add-childns handles this automatically.
Answer: If the parent server did
./add-childns 144.3.2.1.in-addr.arpa 1.2.3.144 ./add-childns 145.3.2.1.in-addr.arpa 1.2.3.144then you should do
cd /service/tinydns/root ./add-ns 144.3.2.1.in-addr.arpa 1.2.3.144 ./add-ns 145.3.2.1.in-addr.arpa 1.2.3.144 maketo create the lines
.144.3.2.1.in-addr.arpa:1.2.3.144:a .145.3.2.1.in-addr.arpa:1.2.3.144:ain /service/tinydns/root/data.
Beware that your parent server might instead have done RFC 2317 ``classless'' reverse delegation, sending all of your reverse domains through a single delegation:
C144.3.2.1.in-addr.arpa:144.144-145.3.2.1.in-addr.arpa C145.3.2.1.in-addr.arpa:145.144-145.3.2.1.in-addr.arpa &144-145.3.2.1.in-addr.arpa:1.2.3.144:a # or, in BIND master zone-file format: # 144.3.2.1.in-addr.arpa. CNAME 144.144-145.3.2.1.in-addr.arpa. # 145.3.2.1.in-addr.arpa. CNAME 145.144-145.3.2.1.in-addr.arpa. # 144-145.3.2.1.in-addr.arpa. NS a.ns.144-145.3.2.1.in-addr.arpa. # a.ns.144-145.3.2.1.in-addr.arpa. A 1.2.3.144In this case your data file should contain lines such as
.144-145.3.2.1.in-addr.arpa:1.2.3.144:a ^144.144-145.3.2.1.in-addr.arpa:phoenix.elysium.heaven.af.mil ^145.144-145.3.2.1.in-addr.arpa:bogey.elysium.heaven.af.milNormally ^ lines are unnecessary, because they are automatically generated by = lines, but classless reverse delegation breaks this feature.
Answer: DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. Most sites have no need to provide TCP service and should not set it up.
You will need to provide TCP service if you are allowing zone transfers, or if your registrar foolishly checks for TCP service, or if you want to provide record sets over 512 bytes (which won't work with most clients anyway).
To set up TCP service without allowing zone transfers, configure axfrdns with the following line in /etc/axfrdns/tcp:
:allow,AXFR=""axfrdns will answer TCP queries from the same database as tinydns.
Answer: BIND's nslookup program has many problems with non-recursive servers, no matter what software the servers are using. For example, nslookup doesn't work with the root servers:
% nslookup -type=soa com. a.root-servers.net *** Can't find server name for address 198.41.0.4: No information *** Default servers are not availableThis failure is a combination of three nslookup mistakes:
The nslookup user can work around this problem by typing
nslookup server a.root-servers.net set type=soa com. exitinstead of nslookup -type=soa com. a.root-servers.net. But it's easier to avoid nslookup and type dnsq soa com a.root-servers.net.
Answer: One site reported receiving 500 queries per second per server at peak times for data from a 350-megabyte data.cdb. The tinydns process handled an average query in about 0.00014 seconds of CPU time. The CPU is a Pentium III-550.
This example, and lab tests, suggest that tinydns can easily handle the .com server load. However, I don't have enough data on the distribution of .com queries to carry out a realistic experiment.
Answer: No time at all. tinydns starts answering queries immediately. It loads data from disk on demand, relying on the UNIX kernel's buffer cache to keep frequently used data in memory. In contrast, BIND needs to load everything into memory before it answers queries.
While you're building a new data.cdb, tinydns continues answering queries from the old data.cdb; when the new data.cdb is complete, tinydns instantly switches to it.
Answer: One site reported tinydns-data taking under a minute on a Pentium III-550 to create a 350-megabyte data.cdb covering almost 300000 domains.
I also tried the dul.maps.vix.com zone, which had 200000 records and occupied 15 megabytes in data format. tinydns-data took under 5 seconds on a Pentium II-350 to create a new 18-megabyte data.cdb and write it safely to disk.
Note that IP-address lists are much more efficiently handled by rbldns, which stores the same DUL information in just 0.15 megabytes.