web-dev-qa-db-ja.com

バインドを開始できません：/etc/named.conf：権限が拒否されました

だから私はこれについて本当に新しく、バインドを設定するために このチュートリアル に従っていて、4：50まで問題なく、pingを実行し、nslookupを使用して、dnsとインターネット接続できましたサーバー、次にゾーンを追加してゾーンファイルを作成する必要があります（それらを作成するだけです）、完璧です。問題がないかどうかを確認するために再起動します（仮想マシンを使用しています）。その後、pingを実行できなくなり、nslookupを使用できなくなりました。インターネット接続さえありませんでした。これは、systemctl statusを使用して取得したものです

Redirecting to /bin/systemctl status  -l named.service
● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor prese$
   Active: failed (Result: exit-code) since jue 2019-04-25 23:14:30 -04; 3min 3$
  Process: 3355 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "y$

abr 25 23:14:30 linux bash[3355]: _default/0.168.192.in-addr.arpa/IN: bad zone
abr 25 23:14:30 linux bash[3355]: zone localhost.localdomain/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone localhost/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone 
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.$
abr 25 23:14:30 linux bash[3355]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial$
abr 25 23:14:30 linux bash[3355]: zone 0.in-addr.arpa/IN: loaded serial 0
abr 25 23:14:30 linux systemd[1]: named.service: control process exited, code=e$
abr 25 23:14:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain$
abr 25 23:14:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:14:30 linux systemd[1]: named.service failed.

これは空のゾーンファイルが原因であると考えたので、ゾーンなしのnamed.confに置き換え、service restart namedで再起動しようとしましたが、（再び）取得しました。

Failed to start BIND : Redirecting to /bin/systemctl start named.service Job 
for named.service failed because the control process exited with error code.
See "systemctl status named.service" and "journalctl -xe" for details.

だから私はやった

● named.service - Berkeley Internet Name Domain (DNS)
 Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since jue 2019-04-25 23:25:30 -04; 1min 3s ago
  Process: 5557 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=1/FAILURE)
  Process: 5552 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS)

abr 25 23:25:30 linux named[5559]: found 2 CPUs, using 2 worker threads
abr 25 23:25:30 linux named[5559]: using 2 UDP listeners per interface
abr 25 23:25:30 linux named[5559]: using up to 21000 sockets
abr 25 23:25:30 linux named[5559]: loading configuration from '/etc/named.conf'
abr 25 23:25:30 linux named[5559]: open: /etc/named.conf: permission denied
abr 25 23:25:30 linux named[5559]: loading configuration: permission denied
abr 25 23:25:30 linux systemd[1]: named.service: control process exited, code=exited status=1
abr 25 23:25:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
abr 25 23:25:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:25:30 linux systemd[1]: named.service failed.

これは許可の問題ですが、以前は完全に機能していたので途方に暮れています。

これは私がls -l /etc/named.confを実行することで得られるものです。

-rw-r-----. 1 root root 1808 abr 25 15:13 /etc/named.conf

そして、これはls -Z /etc/named.confを実行するときです（selinuxと関係がある場合）。

 -rw-r-----. 1 root root unconfined_u:object_r:etc_t:s0 /etc/named.conf

それが役立つかどうかはわかりませんが、named.confは次のとおりです

