Насправді, це складніше, ніж це - а не один "центральний реєстр (який) містить таблицю, яка відображає домени (www.mysite.com) на DNS-сервери", є кілька шарів ієрархії
Там в центральний реєстр (кореневі сервери) , які містять тільки невеликий набір записів: при NS (сервера імен) записи для всіх доменів верхнього рівня - .com, .net, .org, .uk, .us, .au, і так далі.
Ці сервери просто містять записи NS для наступного рівня вниз. Для того, щоб вибрати один приклад, сервери імен для .ukдомену тільки має записів для .co.uk, .ac.ukі інші зони другого рівня в використанні в Великобританії.
Ці сервери просто містять записи NS для наступного рівня вниз - щоб продовжити приклад, вони підкажуть вам, де знайти записи NS google.co.uk. Саме на тих серверах ви нарешті знайдете відображення між іменем хоста www.google.co.ukта IP-адресою.
В якості додаткової зморшки кожен шар також буде служити записом "клею". Кожна запис NS відображає домен до імені хоста - наприклад, NS записує .ukсписок nsa.nic.ukяк один із серверів. Щоб перейти до наступного рівня, нам потрібно з’ясувати записи NS, які nic.ukє, і вони, як виявиться, включають nsa.nic.ukтакож. Отже, зараз нам потрібно знати IP nsa.nic.uk, але щоб дізнатися, що нам потрібно зробити запит nsa.nic.uk, але ми не можемо зробити цей запит, поки не будемо знати IP для nsa.nic.uk...
Щоб вирішити цю дилему, сервери для .ukдодавання запису A для nsa.nic.ukInto The ADDITIONAL SECTIONвідповіді (реакції нижче обрізається для стислості):
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
Без цих додаткових записів про клей ми ніколи не зможемо знайти сервери імен, nic.uk.тому ми ніколи не зможемо знайти жодні домени, розміщені там.
Щоб повернутися до своїх питань ...
а) Яка перевага? Чому б не вказати безпосередньо на IP-адресу?
З одного боку, вона дозволяє редагувати зміни до кожної окремої зони. Якщо ви хочете оновити запис для www.mydomain.co.uk, вам просто потрібно буде відредагувати інформацію на mydomain.co.ukсервері імен вашого . Не потрібно повідомляти центральних .co.ukсерверів, або .ukсерверів, або кореневих серверів імен. Якби був лише єдиний центральний реєстр, який відображав усі рівні аж до ієрархії, яку потрібно було повідомляти про кожну зміну запису DNS аж до ланцюга, він би абсолютно завалений трафіком.
До 1982 року саме таким чином і сталося дозвіл назви. Один центральний реєстр був повідомлений про всі оновлення, і вони поширили файл, hosts.txtякий називався, що містив ім'я хоста та IP-адресу кожної машини в Інтернеті. Нова версія цього файлу публікувалася кожні кілька тижнів, і кожна машина в Інтернеті повинна була б завантажити нову копію. До 1982 року це почало ставати проблематичним, і тому DNS був винайдений для забезпечення більш розподіленої системи.
Інша справа, це була б Єдина точка збою - якби єдиний центральний реєстр знизився, весь Інтернет був би в автономному режимі. Наявність розподіленої системи означає, що збої зачіпають лише невеликі розділи Інтернету, а не всю справу.
(Щоб забезпечити додаткову надмірність, насправді існує 13 окремих кластерів серверів, які обслуговують кореневу зону. Будь-які зміни в записах доменів верхнього рівня повинні бути перенесені на всі 13; уявіть собі, що потрібно координувати оновлення всіх 13 з них для кожної зміни до будь-якого імені хоста в будь-якій точці світу ...)
b) Якщо єдиний запис, який потрібно змінити, коли я конфігурую DNS-сервер для вказівки на іншу IP-адресу, знаходиться на сервері DNS, чому процес не є миттєвим?
Оскільки DNS використовує багато кешування для прискорення роботи та зменшення навантаження на NSes. Без кешування кожен раз, коли ви відвідували google.co.ukкомп’ютер, доведеться виходити в мережу, щоб шукати сервери для .uk, то .co.uk, то .google.co.uk, то www.google.co.uk. Ці відповіді насправді не сильно змінюють, тому щоразу їх шукати - це марна трата часу та мережевого трафіку. Натомість, коли NS повертає записи на ваш комп'ютер, воно буде включати значення TTL, яке повідомляє вашому комп'ютеру кешувати результати протягом декількох секунд.
Наприклад, записи NS .ukмають TTL 172800 секунд - 2 дні. Google ще більш консервативний - записи NS google.co.ukмають TTL 4 дні. Служби, які розраховують на можливість швидкого оновлення, можуть вибирати набагато нижчий TTL - наприклад, telegraph.co.ukTTL складає всього 600 секунд у своїх записах NS.
Якщо ви хочете, щоб оновлення вашої зони були майже миттєвими, ви можете знизити TTL так далеко, як вам подобається. Чим нижче ваш набір, тим більше трафіку будуть бачити ваші сервери, оскільки клієнти частіше оновлюють свої записи. Кожен раз, коли клієнту доводиться звертатися до ваших серверів, щоб зробити запит, це спричинить деяке відставання, оскільки це повільніше, ніж шукати відповідь у своєму локальному кеші, тому ви також хочете розглянути можливість компромісу між швидкими оновленнями та швидким обслуговуванням.
c) Якщо єдиною причиною затримки є кеші DNS, чи можливо їх обійти, щоб я міг бачити, що відбувається в режимі реального часу?
Так, це легко, якщо ви тестуєте вручну за допомогою digабо подібних інструментів - просто скажіть, на якому сервері звернутися.
Ось приклад кешованої відповіді:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
Розділ прапорів тут не містить aaпрапор, тому ми можемо бачити, що цей результат вийшов із кеша, а не безпосередньо з авторитетного джерела. Насправді ми можемо бачити, що воно походить від 97.107.133.4одного з локальних DNS-розв’язувачів Linode. Той факт, що відповідь було подано з кеш-пам'яті дуже близько до мене, означає, що для отримання відповіді мені знадобилося 0 мс; але, як ми побачимо за мить, ціна, яку я плачу за цю швидкість, полягає в тому, що відповідь застаріла майже за 5 хвилин.
Щоб обійти резолюцію Linode та перейти до джерела, просто виберіть одну з цих NSes і скажіть dig, щоб безпосередньо зв’язатися з нею:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
Видно, що цього разу результати подавались безпосередньо з джерела - зверніть увагу на aaпрапор, який вказує на те, що результати надійшли від авторитетного джерела. У моєму попередньому прикладі результати отримані з мого локального кешу, тому їм не вистачає aaпрапора. Я бачу, що авторитетне джерело для цього домену встановлює TTL 600 секунд. Результати, які я отримав раніше з локального кешу, мали TTL всього 319 секунд, що говорить мені, що вони сиділи в кеші протягом 600-319 секунд - майже 5 хвилин - перш ніж я їх побачив.
Хоча TTL тут складає всього 600 секунд, деякі провайдери намагаються ще більше зменшити свій трафік, змушуючи свої DNS-рішення для кешування результатів довше - в деяких випадках протягом 24 годин і більше. Традиційно (таким чином, як ми не знаємо, якщо це є насправді необхідним, але будемо безпечним) вважати, що будь-яка зміна DNS, яку ви внесите, не буде видно скрізь на Інтернет на 24-48 годин.