BIND9 DLZ DNSバックエンド

はじめに

SambaはBIND DNSサーバーをSamba Active Directory(AD) domain controller(DC)上でDNSバックエンドとして利用するためのサポートを提供しています。BIND9_DLZバックエンドは、Samba内部DNSサーバーがサポートしていない複雑なDNSを構成するために推奨されています。

このドキュメントは、ISCによって活発にメンテナンスされているバージョンのBINDのみサポートしています。ISCのBINDのライフサイクルに関する詳細は、https://www.isc.org/downloads/software-support-policy/ を参照してください。

BIND9_DLZモジュールは、Samba Active Directory(AD)データベースに直接アクセスします。理由は以下の通り：

• BINDはSamba ADドメインコントローラ(DC)として同じマシンにインストールする必要があります。
• BINDはchange root環境で実行してはいけません。
• ゾーンはディレクトリと一緒に保存され、複製されます。

ソフトウェアアーキテクチャ

Bind9は'ワーカースレッド'という概念を使用してスレッドモデルを操作します。各プラグインにはmutexが関連付けられているため、2つのワーカースレッドが同時にプラグインが提供するAPI関数を呼び出すことは出来ません。プラグインによるデータベースアクセスは、fcntlロックによって保護されています。

推奨アーキテクチャ

トラフィックの多い環境では、BIND9_DLZバックエンドを使用したsambaをプライマリDNSサーバーとして利用することは推奨されません。そのかわりに、クエリがそのノードによって管理されているゾーンにアドレス指定されている場合にのみ、クエリをBIND9_DLZでバックアップされているsamba DNSに転送する、外部のサーバーを使用してください。

BINDの設定

詳細は、「BIND DNSサーバーの設定」を参照してください。

BIND9_DLZモジュールの設定

ドメインのプロビジョニング、ドメインへの参加、あるいはクラシックアップデートをしている間に、/usr/local/samba/private/named.confファイルが作成されます。

Samba v4.7 とそれ以前では、named.confのファイルパスは少し異なり: /usr/local/samba/private/named.confです。もし、古いバージョンのSambaを使用する場合、以下の手順では、正しいファイルパスを使用するように注意してください。

現在使用しているBINDのバージョンでBIND9_DLZモジュールを有効にするには：

• BINDのnamed.confファイルに次ののincludeステートメントを追加：

include "/usr/local/samba/private/named.conf";

• BINDのバージョンを確認します。

# named -v
BIND 9.9.4

• /usr/local/samba/private/named.confファイルを編集し、確認したBINDのバージョンモジュールをコメントを外します。例：

dlz "AD DNS Zone" {
    # For BIND 9.8
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";

    # For BIND 9.9
    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";

    # For BIND 9.10
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";
    
    # For BIND 9.11
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so";
};

次の表は、サポートされているBINDのバージョンとサポートが開始されたSambaのバージョンを示しています。

BINDバージョン	サポートされたSambaのバージョン
BIND 9.11	Samba 4.5.2以降
BIND 9.10	Samba 4.2以降
BIND9.9	Samba 4.0以降
BIND9.8	Samba 4.0以降

Kerberosを使用した動的DNS更新のセットアップ

Sambaは、BIND9_DLZバックエンドによって管理されるActive Directory（AD）ゾーンを自動的に更新することができます。

動的DNS更新には最低でもBINDバージョン9.8が必要です。

Kerberosを使用して動的DNS更新を有効にするには

• BINDのnamed.confファイルのoptions {}セクションに次のinclude文を追加します。例えば：

options {
     [...]
     tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
     [...]
};

• プロビジョニングまたはADフォレストに参加させた場合、または4.4.0より前のSambaバージョンを使用して従来のアップグレードを実行した場合、誤った権限を使用してBIND Kerberosキータブファイルが生成されました。修正するには、BINDユーザーの読み取りアクセスを有効にします。

#chmod 640 /usr/local/samba/private/dns.keytab
#chown root：named /usr/local/samba/private/dns.keytab

パッケージを使用してSambaをインストールする場合は、BINDユーザーがdns.keytabファイルを読み取ることができることを検証します。一部のパッケージインストールでは、上位のフォルダに対する制限付きのアクセス許可が設定されています。

• /etc/krb5.confKerberosクライアント構成ファイルがBINDユーザーによって読み取り可能であることを確認します。例えば：

# ls -l /etc/krb5.conf
-rw-r--r--. 1 root named 99  2. Sep 2014  /etc/krb5.conf

• ドメインコントローラ（DC）にnsupdateユーティリティが存在することを確認します。

# which nsupdate
/usr/bin/nsupdate

nsupdateコマンドは、DNSを更新するために使用されます。ユーティリティが見つからない場合は、配布物のドキュメントを参照して、コマンドを含むパッケージの識別方法とインストール方法を確認してください。

