Конфигурирование 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
.. и не забыть перезапустить сервер.