Снижение производительности при использовании CNAME

Мы используем текущую запись CNAME для сервера, т.е.

 foo.example.com => CNAME => server1.example.com 
 server1.example.com => CNAME => ec2-34-142-138-31.compute-1.amazonaws.com 
 ec2-34-142-138-31.compute-1.amazonaws.com => A => 34.142.138.31

Это обычная конфигурация?
Снижение производительности при использовании двух записей CNAME критично?
Чтобы свести к минимуму влияние поиска CNAME, следует ли мне установить больший TTL для 1-го CNAME, но более короткий CNAME для 2-го CNAME?

т.е.

 foo.example.com => CNAME (TTL=86400) => server1.example.com 
 server1.example.com => CNAME (TTL=300) => ec2-34-142-138-31.compute-1.amazonaws.com

да. например Yahoo использовать это. вот результат dig www.yahoo.fr на моей машине, которая находится во Франции:

; <<>> DiG 9.9.5-4-Debian <<>> www.yahoo.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1935
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.yahoo.fr.                  IN      A

;; ANSWER SECTION:
www.yahoo.fr.           300     IN      CNAME   rc.yahoo.com.
rc.yahoo.com.           300     IN      CNAME   src.g03.yahoodns.net.
src.g03.yahoodns.net.   300     IN      CNAME   any-src.a03.yahoodns.net.
any-src.a03.yahoodns.net. 300   IN      A       77.238.184.150
any-src.a03.yahoodns.net. 300   IN      A       188.125.73.108

;; AUTHORITY SECTION:
a03.yahoodns.net.       172800  IN      NS      yf1.yahoo.com.
a03.yahoodns.net.       172800  IN      NS      yf2.yahoo.com.

;; ADDITIONAL SECTION:
yf1.yahoo.com.          86391   IN      A       68.142.254.15
yf2.yahoo.com.          86391   IN      A       68.180.130.15

;; Query time: 342 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 29 09:57:01 CEST 2014
;; MSG SIZE  rcvd: 227

Вы можете увидеть двойное перенаправление через несколько записей CNAME, возвращаемых в одном пакете DNS.

Нет. DNS использует механизм кэширования и рекурсивные преобразователи, так что многие пользователи даже не замечают количество подразумеваемых преобразователей DNS, поскольку это быстро, и обычно запрос не обязательно запускает весь процесс разрешения.

Не обязательно. Посмотрите значение для примера Yahoo, которые являются общими. Вот еще один (французский) пример: торговец одеждой:

$ dig www.laredoute.fr
; <<>> DiG 9.9.5-4-Debian <<>> www.laredoute.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28156
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.laredoute.fr.              IN      A

;; ANSWER SECTION:
www.laredoute.fr.       1800    IN      CNAME   www.laredoute.fr.glb.pprgroup.net.
www.laredoute.fr.glb.pprgroup.net. 30 IN A      217.109.67.129

;; AUTHORITY SECTION:
pprgroup.net.           172800  IN      NS      gtm1.pprgroup.net.
pprgroup.net.           172800  IN      NS      gtm2.pprgroup.net.

;; ADDITIONAL SECTION:
gtm1.pprgroup.net.      172800  IN      A       194.206.254.11
gtm2.pprgroup.net.      172800  IN      A       217.109.67.126

;; Query time: 679 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 29 10:03:57 CEST 2014
;; MSG SIZE  rcvd: 178

Используется для установки нормального значения TTL для записи CNAME и адаптации значения TTL для записи A (в зависимости от стабильности IP-адреса, требуемой балансировки нагрузки на основе DNS, ...).

Поиск DNS в целом практически не влияет (может быть, 20-30 мс в зависимости от времени ответа). Если вы не видите, что записи меняются очень часто, установка более высокого TTL поможет с кешированием.