Какво е DNS? Обяснени концепции за система за имена на домейни, DNS сървър и IP адрес

Въведение

До края на тази статия трябва да разберете по-добре:

  1. Какво е DNS и какво прави
  2. Какво правят DNS сървърите
  3. Как работят адресите на интернет протокола (IP) в контекста на DNS

Важни понятия

Има някои основни умствени модели, с които трябва да се запознаете, когато научавате за DNS, DNS сървъри и IP адреси. Преминаването през тези концепции сега, преди да започнете да научавате за DNS, ще

  • да помогне да се осмислят всички различни термини, използвани за описване на поведение, което се вписва в тези модели, и
  • помощ при задържане на паметта.

Психичните модели ви дават референтна рамка, когато нещата станат малко странни и непознати.

Така че нека поставим основите.

  • Запитване и отговор. Това е, когато Thing 1 моли Thing 2 за нещо и Thing 2 отговаря на тази молба. Като този:
  • Взаимоотношения родител-дете и графики, които изглеждат по този начин (само по-сложни).
  • Съобщения. Това не е заявка и отговор, защото няма отговор. В света на DNS форматирането и съдържанието на съобщенията варират в зависимост от употребата.
  • Връзка клиент-сървър. Най-просто казано, сървърът е софтуер или хардуерно устройство, което предоставя функционалност за други софтуерни или хардуерни устройства, наречени „клиенти“.

    Подгответе се за много разговори за сървърите. Както се оказва, има много сървъри, които влизат в това нещо, което ние наричаме DNS, и как ние като хора го използваме, когато се свързваме с интернет.

Какво е DNS?

Системата за имена на домейни (DNS) преобразува човешки имена на домейни (в URL адреси или в имейл адрес) на IP адреси. Например DNS превежда и картографира домейна freecodecamp.org на IP адреса 104.26.2.33.

За да ви помогне да разберете напълно това описание, този раздел подробно описва:

  • Исторически контекст за развитието на DNS - какви проблеми бяха и решаването на IP адреси?
  • Имена на домейни
  • IP адреси

Исторически контекст

През 1966 г. Агенцията за напреднали изследователски проекти (ARPA), правителствена агенция на САЩ, основава компютърна мрежа, наречена ARPAnet. С прости думи, помислете за ARPAnet като за първата итерация на това, което днес познаваме като Интернет.

Включени са основните цели на ARPAnet

„(1) осигуряване на надеждна комуникация дори в случай на частична повреда на оборудване или мрежа, (2) възможност за свързване с различни видове компютри и операционни системи и (3) по-скоро съвместни усилия, отколкото монопол, контролиран от един-единствен корпорация. За да осигури надеждна комуникация в случай на повреда на оборудването, ARPANET е проектиран така, че нито една точка или връзка да не е по-критична от която и да е друга. Това беше придружено от изграждането на излишни маршрути и използването на пренасочване на данни в движение, ако някоя част от мрежата се провали. “

Проблемите

DNS и TCP / IP бяха критични при решаването на два проблема с ARPAnet:

За ARPAnet имаше едно местоположение (файл, наречен HOSTS.TXT), който съдържаше всички съпоставяния от име на адрес за всеки хост в мрежата.

„HOSTS.TXT се поддържаше от мрежовия информационен център на SRI (наречен„ NIC “) и се разпространяваше от един хост, SRI-NIC. [*] Администраторите на ARPAnet обикновено изпращаха своите промени в NIC и периодично FTP’ed към SRI- NIC и взе текущия файл HOSTS.TXT. Техните промени бяха компилирани в нов файл HOSTS.TXT веднъж или два пъти седмично. "

При тази настройка имаше три предизвикателства:

  1. Трафик и натоварване - разпространението на файла става твърде много, за да може отговорният хост да се справи.
  2. Сблъсъци на имена - всеки хост трябваше да има уникално име и нямаше централизиран орган, който да попречи на мрежовите потребители да добавят хост с конфликтно (не-уникално) име, като по този начин „наруши цялата схема“.
  3. Последователност - актът на актуализиране на файла и гарантиране, че всички хостове имат най-актуализираната версия, стана невъзможен или поне много труден.

По същество, HOSTS.TX беше единична точка на отказ, така че целият процес тук не се мащабира добре след определен брой хостове. ARPAnet се нуждаеше от децентрализирано и мащабируемо решение. DNS беше това. Източник

