Зміст
Введення
1. DNS-сервер
2. База даних DNS
3. Система російських доменних імен
4. Принципи роботи динамічного DNS
Висновок
Список використаної літератури
Введення
DNS - Domain Name Service Служба Доменних Імен, призначена для того, щоб машини, що працюють в Internet, могли по доменному імені дізнатися IP-адресу потрібної їм машини, а також деяку іншу інформацію, а я за IP-номеру могли дізнатися доменне ім'я машини.
DNS була розроблена для іменування машин в глобальній мережі. Основною особливістю глобальної мережі є розподілене адміністрування, коли один адміністратор фізично не може устежити за виділенням імен. Тому Служба Доменних Імен функціонує на принципі делегування повноважень. Кожна машина або знає відповідь на питання, або знає кого запитати. При правильному функціонуванні система замкнута, тобто якщо така інформація є у кого-небудь, то вона буде знайдена і повідомлена клієнту, або, якщо питання не має відповіді, клієнт отримає повідомлення про неможливість отримання відповіді на запитання.
У кожного комп'ютера в Інтернеті є два основних ідентифікатора: доменне ім'я (наприклад, www.listsoft.ru) і IP-адресу (наприклад, 127.0.0.1). Приблизність полягає в тому, що, по-перше, IP-адрес у комп'ютера може бути кілька (мало того, що у кожного інтерфейсу свою адресу, так ще й кілька адрес можуть "висіти" на одному інтерфейсі), по-друге, імен теж може бути декілька, причому вони можуть зв'язуватися як з одним, так і з декількома IP-адресами, по-третє, у комп'ютера може і не бути доменного імені ... Словом, ясно, що картина вже починає заплутуватися.
Мета контрольної роботи. Доменні імена. Як працює DNS-сервер
1. DNS-сервер
Основним завданням DNS-сервера є трансляція доменних імен в IP-адреси і навпаки.
Як було сказано вище, основним завданням DNS-сервера є трансляція доменних імен в IP адреси і навпаки. На зорі становлення Інтернету (коли він ще був ARPANET'ом) це вирішувалося веденням довгих списків, що включають всі комп'ютери мережі, причому копія такого списку повинна була бути присутньою на кожному комп'ютері. Зрозуміло, що із зростанням мережі ця технологія перестала задовольняти кого б то не було - адже ці файли треба було ще і синхронізувати, не кажучи вже про їх розмір ... Деякі "пережитки" цього методу можна виявити і зараз: існує файл HOSTS (і в UNIX, і в Windows), в якому можна прописувати адреси серверів, з якими ви регулярно працюєте (до речі, саме його використання лежить в основі багатьох "прискорювачів Інтернету" - такі програми просто записують адреси серверів, до яких ви звертаєтеся, в файл HOSTS і при наступному зверненні беруть дані з нього, не витрачаючи час на запит до DNS-серверу).
На зміну "однофайловой" схемою прийшов DNS - ієрархічна структура імен. Існує "корінь дерева" з ім'ям "." (Крапка). Так як корінь єдиний для всіх доменів, то точка в кінці імені зазвичай не ставиться (але вона використовується в описах DNS - тут треба бути дуже уважним!). Нижче кореня лежать домени першого рівня. Їх небагато - com, net, edu, org, mil, int, biz, info, gov (є ще декілька) і домени держав, наприклад, ru. Ще нижче знаходяться домени другого рівня, наприклад, listsoft.ru. Ще нижче - третього і т.д.
DNS-сервер працює як хороший комп'ютерник: він завжди або знає відповідь, або знає у кого запитати ...
Кожен клієнт знає свого сервера; зазвичай вказується не один, а кілька серверів - якщо перший не відповідає, клієнт звертається до другого і так далі до вичерпання списку. У принципі неважливо, до якого сервера звертатися - вони дають (повинні давати при правильному функціонуванні) однакові відповіді на будь-який запит. Тому для прискорення роботи зазвичай вказують найближчий. Слід пам'ятати, що на одній машині можуть функціонувати одночасно Name-сервер і програми-клієнти, тому якщо на машині запущений Name-сервер, то як Name-сервера на ній повинен бути прописаний "я сам".
Є якийсь домен верхнього рівня з точкою: ".". Є дев'ять серверів (принаймні на моєму Name-сервері записано стільки), які відповідають за цю зону. Вони не знають жодної доменного імені - вони тільки авторизує сервери верхніх зон. Сервери верхніх зон теж гребують зберігати інформацію про конкретні машинах і передають це право нижележащим серверів. Тут вже з'являються перші згадки про конкретні машинах, так само як і відбувається авторизація нижележащих серверів.
Мені невідома жодна машина з доменним ім'ям з одного сегмента; дуже рідко використовуються доменні імена з двох сегментів; імена з трьох і чотирьох сегментів складають переважну частку всіх імен Internet; імена з п'яти сегментів зустрічаються досить рідко, а з шести і більше мені невідомі.
Припустимо, клієнт запросив адресу "www.організація. Місто. Країна". Пошук інформації по доменному імені відбувається наступним чином:
Клієнт запитує свого сервера.
Якщо той є сервером даної зони, то відповість, на чому все закінчується.
Сервер запитує кореневий сервер.
Той не може відповісти, бо не знає, зате знає, який сервер відповідають за зону "країна".
Сервер зони "країна" теж не може відповісти, але знає, що потрібно запитати сервер зони "місто, країна".
Той у свою чергу відсилає запит серверу зони "організація. Місто. Країна", який повідомить потрібну інформацію.
Це наближена модель, яка тим не менш дозволяє представити роботу системи DNS.
Однак цю струнку картину спотворюють системи кешування і вторинних серверів. Справа в тому, що отримавши відповіді на своє питання, DNS-сервер отримує також деяке число, яке говорить йому про те, в якому часовому ця інформація повинна вважатися застарілою. Таким чином, всі сервери, що брали участь в пошуку відповіді на питання, поставлене клієнтом, можуть (і швидше за все будуть) пам'ятати як відповідь на поставлене питання, так і шлях, по якому йшов пошук. При наступних запитах, що мають загальну праву частину з нещодавно зробленими запитами, пошук буде спрощено (прискорений).
Крім того, більшість зон має вторинні сервери, які містять копії даних з первинних серверів. Сервер вищерозміщеної зони може направити запит як первинного сервера, так і будь-якому з вторинних, грунтуючись на своїх міркуваннях про те, який з них ближче.
Хочу звернути особливу увагу на схожість, відмінність і взаємодію систем DNS і IP-маршрутизації. Як і IP-маршрутизація, DNS працює за принципом делегування повноважень, але виділення доменних імен зовсім не залежить від виділення IP-адрес. Для прикладу розглянемо домен freebsd.org. Це - домен організації, що займається поширенням операційної системи FreeBSD Unix. FTP-сервер, що містить дистрибутив операційної системи і безлічі утиліт для неї, має копії в декількох десятках країн. Імена серверів виглядають так:
http://ftp. freebsd.org / - первинний сервер в США
Таким чином, машини, що знаходяться в Росії виявилися довільно (з волі DNS-майстри з університету Bercley) включеними до домену freebsd. org, а проте, вони також складаються у своїх зонах. Система DNS дозволяє будь-якому DNS-майстру включити будь-який сервер у свою зону, хоча це включення нікого ні до чого не зобов'язує.
Проте, деяких сервісів цього недостатньо - так E-mail вимагає, щоб машина, яка бере лист, визнала своїм адресу, вказану в якості пункту призначення. Протокол HTTP 1.1 (в 1.0 цього не було) вимагає, щоб в HTTP-запиті вказувався не шлях до файлу, відрахований від кореня сервера (хоча такі запити теж визнаються), а й ім'я сервера, при цьому сам сервер знає, які імена - його , а решта обрізає та обслуговує відповідно до HTTP 1.0.
Делегування зони ... in-addr. arpa дається тільки від провайдера разом з IP-адресами. Власне, це пов'язано з призначенням ReverceDNS - повідомляти доменне ім'я по IP-адресою. Напевно майстер зони freebsd. org тримає Reverce-зону для IP-номерів, виділених університету Bercley; але всі ці сервери (крім сервера, розташованого в університеті) не входять в цю Reverce-зону, а значить, йому непідконтрольні.
Одна з проблем полягає в тому, що Reverce-зону можна виділити тільки на мережу класу A, B або C (на 16777216, 65536 або 256 адрес) і ніяк інакше. Можна отримати права на декілька зон одного або різних класів, але що робити тим, кому виділили менше 256 адрес? Адже в умовах вичерпання адресного простору не рідкість виділення пулу вже на 16 адрес
Як правило, провайдер надає клієнту цілий комплекс послуг. У число надаваних DNS-послуг входять:
делегування зони ... in-addr. arpa клієнтам, які мають пул адрес, кратний 256.
реєстрація доменного імені клієнта у власника тієї зони, в якій клієнт хоче зареєструватися;
підтримка вторинного сервера прямого і зворотного DNS-зон клієнта;
підтримання первинного сервера цих зон, якщо клієнт з будь-якої причини не підтримує їх сам (особливо це відноситься до випадку віртуальних зон і до випадку виділення малого пулу адрес);
Політика та стратегія призначення імен
Імена зон умовно можна розділити на "організаційні" та "географічні". У вищій зоні зареєстровані наступні "організаційні" зони:
com - commercial (комерційні)
edu - educational (освітні)
gov - goverment (урядові)
mil - military (військові)
net - network (організації, що забезпечують роботу мережі)
org - organization (некомерційні організації)
Ієрархічність DNS-серверів - штука досить цікава, якщо простежити проходження запиту. При установці (точніше, при налаштуванні) клієнту вказується як мінімум один DNS-сервер (як правило, їх два) - його адресу видається провайдером. Клієнт посилає запит цього сервера. Сервер, отримавши запит, або відповідає (якщо відповідь йому відомий), або пересилає запит на "вищий" сервер (якщо він відомий) або на кореневій (кожному DNS-сервера відомі адреси кореневих DNS-серверів). Так виглядає "висхідна ієрархія". Потім запит починає спускатися вниз - кореневий сервер пересилає запит серверу першого рівня, той - сервера другого рівня і т.д. Таким чином, кожен DNS-сервер працює як хороший комп'ютерник: він завжди або знає відповідь, або знає, у кого спитати ...
Крім "вертикальних зв'язків", у серверів є ще й "горизонтальні" відносини - "первинний - вторинний". Дійсно, якщо припустити, що сервер, що обслуговує якийсь домен і працює "без страховки" раптом перестане бути доступним, то всі машини, розташовані в цьому домені, виявляться недоступні! Саме тому при реєстрації домену другого рівня висувається вимога вказати мінімум два сервери DNS, які будуть цей домен обслуговувати.
Рекурсивні сервера зручно використовувати в локальних мережах
DNS-сервера бувають рекурсивні і нерекурсівние. Перші завжди повертають клієнтові відповідь - вони самостійно відстежують відсилання до інших DNS-серверів і опитують їх. Нерекурсівние сервера повертають клієнтові ці відсилання, так що клієнт повинен самостійно опитувати вказаний сервер. Рекурсивні сервера зручно використовувати на низьких рівнях, зокрема, в локальних мережах. Справа в тому, що вони кешують всі проміжні відповіді, і при наступних запитах відповіді будуть повертатися набагато швидше. Нерекурсівние сервера зазвичай стоять на верхніх щаблях ієрархії - оскільки вони отримують дуже багато запитів, то для кешування відповідей ніяких ресурсів не вистачить.
Використання "пересильщіков" прискорює вирішення імен
Корисною властивістю DNS є вміння використовувати "пересильщіков" (forwarders). "Чесний" DNS-сервер самостійно опитує інші сервера і знаходить потрібну відповідь, але якщо ваша мережа підключена до Інтернету по повільної (наприклад, dial-up) лінії, то цей процес може займати досить багато часу. Замість цього можна перенаправляти всі запити, скажімо, на сервер провайдера, а потім приймати його відповідь. Використання "пересильщіков" може виявитися цікавим і для великих компаній з декількома мережами: у кожної мережі можна поставити щодо слабкий DNS-сервер, вказавши в якості "Пересильщік" більш потужну машину, підключену по швидкій лінії. При цьому всі відповіді будуть кешуватися на цьому потужному сервері, що прискорить вирішення назв для цілої мережі.
2. База даних DNS
Для кожного домену адміністратор веде базу даних DNS. Ця база даних являє собою набір простих текстових файлів, розташованих на основному (первинному) DNS-сервері (вторинні сервера періодично копіюють до себе ці файли). У файлах конфігурації сервера вказується, в якому саме файлі містяться описи будь зон, і чи є сервер первинним або вторинним для цієї зони.
Елементи бази DNS часто називають RR (скорочення від Resource Record). Базовий формат запису виглядає так:
[Ім'я] [час] [клас] тип дані
Ім'я може бути відносним або абсолютним (FQDN - Fully Qualified Domain Name). Якщо ім'я відносне (не закінчується крапкою - пам'ятаєте про кореневий домен?), То до нього автоматично додається ім'я поточного домену. Наприклад, якщо в домені listsoft.ru я опишу ім'я "www", то повне ім'я буде інтерпретуватися як "www.listsoft.ru." Якщо ж це ім'я вказати як "www.listsoft.ru" (без останньої крапки), то воно буде вважатися відносним і буде інтерпретовано як "www.listsoft.ru. Listsoft.ru."
Час задає інтервал часу в секундах, протягом якого дані можуть зберігатися в кеші сервера.
клас визначає клас мережі. Практично завжди це буде IN, що позначає INternet.
Тип може бути одним з наступних:
SOA - визначає DNS зону
NS - сервер імен для зони
A - перетворення імені в IP-адресу
PTR - перетворення IP-адреси в ім'я
MX - поштова станція
CNAME - імена машини
HINFO - опис "заліза" комп'ютера
TXT - коментарі або якась інша інформація
Є також деякі інші види, але вони набагато менш поширені.
У записах можна використовувати символи # і; для коментарів, @ для позначення поточного домену, () - дужки - для написання даних на декількох рядках. Крім того, можна використовувати метасимвол * в імені. Порядок записів не має значення за одним винятком: запис SOA повинна йти першою. Подальші записи вважаються відносяться до тієї ж зоні, поки не зустрінеться новий запис SOA. Як правило, після запису зони вказують записи DNS-серверів, а інші записи розташовують за абеткою, але це не обов'язково.
SOA - опис зони
Тепер спробуємо розглянути запису. Першою описуємо зону:
mycompany.ru. IN SOA ns. mycompany.ru. admin. mycompany.ru. (1001; serial
21600; Refresh - 6 годин
1800; Retry - 30 хв
1209600; Expire - 2 тижні
432000); Minimum - 5 днів
Спочатку йде ім'я домену: mycompany.ru. (Зверніть увагу на крапку в кінці імені). Замість імені можна було (і найчастіше так і роблять) поставити знак @.
ns. mycompany.ru. - Основний сервер імен
admin. mycompany.ru. - Поштова адреса адміністратора в форматі ім'я (точка) машина
потім у круглих дужках йдуть поля, необхідні для правильного "сприйняття" вашої зони іншими серверами. Перше число - serial - є "версією" файлу зони. При внесенні змін це число треба збільшити - якщо вторинний сервер побачить, що його версія зони менше, ніж у первинного сервера, то він перечитає дані. Типовою помилкою є оновлення зони без оновлення цього числа. Дуже зручно в якості serial використовувати поточну дату, наприклад, 2003040401 - 4 квітня 2003 року, перше оновлення.
Refresh говорить вторинним серверів, як часто вони повинні перевіряти значення serial.
Retry говорить про те, як часто вторинний сервер повинен намагатися прочитати дані, якщо первинний сервер не відповідає.
Expire говорить вторинним серверів, протягом якого часу вони повинні обслуговувати домен, якщо первинний сервер не відповідає. Після закінчення цього часу вторинні сервера будуть рахувати свої дані застарілими.
Minimum задає час життя записів за умовчанням для даної зони.
NS описує сервера імен
Тепер опишемо сервера імен, які обслуговують наш домен:
mycompany.ru. IN NS ns. mycompany.ru.
mycompany.ru. IN NS ns. provider.ru.
Тут нічого складного немає. Оскільки ім'я зони збігається із зазначеним у полі ім'я запису SOA, то його можна залишити порожнім.
A описує хости
Далі йдуть запису A, що описують ваші комп'ютери і дозволяють перетворити імена в IP-адреси.
major IN A 192.168.0.1
colonel IN A 192.168.0.2
IN HINFO "2xPIV-1.7 Win2K"
general. mycompany.ru. IN A 192.168.0.3
Тут складного теж нічого немає - імена можуть бути відносні або "абсолютні", можна додати записи про конфігурації машини (пропущене ім'я в записі HINFO говорить про те, що мається на увазі попереднє ім'я). Не забудьте додати записи
localhost. IN A 127.0.0.1
localhost IN CNAME localhost.
mycompany.ru. IN A 192.168.0.1
Перша віддає адресу 127.0.0.1 будь-якій машині, що запросила ім'я localhost, друга - localhost. mycompany.ru, а третя говорить, куди послати клієнта, який хоче потрапити на mycompany.ru
C допомогою CNAME можна задавати короткі імена серверів
Записи CNAME дозволяють дати машинам зручні або значущі імена. Наприклад:
ftp IN CNAME general каже, що ftp. mycompany.ru мешкає за адресою 192.168.0.3. CNAME зручно використовувати, якщо ви змінюєте назву машини, але щоб дозволити доступ для клієнтів, які пам'ятають старе ім'я. Зручний трюк з використанням CNAME полягає в призначенні коротких імен часто використовуваним адресами. Наприклад, прописавши ls IN CNAME www.listsoft.ru., Ви зможете заходити на ListSoft просто набираючи ls в якості адреси.
MX описує пересилання пошти.
Записи MX потрібні для того, щоб вказати, куди пересилати пошту. У цих записах додається пріоритет - чим він менший, тим вищий пріоритет машини. Пріоритети потрібні для того, щоб можна було задати кілька записів і перенаправити пошту на альтернативний сервер, якщо основний не працює. MX запис повинна бути вказана для домена в цілому і, можливо, для кожної машини окремо. Складного тут теж нічого немає за одним винятком: дуже часто зустрічається неправильно використання метасимвола "*". Запис "*. mycompany.ru." означає не "будь-яка машина домену mycompany.ru", а "будь-яка машина, яка ще не була описана". Причому, навіть якщо використовувалася не MX, а, наприклад, A-запис, то зірочка все одно не буде працювати для цієї машини. Більш докладно почитати про використання метасимволів можна в RFC 1034, розділ 4.3.3 У принципі, метасимволи потрібні тільки для того щоб приймати пошту для мережі, що знаходиться за брандмауером і щоб пересилати пошту в мережі, не підключені до Інтернету (наприклад, що працюють через UUCP) . Так як записи DNS змінюються досить рідко, то має сенс прописати MX запису для всіх машин, описаних записами A.
mycompany.ru. IN MX 10 relay
mycompany.ru. IN MX 20 mycompany.ru.
mycompany.ru. IN MX 30 mail. provider.ru.
general. mycompany.ru. IN A 192.168.0.3
IN MX 10 mycompany.ru.
Реверсна зона дозволяє визначити ім'я за адресою
На цьому створення файлу зони можна вважати закінченим. Але залишається більш захоплююче заняття: опис реверсної зони. Якщо попередній файл дозволяє визначити IP-адресу на ім'я, то тепер треба зробити так, щоб по IP-адресою можна було "вирахувати" ім'я. Відсутність реверсної зони є досить типовою помилкою і може призводити до самих різних помилок - починаючи від збоїв FTP-серверів і закінчуючи класифікацією відправлених листів як спаму.
PTR перетворює адреса в ім'я.
Для зворотного перетворення використовуються записи PTR. Але не поспішайте їх вписувати - тут є одна хитрість: вони пишуться в окремому спеціальному домені верхнього рівня, з назвою IN-ADDR. ARPA. Домен цей був створений для того, щоб і для прямого, і для зворотного перетворень можна було використовувати одні й ті ж програмні модулі. Справа в тому, що "мнемонічні" імена пишуться зліва направо: www.listsoft.ru означає, що www знаходиться в listsoft, а listsoft - в ru. IP-адреси пишуться навпаки: 195.242.9 4 означає, що машина 4 знаходиться в підмережі 9, яка є частиною 195.242 І для збереження "єдиного стилю" адрес для зворотного перетворення використовуються імена виду 4.9 242.195. IN-ADDR. ARPA (зверніть увагу, що IP-адреса записана в зворотному порядку).
Отже, ми створюємо ще один файл зони (для зони, наприклад, 0.168.192. IN-ADDR. ARPA), копіюємо в нього запис SOA (а заодно і NS), після чого починаємо писати:
1 IN PTR major. mycompany.ru.
2 IN PTR colonel. mycompany.ru.
Можна задавати не тільки відносні, а й абсолютні імена:
3.0.168.192. IN-ADDR. ARPA. IN PTR general. mycompany.ru.
Не забудьте ще поставити зворотне перетворення для 127.0.0.1.
Зверніть увагу на те, що право на ведення "прямого" домену не залежить від провайдера - його видає організація, яка відає розподілом імен в потрібному вам домені. А ось пул IP-адрес знаходиться у веденні провайдера, і саме провайдер делегує (або не делегує) вам права на ведення реверсної зони. У зв'язку з тим, що часто клієнтам видається не ціла мережа класу "C", а її частина, то й реверсна зона знаходиться на сервері провайдера. Так що вам доведеться налагодити з ним взаємодія в області оновлення даних.
Налаштуйте трансфер зони.
Наостанок - одне маленьке зауваження. Дослідження DNS є одним з перших етапів "вивчення мережі" при підготовці її злому. Найчастіше використовується перенесення зони, при якому всі записи зони передаються на комп'ютер "дослідника", де він їх може вивчати в спокійній обстановці. Тому має сенс (крім усього іншого) налаштувати брандмауер на заборону TCP-з'єднань по 53 порту з несанкціонованих адрес (у запитах на визначення імен використовується UDP, а для перенесення зони - TCP).
3. Система російських доменних імен
Яким чином вона працює, розповідає провідний фахівець web-студії "Дизайн-Бюро" Костянтин Шепелін (початок дивіться у попередньому номері).
Система доменних імен - DSN - є основою зручного доступу до серверів Інтернет, дозволяючи використовувати замість їх справжніх цифрових адрес (IP) легко запам'ятовуються словесні позначення, наприклад www.1ru.ru замість 64.45.60.67. Однак за існуючими стандартами доменні імена, тобто фрагменти інтернет-адрес в текстовій формі, повинні складатися із символів ASCII-коду, букв латиниці і цифр, причому допускаються дефіси всередині імен. Технологія, запропонована компанією VeriSing, дозволяє обійти це обмеження. Для того, щоб використовувати символи національних алфавітів, в тому числі і російського, їх потрібно перекодувати в Unicode, що, до речі, вирішує проблему наявності безлічі кодувань, а потім за спеціальним алгоритмом перетворюються в унікальну послідовність "дозволених" ASCII-символів. Наприклад, слово "банк" перетворюється в AQYTAPJ2. До цієї рядку, однозначно відповідної кириличної запису, додається спеціальний префікс BQ - (з двома дефісами). Він служить для того, щоб відрізняти перетворені доменні імена від випадкових наборів ASCII-символів. Такий формат запису називається RACE (Row-based ASCII Compatible Encoding). У результаті адреса сайту www.россія. org перетвориться в www.BQ--ARAD4QKBHBHQ. ORG. Саме RACE-адреса домену зберігається в базах даних DNS, завдяки чому перебудова існуючої світової системи доменних серверів і заміна програмного забезпечення на вашому веб-сайті не потрібно.
В даний час для роботи з багатомовними доменннимі іменами на комп'ютері клієнта (наприклад, відвідувача сайту) повинна бути встановлена спеціальна програма, яка перетворює символи національного алфавіту в RACE-формат, який і використовується при запиті до DNS.
Надалі підтримка багатомовними доменів буде вбудовуватися безпосередньо в операційні системи і браузери. Для розробників ПЗ, які бажають забезпечити підтримку національних доменних імен в своїх продуктах, компанія VeriSing розробила безкоштовний набір бібліотек (SDK).
Враховуючи складність впровадження нової системи доменних імен, компанія розділила її тестову експлуатацію і введення в дію на кілька етапів. Вже зараз ви можете зареєструвати доменне ім'я ім'я російською мовою, проте його делегування буде зроблено тільки після завершення створення необхідної інфраструктури.
На першому етапі всі зареєстровані національні імена в RACE-форматі розміщуються у вигляді доменів третього рівня в тестовій зоні mltbd.com / net / org. Зареєструвавши сайт www.РОССІЯ. org, ви зможете побачити в мережі віртуальний сервер BQ - ARAD4QKBHBHQ. mltbd. org. Оскільки DNS не враховує різницю між заглвнимі і малими символами, то верхній регістр використовується просто для спрощення сприйняття. На сторінці за цією адресою міститься коротка інформація про хід тестування і підтвердження досягнення зареєстрованого домену. На другому етапі створені в зоні mltbd.com / net / org піддомени будуть делеговані власникам відповідних доменів другого рівня.
Таким чином, набравши в браузері www.BQ--ARAD4QKBKBHBH. mltbd. org, користувач потрапляє на сайт www.РОССІЯ. org, а точніше, на сторінку, яка визначається сервером імен РОСІЯ. org. І, нарешті, третій етап - це безпосереднє делегування доменів в зонах.com,. net і. org, тобто адреса www.BQ--ARAD4QKBHBHQ. org призведе користувача безпосередньо на сайт www.РОССІЯ. org /.
4. Принципи роботи динамічного DNS
Комп'ютер, що підключається до мережі Інтернет, незалежно від існуючих на ньому налаштувань, бачиться всім іншим по деякому IP-адресою. Ця адреса може бути постійним, прописаним в настройках комп'ютера і не змінюється при підключенні до Мережі, а може бути динамічним, присвоювати йому на поточний сеанс зв'язку провайдером. У другому випадку ця адреса при кожному підключенні може надаватися відмінним від попереднього. Якщо ж ви хочете, щоб до вашого комп'ютера могли звертатися ваші друзі чи інші відвідувачі, його IP-адреса має бути постійним.
Так, інтернет-сервіси можуть розташовуватися не тільки на спеціально виділених для цього серверах, але і на домашніх комп'ютерах. На такому комп'ютері може розміщуватися сайт, каталог файлів або картинок, поштову або ігровий сервер. Але якщо ваш IP-адреса буде динамічним, то при кожному підключенні до Мережі вам потрібно буде посилати його своїм постійним відвідувачам, щоб вони могли потрапити на ваш сайт. До того ж, підключатися до сайту їм доведеться по IP-адресою, а не по його назві. Що робити, щоб уникнути подібної проблеми?
Один спосіб - придбати у провайдера постійна адреса і використовувати його. Дуже проста ситуація, але не безкоштовна. За таке "задоволення" доведеться викладати цілком відчутну суму. Але в останні роки з'явилися інші можливості забезпечити доступ до комп'ютера з Інтернету, не вимагають при цьому звернення до провайдера. З'явилися служби (Dynamic DNS сервіси) дозволяють це робити для динамічно виділяються адрес. Базові послуги ними, як правило, надаються безкоштовно, а от за додаткові можливості доведеться платити.
Сервіс DDNS складається з двох компонентів. Перша - спеціальне ПЗ, яке працює на віддаленому комп'ютері. Друга - клієнтська програма, що встановлюється на робоче місце. Перша компонента відповідає за взаємодію зі своїм DNS, налаштуванням і підтримкою облікові записи користувачів. Клієнтська частина забезпечує зв'язок з серверної, передає їй поточне значення виділеного для даного з'єднання адреси, забезпечує деякі додаткові настройки.
Суть рішення полягає в наступному. Клієнт сервісу створює на ньому свою обліковий запис і або реєструє субдомен на базі домену сервісу, або прописує вже наявне у власника ім'я домену (можна реєструвати на сервісі і ті домени, про які вже є запис на DNS-серверах, але їх буде потрібно скоригувати). При реєстрації субдомену заповнюються дані, які зазвичай заповнюються при реєстрації. Потрібно це для того, щоб занести в службі імен (DDNS) інформацію в необхідному вигляді та обсязі. Після цього виконується запис відомості про домен з урахуванням IP-адреси, за яким користувач в момент реєстрації підключався до сервісу. Так домен виявляється пов'язаним з цією адресою. Після цього користувач викачує і встановлює клієнтську частину. При підключенні до Інтернету вона пов'язує виділений на дану сесію адресу із зареєстрованим доменом. При зміні адреси відомості, записані в DDNS, оновлюються. Тепер будь-який бажаючий, набравши в рядку браузера адресу вашого сайту, потрапить на ваш комп'ютер.
Невеликий відступ. Такий варіант виявляється дуже зручним при наявності ADSL-підключення, коли біля комп'ютера довгий час залишається один і той же адреса, а перепідключення бувають дуже рідкісними. При підключенні до Мережі за допомогою модему ситуація дещо ускладнюється тим, що зміна IP-адреси буває набагато частіше, до того ж, в проміжках між підключеннями пов'язаний з доменом адресу буде видаватися будь-кому іншому. У результаті відвідувачі домену будуть отримувати повідомлення про те, що шукана сторінка не знайдена. Але на такі витрати доводиться йти, якщо використовується тільки модемне з'єднання.
Розміщуючи інтернет-сервіси на своєму домашньому комп'ютері, не можна забувати про необхідність його захисту. Як тільки ви надасте можливість доступу ззовні, до вас почнуть "заходити" не тільки відвідувачі, але і любителі легкої наживи, розповсюджувачі троянів, вірусів і інших гидот. Тому в обов'язковому порядку необхідно встановлювати як антивірусне ПЗ, так і файрволи. Але в цьому випадку буде потрібно додаткове налаштування. Вам доведеться відкрити для доступу порти, до яких ви прив'яже свої сервіси. Це можуть бути як стандартні порти (наприклад, порт 80 для веб-сервера), так і нестандартні (перш ніж призначати нестандартні, порти переконайтеся, що сервіс DDNS підтримує перенаправлення запитів із стандартних портів на нестандартні). Найбільш часто перепризначення стандартного порту потрібно у випадку встановлення поштового сервера. Провайдери, як правило, забороняють доступ до 25 порту, тому його доводиться перепризначувати на інший порт.
Є відмінності в налаштуванні файрволов, заснованих на використанні проксі або без нього. У першому випадку потрібно налаштування клієнта на використання проксі і видача йому "дозволу" на вихід в Інтернет. У разі використання файрвола, що працює на основі NAT, достатньо лише вказати його адресу в налаштуваннях клієнтської програми.
Як вже говорилося, клієнтська частина служить для передачі на сервіс поточного значення IP-адреси. Але іноді виникають ситуації, що клієнт спочатку виявляє локальний IP-адреса комп'ютера і намагається передати на сервіс його, а не ту адресу, який видає провайдер. Для того щоб уникнути подібної ситуації, потрібно внести локальну адресу в список ігнорованих адрес при налаштуванні клієнта.
Розглянемо, які послуги і можливості пропонують DDNS-сервіси. Візьмемо, наприклад, сервіс Dynu.com.
Підтримка доменів.
Безкоштовний сервіс забезпечує підтримку піддоменів в доменах dynu.com і dynu. net. Домени в зонах *. com, *. net, *. biz, *. co. jp, *. de та інших підтримуються в платному сервісі.
Динамічне оновлення IP-адрес.
Клієнтська частина сервісу є для таких платформ, як Windows 9x/NT/2000/XP, Mac OS, Mac OS X, Linux, FreeBSD, Solaris, Unix.
Підтримка піддоменів (аліасів) зареєстрованого домену
Безкоштовний сервіс забезпечує підтримку таких аліасів, як ftp, mail, www і інших, прив'язаних до одного й того ж адресою. А платний сервіс дозволяє пов'язувати будь-які піддомени з різними IP-адресами (наприклад, якщо ваш веб-сервер і поштовий сервер розміщені на різних комп'ютерах, що мають роздільне підключення до Інтернету).
Підтримка протоколу SSL.
Перенаправлення HTTP-порту.
Дозволяє переналаштувати стандартний HTTP-порт (80) на будь-який інший. Ваш веб-сервер, відповідно, повинен бути налаштований на потрібний порт.
Онлайн-перенаправлення.
У той час, коли ви підключені до сервісу, дозволяє перенаправляти користувачів, що запитують вашу сторінку, на будь-який інший сайт.
Розподіл навантаження на сервер.
При великій відвідуваності вашого ресурсу в платній версії сервісу є можливість використовувати технологію RoundRobin. Вона полягає у створенні кількох записів доменного імені з прив'язкою кожної з них до окремого IP-адресою. Таким чином, відвідувачі будуть перенаправляти на різні комп'ютери в залежності від їх завантаження.
Іншим популярним сервісом вважається DNS2Go. Більшість наданих послуг є безкоштовними. За своєю функціональністю сервіс дуже близький до сервісу Dynu.com, а ось безкоштовних можливостей дає трохи більше. Крім уже перерахованих можливостей, DNS2Go надає послуги з перенаправлення електронної пошти (послуга - платна). Вона включає захист від вірусів і спаму, перенаправлення пошти, пересилання на інший адресу, хостинг поштового сервера. Послуга може бути корисною тим, хто не може тримати встановлений на домашньому комп'ютері поштовий сервер, постійно підключений до Інтернету.
Висновок
Всі компьютеpов, об'єднані в Internet, pаботают над упpавлением власних операційну систему, але всі вони спілкуються між собою на єдиному мовою компьютеpних мереж ТСР / IP (протоколів упpавления пеpедачей над протоколів Internet). По суті це два протоколів TCP / IP.
IP - (Internet Protocol) - визначає, як буде виглядати КВАЛІФІКАЦІЙНА під час подорожі по суші і що з нею робити, а також опpеделяет як pаботает система адpессаціі.
Кожен компьютеp в мережі має свій адpес (4 цифри) ТСР протоколів - для визначених типу КВАЛІФІКАЦІЙНА, міститися в пакеті даних, а також випливає, щоб дані обов'язково дійшли до адpессата.
TCP протоколів - визначених типу КВАЛІФІКАЦІЙНА, міститися в пакеті даних, а також стежить, щоб дані обов'язково дійшли до адpессата. Імена сеpвеpов в Internet визначає, як стpок, напpимеp, jsc. nasa. gov, однак, це не є дійсною частиною протоколів TCP / IP. Існує універсального зовнішній механізм пpеобpазования таких імен в IP адреси, якому розуміє TCP / IP. Цей механізм називається Системою Доменних Імен (DSN), Т.ч. немає необхідності знати IP адреси компьютеpов, до котоpим ми хочемо обpатиться. Напpимеp, якщо компьютеp А хоче знати IP-адpес компьютеpа jsc. nasa. gov, то він робить запpос на глобальний сеpвеp DNS. Цей сеpвеp не знає IP-адреси, але зате знає сеpвеp-DNS, якому знає всі адреси, що закінчуються на nasa. gov і пеpесилает запpос на цей локальний сеpвеp, якому і повідомляє А необхідний IP-адреса.
Список використаної літератури
Інформатика: Підручник / за ред. Н.В. Макарової. - М.: Фінанси і статистика, 2000. - 768 с.
Інформатика. Базовий курс. Підручник для Вузів / під ред. С.В. Симоновича, - СПб.: Пітер, 2000.
Денисов О., Віхарєв І., Бєлов А. Самовчитель Інтернет. - Спб: Питер, 2001. - 461 с.
Коцюбинський А.О., Грошев С.В. Сучасний самовчитель роботи в мережі Інтернет. М.: Тріумф, 2007.
Основи сучасних комп'ютерних технологій: Навчальний посібник / під. ред. Хомоненко. - СПб.: КОРОНА, 2005.
Симонович С.В., Євсєєв Г.А., Практична інформатика, Навчальний посібник. М.: АСТпресс, 2005.
Савельєв О.Я., Сазонов Б.А., Лук'янов Б.А. Персональний комп'ютер для всіх. Зберігання та обробка інформації. Т.1 М.: Вища школа, 2001.
Тюрін Ю.М., Макаров А.А. Статистичний аналіз даних на комп'ютері. Під ред.В.Е. Фигурновой. М.: ИНФРА-М, 1998.
Фігурне В.Е. IBM PC для користувача. М.: Инфра-М, 2001 р.
Фролов А.В., Фролов Г.В. Глобальні мережі комп'ютерів. Практичне введення в Internet, E-Mail, FTP, WWW і HTML. М.: Діалог-МІФІ, 2006.