Virtual Hosts don't work with "www"
Kevin Darcy
kcd at daimlerchrysler.com
Wed Feb 21 02:32:49 UTC 2007
Stephane Bortzmeyer wrote:
> On Mon, Feb 19, 2007 at 08:29:28PM -0500,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote
> a message of 26 lines which said:
>
>
>> Using CNAME means you have one less A record to update if you
>> re-address your server. It also means there is zero ambiguity with
>> respect to forward/reverse record consistency. So from a
>> manageability perspective, CNAME is preferred.
>>
>
> Surely, nobody still edits zone files by hand, except for small and
> unimportant domains? Zone files are typically generated by a program
> like h2n or pre-processed through m4 / cpp / whatever so there is
> really no diference "from a manageability perspective".
>
There is more to DNS manageability than just the mechanism by which data
gets from the administrator's fingers to the actual physical zone file.
That's just the lowest level of abstraction, but manageability also
applies to the higher layers, which tend to be more database-oriented
(and are often in fact real databases). If the maintenance subsystem, as
a whole, is oriented towards *addresses* being the "primary key" of the
database, which is typical when the DNS maintenance subsystem is tightly
integrated with an IPAM (IP Address Management) subsystem, then it can
be problematic to have multiple names pointing to the same address,
because that requires all sorts of exceptions and special cases. It
creates a many-to-one relationship where naturally a one-to-one
relationship should suffice. CNAMEs provide a convenient way to have
multiple DNS names resolve, albeit indirectly, to the same IP, without
having to introduce troublesome multiple references and/or many-to-one
relationships within the A-record database itself.
- Kevin
P.S. For the record, we use a homegrown DDNS-based subsystem here for
DNS maintenance, and are transitioning to a commercial DNS/DHCP/IPAM
product. We haven't used hand-editing of zone files as our primary
method of DNS maintenance for many many years. As for h2n/m4/cpp-based
approaches, we skipped that evolutionary step altogether.
More information about the bind-users
mailing list