Конфигурирование DNS

Для того, чтобы BIND начал отвечать на IPv6-запросы, нужно совсем немного.

Сначала — нужно убедиться, что в конфигурационном файле BIND упоминается loopback-зона, то есть имеются такие строки:

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { 
type master; 
file "standard/loopback6.arpa"; 
allow-transfer { localhost; }; 
};

Содержимое файла loopback6.arpa выглядит так:

$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
$TTL 6h
@       IN      SOA     localhost. root.localhost. (
1       ; serial
1h      ; refresh
30m     ; retry
7d      ; expiration
1h )    ; minimum

NS      localhost.
1       PTR     localhost.

И — нужно проверить наличие AAAA-записи в файле localhost:

$ORIGIN localhost.
$TTL 6h
@       IN      SOA     localhost. root.localhost. (
1       ; serial
1h      ; refresh
30m     ; retry
7d      ; expiration
1h )    ; minimum
NS      localhost.
A       127.0.0.1
AAAA    ::1      ; — эта строка должна быть.

Как правило, все вышеупомянутые записи делаются автоматически при инсталяции BIND.

Затем нужно добавить в конфигурационный файл:

options {
........
listen-on-v6 { any; };          --- нужно добавить (или перечислить только нужное вам)
allow-recursion { clients; };   --- как правило, уже есть
};

и скорректировать (в нашем случае) acl «clients», чтобы сервер отвечал на рекурсивные запросы только от наших клиентов:

acl clients {
......
2001:0db8::/32;
......
};

Все остальные необходимые настройки (loopback-адреса и зоны) уже имелись в дистрибутиве.

Кстати, в файле root.hint уже должны быть IPv6-адреса для нескольких корневых серверов.

Затем можно приступать к добавлению записей в файлы прямых зон и к созданию новых файлов реверсных зон для IPv6.

Поискав («погуглив») информацию на эту тему, обнаружил, что большинство поступает с «прямыми» зонами просто, то есть к любой записи А добавляют запись АААА, и мы решили сделать так же. Тут, главное, не запутаться в адресах… И — все больше приходит осознание того, что поскольку IPv6-адреса запомнить очень сложно (свой префикс выучил только на второй день), то роль DNS возрастает. Имена-то запоминаются легче.

Перед «наполнением» файлов зон АААА-записями начинаем планировать распределение подсетей. Для начала решили сохранить нынешнюю структуру, то есть если у нас есть отдельная подсеть IPv4 с любой маской, то ей будет соответствовать отдельная подсеть IPv6/64. Маска /64 для end-юзерских подсетей выбрана в соответствии с рекомендациями RIPE, хотя подсетей такого размера в IPv4 у нас нет, в нашем блоке адресов /20 размер самой большой подсети составляет /23. Правда, некоторые подсети IPv4 хотелось бы обьединить, а некоторые разделить, но такую реструктуризацию мы будем делать уже в пространстве IPv6.

По нашим оценкам, 16-битного поля, выделяемого в структуре адреса IPv6 под номер подсети, нам вполне хватит на ближайшие годы и пятилетки.

Итак, начинаем «заводить» первые записи в прямые зоны.

Выбираем вторую подсеть (то есть, проще говоря, устанавливаем 64й бит в «1») и добавляем в «прямой» зоне (скажем, domain.ru) две записи:

test1  AAAA  2001:0db8:0000:0001:0000:0000:0000:0001
test2  AAAA  2001:0db8:0000:0001:0000:0000:0000:0002

Перезапускаю BIND и проверяю nslookup-ом на самом сервере:

dig test1.domain.ru aaaa

 ;; <<>> DiG 9.4.2-P2 <<>> test1.bestcom.ru aaaa
 ;; global options:  printcmd
 ;; Got answer:
 ;; << HEADER >> - opcode: QUERY, status: NOERROR, id: 35937
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

 ;; QUESTION SECTION:
 ;test1.domain.ru.               IN      AAAA

 ;; ANSWER SECTION:
 test1.domain.ru.        600     IN      AAAA    2001:0db8:0:1::1

