2026年6月6日

nscd のTTL確認手順｜positive・negative-time-to-live の現在値と、実際に何秒キャッシュされるかの確かめ方

DNS・名前解決

nscd がホスト名の結果を何秒覚えているかは、/etc/nscd.conf の positive-time-to-live と negative-time-to-live で決まり、実行中の値は sudo nscd -g で確認できます。ただし、設定ファイルの値と実行中の値が食い違っていることや、DNSのTTLとの関係で実際の保持時間が設定値と異なることがあります。この記事では、設定値・実行中の値・実測値の3つを順に確かめ、用途に合った値に調整するところまでを説明します。名前解決の障害対応そのものではなく、「TTLをどう確認し、どう決めるか」に絞った内容です。

nscd の「TTL」は2種類ある

nscd では、データベース（passwd、group、hosts、services、netgroup など）ごとに、2種類の保持時間を設定します。

positive-time-to-live：問い合わせが成功した結果（IPが見つかった）を保持する秒数
negative-time-to-live：失敗した結果（見つからなかった）を保持する秒数

DNSのレコードにもTTLがありますが、これはDNSサーバーやリゾルバがキャッシュする時間の目安で、nscd の設定とは別のものです。名前解決の経路では「権威DNSのTTL」「リゾルバのキャッシュ」「nscd のキャッシュ」がそれぞれ働くため、どの層の時間を見ているのかを意識して確認することが大切です。

手順1：設定ファイルの値を確認する

まず、/etc/nscd.conf に書かれている hosts の設定を抜き出します。

grep -E '^\s*(enable-cache|positive-time-to-live|negative-time-to-live|persistent|check-files|shared)\s+hosts' /etc/nscd.conf

出力例は次のようになります（値はディストリビューションや管理者の設定によって異なります）。

enable-cache            hosts   yes
positive-time-to-live   hosts   3600
negative-time-to-live   hosts   20
check-files             hosts   yes
persistent              hosts   yes
shared                  hosts   yes

この例では、成功した結果を1時間、失敗した結果を20秒保持します。行頭に # が付いている行はコメントで、効いていません。項目が見つからない場合は、nscd の組み込みの既定値が使われます。既定値はglibcのバージョンやパッケージによって異なるため、次の手順で実行中の値を確かめてください。

あわせて見ておきたいのが persistent と check-files です。persistent が yes だと、キャッシュがディスクに保存され、nscd を再起動しても残ります。TTLを短くしても、既にキャッシュされている結果は古い保持時間のまま残ることがあるので、変更後は後述の無効化操作を合わせて行います。

手順2：実行中の値を確認する

nscd は起動時に設定を読み込みます。設定ファイルを書き換えたあと再起動していなければ、実行中の値は古いままです。実行中の値は統計情報で確認します。

sudo nscd -g | grep -A25 '^hosts cache'

hosts cache の欄に、seconds time to live for positive entries と seconds time to live for negative entries という行があり、その左の数値が実行中の保持時間です。表記はバージョンによって多少異なることがあります。一般ユーザーで実行すると拒否される場合があるため、sudo を付けてください。

ここで手順1の値と一致していなければ、設定変更後に再起動していないか、別の設定ファイルを見ている可能性があります。systemctl status nscd で起動時刻を確認し、設定ファイルの更新日時（ls -l /etc/nscd.conf）より前なら再起動が必要です。

手順3：DNSのTTLと比べる

nscd の値だけを見ても、それが適切かは判断できません。対象のホスト名がDNS上でどれくらいのTTLを持っているかを確認します。

dig +noall +answer www.example.com A

答えの2列目の数値がTTL（秒）です。キャッシュDNSサーバー経由で問い合わせると、残り時間がカウントダウンされた値が出ます。本来のTTLを知りたいときは、権威DNSサーバーに直接問い合わせます。

dig +short NS example.com
dig +noall +answer +norec @ns1.example-dns.net www.example.com A

ns1.example-dns.net の部分は、1行目で表示されたネームサーバー名に置き換えてください。