Комуникацията между хост и хост в същата мрежа не беше достатъчно надеждна. TCP / IP помогна за решаването на този проблем.

  1. Протоколът за контрол на предаването (TCP) предоставя мерки за осигуряване на качеството за процеса на превръщане на съобщенията (между хостовете) в пакети. Протоколът TCP е ориентиран към връзката, което означава, че трябва да се установи връзка между хост източник и хост дестинация.
  2. Интернет протоколът (IP) дефинира как се пренасят съобщения (пакети) между хост източник и хост дестинация. IP адресът е уникален идентификатор за определен път, който води до хост в мрежа.
  3. TCP и IP работят в тясно сътрудничество, поради което обикновено се посочват като „TCP / IP“.
  4. Въпреки че няма да се впускам в него в тази статия, както TCP, така и потребителски протокол за Datagram (UDP) се използват в слоя за пренос на данни на DNS. UDP е по-бърз, много по-малко надежден и не изисква връзки; TCP е по-бавен, много по-надежден, но се нуждае от връзки. Те се използват при необходимост и подходящи в DNS; излишно е да казвам, че включването на TCP в APRAnet беше ценно допълнение към слоя за пренос на данни.

До началото на 80-те години DNS и TCP / IP (и следователно IP адресите) бяха стандартни оперативни процедури за ARPAnet.

Тази история е много съкратена. Ако искате да научите повече за тези теми, моля, направете справка с раздела Ресурси в края на тази статия.

Сега, когато имаме известен исторически контекст, нека преминем към научаването на повече за имена на домейни и IP адреси.

Имена на домейни

В контекста на DNS, име на домейн предоставя удобен начин за насочване към нелокални ресурси. Това може да е уебсайт, пощенска система, сървър за печат или друг сървър, който е достъпен в Интернет. Името на домейн може да бъде нещо повече от уебсайт!

„Целта на имената на домейни е да осигурят механизъм за именуване на ресурси по такъв начин, че имената да се използват в различни хостове, мрежи, семейства протоколи, интернет и административни организации.“

Името на домейн е много по-лесно да се запомни и въведе в терминал или интернет браузър, отколкото IP адрес.

Името на домейн е част от Унифициран локатор на ресурси (URL), но термините не са синоними . URL адресът е пълният уеб адрес на ресурс, докато името на домейна е името на уебсайт и е подкомпонент на всеки URL адрес.

Въпреки че има технически разграничения между URL адреси и имена на домейни, уеб браузърите обикновено ги третират по един и същи начин, така че ще стигнете до уебсайта, ако въведете пълния уеб адрес или само името на домейна.

Домейни от първо ниво и домейни от второ ниво

Във всеки даден домейн има две части: домейн от първо ниво (TLD) и домейн от второ ниво (SLD). Частите от име на домейн стават по-специфични при преместване отдясно (края) наляво (началото).

Това в началото може да обърка. Например, нека разгледаме „freecodecamp.org“

  • URL: //www.freecodecamp.org
  • Име на домейн: freecodecamp.com
  • TLD: org
  • SLD: freecodecamp

В ранните дни на ARPAnet имаше ограничен брой TLD, включително com, edu, gov, org, arpa, mil и двубуквени кодове на държави. Тези TLD първоначално бяха запазени за институции, участващи в ARPAnet, но някои по-късно станаха достъпни на търговските пазари.

Днес има сравнително богатство от налични TLD, включително net, aero, biz, coop, info, музей, име и други.

Домейни от второ ниво са домейните, които са достъпни за индивидуална покупка чрез регистратори на домейни (например Namecheap).

IP адреси

Докато IP адресите са свързани с DNS по своята функция, самият Интернет протокол е технически отделен от DNS. Вече предоставих исторически контекст за това разграничение, така че сега ще обясня как функционират IP адресите.

IP адресът, както беше споменато по-горе, е уникален идентификатор за конкретен път, който води до хост в мрежа. Бих искал да се позова на аналогията на телефонен номер и телефон: телефонният номер не представлява самия телефон, това е просто начин да се свържете с човека с телефона.

Тази аналогия е разумно подходяща (поне на повърхностно ниво) с IP адреси. IP адресът представлява крайна точка, но не е самата крайна точка. IP заданията могат да бъдат фиксирани (постоянни) или динамични (гъвкави и могат да бъдат преназначени).

