23.02.2011

Продолжаем-с..

Оказалось, что делегировать реверсные субзоны для IPv6 очень просто. Единственное условие — 4битная граница.

Последовательность такая: предположим, что RIPE выдал 2xxx.yyyy::/32, а мы создаем для начала две подсети /64, скажем а и b, то есть нужно сформировать 3 зоны:

2xxx.yyyy::/32

2xxx.yyyy:0000:000a::/64

2xxx.yyyy:0000:000b::/64

(так и назовем файлы зон, только без дробей) 

В named.conf пишем:

zone «y.y.y.y.x.x.x.2.ip6.arpa» in {
type master;
file «master/2xxx:yyyy»;
};
zone «a.0.0.0.0.0.0.0.y.y.y.y.x.x.x.2.ip6.arpa» in {
type master;
file «master/2xxx:yyyy:0000:000a»;
};

zone «b.0.0.0.0.0.0.0.y.y.y.y.x.x.x.2.ip6.arpa» in {
type master;
file «master/2xxx:yyyy:0000:000b»;
};

В файл 2xxx.yyyy, кроме обычных записей, добавляем:

; delegate 2xxx:yyyy:0000:000a::/64
a.0.0.0.0.0.0.0.y.y.y.y.x.x.x.2.ip6.arpa                NS      ns.mydomain.ru

; delegate 2xxx:yyyy:0000:000b::/64
b.0.0.0.0.0.0.0.y.y.y.y.x.x.x.2.ip6.arpa                NS      ns.mydomain.ru

Разумеется, можно использовать $ORIGIN с целью минимизации бюрократизма, а также добавить другие slave-серверы.

 Ну, а файлы зон и реверсные записи в них выглядят как обычно (в смысле — как обычные реверсные записи для IPv6). Конечно же, после обновления конфигурации named-a нужно проверить, все ли нормально, сначала — по логам, затем — при помощи dig или nslookup, через свои и сторонние DNS. В качестве сторонних очень удобно использовать Гугловские, правда я заметил, что они воспринимают обновления не сразу, а минут через пять-десять..


  *** Via IPv4 ***