How to setup multiple TLDs to one base-domain?
Stephane Bortzmeyer
bortzmeyer at nic.fr
Thu Feb 28 10:19:06 UTC 2008
On Tue, Feb 26, 2008 at 09:50:26AM +0100,
Michelle Konzack <linux4michelle at freenet.de> wrote
a message of 30 lines which said:
> (I have several Class C nets),
Classes for IP addresses have been suppressed in 1993...
> how can I add other TLD's like:
>
> .com .org .de .fr .ma .ir .tr
Managing a lot of identical DNS zones with BIND
http://www.bortzmeyer.org/identical-domains-with-bind.html
A very common question on mailing lists of other fora dedicated to the
DNS or specifically to BIND is 'How can I have a single zone file for
all the domains I manage, since their content is more or less
identical?'
There are several ways to do so, I describe them here, while developing
my personal preference, file sharing, more in depth.
The solutions are:
* Use only one zone file, shared by all zones, with all the content in
it being relative,
* Generate zone files from some sort of a database by a program,
* Use DNAME records.
The first solution is often my favorite. The idea is to have one zone
file, with a content made mostly of *relative* domain names. That is
using @ instead of the zone name, not adding the zone name and the
final dot, etc. BIND lets you use the at sign (@) to refer to the zone
to which named.conf assigns the zone file. An example of such a zone
file is:
$TTL 38400
@ IN SOA ns1.myorg.net. hostmaster.myorg.net. (
2007100601
10800
3600
604800
38400 )
IN NS ns1.myorg.net.
IN NS ns2.myorg.net.
IN MX 10 smtp.myorg.net.
www IN A 192.0.2.34
imap IN A 192.0.2.45
; Add more at your leisure
The name of the zone never appears on the left-hand side of the
resource records above. If this zone is loaded for
example.org, www.example.org
will resolve to 192.0.2.34 (because www is
written without a final dot, the name of the zone will be
automatically appended).
Once you have such a file, then use a symbolic link on the master name
server, so that all files links to this one. For instance, if
named.conf contains:
zone "example.org" {
type master;
file "example.org.db";
};
zone "example.net" {
type master;
file "example.net.db";
};
you just have to create the symbolic links to the reference file:
% ln -s reference-zone.db example.org.db
% ln -s reference-zone.db example.net.db
(Another way to have all domains use the same zone file is to name it
in named.conf zone statements, that way:
zone "example.org" {
type master;
file "reference-zone.db";
};
zone "example.net" {
type master;
file "reference-zone.db";
};
Wether it is simpler for your co-workers or your successors is
a matter of taste)
The O'Reilly book 'DNS & BIND Cookbook' has a chaper online, which is
precisely the chapter dealing with this issue
(http://www.oreilly.com/catalog/dnsbindckbk/chapter/ch02.pdf) ('Using a
Single Data File for Multiple Zones').
The second solution, the generation of the zone files from a program
which reads some sort of a database is a bit more complicated (you need
someone able to write a twenty-lines program in Perl or Python) but is
more powerful since it can even handle cases where the zone files are
not exactly identical.
The 'database' does not have to be a relational database engine, text
files with a format are databases, too, and so are XML or JSON files.
The third solution is to use the DNAME resource records described in
RFC 2672. I find DNAME complicated to understand and counter-intuitive
and not supported by all DNS implementations (but note that only the
authoritative name servers of the zone have to support them).
The main advantage of DNAME records is of memory use: it gives a
significant memory benefit (with file sharing, my favorite approach,
the memory used by BIND is proportional to the number of zones
multiplied by the size of the zone; with DNAME, most zones use very
little memory).
Here is an example. We assume that the parent zone does not allow you
to insert DNAME so you have to do everything yourself. We want
example.net to be an equivalent of example.org. The zone file for
example.net will look like:
; DNAME only handles subdomains, we need to duplicate the MX, the NS,
; etc, of the apex.
@ IN SOA ns1.myorg.net. hostmaster.myorg.net. (
2007100601
10800
3600
604800
38400 )
IN NS ns1.myorg.net.
IN NS ns2.myorg.net.
IN MX 10 smtp.myorg.net.
;
IN DNAME example.org.
; Add nothing more, all domain names *under* example.net will be
; "created" by the DNAME record above.
Remember that DNAME records only work for the domain names
*underneath* the domain you manage (the RFC says "a new DNS Resource Record called "DNAME", which
provides the capability to map an entire *subtree* of the DNS name
space to another domain). So,
www.example.net will be handled by the DNAME
record (and rewritten as www.example.org but we
need to put manually the MX and NS records of the domain example.net.
More information about the bind-users
mailing list