Thank you for reading this post, don't forget to subscribe!

DOMAIN NAME SYSTEM

DNS сопо­став­ля­ет меж­ду собой чело­ве­ко­чи­та­е­мые сим­воль­ные стро­ки, такие как имя service1. exemple, исполь­зу­е­мый на рисун­ке 1, для IP-адре­сов. На рисун­ке 3 пока­за­на основ­ная рабо­та систе­мы DNS.

На рисун­ке 3, пред­по­ла­гая, что нет ника­ких кэшей любо­го вида (таким обра­зом, весь про­цесс проиллюстрирован):

1. Хост A пыта­ет­ся под­клю­чить­ся к www.service1.example. Опе­ра­ци­он­ная систе­ма хоста про­ве­ря­ет свою локаль­ную кон­фи­гу­ра­цию на пред­мет адре­са DNS-сер­ве­ра, кото­рый она долж­на запро­сить, что­бы опре­де­лить, где рас­по­ло­же­на эта служ­ба, и нахо­дит адрес рекур­сив­но­го сер­ве­ра. При­ло­же­ние DNS опе­ра­ци­он­ной систе­мы хоста отправ­ля­ет DNS-запрос на этот адрес.
2. Рекур­сив­ный сер­вер полу­ча­ет этот запрос и - при отсут­ствии кешей - про­ве­ря­ет домен­ное имя, для кото­ро­го запра­ши­ва­ет­ся адрес. Рекур­сив­ный сер­вер отме­ча­ет, что пра­вая часть име­ни доме­на име­ну­ет­ся example, поэто­му он спра­ши­ва­ет кор­не­вой сер­вер, где най­ти инфор­ма­цию о домене example.
3. Кор­не­вой сер­вер воз­вра­ща­ет адрес сер­ве­ра, содер­жа­щий инфор­ма­цию о домене верх­не­го уров­ня (TLD) example.
4. Рекур­сив­ный сер­вер теперь запра­ши­ва­ет инфор­ма­цию о том, с каким сер­ве­ром сле­ду­ет свя­зать­ся по пово­ду service1.example. Рекур­сив­ный сер­вер про­хо­дит через домен­ное имя по одно­му раз­де­лу за раз, исполь­зуя инфор­ма­цию, обна­ру­жен­ную в раз­де­ле име­ни спра­ва, что­бы опре­де­лить, какой сер­вер сле­ду­ет запро­сить об инфор­ма­ции сле­ва. Этот про­цесс назы­ва­ет­ся рекур­си­ей через домен­ное имя; сле­до­ва­тель­но, сер­вер назы­ва­ет­ся рекур­сив­ным сервером.
5. Сер­вер TLD воз­вра­ща­ет адрес пол­но­моч­но­го сер­ве­ра для service1.example. Если инфор­ма­ция о место­на­хож­де­нии служ­бы была кэши­ро­ва­на из преды­ду­ще­го запро­са, она воз­вра­ща­ет­ся как неав­то­ри­зо­ван­ный ответ; если фак­ти­че­ский сер­вер настро­ен для хра­не­ния инфор­ма­ции об отве­тах доме­на, его ответ явля­ет­ся авторитетным.
6. Рекур­сив­ный сер­вер запра­ши­ва­ет инфор­ма­цию о www.service1.example у пол­но­моч­но­го сервера.
7. Авто­ри­тет­ный сер­вер отве­ча­ет IP-адре­сом сер­ве­ра B.
8. Рекур­сив­ный сер­вер теперь отве­ча­ет хосту A, сооб­щая пра­виль­ную инфор­ма­цию для досту­па к запро­шен­ной службе.
9. Хост A свя­зы­ва­ет­ся с сер­ве­ром, на кото­ром рабо­та­ет www.service1.example, по IP-адре­су 2001:db8:3e8:100::1.

