Основная функция DNS-сервера NSD — обслуживание вторичных копий (реплик) зон. NSD может использоваться и для обслуживание первичных копий зон, однако эта функциональность в нем несколько ограничена — отсутствуют, в частности, функции DNSSEC и динамического обновления зон — и, поэтому, не будет нами здесь рассмотрена. Рекурсивное разрешение имен не реализовано вовсе, что также отличает NSD от, к примеру, BIND.

Пример настройки

править

Рассмотрим следующий пример конфигурационного файла /etc/nsd3/nsd.conf, дополняющий, в определенном смысле, рассматриваемую нами в другом разделе настройку сервера BIND.

Отметим, что данный файл включает ключи транзакций, а значит доступ к нему должен быть ограничен. Проще всего этого добиться ограничив доступ к директории /etc/nsd3, подобно:

# chmod -- g=rx,o=  /etc/nsd3 
# chown -- root:nsd /etc/nsd3 
# 
### nsd.conf --- nsd(8) configuration  -*- Default-Generic -*-
server:
    hide-version: yes
    zonesdir: "/var/cache/nsd3/cache"
key:
    name: "betby-l33t"
    algorithm:  hmac-sha256
    secret: "XXX"
zone:
    name: "example.org"
    zonefile: "example.org"
    allow-notify: 2000::/3    "betby-l33t"
    allow-notify: 192.0.2.53  "betby-l33t"
    request-xfr:  2001:db8:42::53:53  "betby-l33t"
    request-xfr:  192.0.2.53          "betby-l33t"
    provide-xfr:  ::1/128 NOKEY
### nsd.conf ends here

В данном примере, мы считаем, что первичную копию зоны следует запрашивать (опция request-xfr:) с сервера betby, доступного по IP-адресам 2001:db8:42::53:53 и 192.0.2.53. На тот случай, если данный сервер обладает и другими IP-адресами (что не редкость в случае IPv6), мы принимаем сообщения об обновлении зоны (allow-notify:) с любых адресов одноадресной рассылки IPv6 (2000::/3), при условии, что они подписаны верным ключом (betby-l33t.)

Для шифрования ключом betby-l33t (обеспечивающим цифровые подписи транзакций; англ. transaction signature, TSIG) используется стандартный[1] алгоритм hmac-sha256. Кроме него, NSD поддерживает алгоритмы HMAC-MD5.SIG-ALG.REG.INT и hmac-sha1, обозначенные как обязательные там же. (Прочие, необязательные алгоритмы на текущий момент не поддерживаются NSD.) [2]

Собственно ключ (secret:) следует копировать с первичного DNS-сервера используя защищенный протокол, такой как, например, SSH.

Наконец, опцией provide-xfr: ::1/128 NOKEY мы разрешаем доступ к AXFR-запросу клиентам с адреса ::1 (ip6-localhost), что делает доступной полезную для диагностики команду $ dig @::1 axfr example.org .

Актуализировать внесенные в конфигурацию NSD изменения можно обычной для Debian командой service(8), подобно:

# service nsd3 restart 

Примечания

править

См. также

править