DNS-протокол використовується для словесних адрес IP-адрес (які вказують, що унікальний Інтернет кожен комп'ютер) - так що ми можемо використовувати легкий імена в пам'яті, а також врятувати нас потрібно, щоб кожен раз, коли зміни, внесені в IP-адреси, що належать до системи, до якої ми хочемо підключитися . Можна сказати, що DNS насправді в Жовті сторінки "в Інтернеті.
Система DNS складається з ієрархічного дерева, гілки дерев відокремлювали їх відзначте крапку. Корінь дерева, тобто його ключовий момент, а також відзначені точки, і називається кореневим. У корені дерева, є основними областями (рДВУ - глобальний домен верхнього рівня) - ми знаємо, URL, такі як COM, NET, ORG та національні домени (ксДВУ - код країни доменів верхнього рівня), таких як, наприклад, Іра для Ізраїлю. Технічно немає ніякої різниці між двома видами - і - як описано нижче - (). Всього записів в ім'я кореневого домена.
Кожна гілка в дереві DNS визначається як зона (зони) - і в кожній такій області визначені різні типи записів ресурсів. Серед іншого є записи, які перетворюють доменне ім'я (ім'я домену) або ім'я хоста в домен (ім'я), а посилання на версію 4 IP-адресу (або IPv4) - так звані записи "A", посилання на поштовий сервер, який приймає пошту для домену (MX записів - Mail Exchange), напрям в IP версії 6 (або IPv6) - запис "AAAA", або навіть звернутися до - площа під дерево, яке знаходиться під управлінням сервера DNS Інші (запис "NS" - скорочення від сервера імен "), і навіть - Хто несе відповідальність за область (запис RP - Відповідальна особа).
На додаток до запису ресурсу, площа також містить інформацію про себе. Такі як - зміна номера версії (Serial) - який зазвичай визначає формат дати і часу для зручності, інтервал в секундах між оновленнями інформації (Refresh) вторинного серверів DNS, час затримки між спробами, як зазначено вище у разі виходу з ладу
(Повтор), і час, після якого сервер DNS припустити, що інформація не є дійсним, якщо він не може отримувати оновлення до тих пір (Термін дії). Інший дуже важливе питання, яке можна налаштувати на кожен регіон в глобальному масштабі (Ви також можете встановити окремий запис в регіоні) - це «живе час», або англійську TTL - Time To Live. Ця величина, що визначається як одиниця виміру секунди, сказати, що довжина дії будь-який запис, і містити інформацію про локальний кеші копії запису (кеш), якщо пройшло цей час. Причина, чому взагалі повинні мати локальну копію, а не просто отримати поточну копію інформації в той час, безпосередньо з авторитетних DNS - буде пояснено нижче.
Для того, щоб "побачити очима" Що таке визначення регіону, є прикладом такого формату для сайту, ви дивитеся на в даний час, сервер DNS спільного - BIND - Berkeley Internet Name Daemon. Це не є рекомендацією на цьому сервері, і навпаки, я думаю, Tinydns робить набагато краще, не педант маніакально, і серйозні економічні ресурси. Це тільки один приклад:
$ TTL 86400 @ IN SOA shimi.net. hostmaster.shimi.net. ( 2007040808; послідовного 28800; Оновити 14400; Повторити 3600000; закінчується 86400) Мінімальні shimi.net. В NS ns2.powweb.com. shimi.net. В NS ns3.powweb.com. shimi.net. IN MX 30 mx.shimi.net. shimi.net. В 65.254.250.106 WWW IN CNAME shimi.net. м В 65.254.254.50 м В 65.254.254.51
Ви можете помітити такі важливі речі: TTL певні правила для регіону, який є 86400 секунд (один повний робочий день не вірю Multiply - 60 * 60 * 24 і переконайтеся в цьому самі ....?). Це означає, що будь-який клієнт DNS світ вирішить зберегти цей сайт, заборонено "пам'ятають", що він дізнався протягом більше 24 годин. І чому це важливо для нас? Тому що, якщо в один прекрасний день я вирішив перевести свій сайт або поштового сервера, інший комп'ютер, я хочу, щоб всі відвідувачі сайту отримають оновлену інформацію про нову адресу комп'ютера в найближчим часом, і буде тривати протягом тривалого часу (скажімо, - через тиждень ...) спробувати отримати на сервері старий, який не міг утримувати свій сайт чи мій електронну поштову скриньку, а потім втрачати відвідувачів та / або електронній пошті. Я сказав, перш ніж я поясню, чому навіть тримати цю інформацію в оновленій і дізнатися від джерела даних безпечним чи не так? Ну, причина проста. Перш за все, питання навантаження на центральний сервер. Так як всі веб-пошуку DNS починається з кореня дерева вниз, якби був механізм відкликання за результатами запиту, то будь пошук DNS, будь-який з мільйонів (або мільярдів?) Використовуйте Інтернет, прийде до DNS-серверів з головних - і немає жодних шансів, що вони будуть відповідати цим тягарем, а не з точки зору швидкості обробки даних, і, цілком можливо, не з точки зору пропускної здатності виділених для них. Тому важливо пам'ятати, що дані вже зібрані. Друга причина полягає в ефективності для кінцевого користувача. Коли результат зберігається в локальному клієнта DNS (яка зазвичай знаходиться на сервері провайдера, який кінцевий користувач підключений), а доступ до даних набагато швидше. Середня підключення до Інтернету, це не більше ніж -50 мілі - секундах між відправленням запиту для коментарів. Якщо запит необхідно кожен раз просимо всіх DNS-серверах, що входять до складу дерева (поясню пізніше), користувач може чекати часу було навіть секунди досконалості відповіді.
З наведених вище теорії, ми будемо тепер Lt'acls - Що відбувається, наприклад, коли ви йдете в www.cnn.com.
Припустимо, що я є клієнтом компанії NetVision. При підключенні до Інтернет, системи Netvision сказати комп'ютер (або на мій домашній маршрутизатор), які використовують DNS серверів для наступних цілей: 194.90.1.5 і 194.90.1.49 запит DNS.
Мені цікаво, як сказано вище, перейдіть до www.cnn.com. Для цього мені потрібно, щоб знайти IP-адресу сервера www.cnn.com. Мій комп'ютер перетвориться на сервер DNS з Netvision і запитати його: Дайте мені запис www.cnn.com. Припустимо відбування Netvision без попереднього інформацію з цього питання. Що будемо робити? Він знайде для себе те, що адреса www.cnn.com, і що він буде просити одного з головних DNS-серверів в Інтернеті, наприклад, сервер a.root-servers.net:
; << >> DiG 9.2.5 << >> @ a.root-servers.net www.cnn.com; (1 сервер знайдено), глобальні параметри: printcmd;; Отримав відповідь:;; - >> HEADER < <- код операції: QUERY, статус: NOERROR, ID: 23611;; прапори: QR-й; QUERY: 1, відповідей: 0, повноваження: 13, ДОДАТКОВО: 14;; ПИТАННЯ РОЗДІЛ:; www.cnn.com. В;; ВЛАДИ РОЗДІЛ: ком. 137834 IN NS d.gtld-servers.net. ком. 137834 IN NS e.gtld-servers.net. ком. 137834 IN NS f.gtld-servers.net. ком. 137834 IN NS g.gtld-servers.net. ком. 137834 IN NS h.gtld-servers.net. ком. 137834 IN NS i.gtld-servers.net. ком. 137834 IN NS j.gtld-servers.net. ком. 137834 IN NS k.gtld-servers.net. ком. 137834 IN NS l.gtld-servers.net. ком. 137834 IN NS m.gtld-servers.net. ком. 137834 IN NS a.gtld-servers.net. ком. 137834 IN NS b.gtld-servers.net. ком. 137834 IN NS c.gtld-servers.net. ;; Додатковий розділ: a.gtld-servers.net. 171837 В 192.5.6.30 a.gtld-servers.net. 171759 В AAAA 2001:503: a83e :: 2:30 b.gtld-servers.net. 161282 В 192.33.14.30 b.gtld-servers.net. 165361 В AAAA 2001:503:231 г :: 2:30 c.gtld-servers.net. 171159 В 192.26.92.30 d.gtld-servers.net. 161282 В 192.31.80.30 e.gtld-servers.net. 171159 В 192.12.94.30 f.gtld-servers.net. 171159 В 192.35.51.30 g.gtld-servers.net. 171159 В 192.42.93.30 h.gtld-servers.net. 171159 В 192.54.112.30 i.gtld-servers.net. 170422 В 192.43.172.30 k.gtld-servers.net. 171159 В 192.52.178.30 l.gtld-servers.net. 171159 В 192.41.162.30 m.gtld-servers.net. 171159 В 192.55.83.30;; запит часу: 190 мс;; SERVER: 198.41.0.4 # 53 (198.41.0.4), коли: Нд 8 квітня 15:20:24 +2007; MSG SIZE RCVD: 493
Тобто, інформація про кого записів ресурсів, що відбулася повний набір інших серверів DNS в доменне ім'я рДВУ-servers.net. Для того, щоб наше життя "простіше", якщо "клей записи", які дають нам цей запит має IP - адреси цих серверів, так що ми повинні перевірити самі. Тепер переходимо на сервер DNS з Netvision рандомізовані в одну з IP-адреси він отримав у відповідь на DNS-серверах інтернет-начальник, і запитав його: "www.cnn.com - що тоді?" - І отримаєте таку відповідь:
; << >> DiG 9.2.5 << >> @ a.gtld-servers.net www.cnn.com (2 сервера знайдено) ;; Глобальні параметри: printcmd ;; Отримав відповідь: ;; - >> << HEADER - код операції: QUERY, статус: NOERROR, ID: 408 ;; Прапори: QR-й; QUERY: 1, відповідей: 0, влада: 4, ДОДАТКОВЕ: 4 ;; ПИТАННЯ РОЗДІЛ: ; Www.cnn.com. В ;; ВЛАДИ РОЗДІЛ: cnn.com. 172800 В NS-twdns 01.ns.aol.com. cnn.com. 172800 В NS-twdns 02.ns.aol.com. cnn.com. 172800 В NS-twdns 03.ns.aol.com. cnn.com. 172800 В NS-twdns 04.ns.aol.com. ;; Додатковий розділ: twdns-01.ns.aol.com. 172800 В 149.174.213.151 twdns-02.ns.aol.com. 172800 В 152.163.239.216 twdns-03.ns.aol.com. 172800 В 207.200.73.85 twdns-04.ns.aol.com. 172800 В 64.12.147.120 ;; Запит часу: 233 мс ;; SERVER: 192.5.6.30 # 53 (192.5.6.30) ;; КОЛИ: Нд 8 квітня 2007 15:30:53 ;; MSG SIZE RCVD: 192
Тут же, каже нам a.gtld-servers.net факт: "Що ви хочете від життя - я нічого не знаю про www.cnn.com, якщо ви хочете щось все нижче cnn.com, будь ласка, зв'яжіться з одним з слуг DNS наступне: twdns-01.ns.aol.com, twdns-02.ns.aol.com, twdns-03.ns.aol.com, twdns-04.ns.aol.com ", і знову, ми добровільно IP-адреси цих серверів в якості доповнення до відповіді, не повинні дивитися на них. "Великий", говорить сам сервер в Netvision, випадковим чином вибирає один з чотирьох серверів, і запитує його: "Ну, хтось, щоб сказати мені, що IP-адреса www.cnn.com!" А ось і відповідь він отримав:
; << >> DiG 9.2.5 << >> @ twdns-02.ns.aol.com www.cnn.com : (1 сервер знайдено) ;; Глобальні параметри: printcmd ;; Отримав відповідь: ;; - >> << HEADER - код операції: QUERY, статус: NOERROR, ID: 6714 ;; Прапори: QR-й; QUERY: 1, відповідей: 0, влада: 2, ДОДАТКОВІ: 2 ;; ПИТАННЯ РОЗДІЛ: ; Www.cnn.com. В ;; ВЛАДИ РОЗДІЛ: www.cnn.com. 3600 в С. dmtns01.turner.com. www.cnn.com. 3600 в С. dmtns02.turner.com. ;; Додатковий розділ: dmtns01.turner.com. У 3608 64.236.29.150 dmtns02.turner.com. У 3608 64.236.22.150 ;; Запит часу: 163 мс ;; SERVER: 152.163.239.216 # 53 (152.163.239.216) ;; КОЛИ: Нд 8 квітня 2007 15:33:16 ;; MSG SIZE RCVD: 112
Що відбувається? Ми повинні відповісти на цей сервер уже! Ну що ж. Так CNN вирішив перейти DNS-серверів їх - але те, що вони будуть оновлювати доменні імена зареєстровані на DNS-сервери можуть бути новими, якщо їхні клієнти просто викликати більше затримка, і відправити їх на інший сервер DNS і непотрібним? В крайньому випадку, сервер DNS з Netvision триває, і перетворюється в dmtns01.turner.com, щоб отримати, нарешті, потрібну інформацію, і це виглядає так:
; << >> DiG 9.2.5 << >> @ dmtns01.turner.com www.cnn.com : (1 сервер знайдено) ;; Глобальні параметри: printcmd ;; Отримав відповідь: ;; - >> << HEADER - код операції: QUERY, статус: NOERROR, ID: 44943 ;; Прапори: QR-аа-й; QUERY: 1 ВІДПОВІДЬ: 8 ВЛАДИ: 0, ДОДАТКОВІ: 0 ;; ПИТАННЯ РОЗДІЛ: ; Www.cnn.com. В ;; Розділ відповідей: www.cnn.com. 600 В 64.236.29.120 www.cnn.com. 600 В 64.236.91.21 www.cnn.com. 600 В 64.236.91.22 www.cnn.com. 600 В 64.236.91.23 www.cnn.com. 600 В 64.236.91.24 www.cnn.com. 600 В 64.236.16.20 www.cnn.com. 600 В 64.236.16.52 www.cnn.com. 600 В 64.236.24.12
Святе дерьмо, скільки серверів у них! Браузер користувача, ймовірно, доведеться вибрати один з восьми випадкових отримати від сайту! Відзначимо, що ще один цікавий факт - їх TTL це всього 600 секунд, або десять хвилин. Чому так низько? Щоб дізнатися про оновлених даних кожні десять хвилин. І чому так багато навантаження на DNS? Напевно, тому що наявність для них важливо, і хочете, щоб сервер з восьми восени DNS будуть оновлені одразу ж автоматизований процес, щоб видалити сервер зі списку, а не один сайт буде недоступний протягом більше десяти хвилин, що є максимальним час, що надається клієнтам зберігати інформацію про перетворення IP-адреса цього.
Нарешті, пункти уточнити: всі описані вище кроки, а також зберігає інформацію, отриману в результаті запиту до локальної копії (якщо вона знаходиться в кешуючий сервер імен - і зазвичай так воно і є), тому, якщо інформація була доступна локально, сервер не набридло подорожувати Землі, щоб знайти його, але стверджує, що локальна копія, тим самим заощаджуючи час і трафік. Крім того, якщо DNS-сервер, на рівні клієнта, а також декодування серверів, які допомагали в дорозі, не було, то заявник повинен підійти ще один випадковий список серверів, і отримати відповідь від нього. Це займе більше часу, але був успішним в кінці. Це завжди найбільш часто використовувані DNS-сервера по одному для кожного регіону - виживання.