|
With addon domain I mean an additional zone (having two domain zones, one which is set up to act as an authoritative domain and has the nameservers set up, and the other just an additional domain that uses the first one's nameservers). What I wanted to know was, whether or not, do I have to specify the IP mappings to the nameservers also for this additional domain in it's SOA record. But I already found that out, so thanks anyway. |
|||||||||||
|
|
Rather than searching for examples, Bind and DNS is one of those things that you really need to understand before trying to implement it. No matter how many DNS servers I've set up, I always end up having to re-read the man pages. If you want to use Bind, check out Langfeldt's docs: http://langfeldt.net/DNS-HOWTO/BIND-9/ I started using PowerDNS because of the DB support and the way it handles updates makes it better for DDNS. HTH |
|||
|
|
|
You can have as many zone files as needed, but only for zones you are authoritive for. The origin must be different for each zone, and the records contained inside are normally different. Each zone should only have the appropriate definitions A, TXT, MX, and SPF records, etc. as required. Your bind configuration will need a zone definition for each zone you serve. If you are a secondary server for a zone, you normally get the zones from the primary. This is done using a zone transfer request. Cached versions of the zone are semantically identical, but usually differ in format. Bind has mechanisms to keep the secondaries reasonably syncronized with the primary. Because bind is a caching service, there is some delay before all the servers are syncronized. Even if the primary and secondary servers are in sync there is likely cached data in the network which is not the lasted copy. By defaul Debian (Ubuntu) based systems have master zone defintions for all the RFC 1918 zones. These all use the same zone file, db.empty. This prevents upstream calls for addresses which should never be queried outside the local zone. |
|||
|
|