Этот про­цесс может пока­зать­ся очень затяж­ным; напри­мер, поче­му бы про­сто не сохра­нить всю инфор­ма­цию на кор­не­вом сер­ве­ре, что­бы сокра­тить коли­че­ство шагов? Одна­ко это нару­шит основ­ную идею DNS, кото­рая заклю­ча­ет­ся в том, что­бы дер­жать инфор­ма­цию о каж­дом домене под кон­тро­лем вла­дель­ца доме­на в мак­си­маль­но воз­мож­ной сте­пе­ни. Кро­ме того, это сде­ла­ло бы созда­ние и обслу­жи­ва­ние кор­не­вых сер­ве­ров очень доро­ги­ми, посколь­ку они долж­ны были бы иметь воз­мож­ность хра­нить мил­ли­о­ны запи­сей и отве­чать на сот­ни мил­ли­о­нов запро­сов инфор­ма­ции DNS каж­дый день. Раз­де­ле­ние инфор­ма­ции поз­во­ля­ет каж­до­му вла­дель­цу кон­тро­ли­ро­вать свои дан­ные и поз­во­ля­ет мас­шта­би­ро­вать систе­му DNS.

Обыч­но инфор­ма­ция, воз­вра­ща­е­мая в про­цес­се запро­са DNS, кэши­ру­ет­ся каж­дым сер­ве­ром на этом пути, поэто­му сопо­став­ле­ние не нуж­но запра­ши­вать каж­дый раз, когда хосту необ­хо­ди­мо достичь ново­го сервера.

Как обслу­жи­ва­ют­ся эти таб­ли­цы DNS? Обыч­но это руч­ная рабо­та вла­дель­цев доме­нов и доме­нов верх­не­го уров­ня, а так­же погра­нич­ных про­вай­де­ров по все­му миру. DNS не опре­де­ля­ет авто­ма­ти­че­ски имя каж­до­го объ­ек­та, под­клю­чен­но­го к сети, и адрес каж­до­го из них.

DNS объ­еди­ня­ет базу дан­ных, обслу­жи­ва­е­мую вруч­ную, с рас­пре­де­ле­ни­ем рабо­ты меж­ду людь­ми, с про­то­ко­лом, исполь­зу­е­мым для запро­са базы дан­ных; сле­до­ва­тель­но, DNS попа­да­ет в базу дан­ных сопо­став­ле­ния с клас­сом про­то­ко­лов реше­ний. Как хост узна­ет, какой DNS-сер­вер запра­ши­вать? Эта инфор­ма­ция либо настра­и­ва­ет­ся вруч­ную, либо изу­ча­ет­ся с помо­щью про­то­ко­ла обна­ру­же­ния, тако­го как IPv6 ND или DHCP.

---

DHCP

Когда хост (или какое-либо дру­гое устрой­ство) впер­вые под­клю­ча­ет­ся к сети, как он узна­ет, какой IPv6-адрес (или набор IPv6-адре­сов) назна­чить локаль­но­му интер­фей­су? Одним из реше­ний этой про­бле­мы явля­ет­ся отправ­ка хостом запро­са в какую-либо базу дан­ных, что­бы опре­де­лить, какие адре­са он дол­жен исполь­зо­вать, напри­мер DHCPv6. Что­бы понять DHCPv6, важ­но начать с кон­цеп­ции link local address в IPv6. При обсуж­де­нии раз­ме­ра адрес­но­го про­стран­ства IPv6, fe80:: / 10 был назван заре­зер­ви­ро­ван­ным для link local address. Что­бы сфор­ми­ро­вать link local address, устрой­ство с IPv6 объ­еди­ня­ет пре­фикс fe80:: с MAC (или физи­че­ским) адре­сом, кото­рый часто фор­ма­ти­ру­ет­ся как адрес EUI-48, а ино­гда как адрес EUI-64. Например:

• Устрой­ство име­ет интер­фейс с адре­сом EUI-48 01-23-45-67-89-ab.
• Этот интер­фейс под­клю­чен к сети IPv6.
• Устрой­ство может назна­чить fe80 :: 123: 4567: 89ab в каче­стве link local address и исполь­зо­вать этот адрес для свя­зи с дру­ги­ми устрой­ства­ми толь­ко в этом сегменте.

