FW: DNS Question

[krad]

2009/10/23 Len Conrad <lconrad at go2france.com>

> ---------- Original Message ----------------------------------
> From: krad <kraduk at googlemail.com>
> Date:  Fri, 23 Oct 2009 15:56:40 +0100
>
> >2009/10/23 Sean Cavanaugh <millenia2000 at hotmail.com>
> >
> >>
> >>
> >>
> >> > Date: Fri, 23 Oct 2009 08:30:08 -0400
> >> > From: dave.list at pixelhammer.com
> >> > To: freebsd-questions at freebsd.org
> >> > Subject: DNS Question
> >> >
> >> > Good morning.
> >> >
> >> > I have been asked by my co-workers and sales why I always create a A
> >> > record for new domains we host instead of a CNAME.
> >> >
> >> > The issue I run into lately with some domains is that a client has a
> >> > website with a industry host such as frank.relator.com and he wants
> to
> >> > have DNS point www.frank.com to frank.relator.com with a CNAME. The
> >> > client does not want an A record for frank.com.
> >> >
> >> > Somewhere, in a class far far away, I was taught a DNS zone had to
> have
> >> > a A record to function properly. I can't seem to locate anything in
> the
> >> > RFCs.
> >> >
> >> > Am I wrong?
> >> >
> >>
> >>
> >> I think you are confusing basics of DNS records. you are partially
> correct
> >> in that a DNS zone needs an initial A record to be able to translate a
> name
> >> to an IP, but there is nothing wrong about setting up a CNAME to point
> to a
> >> record in a different zone instead. you just cannot do a zone that has a
> >> CNAME only that does not at some point to a valid A record. CNAMEs are
> >> forwarders only whereas A records are actual lookups.
> >>
> >> for proper way to set this up....
> >>
> >> The A record would be assigned for the main name that you want to
> associate
> >> to an IP address.
> >> The CNAME record just relates a different name to that original name.
> this
> >> allows you to change the IP address of the server and only have to
> update
> >> the original A record instead of every DNS record for that server.
> >>
> >> for small number of vhosts, this would not really be an issue, but
> imagine
> >> if you were hosting a couple hundred vhosts from a single IP and then
> had to
> >> change that IP because you switched your ISP. It would take you a LONG
> time
> >> to update them if they were all A records, but only a couple of seconds
> if
> >> you had it properly set up as CNAME's
> >>
> >> www.bobshosting.com    A         192.168.0.1
> >> www.vhost1.com          CNAME  www.bobshosting.com.
> >> www.vhost2.com          CNAME  www.bobshosting.com.
> >> www.vhost3.com          CNAME  www.bobshosting.com.
> >> www.vhost4.com          CNAME  www.bobshosting.com.
> >>
> >>
> >>
> >> -Sean
> >>
> >>
> >>  _______________________________________________
> >> freebsd-questions at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> >> To unsubscribe, send any mail to "
> >> freebsd-questions-unsubscribe at freebsd.org"
> >>
> >
> >I try to use CNAMES as much as possible, for one very good reason. If say
> I
> >have web server with 1000 vhost on it. I have one A record for the server
> >and all the cnames point at that A record. Now i need to change the ip of
> >the server. I update the A record and add a reverse record and im done. IF
> I
> >had done it your way with all A records I would now have to go and edit
> >another 1000 records. Even worse if some of these domains are not under my
> >control I have to go and liaise with customers, or other third parties,
> and
> >it becomes a complete mess. The chances of me convincing them all and
> >coordinated it correctly are minimal 8(
>
> domains sharing records is better handled by $INCLUDE
>
> $INCLUDE /path/db.ttl, which contains
>
> $TTL 6h
>
>
> $INCLUDE /path/db.ns, which contains
>
> @ ns ns1.domain.tld.
> @ ns ns2.domain.tld.
>
> $INCLUDE /path/db.www, which contains
>
> @   a ip.ad.re.ss
> www a ip.ad.re.ss
>
> etc.
>
> Changing an include file changes all the zone files that include it, giving
> enormous leverage, while removing the extra query required to resolve a
> CNAME to canonical.
>
> Len
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>

a few massive assumptions here I feel.

1. all the domains are controlled by said person
2. Are on the same server
3. Fits with the relevent provisioning system,
4. Is probably are using bind