У фізичному плані делегування дуже схоже на те, як менеджер делегує відповідальність за виконання завдань своєму персоналу. Результати однакові, проте в процесі було залучено більше однієї людини. Керівник отримує запит на роботу, передає відповідальність іншому члену персоналу і або працівник, або керівник повертається з результатами роботи. Це все за умови, що робота, яку виконує співробітник, насправді правильна і це те, про що попросив оригінальний запитувач (або що запитувач насправді попросив щось, що було дійсно в першу чергу!).
З делегацією DNS це дуже схоже. Коли comсервери імен запитують місце для пошуку повноважень зони example.com, вони часто делегують цю роботу окремим серверам імен (адже в переважній більшості випадків вони фактично делегують відповідь іншим серверам імен). Коли ви вперше реєструєте домен, скажімо, наш example.comдомен, це часто робиться через третю сторону, яку називають реєстратором. Зазвичай практика реєстраторів розміщувати на своїх серверах імен для делегування та обслуговувати зону за замовчуванням з цих серверів імен. Ця зона по замовчуванням включає в себе основні вимоги для обслуговування цієї зони в Інтернеті (в SOA, NSі Aзапис , пов'язану з цим NS записи).
Очевидно, що якщо ви самі хочете взяти під контроль повноваження домену, вам доведеться попросити реєстратора замість цього домену своєму серверу імен. Різні реєстратори посилаються на це в процесі по-різному: "зміни серверів імен", "використання сторонніх DNS", "Додати записи клею" тощо. Механізм під ним залишається колишнім. Ви надаєте, як правило, 2 або більше "імен серверів імен" (наприклад, ns0.example.comі ns1.example.com) та IP-адреси, за якими ns0і ns1знаходяться. Потім вони обробляють запит, і делегація спрямовується від вашого реєстратора до наданих вами серверів імен.
З технічної точки зору, це на даний момент , ви повинні забезпечити ваші сервера імен і працює, які обслуговують домен example.com, з мінімумом в SOA(початок запису повноважень), 1 або більше NSзаписи і Aзапису (ІПС) , що ці NS записи вирішено з:
example.com. IN SOA ns0.example.com. hostmaster.example.com. ( 10 3600 900 604800 7200 )
IN NS ns0.example.com.
IN NS ns1.example.com.
ns0 IN A 192.0.2.8
ns1 IN A 192.0.2.44
(Я вибрав декілька загальних довільних значень для значень SOA, імен для записів NS та IP-адрес, на які вирішуються сервери імен). Усі вони повинні відображати зону, для якої ви обслуговуєте.
Ця служба DNS повинна бути видимою з будь-якого місця в Інтернеті, а не підлягати фаєверляції (тобто порт 53 udp та вхідний tcp повинні бути дозволені). Також ваш постачальник послуг також не повинен блокувати цей порт (що деякі провайдери блокують вхідний трафік, призначений для цих портів).
З огляду на моє початкове порівняння, то comнеймсервери є менеджерами DNS, які делегують зону example.comна сервера імен (співробітники) , щоб зробити роботу з надання базової інформації про зону ( SOA, NS, A). Ви також можете обслуговувати будь-які додаткові записи, такі як записи поштового сервера MXабо можуть бути Aзаписами для вашої www.example.comадреси.
Якщо цей сервер імен не виконує роботу, повертає неправильні результати або має сторонню сторону (брандмауер / провайдер), що блокує роботу, у вас не буде робочого DNS і перерви делегації.
Це може бути також варто відзначити , що домен не повинен бути делегована серверів імен в тому ж домені, так ns0.example.netі ns0.example.orgобидва могли бути дійсними сервера імен , які могли б example.comїм делеговані. За умови, що обидва ці сервери імен обслуговували example.comдомен.