Это при­мер вычис­ле­ния одно­го иден­ти­фи­ка­то­ра из дру­го­го. После того, как link local address сфор­ми­ро­ван, DHCP6 явля­ет­ся одним из мето­дов, кото­рый мож­но исполь­зо­вать для полу­че­ния уни­каль­но­го адре­са в сети (или гло­баль­но, в зави­си­мо­сти от кон­фи­гу­ра­ции сети). DHCPv6 исполь­зу­ет User Datagram Protocol (UDP) на транс­порт­ном уровне. Рису­нок 4 иллю­стри­ру­ет это.

1. Хост, кото­рый толь­ко что под­клю­чил­ся к сети, A, отправ­ля­ет сооб­ще­ние с запро­сом. Это сооб­ще­ние посту­па­ет с link local address и отправ­ля­ет­ся на multicast address ff02 :: 1: 2, пор­ты UDP 547 (для сер­ве­ра) и 546 (для кли­ен­та), поэто­му каж­дое устрой­ство, под­клю­чен­ное к одно­му и тому же физи­че­ско­му про­во­ду, полу­чит сооб­ще­ние. Это сооб­ще­ние будет вклю­чать уни­каль­ный иден­ти­фи­ка­тор DHCP (DUID), кото­рый фор­ми­ру­ет кли­ент и исполь­зу­ет сер­вер, что­бы обес­пе­чить посто­ян­ную связь с одним и тем же устройством.
2. B и C, оба из кото­рых настро­е­ны для рабо­ты в каче­стве сер­ве­ров DHCPv6, отве­ча­ют реклам­ным сооб­ще­ни­ем. Это сооб­ще­ние явля­ет­ся одно­ад­рес­ным паке­том, направ­лен­ным само­му A с исполь­зо­ва­ни­ем link local address, из кото­ро­го A отправ­ля­ет запра­ши­ва­е­мое сообщение.
3. Хост A выби­ра­ет один из двух сер­ве­ров, с кото­ро­го запра­ши­вать адрес. Хост отправ­ля­ет запрос на multicast address ff02 :: 1: 2, про­ся B предо­ста­вить ему адрес (или пул адре­сов), инфор­ма­цию о том, какой DNS-сер­вер исполь­зо­вать, и т. д.
4. Сер­вер, рабо­та­ю­щий на B, затем отве­ча­ет отве­том на изна­чаль­но сфор­ми­ро­ван­ный link local address A; это под­твер­жда­ет, что B выде­лил ресур­сы из сво­е­го локаль­но­го пула, и поз­во­ля­ет A начать их использование.

Что про­изой­дет, если ни одно устрой­ство в сег­мен­те не настро­е­но как сер­вер DHCPv6? Напри­мер, на рисун­ке 4, что, если D - един­ствен­ный доступ­ный сер­вер DHCPv6, пото­му что DHCPv6 не рабо­та­ет на B или C? В этом слу­чае марш­ру­ти­за­тор (или даже какой-либо дру­гой хост или устрой­ство) может дей­ство­вать как ретранс­ля­тор DHCPv6. Паке­ты DHCPv6, кото­рые пере­да­ет A, будут при­ня­ты ретранс­ля­то­ром, инкап­су­ли­ро­ва­ны и пере­да­ны на сер­вер DHCPv6 для обработки.

При­ме­ча­ние. Опи­сан­ный здесь про­цесс назы­ва­ет­ся DHCP с отсле­жи­ва­ни­ем состо­я­ния и обыч­но запус­ка­ет­ся, когда в объ­яв­ле­нии марш­ру­ти­за­то­ра уста­нов­лен бит Managed. DHCPv6 может так­же рабо­тать с SLAAC, для предо­став­ле­ния инфор­ма­ции, кото­рую SLAAC не предо­став­ля­ет в режи­ме DHCPv6 без сохра­не­ния состо­я­ния. Этот режим обыч­но исполь­зу­ет­ся, когда в объ­яв­ле­нии марш­ру­ти­за­то­ра уста­нов­лен бит Other. В тех слу­ча­ях, когда сете­вой адми­ни­стра­тор зна­ет, что все адре­са IPv6 будут настро­е­ны через DHCPv6, и толь­ко один сер­вер DHCPv6 будет досту­пен в каж­дом сег­мен­те, сооб­ще­ния с объ­яв­ле­ни­ем и запро­сом мож­но про­пу­стить, вклю­чив быст­рое при­ня­тие DHCPv6.