「BIND9 DLZ DNSバックエンド」の版間の差分

提供: 雑廉堂Wiki
(→‎DNSの更新に失敗する：NOTAUTH)
 
(同じ利用者による、間の30版が非表示)
1行目: 1行目:
−
== はじめに ==
+
= はじめに =
  
 
SambaはBIND DNSサーバーをSamba Active Directory(AD) domain controller(DC)上でDNSバックエンドとして利用するためのサポートを提供しています。<code>BIND9_DLZ</code>バックエンドは、Samba内部DNSサーバーがサポートしていない複雑なDNSを構成するために推奨されています。
 
SambaはBIND DNSサーバーをSamba Active Directory(AD) domain controller(DC)上でDNSバックエンドとして利用するためのサポートを提供しています。<code>BIND9_DLZ</code>バックエンドは、Samba内部DNSサーバーがサポートしていない複雑なDNSを構成するために推奨されています。
14行目: 14行目:
 
* ゾーンはディレクトリと一緒に保存され、複製されます。
 
* ゾーンはディレクトリと一緒に保存され、複製されます。
  
−
== BINDの設定 ==
+
= ソフトウェアアーキテクチャ =
 +
Bind9は'ワーカースレッド'という概念を使用してスレッドモデルを操作します。各プラグインにはmutexが関連付けられているため、2つのワーカースレッドが同時にプラグインが提供するAPI関数を呼び出すことは出来ません。プラグインによるデータベースアクセスは、fcntlロックによって保護されています。
 +
 
 +
= 推奨アーキテクチャ =
 +
 
 +
トラフィックの多い環境では、BIND9_DLZバックエンドを使用したsambaをプライマリDNSサーバーとして利用することは推奨されません。そのかわりに、クエリがそのノードによって管理されているゾーンにアドレス指定されている場合にのみ、クエリをBIND9_DLZでバックアップされているsamba DNSに転送する、外部のサーバーを使用してください。
 +
 
 +
= BINDの設定 =
  
 
詳細は、「[[BIND DNSサーバーの設定]]」を参照してください。
 
詳細は、「[[BIND DNSサーバーの設定]]」を参照してください。
  
−
== BIND9_DLZモジュールの設定 ==
+
= BIND9_DLZモジュールの設定 =
 +
 
 +
ドメインのプロビジョニング、ドメインへの参加、あるいはクラシックアップデートをしている間に、<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>named.conf</code>ファイルに次のの<code>include</code>ステートメントを追加：
 +
 
 +
include "/usr/local/samba/private/named.conf";
 +
 
 +
* BINDのバージョンを確認します。
 +
 
 +
# named -v
 +
BIND 9.9.4
 +
 
 +