Вроде все верно, ответ получен. Запрос к хосту test2 также проходит нормально.

Теперь проверяю со своей машины из офисной сети (учтите, дело было в 2012 году).

  Microsoft Windows XP [Version 5.1.2600]
  (C) Copyright 1985-2001 Microsoft Corp.

  C:>nslookup

  server xxx.yyy.zzz.ttt
  Default Server:  ns.domain.ru
  Address:  xxx.yyy.zzz.ttt

  set q=aaaa
  test1.domain.ru
  Server:  ns.domain.ru
  Address:  xxx.yyy.zzz.ttt

  test1.domain.ru AAAA IPv6 address = 2001:0db8:0:1::1
  …

  test2.domain.ru
  Server:  ns.domain.ru
  Address:  xxxx.yyyy.zzzz.tttt

  test2.domain.ru        AAAA IPv6 address = 2001:0db8:0:1::2
  …
  >
  exit

И здесь все нормально! Теперь — создаем реверсные зоны. Кстати, делегирование обьекта domain для IPv6-префикса у нас еще не оформлено… Ну ничего, не забудем.

Создаем первую реверсную зону. Название зоны выбираем как 2001:0db8, благо UNIX не возражает против такого имени файла.

Файл реверсной зоны для IPv6 устроен так же, как и для IPv4, его начало выглядит так:

  $ORIGIN .
  $TTL 7200 ; 2 hours
  8.b.d.0.1.0.0.2.ip6.arpa IN SOA ns.domain.ru mail.domain.ru. (
  2010121801 ; serial
  18000 ; refresh (5 hours)
  3600 ; retry (1 hour)
  1728000 ; expire (2 weeks 6 days)
  172800 ; minimum (2 days)
  )

  NS           ns.domain.ru.
  NS           ns1.domain.ru.
  ; subnet 2001:0db8::/32
  $ORIGIN           8.b.d.0.1.0.0.2.ip6.arpa.

… далее идут записи зоны …

  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.0.0  IN  PTR  test1.domain.ru.
  2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.0.0  IN  PTR  test2.domain.ru.

Для упрощения (автоматизации) преобразований можно использовать утилиту из состава Unix-Linux, она сразу преобразует адрес в ptr-формат:

    $ host -n 2001:db8::1
    Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)

Проверяю тут же при помощи dig:

dig @ns.mydomain.ru 2xxx:yyyy:0:1::1 ptr

…… и получаю сообщение об ошибке!

А вот nslookup работает!


**nslookup**

  set q=ptr
  2xxx:yyyy:0:1::3
  Server: 123.12.123.1
  Address: 123.12.123.1#53
  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.0.0.y.y.y.y.x.x.x.2.ip6.arpa name = test1.domain.ru.

То есть dig под UNIX не понимает, что это — структура адреса в формате IPv6…. Нужно будет проверить на самой свежей версии UNIX.

Проверил. Оказалось, что версия не при чем. А чтение документации показало, что вот такой формат команды работает:

dig @8.8.8.8 -x 2001:db8:0:1::1

Спасибо Google DNS, здорово выручает при проверках.

Тот же nslookup под WinXP при получении такой команды выдает:

Unrecognized command: 2001:0db8:0:1::1

— то есть он не понимает, что это адрес в формате IPv6.

(Нужно будет проверить это на Висте и 7-ке. - написано в 2012 году)

Кстати, если на DNS-серверах, которые являются авторитарными для каких-то зон, поднять IPv6, то также нужно на вышестоящих серверах (в данном случае — в РУ-центре) добавить IPv6-адреса к данным своих DNS-серверов, то есть сделать «glue ns records». Процедура несложная.

Ниже все вышеизложенное приведено в компактном виде:

LIR: IPv6 и revDNS

Практические шаги

(примечание: каких-либо сведений о конфигурировании адресов интерфейсов и роутинга здесь не будет)

Получить от RIR (у нас — от RIPE) блок адресов IPv6. Как и все остальные действия с RIPE, данную процедуру можно осуществить 3 способами:

  • «в лоб», через почтового робота
  • через Webupdates
  • через специальную форму на LIR-портале