nscd の hosts キャッシュとDNSのTTLの関係は、glibcのバージョンによって異なります。古い実装では、DNSのTTLに関係なく positive-time-to-live の間保持していました。新しめの実装ではDNSのTTLも考慮し、設定値を上限として短い方を使うように変わっています。手元の環境がどちらかは、次の実測で確かめるのが確実性の高い方法です。

手順4：実際に何秒キャッシュされるかを測る

設定値どおりに動いているかは、実際に試すと分かります。自分で管理しているドメインにテスト用のレコードを作り、値を変えて、OSの名前解決がいつ新しい値に切り替わるかを記録します。本番で使っているレコードは使わず、nscd-test.example.com のような専用の名前を用意してください。

# 10秒ごとに、DNSへの直接問い合わせと、nscd を通る結果を並べて記録する
while true; do
  printf '%s dig=%s getent=%s\n' \
    "$(date +%H:%M:%S)" \
    "$(dig +short nscd-test.example.com A | head -n1)" \
    "$(getent hosts nscd-test.example.com | awk '{print $1}')"
  sleep 10
done

ループを動かしたまま、DNS管理画面でテスト用レコードのIPを変更します。dig 側が新しいIPになってから getent 側が追いつくまでの時間が、nscd が古い結果を持ち続けた時間の目安です。Ctrl+C で止めます。

dig 自体がなかなか変わらない場合は、上流のキャッシュDNSサーバーのTTLが残っています。その分は nscd とは関係ないので、dig が切り替わった時刻を起点に数えてください。

ネガティブキャッシュも同じ方法で測れます。まだ存在しない名前を引いて失敗させたあとにレコードを作成し、getent が成功するまでの時間を見ます。ただしDNS側にも否定応答のキャッシュ（SOAレコードの値で決まります）があるため、こちらも dig が成功した時刻を起点にします。

手順5：用途に合わせて値を調整する

確認できたら、用途に合わせて値を決めます。目安としての考え方は次のとおりです。

外部APIやCDNに頻繁に接続するWebサーバー（WordPressの更新確認や決済・メール配信APIなど）では、接続先のIPが変わることがあるため、positive-time-to-live hosts はDNS側のTTLと同程度か短めにする
negative-time-to-live hosts は短く（数秒〜数十秒）する。長いと、一瞬のDNS障害が長時間の接続失敗になる
passwd や group は変更頻度が低いので、hosts とは別に長めでも問題になりにくい

変更の前に設定ファイルをバックアップし、可能ならステージング環境で試してから本番に反映してください。

sudo cp /etc/nscd.conf /etc/nscd.conf.bak
sudoedit /etc/nscd.conf
sudo systemctl restart nscd
sudo nscd -i hosts
sudo nscd -g | grep -A25 '^hosts cache' | grep 'time to live'

nscd -i hosts を実行するのは、persistent が有効な場合に、変更前の長い保持時間で入ったキャッシュが残るのを避けるためです。最後の行で、実行中の値が新しい値に変わったことを確かめます。

キャッシュの効き具合も合わせて見る

TTLを短くしすぎると、キャッシュの効果が下がり、DNSへの問い合わせが増えます。nscd -g の hosts cache の欄には、キャッシュのヒット率（cache hit rate）や、ヒット・ミスの回数も出ています。変更前後でヒット率を比べ、極端に下がっていないかを確認すると、短くしすぎを防げます。nscd を再起動すると統計はリセットされるため、比べるときは同じくらいの稼働時間で見てください。

なお、nscd の扱いはディストリビューションによって異なり、近年は非推奨扱いとして systemd-resolved や SSSD への移行を案内しているものもあります（2026年10月現在）。TTLを調整するより、hosts のキャッシュ自体を nscd から外したほうが運用しやすい場合もあります。

まとめ

nscd の保持時間は positive-time-to-live（成功）と negative-time-to-live（失敗）の2種類で、データベースごとに設定する
設定ファイルの値は grep、実行中の値は sudo nscd -g で確認し、食い違えば再起動する
DNSのTTLとの関係はglibcのバージョンで異なるため、テスト用レコードで実測すると確かめられる
Webサーバーでは positive をDNSのTTL以下、negative を短くするのが基本。変更後は nscd -i hosts で古いキャッシュを消す
値を変えたらヒット率も見て、短くしすぎていないかを確認する