Dns система імен доменів (domain name system),Документація
розділ 14 dns: система доменних імен
rfc 1034 [mockapetris 1987a] описує концепції, що лежать в основі dns, а rfc 1035 [mockapetris 1987b] містить подробиці розробки та специфікації dns. найбільш широко використовується реалізація dns, як розбирача, і сервера - bind (berkeley internet name domain). процес сервера називається named. аналіз трафіку, що генерується dns у глобальних мережах, наводиться в [danzig, obraczka, and kumar 1992].
простір імен dns має ієрархічну структуру, що зовні нагадує файлову систему unix. малюнку 14.1 показано ієрархічна організація dns.
14.1 ієрархічна організація dns.
кожен вузол (кружечки малюнку 14.1) має мітку довжиною до 63 символів. Корінь дерева - це спеціальний вузол без мітки. мітки можуть містити великі літери або маленькі. Ім'я домену (domain name) для будь-якого вузла в дереві - це послідовність міток, яка починається з вузла виступаючого в ролі кореня, при цьому мітки поділяються точками. (тут видно відмінність від файлової системи unix, де повний шлях завжди починається з вершини (кореня) і опускається вниз деревом.) кожен вузол дерева повинен мати унікальне ім'я домену, однак однакові мітки можуть бути використані в різних точках дерева.
Ім'я домену, яке закінчується точкою, називається абсолютним ім'ям домену (absolute domain name) або повним ім'ям домену (fqdn - fully qualified domain name). наприклад, sun.tuc.noao.edu.. якщо ім'я домену не закінчується на точку, мається на увазі, що ім'я має бути завершено. Як буде закінчено ім'я, залежить від програмного забезпечення DNS. якщо незакінчене ім'я складається із двох або більше міток, його можна сприймати як закінчене чи повне; інакше праворуч від іменімає бути доданий локальний суфікс. наприклад, ім'я sun може бути завершене локальним суфіксом .tuc.noao.edu.
на малюнку 14.2 наведено перелік звичайної класифікації семи основних доменів.
рисунок 14.2 3-символьні загальні домени.
іноді вважається, що 3-символьні спільні домени використовуються лише організаціями з'єднаних штатів, а 2-символьні домени країн рештою, проте це не так. існують неамериканські організації в основних доменах, і багато організацій у сполучених штатах перебувають у домені країни .us. (rfc 1480 [cooper and postel 1993] описує домен .us докладніше.) єдині загальні домени, які закріплені за з'єднаними штатами, це .gov і .mil.
багато 2-символьних доменів країн другого рівня дуже схожі на основні домени: .ac.uk, наприклад, належить академічним інститутам, а .co.uk комерційним організаціям Великобританії.
одна важлива характеристика dns, не показана малюнку 14.1, це передача відповідальності всередині dns. не існує організації, яка б керувала та обслуговувала все дерево загалом і кожну мітку окремо. натомість одна організація (nic) обслуговує лише частину дерева (домени верхнього рівня), а відповідальність за певні зони передає іншим організаціям.
зона (zone) це окремо адміністрована частина дерева dns. наприклад, домен другого рівня noao.edu – це окрема зона. багато доменів другого рівня поділені на менші зони. наприклад, університет може поділити свою зону на підзони на факультетах, а компанія може поділити себе на зони за принципом поділу на філії або відділи.
якщо ви знайомі з файловою системою unix, то зверніть увагу, що розподіл дерева dns на зони дуже нагадує розподіл на логічні файловісистеми фізичних дискових розділів однак ми не можемо сказати, ґрунтуючись на малюнку 14.1, під чиїм керівництвом знаходяться зони, так само як ми не можемо за подібним малюнком сказати, які директорії у файловій системі знаходяться у певному дисковому розділі.
сервер dns, скажімо, обслуговує одну зону чи кілька зон. людина, яка несе відповідальність за зону, адмініструє основний сервер dns (primary name server) для цієї зони та один або кілька вторинних серверів dns (secondary name servers). первинний і вторинний сервери повинні бути незалежними і надмірними таким чином, щоб система dns не вийшла з ладу при відмові одного з серверів.
Ви можете отримати поточний список кореневих серверів, скориставшись анонімним (anonymous) FTP. отримайте файл netinfo/root-servers.txt із ftp.rs.internic.net або nic.ddn.mil.
формат повідомлення dns
для dns запиту та dns відгуку використовується однаковий формат. на малюнку 14.3 показано загальний формат dns повідомлення.
малюнок 14.3 загальний формат dns запиту та відповіді.
повідомлення містить фіксований 12-байтний заголовок, за яким йдуть чотири поля змінної довжини.
значення в полі ідентифікації (identification) встановлюється клієнтом та повертається сервером. це поле дозволяє клієнту визначити, на який запит надійшов відгук.
16-бітове поле прапорів (flags) поділено кілька частин, як показано малюнку 14.4.
малюнок 14.4 поле прапорів (flags) у заголовку dns.
Наступні чотири 16-бітові поля вказують на кількість пунктів у чотирьох полях змінної довжини, які завершують запис. у запиті кількість питань (number of questions) зазвичай дорівнює 1, а решта трьох лічильників дорівнюють 0. у відгуку кількість відповідей(number of answers) щонайменше одно 1, а два лічильника, що залишилися, можуть бути як нульовими, так і ненульовими.
розділ запитань у dns запиті
Формат кожного питання у розділі питань (question) показаний на малюнку 14.5. зазвичай є лише одне питання.
Ім'я запиту (query name) це ім'я, що шукається. воно виглядає як послідовність з однієї або кількох міток. кожна мітка починається з 1-байтового лічильника, який містить кількість наступних байт. ім'я закінчується байтом рівним 0, який є міткою з нульовою довжиною. і є, своєю чергою, міткою кореня. кожен лічильник байтів має бути в діапазоні від 0 до 63, оскільки довжина мітки обмежена 63 байтами.
рисунок 14.5 формат розділу питання (question) у запиті dns.
(Далі в цьому розділі ми побачимо, що байт лічильник з двома старшими бітами, встановленими в 1, значення від 192 до 255, використовується в схемі зі стисненням.) На відміну від багатьох інших форматів повідомлень, які ми розглянули, цьому полю дозволено закінчуватися на обмежувачі не дорівнює 32 біт. заповнення не використовується.
на малюнку 14.6 показано, як зберігається ім'я домену gemini.tuc.noao.edu.
рисунок 14.6 подання імені домену gemini.tuc.noao.edu.
у кожного питання є тип запиту (query type), а кожен відгук (званий записом ресурсу, про що ми поговоримо нижче) має тип (type). існує близько 20 різних значень, деякі з яких нині вже застаріли. на малюнку 14.7 показані деякі з цих значень. тип запиту це надмножина (множина, підмножиною якого є дана безліч) типів: два із показаних значень, можуть бути використані тільки в питаннях.