ИМХО, лучше это сделать через LIR-portal, где есть специальная форма для первого заказа IPv6-адресов

Если пойти третьим путем, то обычным путем получаем шаблон :

whois -h whois.ripe.net — ‘-t inet6num’ (так делается на BSD)

В ответ приходит:

inet6num:       [mandatory]  [single]     [primary/look-up key]
netname:        [mandatory]  [single]     [lookup key]
descr:          [mandatory]  [multiple]   [ ]
country:        [mandatory]  [multiple]   [ ]
org:            [optional]   [single]     [inverse key]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [mandatory]  [multiple]   [inverse key]
status:         [mandatory]  [single]     [ ]
mnt-by:         [mandatory]  [multiple]   [inverse key]
mnt-lower:      [optional]   [multiple]   [inverse key]
mnt-routes:     [optional]   [multiple]   [inverse key]
mnt-domains:    [optional]   [multiple]   [inverse key]
mnt-irt:        [optional]   [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Далее заполняем его, добавляем аутентификационные данные, и отправляем.

Предположим, что нам выдали 2001:0db8::/32 (вроде бы всем LIR дают /32) Сразу заказываем обьект domain, для этого нужно знать имена своих dns-серверов. Опять-таки это можно сделать любым из трех способов, мы делали через Webupdates.

Каких-либо конфигурационных изменений в настройках DNS, связанных с IPv6, на этом этапе делать не нужно. Точнее — не требуется.

Для приверженцев почты: шаблон получаем так:

whois -h whois.ripe.net — ‘ -t domain’

Вот образец-макет того, что отправляют в RIPE:

% Information related to '8.b.d.0.1.0.0.2.ip6.arpa'

domain:         8.b.d.0.1.0.0.2.ip6.arpa
descr:          Reverse delegation for 2001:0db8::/32
nserver:        ns1.server.zz
nserver:        ns2.server.zz
admin-c:        PERSON1-RIPE
tech-c:         PERSON2-RIPE
zone-c:         PERSON3-RIPE
source:         RIPE # Filtered
mnt-by:         EARTH-MNT

Сразу же можно (и, имхо, желательно) завести обьект route6

Шаблон:

whois -h whois.ripe.net — ‘ -t route6’

А заполняем примерно так: (аутентификация не показана)

route6:          2001:0db8::/32
descr:           AS23456 IPv6 block
origin:          AS23456
mnt-by:          PERSON-MNT
source:          RIPE

Не забыть про аутентификацию!

В обьекте route6 есть еще один интересный атрибут: в нем можно указать пингуемый адрес, то есть адрес из вашего блока, который отвечает на пинги из всех сетей. Знание такого адреса очень полезно при отладке, при трассировке и проч. После «подьема» IPv6 BGP мы сразу же завели такой адрес у себя.

В шаблоне это выглядит так:

  pingable:       [optional]   [multiple]   [ ]
  ping-hdl:       [optional]   [multiple]   [inverse key]

И — вот так это выглядит в жизни, например:

  pingable:        2001:0db8::1
  ping-hdl:        PERSON1-RIPE

Второй атрибут также имеет ценность: если адрес не отвечает на ICMP-запросы, а вы уверены, что у вас все нормально — то можно написать письмо ответственному и указать на недостатки (разумеется, если суметь извлечь почтовый адрес).

Далее — переходим к ДНС и формируем реверсные зоны. Наша зона (в соответствии с префиксом 2001:0db8::/32) будет выглядеть так: 8.b.d.0.1.0.0.2.ip6.arpa, соответственно так назовем и файл. Прописываем это дело в конфигурационый файл и переходим к файлу зоны:

SOA-запись ничем не отличается от обычной, записи для ns-серверов тоже обычные

$ORIGIN .
$TTL 7200       ; 2 hours
8.b.d.0.1.0.0.2.ip6.arpa                IN SOA  ns1.domain.zz. dnsmaster.domain.zz. (
2011010201 ; serial
18000      ; refresh (5 hours)
3600       ; retry (1 hour)
1728000    ; expire (2 weeks 6 days)
172800     ; minimum (2 days)
)

NS      ns1.domain.zz.
NS      ns2.domain.zz.

Реверсная запись для нашего «пингуемого» адреса (пусть его имя будет ping6.domain.zz) будет выглядеть так:

    1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN      PTR     ping6.domain.zz.

Не правда ли, длинновато получилось? Не всегда умещается на одной строке (см.выше насчет частичной автоматизации).

Спасает ORIGIN. Если взять «стандартную» для IPv6-документации подсеть 2001:0db8::/64, то первый, второй и третий адрес будут выглядеть так:

;subnet 2001:0db8::/64
$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa                IN PTR      pingable.domain.zz
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa                IN PTR      2.domain.zz
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa                IN PTR      3.domain.zz

Отметим, что адрес 2001:0db8::/64 также допустим, и его реверсная запись будет такой:

`0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa                NS      zero.domain.zz`

Использовать автозаполнение последовательно идущих записей нет смысла, так как зона получится длиной от Земли до Луны.

Делегирование подсетей.

RIPE выдает для LIR подсети /32, то есть по 4 миллиона адресов на 1 квадратный метр земной поверхности. Конечно же, можно все реверсные записи для одного блока «запихать» в один файл, но:

— он станет огромным — будет сложно искать и редактировать нужную запись — придется перезагружать огромный файл

А если клиент попросит делегировать ему его подсеть?

То есть имеет смысл делать делегирование реверсных субзон и делать отдельные файлы на подсети, так как при этом будет меньше работы (делегирование) и файлы зон станут короче (соответственно, будут быстрее находитьcя записи). И работать станет проще. Даже если это делать только для себя и не делегировать клиентам.

Предположим, вы хотите делегировать подсети «a» и «b» (для /64 префикса) на сервер ns3.server.zz, то есть вы хотите, что бы реверсные запросы к подсетям 2001:0db8:0:a::/64 и 2001:0db8:0:b::/64 направлялись к серверу ns3.server.zz. В отличие от IPv4 это делается достаточно просто.

Во-первых, на сервере ns1.domain.zz в начале файла зоны 8.b.d.0.1.0.0.2.ip6.arpa делаем такие записи:

; delegate 2001:0db8:0000:000a::/64
a.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa                NS      ns3.server.zz

; delegate 2001:0db8:0000:000b::/64
b.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa                NS      ns3.server.zz

Затем, на сервере ns3.server.zz в конфигурационном файле обьявляем две мастер-зоны:

a.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

и

b.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

(обычным образом, как и любую другую зону)

И — создаем файлы для этих зон, полностью аналогично зоне 2001:0db8::/32

Например, фрагмент первой зоны может выглядеть так (soa-запись пропущена, она обычная)

; subnet 2001:0db8:0:a::/64

$ORIGIN a.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN      PTR     host-1.subnet-a.server.zz.
a.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN      PTR     host-ba.subnet-a.server.zz.
1.3.d.0.0.0.0.0.0.0.0.0.0.0.0.0 IN      PTR     host-d13.subnet-a.server.zz.

Сравним IPv4 и IPv6:


Параметр                               IPv4                                 IPv6
Префикс «классической» зоны             /24                                 Нет такого понятия
Делегирование от RIR         Блоками по /24                                 Одним блоком
Делегирование клиентам      По /24 — просто, меньше — со сложностями        По 4-битной границе — просто, не по границе — аналогично v4
Использование ORIGIN     Можно использовать                                 Можно считать жизненно необходимым
Формирование реверсной записи вручную                                       Можно, несложно Можно, очень трудоемко
Количество файлов зон  /24 — один файл (как правило)                        По вашему выбору, с учетом 4-битной границы

Справедливости ради следует отметить, что возможно и «классическое» делегирование реверсных субзон по любой границе, то есть использование CNAME, о чем сказано на сайте RIPE в разделе FAQ по реверсным зонам.

Вручную формировать реверсные записи для IPv6-адресов достаточно тоскливо, мы решили попытаться облегчить этот процесс и написали небольшой скрипт на Perl, который из IPv6-адреса делает реверсную запись.

Скрипт умеет:

— делать синтаксический анализ IPv6-адреса и сообщать о найденных ошибках — выдавать параметр ORIGIN — формировать на выходе файл, который несложно преобразовать в файл зоны

Файл скрипта называется ip6.pl и должен иметь исполняемый статус, в противном случае нужно вызывать его через интерпретатор Perl. Скрипту передается один параметр — имя файла, содержащего IPv6-адреса в любом возможном формате. В архиве приведено три таких файла:

  • aaaa-bad — файл с IPv6-адресами, содержащий ошибки (для демонстрационных целей)
  • aaaa — файл с IPv6-адресами, не содержащими ошибок (тоже для демонстраии)
  • aaaa-o — файл, используюемый для построения блока реверсных адресов с ORIGIN

Пример вызова скрипта:

./ip6.pl aaaa

После завершения работы скрипта результаты будут выведены на экран, и при успешном завершении будет сформирован файл ip6.arpa с несложной структурой.

Сообщения об ошибках также выдаются на экран.

Некоторые соображения: делать реверсные записи для каждого ipv6-адреса, например при помощи $GENERATE можно, но вряд ли стоит: такая зона будет не просто очень большой, а ОГРОМНОЙ (полагая, что она /64), а про вторую причину, по которой не следует этого делать, может рассказать любой инженер, занимающийся электронной почтой: дело в том, что практически все почтовые серверы настроены так, что проверяют наличие реверсной записи (именно наличие, а не ее совпадение с тем, что идет в заголовке протокола или почты), и при ее отсутствии не принимают почту. Делается это в первую очередь из-за спама от машин, зараженных вирусом. А если у такой машины есть реверсная запись в ДНС, то спам может и пройти.

Другой «автоматизированный» выход — это динамические обновления в ДНС. Но, опять-таки, нельзя по вышеизложенной причине создавать такую запись всем подряд. А вот как селектировать нужных клиентов — это вопрос, например можно попытаться создать для них отдельный класс в DNS, хотя по трудоемкости это аналогично ручному конфигурированию реверсных записей. Да и не все DNS-клиенты поддерживают динамические обновления. При использовании DHCP-сервера задачу динамической регистрации клиента в DNS с созданием прямой и реверсной записи можно возложить на этот сервер.

И последнее: появился новый термин — «nibble», он же ПОЛУБАЙТ, то есть 4 бита, граница разумного делегирования зон и подсетей в IPv6.

Сконфигурировать Unbound тоже несложно, в конфигурационный файл нужно добавить строки:

do-ipv6:   yes  # (можно и не добавлять, по умолчанию это разрешено)
interface:   2001:db8::53:53   #(IPv6-адрес вашего интерфейса, если не задать — то сервер будет работать на всех интерфейсах)
access-control:   ::1 allow
access-control:   2001:db8::/32 allow

В последней строке (или в нескольких таких строках) укажите «свои» сети, то есть блоки адресов, из которых разрешены рекурсивные запросы (как и для IPv4).

Вместо директивы interface: можно использовать директиву ip-address:

Также несложно конфигурируется NSD:

do-ip6: yes
interface:  2001:db8::a:b:c # также можно использовать директиву ip-address:

Внутри блоков директив, описывающих зоны, можно также задать IPv6-адреса для трансфера зон по IPv6:

Для secondary zone:

allow-notify: 2001:db8::123:2 # принимать уведомления от этого сервера о появлении изменений в зоне
request-xfr:   2001:db8::123:2 # а отсюда slave должен считывать информацию о зоне

Для primary zone:

notify:  2001:db8::1:73 # уведомлять этот сервер о появлении изменений в зоне
provide-xfr:   2001:db8::1:73    # на этот адрес разрешено отдавать копию зоны для secondary

.. и не забыть перезапустить сервер.

Ваш IP

Этот адрес отвечает на пинги

ASN в России