* <code>/usr/local/samba/private/named.conf</code>ファイルを編集し、確認した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のバージョンを示しています。
 +
 
 +
{| class="wikitable"
 +
!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は、<code>BIND9_DLZ</code>バックエンドによって管理されるActive Directory（AD）ゾーンを自動的に更新することができます。
 +
 
 +
{{imbox
 +
| style = margin: 4px 2%;
 +
| text  = 動的DNS更新には最低でもBINDバージョン9.8が必要です。
 +
}}
 +
 
 +
Kerberosを使用して動的DNS更新を有効にするには
 +
 
 +
* BINDの<code>named.conf</code>ファイルの<code>options {}</code>セクションに次の<code>include</code>文を追加します。例えば：
 +
 
 +
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
 +
 
 +
{{imbox
 +
| style = margin:4px 2%;
 +
| text = パッケージを使用してSambaをインストールする場合は、BINDユーザーがdns.keytabファイルを読み取ることができることを検証します。一部のパッケージインストールでは、上位のフォルダに対する制限付きのアクセス許可が設定されています。
 +
}}
 +
 
 +
* <code>/etc/krb5.conf</code>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
 +
 
 +
<code>nsupdate</code>コマンドは、DNSを更新するために使用されます。ユーティリティが見つからない場合は、配布物のドキュメントを参照して、コマンドを含むパッケージの識別方法とインストール方法を確認してください。
 +
 
 +
 
 +
= AppArmorとSELinuxの統合 =
 +
 
 +
詳細は、[[BIND9 DLZ AppArmorとSELinux統合]]を参照してください。
 +
 
 +
= BINDサービスの開始 =
 +
 
 +
* サービスを開始する前に、BINDの設定を確認してください。
 +
 
 +
<pre># named-checkconf</pre>
 +
出力が表示されない場合、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バックエンドの再構成 ==
 +
 
 +
<code>BIND9_DLZ</code>バックエンドセットアップを実行すると、Active Directory（AD）BIND DNSアカウント（<code>dns-*</code>）とBIND Kerberosキータブファイルの
 +
問題を再現するなどのいくつかの問題が自動的に修正されます。
 +
 
 +
問題を解決するには：
 +
 
 +
* 自動再構成を実行します。
 +
 
 +
<pre># 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</pre>
 +
* BINDサービスを再起動します。
 +
 
 +
== BIND9_DLZモジュールのデバッグ ==
 +
 
 +
<code>BIND9_DLZ</code>モジュールのログレベルを設定するには：
 +
 
 +
<code>/usr/local/samba/private/named.conf</code>ファイルのモジュールに<code>-d</code>パラメータとログレベルを追加します。例えば：
 +
 
 +
<pre>database &quot;dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3&quot;;</pre>
 +
* BINDサービスを停止します。
 +
* デバッグ出力を表示し、ログ出力を/tmp/named.logファイルにキャプチャするには、BINDを手動で起動します。
 +
 
 +
<pre> # named -u named -f -g 2&gt;&amp;1 | tee /tmp/named.log</pre>
 +
使用されるパラメータの詳細については、<code>named (8)</code>のマニュアルページを参照してください。
 +
 
 +
 
 +
== 新しいDNSエントリが解決できない ==
 +
 
 +
ディレクトリに新しいDNSレコードを作成し、<code>nslookup</code>、<code>host</code>、またはその他のDNSルックアップツールを使用して新しいDNSレコードを作成できない場合は、データベースのハードリンクが失われている可能性があります。これは、たとえば、マウントポイント
 +
間でデータベースを移動する場合に発生します。
 +
 
 +
ドメインとフォレストのパーティションと<code>metadata.td</code>bデータベースが両方のディレクトリでハードリンクされていることを確認
 +
するには、
 +
 
 +
<pre># 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</pre>
 +
同じファイルは、両方のディレクトリの出力の最初の列に同じinode番号を持つ必要があります。それらが異なる場合、ハードリンクが失われて
 +
しまい、SambaとBINDが別々のデータベースファイルを使用するため、ディレクトリ内のDNS更新がBIND DNSサーバーから解決できません。
 +
 
 +
ハードリンクの自動修復については、[[#BIND9_DLZバックエンドの再構成|BIND9_DLZバックエンドの再構成]]を参照してください。
 +
 
 +
== DNSの更新に失敗する：NOTAUTH ==
 +
 
 +
BINDがSamba Active Directory（AD）ドメインコントローラ（DC）で不正なKerberos設定を使用すると、動的DNS更新が失敗します。例えば：
 +
 
 +
<pre># 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:
 +
;; -&gt;&gt;HEADER&lt;&lt;- 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</pre>
 +
この問題を解決するために：
 +
 
 +
* BINDの設定が正しく設定されていることを確認してください。詳細については、[[#Kerberosを使用した動的DNS更新のセットアップ|Kerberosを使用した動的DNS更新のセットアップ]]を参照してください。
 +
* BINDバックエンド設定を再作成します。詳細については、[[#BIND9_DLZバックエンドの再構成|BIND9_DLZバックエンドの再構成]]を参照してください。
 +
 
 +
== DNSの更新に失敗する：dns_tkey_negotiategss：TKEYは受け入れられません ==
 +
 
 +
詳細については、「[[dns_tkey_negotiategss:_TKEYは受け入れられません]]」を参照してください。
 +
 
 +
== Bind9 DNSサーバーのリロード ==
 +
 
 +
Bind9を<code>reload</code>すると、ログに次のような行が表示されます。
 +
 
 +
<pre>named[29534]: samba_dlz: Ignoring duplicate zone</pre>
 +
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'
 +
 
  
−
ドメインのプロビジョニング、ドメインへの参加、あるいはクラシックアップデートをしている間に、<code>/usr/local/samba/private/named.conf</code>ファイルが作成されています。
+
これは、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を構成するために推奨されています。

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」から取得