Hi Everyone,
I am currently reviewing the DNS records for the organization I work for and have one area I would like other peoples thoughts on. Would there ever be a situation where you need to have multiple A records pointing to the same IP Address?
Currently we have a small number of cases where one IP Address has multiple A Records. This seems like a bad idea to me and I would replace these records with cnames. But I am meeting resistance to this. As far as I can think right now if you have one correctly configured A record with a matching reverse entry and then use cnames there shouldn't be any cases where you must add a second A record. Or am I missing something ?
On May 15, 2008, at 7:34 PM, Clint Dilks wrote:
I am currently reviewing the DNS records for the organization I work for and have one area I would like other peoples thoughts on. Would there ever be a situation where you need to have multiple A records pointing to the same IP Address?
Currently we have a small number of cases where one IP Address has multiple A Records. This seems like a bad idea to me and I would replace these records with cnames. But I am meeting resistance to this. As far as I can think right now if you have one correctly configured A record with a matching reverse entry and then use cnames there shouldn't be any cases where you must add a second A record. Or am I missing something ?
A shared web server is a good example of multiple As resolving to the same IP.
CNAMEs require two dips into the DNS (one to get the CNAME, another to look up the IP), and so can be much slower if you are the victim of a slow resolver.
--Chris
Hi,
On Thu, May 15, 2008 at 8:45 PM, Chris Boyd cboyd@gizmopartners.com wrote:
CNAMEs require two dips into the DNS (one to get the CNAME, another to look up the IP), and so can be much slower if you are the victim of a slow resolver.
Not true (AFAIR). If I remember correctly, if the information about the destination of the CNAME is on the same DNS server (either because it is authoritative, or because the resolver has it already on cache), it will piggyback the information on the same response packet. You can check this behaviour by using "dig" with the options that show all that comes in the original response.
Look:
$ dig www.google.com
; <<>> DiG 9.3.3rc2 <<>> www.google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53650 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;www.google.com. IN A
;; ANSWER SECTION: www.google.com. 10048 IN CNAME www.l.google.com. www.l.google.com. 115 IN A 64.233.169.147 www.l.google.com. 115 IN A 64.233.169.104 www.l.google.com. 115 IN A 64.233.169.103 www.l.google.com. 115 IN A 64.233.169.99
;; Query time: 3 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu May 15 20:56:30 2008 ;; MSG SIZE rcvd: 126
192.168.1.1 is my router which is running DNS. Just to make sure, I opened another window and started a tcpdump udp on it, and this is what I got:
20:56:30.641239 IP 192.168.1.10.33672 > 192.168.1.1.53: 53650+ A? www.google.com. (32) 20:56:30.642791 IP 192.168.1.1.53 > 192.168.1.10.33672: 53650 5/0/0 CNAME[|domain]
One packet request, one packet response. That's it, nothing else.
On Thu, May 15, 2008 at 8:34 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
I am currently reviewing the DNS records for the organization I work for and have one area I would like other peoples thoughts on. Would there ever be a situation where you need to have multiple A records pointing to the same IP Address?
Yes, if the domains are used as e-mail domains or as mail exchangers in MX records. Although this is probably not true anymore, some MTAs used to have problems with CNAMEs, so it was (and still is) considered "best practice" to use A records for those.
You also might have to use A records if you want to associate other records to a name (like MX or TXT or even SOA for a parent domain).
Whatever you do, be careful to not use CNAME pointing to a CNAME. Although it kind of works, it's expressly forbidden by the RFCs and might get you into trouble. Before changing those As into CNAMEs, make sure that nobody has a CNAME that points to one of those.
Other than that, yes, it is a good idea to change As into CNAMEs, specially in cases where you don't have control on the nameserver for some domains and you might need to change the IP of the server, then you might change the A record and have all others follow you wherever you go.
HTH, Filipe
On May 15, 2008, at 7:59 PM, Filipe Brandenburger wrote:
Not true (AFAIR). If I remember correctly, if the information about the destination of the CNAME is on the same DNS server (either because it is authoritative, or because the resolver has it already on cache), it will piggyback the information on the same response packet. You can check this behaviour by using "dig" with the options that show all that comes in the original response.
Yes, you are correct.
I was mis-remembering this bit of RFC 1035 about restarting the query: "CNAME RRs cause no additional section processing, but name servers may choose to restart the query at the canonical name in certain cases. See the description of name server logic in [RFC-1034] for details." --Chris
Clint Dilks wrote:
Hi Everyone,
I am currently reviewing the DNS records for the organization I work for and have one area I would like other peoples thoughts on. Would there ever be a situation where you need to have multiple A records pointing to the same IP Address?
Currently we have a small number of cases where one IP Address has multiple A Records. This seems like a bad idea to me and I would replace these records with cnames. But I am meeting resistance to this. As far as I can think right now if you have one correctly configured A record with a matching reverse entry and then use cnames there shouldn't be any cases where you must add a second A record. Or am I missing something ? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks for the responses :) Much appreciated