options {
    listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory   "/var/named";
        dump-file   "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { localhost; };

    recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

logging {
    channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
    type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

/ etc/named /にchrootフォルダーもありません
これに対する解決策はありますか？ありがとう。

linuxdebiancentos7bindtmpfs
2
Nelson SMG

named.confを置き換えると、selinuxコンテキストが混乱しました。ls-Zを実行すると、次のようになります。

-rw-r--r--. root root system_u:object_r:named_conf_t:s0 named.conf

あなたが私のそれを見ることができるように、それをリセットするために、私は使用しました

restorecon -RFv /etc/named.conf

ただし、これを使用してls -Zを実行すると、

-rw-r-----. root root system_u:object_r:named_conf_t:s0 named.conf

最後の「r」を追加して、誰でも読めるようにしました。

chmod 644 /etc/named.conf

という名前のサービスを停止して再起動すると、再び機能します。

2
Nelson SMG

CentOS 7では、バインドはデフォルトでnamedではなくrootユーザーとして実行されます。したがって、named.confはrootが所有し、rootのみ。

HåkanLindqvistがすでにコメントしたように、CentOS 7の権限は以下のようになります。

-rw-r-----. 1 root named 10672 04-09 20:02 /etc/named.conf

そうする：

# chown root:named /etc/named.conf
# chroot 640 /etc/named.conf
1
Tomek

監査ログを確認してください。追加のファイルシステムACLを使用している場合は、それらのログも確認してください。これがSELinuxの問題であると思われる場合は、無効にしてもう一度試してください。問題が解決した場合は、SELinuxポリシーを修正する必要があります。バインドselinuxのリファレンスについては、 https://www.systutorials.com/docs/linux/man/8-bind_selinux/ を確認してください。

0
asktyagi

同上：しかし、Debian 10では、ISC Bind 9.11.5。

事前チェックリスト

メッセージの残りの部分が適用されないことを確認するためのチェックリストを提供します。Bind9/ namedの誤ったPIDパス構成設定がないか、次のディレクトリを確認することをお勧めします。

  • /etc/default/namedの場合は/etc/default/bind9（またはPIDFILE=）
  • /etc/named/named.confのpid-file=（またはinclude構成ファイル）
  • /etc/systemd/system/bind9.conf（PIDfile=の場合）

詳細、詳細、詳細

上記のチェックリストが完了したら...このTLの最後に行くことができます; DRの回避策インスタントソリューションのセクション。

部分的なエラーログメッセージ "mkdir't mkdir"はbind9/named/unix/os.cソースファイルでのみ見つかります：最も近い行のリンクは ISC Bind9 Github にあります。

mkdirpath()の使用法のソースコードを熟読し、mkdirpath()がbind9/named/unix/os.cソースコード内でのみ使用されていることを確認した後、ISC開発者が新しいコードを選択していないことを確認しました「非ルート」グループファイルのアクセス権保護方法...ただし、名前付きデーモンが「ルート」グループとしてのみ実行され、「バインド」（または「名前付き」）グループでは実行されないようにコードがまだハードコードされているため...

これは、systemctl start tmpfilesd（より正確には、/var/run）の制御がtmpfilesデーモン（および名前付きデーモンではない）によって制御されているtmpfilesデーモンを（/runを介して）実行するDebianで特に当てはまります。

私の名前付きデーモンCLIオプションには、ハードコーディングされた「ルート」と競合する-u bindオプションがあります。

Named_os_issingleton（）はmkdirpath()の呼び出し元ではないことがわかっています。これは、2番目のエラーログ「could n't create：...」のログ出力が欠落しているためです。

これにより、named_os_openfile()の呼び出し元が `mkdirpath（） 'を呼び出すだけになります。そしてそれは2つの場所で呼ばれます：

  • server.c（鍵を鍵ファイルにダンプするため）
  • os.c（PIDファイルを書き込むため）

ログファイルにも2番目のエラーメッセージがないため、server.cではありません。

この時点では、PIDファイルの書き込みに問題があるとしか想定できません。 Debianが/varの部分を通常の/var/run/named.pidからノックオフすることに決めたのは当然のことです。最新のLinuxファイルシステム標準 .0、ここでは詳細 が与えられた場合、これは予想されます。

あなたのように、私もこのPIDファイルディレクトリを '/run/named'から '/run/bind'に変更しました（正確には、/run/bind-public 'は、要塞ホスト構成モードで複数の名前付きデーモンを実行しているためです）。また、SOMEONEをnamedに変更しても、サブディレクトリ名としてbindが残っています。

現時点では、これまでのところ手動トレースバックは次のとおりです。

  • mkdirpath()
  • named_os_openfile()
  • named_os_writepidfile()

server.cを再確認すると、named_g_defaultpidfileの定義が "/run/named"にハードコーディングされていることに気づくでしょう。 globals.h（ here ）で定義されています。

Workaround

回避策は...サブディレクトリ/run/namedを作成して、起動時にISCバインドコードを偽造することです。

   mkdir /run/named
   chown root:bind /run/named
   chmod u+rwx,g+rx-w,o-rwx /run/named

とりあえず「無視する」。

しかし....また、起動時にtmpfilesデーモンを実行している場合は、代わりにこれを/etc/tmpfiles.d/named.conf（またはbind.confまたは私の場合は/etc/tmpfiles.d/bind-public.conf）に実行する必要があります。

#Type Path                 Mode User Group Age Argument

# We set the 2xxx part (g+s) of directories' chmod so
# that when the named/bind9 daemon creates 
# that PID file, its ownership would be bind:bind.
d  /run/bind           2770 root bind  - -

# Add the following line to suppress spurious log message    
d  /run/named          0750 root bind  - -

作成すると、厄介なログが消えます。

0
John Greene