> CNAME records make it possible to introduce recursion errors.
> The extra lookup is definitely an issue for small data centers 
> trying to maximize bandwidth and resources. And from a management
> standpoint it seems easier to work with 1 less kind of record.

At this point, we're quibbling about something pretty small, but I can only
say that none of these things have been problems for me or my clients, while
I have seen problems using multiple A records pointing to the same IP
address. I don't see how working with one less DNS record type makes any
difference, since you still have to know SOA, MX, etc. My preference for
using CNAME records for aliases is simply that this is what they're intended
for, and as a result they provide (slightly) useful information that
multiple A records don't provide.

And as for the difference in traffic, I don't think there are more requests
and responses when you get back a CNAME that's pointing to an A record - you
simply get both answers in a single response. At least, that's what nslookup
tells me. Here are some sample grabs from nslookup (I changed the names of
the servers to protect the innocent - that's why the length of the first
request is shorter, even though the server name is longer):

> test_cname.figleaf.com.
Server:  ns.figleaf.com
Address:  xxx.xxx.xxx.xxx

------------
SendRequest(), len 33
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        test_cname.figleaf.com, type = A, class = IN

------------
------------
Got answer (72 bytes):
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion
avail.
        questions = 1,  answers = 2,  authority records = 0,  additional = 0

    QUESTIONS:
        test_cname.figleaf.com, type = A, class = IN
    ANSWERS:
    ->  test_cname.figleaf.com
        type = CNAME, class = IN, dlen = 11
        canonical name = test_a.figleaf.com
        ttl = 3600 (1 hour)
    ->  test_a.figleaf.com
        type = A, class = IN, dlen = 4
        internet address = xxx.xxx.xxx.xxx
        ttl = 3600 (1 hour)

------------
Name:    test_a.figleaf.com
Address:  xxx.xxx.xxx.xxx
Aliases:  test_cname.figleaf.com

> test_a.figleaf.com.
Server:  ns.figleaf.com
Address:  xxx.xxx.xxx.xxx

------------
SendRequest(), len 38
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        test_a.figleaf.com, type = A, class = IN

------------
------------
Got answer (54 bytes):
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion
avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        test_a.figleaf.com, type = A, class = IN
    ANSWERS:
    ->  test_a.figleaf.com
        type = A, class = IN, dlen = 4
        internet address = xxx.xxx.xxx.xxx
        ttl = 3600 (1 hour)

------------
Name:    test_a.figleaf.com
Address:  xxx.xxx.xxx.xxx

You notice the difference? Eighteen bytes. That's it. The answer in either
case was small enough to fit within a UDP packet. That's hardly a big amount
of traffic, and you'd be better served in most cases just increasing the TTL
values so your DNS server is queried less frequently - the DNS server above
is an internal server, so it's not a big deal.

I'm not saying you're wrong to recommend using A records instead of CNAME
records, just that we seem to value different results in this case.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/

Fig Leaf Software provides the highest caliber vendor-authorized 
instruction at our training centers in Washington DC, Atlanta, 
Chicago, Baltimore, Northern Virginia, or on-site at your location. 
Visit http://training.figleaf.com/ for more information!


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble 
Ticket application

http://www.houseoffusion.com/banners/view.cfm?bannerid=48

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:224706
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to