Подобно на име на домейн, организацията на IP адресите следва йерархична структура. За разлика от имената на домейни, IP адресите стават по-конкретни, като се движат отляво надясно. Това е пример за IPv4 по-долу:

Диаграмата показва, че 129.144 е мрежовата част, а 50.56 е хост частта на IPv4 адрес.
  • Мрежа: уникалният номер, присвоен на вашата мрежа
  • Хост: идентифицира хоста (машината) в мрежата

Ако е необходима по-голяма конкретност, мрежовите администратори могат да подмрежи адресното пространство и да делегират допълнителни номера.

Колко IP адреса има?

IPv4 беше първата итерация на IP, която ARPAnet използва в производството. Внедрена в началото на 80-те години, тя все още е най-разпространената IP версия. Това е 32-битова схема и следователно може да поддържа малко над 4 милиарда адреси.

Но изчакайте, достатъчно ли е това? Не.

IPv6 има 128-битова схема, която му позволява да поддържа 340 недецилионни адреса. Той също така предлага подобрения в производителността на IPv4.

Примерен IPv4 адрес:

  • 104.26.2.33 (freeCodeCamp)

Примерен IPv6 адрес:

  • 2001: db8: a0b: 12f0 :: 1 (компресираният формат и не сочи към freeCodeCamp)

Как работи системата за имена на домейни?

И така, научихме за имена на домейни! Научихме за IP адресите! Сега как се отнасят към системата за имена на домейни?

На първо място, те се вписват в пространството на имената.

Пространството на имена на домейни

Както се подразбира от езика „домейн“ от първо ниво и домейн „второ“ ниво, пространството от имена се основава на йерархия

“... с йерархията, приблизително съответстваща на организационната структура, и имена, използващи„. “ като знак за маркиране на границата между йерархичните нива. " Източник.

Тази дървовидна графика с корен в горната част илюстрира най-добре структурата:

Нека разделим това, започвайки отгоре.

Горната част на тази графика, отбелязана с „.“ се нарича „коренът“.

„Авторитетните сървъри за имена, които обслужват DNS коренната зона, известна като„ коренни сървъри “, представляват мрежа от стотици сървъри в много страни по света. Те са конфигурирани в DNS коренната зона като 13 имена на авторите. “

Основният домейн има етикет с нулева дължина.

От тук нататък всеки възел (точка) в графиката има уникален етикет с дължина до 63 знака.

Първото ниво надолу от корена са TLD: com, org, edu и gov. Моля, обърнете внимание, че тази графика не съдържа пълен списък на TLD.

Под TLD са SLD, домейните от второ ниво. Децата на всеки възел се наричат ​​„поддомейни“, които все още се считат за част от родителския домейн. Например в freecodecamp.org, freecodecamp (SLD) е поддомейн на org (TLD).

В зависимост от йерархията на уебсайта може да има домейни от трето, четвърто и пето ниво. Например в hypothetical-subdomain.freecodecamp.org хипотетичният-поддомейн е домейнът от трето ниво и поддомейнът на freecodecamp. И така, и така нататък, поне до 127 нива, което е максимално разрешеното от DNS.

Кой управлява пространството от имена?

Не би ли било лудост да се опитаме един човек или организация да администрира всичко? Да, би. Особено защото една от главните дизайнерски цели на DNS беше да насърчава разпределено, децентрализирано управление на системата като цяло.

Иска ми се да мога да ви кажа, че отговорните хора се наричат ​​„Кралете на пространството от имена“, но уви.

Всеки домейн (или поддомейн) в пространството на имена на домейни е или е част от зона , „автономно администрирано парче от пространството на имената“. И така, пространството от имена е разбито на зони.

Отговорността за тези зони се управлява чрез делегиране и администриране.

Процесът на възлагане на отговорността на поддомейните на други обекти се нарича делегиране.

Например Регистърът на обществения интерес администрира името на домейна org и е от 2003 г. Регистърът на публичния интерес може да делегира отговорност на други страни за управление на поддомейни на org, казват freecodecamp. И тогава, който администрира freecodecamp, може да възложи отговорност за поддомените на freecodecamp (например, hypothethical-subdomain.freecodecamp.com) на друга страна.

