Напълно автономно делегиране на in-addr.arpa и ip6.arpa поддомейни

Версия 1.0.1, 28 май 2008

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Адрес за кореспонденция: vesso AT vesselin.org

Първоизточник: http://www.vesselin.org

Лиценз на документа: CC Attribution-ShareAlike

 

Съдържание:

  1. Увод

  2. Напълно автономно делегиране на in-addr.arpa

  3. Напълно автономно делегиране на ip6.arpa

  4. Ограничени

  5. Предишни версии на публикацията

 

1. Увод

Напълно автономното делегиране на in-addr.arpa и ip6.arpa поддомейни има за цел да снижи броят запитвания към DNS, извървшвани в хода на изпълнението на рекурсивните заявки, за извличането на записи от in-addr.arpa и ip6.arpa поддомейни. В изложението по-долу нарочно е употребяван термина "поддомейн", а не домейн. Разделението на домейн и поддомейни почти винаги е условно и зависи от това къде в дървото на делегирания в DNS и от кого е обособена дадена автономна структура от имена. Негласно е прието всяка йерархична структура от имена, която се обслужва технически и административно от един субект, да се нарича домейн. Всяко дефиниране на подструктура в йерархичното дърво на домейна, което се извършва от организацията, която управлява последния, се нарича поддомейн. От тази гледна точка, RIPE и останалите RIR (регионални интернет регистри), делегират in-addr.arpa и ip6.arpa домейни. След като един субект получи управлението на съответния in-addr.arpa или ip6.arpa домейн, той може да дефинира в него поддомейни, съгласно своите нужди. Поддомейните обаче, нямат делегиращи записи в сървърите за имена на RIR. Те се делегират от субекта, който управлява домейна.

Най-честата практика е делегирането на in-addr.arpa и ip6.arpa домейните и поддомейните, да става чрез домейни различни от in-addr.arpa и ip6.arpa. Например, домейнът 0.0.193.in-addr.arpa (служеш за решаване на обратната задача в DNS за IPv4 мрежата 193.0.0.0/24), е делегиран по следния начин в RIR зоната 193.in-addr.arpa:

0.0.193.in-addr.arpa.  172800  IN   NS   sec1.apnic.net.
0.0.193.in-addr.arpa.  172800  IN   NS   sec3.apnic.net.
0.0.193.in-addr.arpa.  172800  IN   NS   ns-pri.ripe.net.

Това делегиране е направено така, че за да стане извличане на записи от зоната на домейна 0.0.193.in-addr.arpa, следва да се извличат записи от зоните на домейните apnic.net и/или ripe.net.

Подобен пример може да се даде и ip6.arpa чрез зоната на домейна 6.0.1.0.0.2.ip6.arpa, която е делегирана по следния начин:

6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sec1.apnic.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sec3.apnic.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   sunic.sunet.se.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   ns-pri.ripe.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   tinnie.arin.net.
6.0.1.0.0.2.ip6.arpa.  84600   IN   NS   ns3.nic.fr.

Тук отново имаме делегиране чрез използване на други домейни, различни дори от майчиния ip6.arpa.

Целта на настоящата статия е да покаже, че има и друг, по-икономичен откъм брой заявки към DNS и трафик начин, чрез който могат да се делегират in-addr.arpa и ip6.arpa домейни и поддомейни.

Синтаксисът на прмерните декларации и дефиниции е съобразен с BIND9.

 

2. Напълно автономно делегиране на in-addr.arpa

Примерът по-долу показва начин за напълно автономно делегиране на in-addr.arpa поддомейн. Нека се иска напълно автономното делегиране на домейна 100.10.in-addr.arpa. В зоната на домейна 10.in-addr.arpa делегирането на поддомейна може да се извърши така:

$ORIGIN @
100	NS	ns1.100
100	NS	ns2.100
ns1.100	A	10.100.0.1
ns2.100	A	10.100.0.2

По-този начин домейнът 100.10.in-addr.arpa е делегиран чрез сървърите за имена ns1.100.10.in-addr.arpa (10.100.0.1) и ns2.100.10.in-addr.arpa (10.100.0.2). Двата A ресурсни записи в случая са "залепени", т.е. деклирирани са в майчината зона, от която започва делегирането на поддомейна, а не само в зоната на поддомейна.