AppArmorとSELinuxの統合

詳細は、BIND9 DLZ AppArmorとSELinux統合を参照してください。

BINDサービスの開始

• サービスを開始する前に、BINDの設定を確認してください。

# named-checkconf

出力が表示されない場合、BIND構成は有効です。

• BINDサービスを開始します。

動的DNS更新のテスト

詳細については、動的DNS更新のテストを参照してください。

The Lockup Problem

When a BIND thread calls one of the BIND9_DLZ plugin API calls, execution can be blocked on database access calls if locks are out on the database at the time. Unfortunately, during that time, BIND will not be able to serve any queries, even external (non-samba) queries. Bind has a "-n" option that can increase the number of worker threads but testing has shown that increasing this number does not fix the problem, indicating that BIND's threading and queueing models are probably a bit broken. In small-scale environments this problem is unlikely to come up, but, in high-traffic environments, it may cause DNS outage. The only solution right now is to use an external DNS server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.

トラブルシューティング

BIND9_DLZバックエンドの再構成

BIND9_DLZバックエンドセットアップを実行すると、Active Directory（AD）BIND DNSアカウント（dns-*）とBIND Kerberosキータブファイルの 問題を再現するなどのいくつかの問題が自動的に修正されます。

問題を解決するには：

• 自動再構成を実行します。

# samba_upgradedns --dns-backend=BIND9_DLZ
Reading domain information
DNS accounts already exist
No zone file /usr/local/samba/private/dns/SAMDOM.EXAMPLE.COM.zone
DNS records will be automatically created
DNS partitions already exist
dns-DC1 account already exists
See /usr/local/samba/private/named.conf for an example configuration include file for BIND
and /usr/local/samba/private/named.txt for further documentation required for secure DNS updates
Finished upgrading DNS

• BINDサービスを再起動します。

BIND9_DLZモジュールのデバッグ

BIND9_DLZモジュールのログレベルを設定するには：

/usr/local/samba/private/named.confファイルのモジュールに-dパラメータとログレベルを追加します。例えば：

database "dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3";

• BINDサービスを停止します。
• デバッグ出力を表示し、ログ出力を/tmp/named.logファイルにキャプチャするには、BINDを手動で起動します。

 # named -u named -f -g 2>&1 | tee /tmp/named.log

使用されるパラメータの詳細については、named (8)のマニュアルページを参照してください。

新しいDNSエントリが解決できない

ディレクトリに新しいDNSレコードを作成し、nslookup、host、またはその他のDNSルックアップツールを使用して新しいDNSレコードを作成できない場合は、データベースのハードリンクが失われている可能性があります。これは、たとえば、マウントポイント 間でデータベースを移動する場合に発生します。

ドメインとフォレストのパーティションとmetadata.tdbデータベースが両方のディレクトリでハードリンクされていることを確認 するには、

# ls -lai /usr/local/samba/private/sam.ldb.d/
17344368 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named   421888 11. Nov 17:53 metadata.tdb

# ls -lai /usr/local/samba/private/dns/sam.ldb.d/
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb

同じファイルは、両方のディレクトリの出力の最初の列に同じinode番号を持つ必要があります。それらが異なる場合、ハードリンクが失われて しまい、SambaとBINDが別々のデータベースファイルを使用するため、ディレクトリ内のDNS更新がBIND DNSサーバーから解決できません。

ハードリンクの自動修復については、「BIND9_DLZバックエンドの再構成」を参照してください。

DNSの更新に失敗する：NOTAUTH

BINDがSamba Active Directory（AD）ドメインコントローラ（DC）で不正なKerberos設定を使用すると、動的DNS更新が失敗します。例えば：

# samba_dnsupdate --verbose
...
update(nsupdate): SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268
Calling nsupdate for SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268 (add)
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
_gc._tcp.Default-First-Site-Name._sites.samdom.example.com. 900 IN SRV 0 100 3268 DC1.samdom.example.com.

update failed: NOTAUTH

この問題を解決するために：

• BINDの設定が正しく設定されていることを確認してください。詳細については、「Kerberosを使用した動的DNS更新のセットアップ」を

参照してください。

• BINDバックエンド設定を再作成します。詳細については、「[[#BIND9_DLZバックエンドの再構成|]]」を参照してください。

DNSの更新に失敗する：dns_tkey_negotiategss：TKEYは受け入れられません

詳細については、「dns_tkey_negotiategss:_TKEYは受け入れられません」を参照してください。

Bind9 DNSサーバーのリロード

Bind9をreloadすると、ログに次のような行が表示されます。

named[29534]: samba_dlz: Ignoring duplicate zone

Samba AD DCでBind9をreloadすることはできません。restartする必要があります。 logrotateがreloadを使用しているかどうかを確認し、もしそうであれば変更して下さい。