BIND9 DLZ DNSバックエンド

提供: 雑廉堂Wiki

はじめに

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

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ファイルが作成されます。


現在使用している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）ゾーンを自動的に更新することができます。

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
  • /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更新のテストを参照してください。

ロックアップ問題

BINDスレッドがBIND_DLZプラグインのAPIの一つを呼び出すとき、その時点で、データベースのロックが解除されている場合、データベース呼び出しで実行がブロックされる可能性があります。残念ながら、その間、BINDは、たとえ外部の(Sambaではない)クエリであったとしても、どんなクエリも対応することができません。Bindは、ワーカースレッドの数を増やすことのできる、"-n"オプションを持っていますが、テストによると、この数字を増やすことでは、この問題を解決されず、おそらくBindのスレッドとキューモデルは、少し壊れていることがわかります。 小規模な環境であれば、この問題は起こりそうにはありませんが、トラフィックの多い環境では、DNSが停止する可能性があります。今すぐできる唯一の解決策は、クエリがそのノードによって管理されているゾーンに当てられている場合にのみ、BIND_DLZでサポートされているSamba DNS インストールにクエリ転送する、外部のDNSサーバを使用することです。

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

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

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を使用しているかどうかを確認し、もしそうであれば変更して下さい。

Bind9 DNS サーバーが "unhandled record type 65281" で起動に失敗する (Windows AD + Samba AD)

Bind9 DNSサーバーを起動する時、次のように表示される場合: If when starting Bind9 DNS Server you see something like: 

samba_dlz: starting configure
samba_dlz b9_format: unhandled record type 65281
zone example.local/NONE: could not find NS and/or SOA records
zone example.local/NONE: has 0 SOA records
zone example.local/NONE: has no NS records
samba_dlz: Failed to configure zone 'example.local'


これは、WINSエントリを持つWindows Server Active Directoryがあり、それに参加しようとしているために発生する可能性があります。 これを修正するには、Windows Server DCの直接検索ゾーンのDNSでWINS解決を無効にし、Samba ADサービスを再起動し、DNS設定をリロードsamba_upgradedns --dns-backend=BIND9_DLZしてからBind9サービスを再起動します。

「http://www.rough-and-cheap.jp/mediawiki/index.php?title=BIND9_DLZ_DNSバックエンド&oldid=10022」から取得