Ако някой (организация, екип или физическо лице) администрира зона, това, което прави, е администриране на сървъра на имената, който отговаря за зоната.

Това ни води до една от най-фундаменталните концепции в системата за имена на домейни.

Сървъри за имена на домейни

„Програмите, които съхраняват информация за пространството от имена на домейни, се наричат ​​сървъри на имена.“

В този момент е полезно поне първоначално да се мисли за взаимоотношенията клиент-сървър. Сървърите на имена на домейни са „сървърната“ страна на връзката клиент-сървър. Сървърите на имена могат да зареждат една, стотици или дори хиляди зони, но никога не зареждат цялото пространство от имена. След като сървърът на имена е заредил цялата зона, се казва, че е авторитетен за тази зона.

За да разберете защо сървърите на имена функционират по начина, по който работят, е полезно да разберете „клиентската“ част от връзката.

Решители

В DNS клиентът (заявителят на информацията) се нарича „преобразувател“, който в началото може да изглежда назад. Няма ли сървърът, който разрешава заявката, да бъде наречен „преобразувател?“ И аз така си мислех, но не е така. Най-добре просто да запомните това и да продължите напред.

Разрешителите обикновено са включени, де факто, в повечето операционни системи, така че приложенията, инсталирани в операционната система, не трябва да разберат как да правят DNS заявки на ниско ниво.

DNS заявките и техните отговори са видове DNS съобщения и имат собствен протокол за пренос на данни (обикновено UDP). Разрешителите са отговорни за подпомагането на приложенията, инсталирани в операционната система, да превеждат заявки за свързани с DNS данни в DNS заявки.

В обобщение, преобразувателите отговарят за опаковането и изпращането на заявки за данни. След като преобразувателят получи отговор (ако изобщо), той го предава обратно на оригиналното заявяващо приложение във формат, консумативен за заявяващото приложение.

Обратно към сървърите на имена

Сега, когато сме малко по-запознати с клиентската страна на връзката, трябва да разберем как сървърите на имена на домейни реагират на заявките за преобразуване.

Имен сървърите отговарят на DNS заявки чрез резолюция . Резолюцията е процес, чрез който сървърите на имена намират файлове с данни в пространството на имената. В зависимост от вида на заявката сървърите на имена реагират по различен начин на различните заявки, но крайната цел е разделителната способност.

Типове заявки

Тип заявка? Да, има няколко типа DNS заявки. Но първо, какво обикновено има в DNS заявка? Това е искане за информация, по-специално за IP адреса, свързан с име на домейн.

  • Рекурсивни : рекурсивните заявки позволяват заявката да бъде насочена към множество сървъри на имена, за да бъде разрешена. Ако първият заявен сървър за имена няма желаните данни, тогава този сървър за имена изпраща заявката до най-подходящия следващ сървър за имена, докато сървърът с имена с желаните файлове с данни не бъде намерен и изпрати отговор на резолвера.
  • Итеративно : итеративните заявки изискват заявеният сървър на имена да отговори или с желаните данни, или с грешка. Отговорът може да съдържа IP адреса на най-подходящия сървър на имена, за да изпрати заявката до следващия; Резолюторът може след това да изпрати друга заявка до този, по-подходящ, сървър на имена.

В случай, че се нуждаете, можете също да направите заявка за името на домейна, ако всичко, което имате, е IP адресът. Това се нарича обратно DNS търсене.

След като заявката достигне до сървър на имена, който съдържа желаните файлове с данни, заявката може да бъде разрешена. Сървърите на имена са свързани с няколко файла с данни, всички или някои от които могат да бъдат използвани за разрешаване на заявката.

Ресурсни записи (RR)

Това са файловете с данни в пространството от имена на домейни. Тези файлове с данни имат специфични формати и съдържание.

Най-често срещаните RR:

  • Запис: ако не сте чували за други RR, с изключение на този, това би имало смисъл. Вероятно е най-известният RR и съдържа IP адреса на дадения домейн.
  • Запис CNAME: ако не сте чували за други RR, с изключение на този и записа A, това също би имало смисъл. „C“ означава „каноничен“ и се използва вместо запис A, за да присвои псевдоним на домейн.
  • Запис SOA: този запис съдържа административна информация за него, включително имейл адреса на администратора. Съвет: ако администрирате зона, уверете се, че тук има валиден имейл адрес, така че хората да могат да се свържат с вас, ако е необходимо.
  • Други важни типове ресурсни записи (RR) са PR, NS, SRV и MX. Прочетете за тях тук.

