Чи потрібні записи CNAME для поширення?


23

Коли я зазвичай оновлюю записи DNS ("A"), я дозволятиму протягом тривалого періоду часу, щоб зміни розповсюджувалися через кореневі сервери імен.

Чи потрібно мені вносити такий самий припуск для оновлень та змін у записах CNAME?



@MichaelHampton - правда, якщо ми змінимо an A recordдо DNS recordsв назві цього питання. Жодне питання не стосується конкретно записів A. [оновлення] Я подав цю редакцію.
Хенк Лангевельд

Відповіді:


31

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

Якщо це новий запис, кешування не може статися, тому новий запис повинен бути доступним і повинен вирішуватися негайно.

Крім того, кореневі сервери (перший рівень;.) Не розміщують DNS-зони або записи для доменних імен третього рівня. Кореневі сервери знають, які сервери імен відповідають за зони gTLD (другий рівень; .com, .edu тощо), які, в свою чергу, знають, які сервери імен відповідають за вашу зону (третій рівень; ваша компанія), які в свою чергу мають місце копія файлу вашої зони. Жоден інший DNS-сервер не зберігає копію вашого зонового файлу або DNS-записи, крім серверів імен.


  1. .

  2. COM

  3. ВАША КОМПАНІЯ


Радий допомогти ...
joeqwerty

@Jaryd, будь ласка, зверни особливу увагу на це найперше речення. Занадто багато людей тут просто не розуміють цього.
Джон Гарденєр

1
@JohnGardeniers, дякую - так! Це була особливо яскрава частина відповіді для мене :) Я ціную урок.
Джарид Малбін

3

[ Редагувати - Здається, я неправильно прочитав питання]

Існує два способи "розповсюдження" вашої зони. І кореневі сервери не (безпосередньо) залучені. Вони дозволяють іншим комп'ютерам знаходити ваші сервери, а отже, і ваші дані зони. Але це інші системи, які перевіряють кореневі та tld сервери, перш ніж вони переходять на ваш.

Ось як ваші дані дійсно просунуться.

По-перше, ви надсилаєте ці дані на свої авторитетні сервери, а деякі з них можуть використовувати (поступову) передачу зон для оновлення один одного. Це може зайняти до REFRESHчасу завершення зони.

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

Тривалість кешування даних має залежати від особи запису TTL(час жити). Теоретично це не повинно займати більше часу, ніж сума оновлення зони та ttl запису для кешованого запису на час очікування. Однак там є багато різного програмного забезпечення. Google для dns ttl bugs- останній підрахунок, який я зробив, склав близько 850 тис.

Але ви можете мати записи CNAME для www.example.com вказувати на щось подібне www-server.dynamic.example.com, а також встановлювати TTL та час оновлення для матеріалів усередині dynamic.example.comзначно нижчих значень, ніж батьківські. Це дозволяє операторам швидко перенаправляти трафік на іншу інфраструктуру, коли виникає потреба.


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

2
І все частіше стають звичнішими. Крім того, багато систем підпорядковуються TTL лише у тому випадку, якщо він перевищує певний попередньо визначений період, тому чим коротше ви зробите TTL, тим більше шансів він буде ігнорований.
Джон Гарденєр
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.