「BIND9 DLZ DNSバックエンド」の版間の差分
(→Recommended Architecture) |
(→DNSの更新に失敗する:NOTAUTH) |
||
(同じ利用者による、間の11版が非表示) | |||
25行目: | 25行目: | ||
詳細は、「[[BIND DNSサーバーの設定]]」を参照してください。 | 詳細は、「[[BIND DNSサーバーの設定]]」を参照してください。 | ||
− | + | = BIND9_DLZモジュールの設定 = | |
ドメインのプロビジョニング、ドメインへの参加、あるいはクラシックアップデートをしている間に、<code>/usr/local/samba/private/named.conf</code>ファイルが作成されます。 | ドメインのプロビジョニング、ドメインへの参加、あるいはクラシックアップデートをしている間に、<code>/usr/local/samba/private/named.conf</code>ファイルが作成されます。 | ||
+ | |||
+ | |||
+ | {{Imbox | ||
+ | | type = notice | ||
+ | | style = margin:4px 2%; | ||
+ | | text = Samba v4.7 とそれ以前では、<code>named.conf</code>のファイルパスは少し異なり: <code>/usr/local/samba/private/named.conf</code>です。もし、古いバージョンのSambaを使用する場合、以下の手順では、正しいファイルパスを使用するように注意してください。 | ||
+ | }} | ||
+ | |||
現在使用しているBINDのバージョンで<code>BIND9_DLZ</code>モジュールを有効にするには: | 現在使用しているBINDのバージョンで<code>BIND9_DLZ</code>モジュールを有効にするには: | ||
74行目: | 82行目: | ||
|} | |} | ||
− | + | = Kerberosを使用した動的DNS更新のセットアップ = | |
Sambaは、<code>BIND9_DLZ</code>バックエンドによって管理されるActive Directory(AD)ゾーンを自動的に更新することができます。 | Sambaは、<code>BIND9_DLZ</code>バックエンドによって管理されるActive Directory(AD)ゾーンを自動的に更新することができます。 | ||
116行目: | 124行目: | ||
− | + | = AppArmorとSELinuxの統合 = | |
− | + | 詳細は、[[BIND9 DLZ AppArmorとSELinux統合]]を参照してください。 | |
− | + | = BINDサービスの開始 = | |
* サービスを開始する前に、BINDの設定を確認してください。 | * サービスを開始する前に、BINDの設定を確認してください。 | ||
129行目: | 137行目: | ||
* BINDサービスを開始します。 | * BINDサービスを開始します。 | ||
− | + | = 動的DNS更新のテスト = | |
− | + | 詳細については、[[動的DNS更新のテスト]]を参照してください。 | |
− | = | + | = ロックアップ問題 = |
− | === BIND9_DLZバックエンドの再構成 | + | 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バックエンドの再構成 == | ||
<code>BIND9_DLZ</code>バックエンドセットアップを実行すると、Active Directory(AD)BIND DNSアカウント(<code>dns-*</code>)とBIND Kerberosキータブファイルの | <code>BIND9_DLZ</code>バックエンドセットアップを実行すると、Active Directory(AD)BIND DNSアカウント(<code>dns-*</code>)とBIND Kerberosキータブファイルの | ||
156行目: | 172行目: | ||
* BINDサービスを再起動します。 | * BINDサービスを再起動します。 | ||
− | + | == BIND9_DLZモジュールのデバッグ == | |
<code>BIND9_DLZ</code>モジュールのログレベルを設定するには: | <code>BIND9_DLZ</code>モジュールのログレベルを設定するには: | ||
170行目: | 186行目: | ||
− | + | == 新しいDNSエントリが解決できない == | |
ディレクトリに新しいDNSレコードを作成し、<code>nslookup</code>、<code>host</code>、またはその他のDNSルックアップツールを使用して新しいDNSレコードを作成できない場合は、データベースのハードリンクが失われている可能性があります。これは、たとえば、マウントポイント | ディレクトリに新しいDNSレコードを作成し、<code>nslookup</code>、<code>host</code>、またはその他のDNSルックアップツールを使用して新しいDNSレコードを作成できない場合は、データベースのハードリンクが失われている可能性があります。これは、たとえば、マウントポイント | ||
190行目: | 206行目: | ||
しまい、SambaとBINDが別々のデータベースファイルを使用するため、ディレクトリ内のDNS更新がBIND DNSサーバーから解決できません。 | しまい、SambaとBINDが別々のデータベースファイルを使用するため、ディレクトリ内のDNS更新がBIND DNSサーバーから解決できません。 | ||
− | + | ハードリンクの自動修復については、[[#BIND9_DLZバックエンドの再構成|BIND9_DLZバックエンドの再構成]]を参照してください。 | |
− | + | == DNSの更新に失敗する:NOTAUTH == | |
BINDがSamba Active Directory(AD)ドメインコントローラ(DC)で不正なKerberos設定を使用すると、動的DNS更新が失敗します。例えば: | BINDがSamba Active Directory(AD)ドメインコントローラ(DC)で不正なKerberos設定を使用すると、動的DNS更新が失敗します。例えば: | ||
209行目: | 225行目: | ||
この問題を解決するために: | この問題を解決するために: | ||
− | * | + | * BINDの設定が正しく設定されていることを確認してください。詳細については、[[#Kerberosを使用した動的DNS更新のセットアップ|Kerberosを使用した動的DNS更新のセットアップ]]を参照してください。 |
− | + | * BINDバックエンド設定を再作成します。詳細については、[[#BIND9_DLZバックエンドの再構成|BIND9_DLZバックエンドの再構成]]を参照してください。 | |
− | * | ||
− | + | == DNSの更新に失敗する:dns_tkey_negotiategss:TKEYは受け入れられません == | |
詳細については、「[[dns_tkey_negotiategss:_TKEYは受け入れられません]]」を参照してください。 | 詳細については、「[[dns_tkey_negotiategss:_TKEYは受け入れられません]]」を参照してください。 | ||
− | + | == Bind9 DNSサーバーのリロード == | |
Bind9を<code>reload</code>すると、ログに次のような行が表示されます。 | Bind9を<code>reload</code>すると、ログに次のような行が表示されます。 | ||
223行目: | 238行目: | ||
<pre>named[29534]: samba_dlz: Ignoring duplicate zone</pre> | <pre>named[29534]: samba_dlz: Ignoring duplicate zone</pre> | ||
Samba AD DCでBind9を<code>reload</code>することはできません。<code>restart</code>する必要があります。 logrotateが<code>reload</code>を使用しているかどうかを確認し、もしそうであれば変更して下さい。 | Samba AD DCでBind9を<code>reload</code>することはできません。<code>restart</code>する必要があります。 logrotateが<code>reload</code>を使用しているかどうかを確認し、もしそうであれば変更して下さい。 | ||
+ | |||
+ | == 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設定をリロード<code>samba_upgradedns --dns-backend=BIND9_DLZ</code>してからBind9サービスを再起動します。 |
2019年3月9日 (土) 15:53時点における最新版
目次
はじめに
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.conf
Kerberosクライアント構成ファイルが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.td
bデータベースが両方のディレクトリでハードリンクされていることを確認
するには、
# 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
を使用しているかどうかを確認し、もしそうであれば変更して下さい。
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サービスを再起動します。