Икономичността на този начин на делегиране се вижда най-добре при анализ на отговора на заявката за извличане на NS записите за делегирането на домейна 100.10.in-addr.arpa (примерния изход по-долу е генериран с dig):

;; QUESTION SECTION:
;100.10.in-addr.arpa.        IN   NS

;; AUTHORITY SECTION:
100.10.in-addr.arpa.  86400  IN   NS   ns2.100.10.in-addr.arpa.
100.10.in-addr.arpa.  86400  IN   NS   ns1.100.10.in-addr.arpa.

;; ADDITIONAL SECTION:
ns1.100.10.in-addr.arpa. 86400  IN   A   192.168.10.1
ns2.100.10.in-addr.arpa. 86400  IN   A   192.168.10.2

Няма отговор, който да иницира заявка за извличане на запис от никой друг домейн, освен от този, записи от чиято зона се търсят (за примера 100.10.in-addr.arpa). "Залепените" A ресусни записи се връщат в отговора на заявката и правят излишни допълнителни запитвания за установяване на адресите на сървърите за имена ns1.100.10.in-addr.arpa и ns2.100.10.in-addr.arpa. Освен икономия на процесорно време и памет, се постига и икономия на трафик.

 

3. Напълно автономно делегиране на ip6.arpa

Примерът по-долу показва начин за напълно автономно делегиране на ip6.arpa поддомейн. Нека се иска напълно автономното делегиране на поддомейна 2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa. В зоната на домейна 6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa делегирането на поддомейна може да се извърши така:

ns1.2.0.0.0.0.0.0.0   AAAA   2a01:288:8000:6:0:2:0:1
ns2.2.0.0.0.0.0.0.0   AAAA   2a01:288:8000:6:0:2:0:2
2.0.0.0.0.0.0.0   NS   ns1.2.0.0.0.0.0.0.0
2.0.0.0.0.0.0.0   NS   ns2.2.0.0.0.0.0.0.0

По-този начин домейнът 2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa е делегиран чрез сървърите за имена ns1.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa (2a01:288:8000:6:0:2:0:1) и ns2.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa (2a01:288:8000:6:0:2:0:2). Двата AAAA ресурсни записи в случая са "залепени", т.е. деклирирани са в майчината зона, от която започва делегирането на поддомейна, а не само в зоната на поддомейна.

Икономичността на този начин на делегиране се вижда най-добре при анализ на отговора на заявката за извличане на NS записите за делегирането на домейна 2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa (примерния изход по-долу е генериран с dig):

;; QUESTION SECTION:
;2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa        IN   NS

;; AUTHORITY SECTION:
2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa  86400  IN   NS
   ns1.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa.
2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa  86400  IN   NS
   ns2.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa.

;; ADDITIONAL SECTION:
ns1.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400  IN   AAAA
   2a01:288:8000:6:0:2:0:1
ns2.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa. 86400  IN   AAAA
   2a01:288:8000:6:0:2:0:2

Няма отговор, който да иницира заявка за извличане на запис от никой друг домейн, освен от този, записи от чиято зона се търсят (за примера 2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa). "Залепените" AAAA ресусни записи се връщат в отговора на заявката и правят излишни допълнителни запитвания за установяване на адресите на сървърите за имена ns1.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa и s2.2.0.0.0.0.0.0.0.6.0.0.0.0.0.0.8.8.8.2.0.1.0.a.2.ip6.arpa. Освен икономия на процесорно време и памет, се постига и икономия на трафик.

 

4. Ограничения

Описаният начин на делегиране засега е неприложим при делегиране на in-addr.arpa и ip6.arpa и може да се използва само за поддомейни. Необходима е задълбочена дискусия по темата, която да потвърди или отхвърли ефективността на този начин на делегиране, преди той да бъде предложен официално като добра практика на съответния RIR.

 

5. Предишни версии на публикацията.

 

Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис] [TimeStamp: заявка|удостоверение]

Creative Commons - Признание 2.5 Valid CSS! Valid XHTML 1.1