Кеширане и време за живот (TTL)

Когато локалният сървър на имена получи отговор от заявка, той кешира тези данни (съхранява ги в паметта), така че следващия път, когато получи същата заявка, той може просто да отговори директно на заявката, вместо да премине през първоначалния, по-дълъг процес на разрешаване.

Но след като тази информация е кеширана, тя е както статична, така и изолирана и следователно има риск да остарее. Следователно, ресурсните записи имат стойност, която се нарича време за живот (TTL), която диктува колко дълго тези данни могат да се кешират. Когато това време изтече (достигне нула), сървърът на имената изтрива записа.

Важна забележка: TTL не се прилага за сървърите за имена, които са авторитетни за зоната, която съдържа ресурсния запис. Това се отнася само за сървъра на имена, който е кеширал този ресурсен запис.

Един ден от живота на една заявка

Ние разгледахме много основания в тази статия и тя беше тежка за концепциите. За да свържете всичко това заедно и да го направите реално, ето един ден (фигуративен ден) в живота на заявката.

И така, защо трябва да знам всичко това?

Има толкова много причини да се запознаете с концепциите, свързани с DNS и IP адреси.

  • Първо, това е гръбнакът на Интернет, нещото, което много от нас използват, развиват чувства за (любов / омраза / вие-име-то) и приемате за даденост всеки ден. Важно е да сме запознати със структурите, които ни дават възможност да постигнем големи неща днес с технологиите и интернет днес.
  • Невероятно умни хора прекараха десетилетия от живота си в изграждането на тези неща! Нека признаем и оценим техния принос.
  • Сега, след като отстраних неприятните неща, важно е да се запознаете с DNS концепциите, в случай че отговаряте за нещо, свързано с инфраструктурата във вашата компания или екип или вашия собствен бизнес. Наличието на референтна рамка, когато се появят значителни проблеми, ви позволява да действате много по-бързо и да намерите решения много по-рано.

Заключение

На този етап трябва да разберете какво е DNS и какво е сървър на имена, както и да сте запознати с техническите концепции, свързани с IP адресите.

Много книги са написани и се гмуркат по-дълбоко в очарователния свят на DNS и има още много какво да научите. Темите, които не са били включени в тази статия, но са част от DNS или са много свързани, включват:

  • Реализации на сървъра на имена
  • Препращане
  • (Повече за) етикети на възли
  • Основни и вторични връзки на сървъри на имена
  • Алгоритми за препредаване
  • Балансиране на натоварването
  • Освен това, други по-общи теми за това как функционира Интернет, като:
  • Световната мрежа
  • HTTP
  • FTP
  • Слоеве на комуникационния протокол: ниво на връзката, IP слой, транспортен слой, интернет слой и др.

За тези от вас, които все още четат иИскам да науча повече за DNS, аз преди всичко препоръчвам „DNS и BIND, 5-то издание“, написано от Cricket Liu и публикувано от O'Reilly Media. Това е безценно.

Също така насърчавам всички да се пооправят в оригиналното искане за коментари (RFC), посочено по-долу. Не само има точки за четене на първоизточници, но те са и изключително добре организирани и разбираеми документи, поради което ги цитирах в тази статия.

Ресурси

  1. RFC 1034: ДОМЕННИ ИМЕНА - КОНЦЕПЦИИ И СЪОРЪЖЕНИЯ
  2. RFC 1035: ДОМЕННИ ИМЕНА - ИЗПЪЛНЕНИЕ И СПЕЦИФИКАЦИЯ
  3. RFC 1122: Изисквания за интернет хостове - комуникационни слоеве
  4. Повече за целите на DNS дизайна от Connected: Internet Encyclopedia
  5. Как се роди интернет от ARPAnet за интерпретатора, от The Conversation
  6. Изучаване на DNS видео курс от Крикет Лиу от O'Reilly Media

Малко за мен

Аз съм Клоу Тъкър, художник и разработчик в Портланд, Орегон. Като бивш преподавател непрекъснато търся пресечната точка на ученето и преподаването или технологиите и изкуството. Свържете се с мен в Twitter @_chloetucker и проверете уебсайта ми на chloe.dev.