Значительно ли быстрее, чем CNAME, в этом случае?
$ dig www.google.com
; <<>> DiG 9.8.1-P1 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28336
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 13 IN A 173.194.78.103
www.google.com. 13 IN A 173.194.78.106
www.google.com. 13 IN A 173.194.78.105
www.google.com. 13 IN A 173.194.78.99
www.google.com. 13 IN A 173.194.78.147
www.google.com. 13 IN A 173.194.78.104
;; Query time: 11 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 24 10:22:28 2013
;; MSG SIZE rcvd: 128
Что ж, если вы Google, с миллионами запросов DNS в день, я бы сказал, что сокращение запросов на 50% является значительным.
Основная цель использования записей CNAME RR - облегчить администрирование зоны DNS. Поскольку это просто указатель на другую метку со всеми ее RR (кстати, не только A RR) все RR), в былые времена, когда изменение RR требовало включения vi Чтобы отредактировать файл зоны в стиле BIND, у вас будет меньше работы, если вам когда-либо понадобится изменить RR.
Зоны Google, конечно, не редактируются вручную в файлах в стиле BIND, поэтому полезность записей CNAME вызывает сомнения. Кроме того, Google использует гео-DNS, где ответ RR будет зависеть от того, откуда вы запрашиваете - статические CNAME здесь не помогут.
Кроме того, всякий раз, когда запрос DNS для метки приводит к ответу CNAME, необходимо выполнить другой запрос, чтобы получить RR метки назначения CNAME. Неблагоприятные эффекты задержки и потребления ресурсов в основном нейтрализуются кеширующими резолверами на стороне провайдера, но если нет конкретных необходимость для CNAME их просто не следует использовать.
Я бы сказал, что A в любом случае быстрее CNAME! Потому что, когда вы ищете IP-адрес для домена с записью cname, DNS всегда выполняет в два раза больше работы, чем ищет только запись A.