Маючи кілька CNAME

У нас є домен DNS з 5-рівневими CNAME з історичних причин. Деякі речі передаються в аутсорсинг за високої доступності тощо, але тут справа не в цьому. У мене питання про те, чи є 5 CNAME надлишків для DNS-рішення? Мені не вдалося знайти жодного відомого веб-сайту з більш ніж 2-3 рівневими вкладеними CNAME, що вказують на різні домени DNS.

Наш хміль CNAME виглядає так: (Я використовую xyz лише як приклад)

www.xyz.com -> xyz.akadns.net -> xyz.worldwide.akadns.net -> xyz.cedexis.net -> xyz.msedge.net -> host1.msedge.net (остаточний запис A \ AAAA)

Я бачу, як багато клієнтів скаржаться на проблеми з вирішенням DNS на нашому веб-сайті, коли інші сайти працюють на них нормально, хоча коли я використовую http://check-host.net/check-dns?host=www.xyz.com для тестування нашого DNS дозвіл.

Здається, завжди працює в усьому світі. Мій висновок полягає в тому, що здебільшого місцеві провайдери провайдерів DNS-розв'язника розгортаються, коли один із перерахованих вище хмелів не вдається вирішити. nslookup виходить з ладу на цих клієнтських комп'ютерах лише для нашого веб-сайту, і це занадто епізодично.

Це загальний багаторівневий CNAME поганий дизайн взагалі?

Це загальний багаторівневий CNAME поганий дизайн взагалі?

CNAME в ланцюгах CNAME не заборонено, але, як ви вже відчували, це не дуже надійне рішення.

Кожен додатковий CNAME збільшує глибину рекурсії для розділювача, і ця глибина не завжди необмежена. Також ви ризикуєте створити цикли або запустити алгоритм виявлення циклу.

Щоб скласти уявлення про те, скільки і які запити повинен виконувати сервер імен користувачів, запустіть DNS-слід:

dig +trace www.example.com 

або в Windows

nslookup -debug www.example.com

HBrujin правильний, але насправді глибина рекурсії набагато гірша, ніж все dig +trace, що вам покаже. Глибина рекурсії - це те, що часто хизується і надмірно трівіалізується, але ті люди забувають, що ви не просто вирішуєте ~ 5 CNAMEзаписів. Це тому, що вирішення цілі CNAMEзапису створює потребу шукати кожного сервера імен на шляху, який часто набагато більше, ніж це видно на перший погляд.

Чи працює CNAMEціль в іншому домені? Вам потрібно буде повторно вписатись у його сервери імен, що вимагає не лише NSзаписів записів, але й A(AAA)пошуку, де клею немає. Чи живуть сервери імен для цих серверів імен в іншому домені верхнього рівня? Якщо ці TLD не мають серверів імен, швидше за все, записи клею не будуть включені, і вам доведеться повторно прослухати також і інші сервери імен TLD. І так далі.

Кожна CNAMEзапис, доданий до ланцюжка, може додавати експоненціально до кількості необхідних пошукових запитів, залежно від кількості серверів імен, які необхідно повторити. Ці ланцюжки пошуку CNAME+ NS+ A(AAA)записів можуть, у свою чергу, отримати шалено згорнувшись, досягнувши значно більше 150 рівнів глибини кеш-порожнечі. Ось де обмеження глибини рекурсії можуть стати надзвичайно неприємними, що спричинить тимчасові збої в пошуку вашого домену в порожньому кеші, і з причин, які часто не очевидні відразу.

Коротше кажучи, ви можете це зробити, але продовжуйте обережно і сприйміть відгуки такого характеру серйозно. Ви не маєте контролю над тим, як часто перезапускаються або очищаються рекурсивні DNS-сервери в Інтернеті.

Багаторівневі CNAMEs часто зручні на практиці. Кожен рівень перенаправлення забезпечує рівень контролю в потенційно окремій адміністративній зоні або зовсім іншій організації. Хоча це навряд чи кожен технічно необхідний, він може вирішити організаційні проблеми.

Як зазначають інші, це може спричинити труднощі, але їх можна вирішити:

• контролювати всі DNS-сервери. Можливо, одна несправна. Монітор зовнішніх серверів, а також власних. Можливо, вам доведеться повідомити про проблему Akamai або іншим постачальникам.

• TTLs має бути встановлено достатньо високо, щоб дозволити кешування, але достатньо низьким, щоб ви могли перенести трафік досить швидко для вашої програми