2009/10/23 Len Conrad <lcon...@go2france.com> > ---------- Original Message ---------------------------------- > From: krad <kra...@googlemail.com> > Date: Fri, 23 Oct 2009 15:56:40 +0100 > > >2009/10/23 Sean Cavanaugh <millenia2...@hotmail.com> > > > >> > >> > >> > >> > Date: Fri, 23 Oct 2009 08:30:08 -0400 > >> > From: dave.l...@pixelhammer.com > >> > To: freebsd-questions@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@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >> To unsubscribe, send any mail to " > >> freebsd-questions-unsubscr...@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscr...@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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
