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 one minute.
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 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, add your favorite file-management tools to /service/tinydns/root/Makefile on 1.2.3.5 so that changes in /service/tinydns/root/data are automatically copied to 1.2.3.6.
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:
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: 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: I tried the dul.maps.vix.com zone, which has 200000 records and occupies 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.
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.