ブログ ランキング
インターネットサーバー設定・運用
HOME  | MYBlog  | MAIL 

bind9

cache 情報のクリア方法

bind9に付属のrndc(namedの制御やステータスを表示するツール)でサービスに影響なくクリアできる


[書式]
rndc [option]
よく使うoptionの説明
オプション 説明
flush cache をクリア
dumpdb キャッシュされたデータをテキストファイルに落とす
ゾーンディレクトリ(/var/named/)に「named_dump.db」が生成される
TTLは少しずつ減っていく(キャッシュの有効期間がわかる)
使用例)

cacheの内容を更新させる必要がある場合に cacheのダンプを取ってcacheの内容が古いことを確認後、cacheをクリアすることで 以降のリクエストで上位のDNSサーバに問い合わせする

↑top
ゾーンファイル中の$TTLの指定
TTLとは
キャッシュ内における有効期限

bind8まではSOAの最小TTLがデフォルトのTTLとして扱ったが、bind9ではゾーンファイルの1行目に$TTLで指定する。
$TTLが存在しない場合の挙動は以下の通り

bind 8.x 正常にnamed は起動できるがRFC違反
bind 9.0, 9.1 エラーを出して起動できない
bind 9.2 警告を出すがとりあえず起動できる

ゾーン外グルー(ignoring out-of-zone)

ゾーン外のグルーレコードが登録されてると、bind9では起動時に以下のワーニングが出ます。

Nov  7 19:45:08 ns named[26020]: [ID 866145 daemon.warning] example.zone:20
: ignoring out-of-zone data (ns.center.outzone.ad.jp)


bind9 でのグルーの扱い
事象 bind のバージョンアップ後、自身で保持しているゾーンで引けないエントリーがある
バージョン bind8.2.5 -> bind9.3.2-P1

引けない例

example.co.jpゾーン
=============================================
testexample         IN  NS  DCxxx.testexample.example.co.jp.
DCxxx.testexample IN  A   192.168.1.24  <- グルーレコード
============================

原因
bind9とbind8でグルーレコードの扱いが変更されたため

グルーレコードの扱い
バージョン 説明
bind 9.3.2-P1 グルーレコードを返さず、委任先サーバ(192.168.1.24)に名前解決の要求パケットを出す(値が返ってこないのは相手先の問題)
bind 8.2.5 正常にDCxxxのIPアドレス(192.168.1.24)が返ってくる。
この時のパケットを確認すると委任先サーバには名前解決の要求パケットは発行していないので、 自身が保持しているAレコード(グルーレコード)を返答したと考えられる。
説明
bind8ではデフォルトでfetch-glue yes のため、グルーレコードを返す。
一方、bind9では常にfetch-glue no なのでグルーレコードは返さずにNSレコードで指定した権威サーバに問い合わせに行く。
(bind9ではfetch-glue yes にできない・・? テスト機で試すとエラー "option 'fetch-glue' is obsolete"でnamedの起動に失敗)

bind9 付属のnslookupがエラーになる
(wsproxy) $ /usr/sbin/nslookup
 
 *** Can't find server name for address 192.168.1.10: Non-existent host/domain
 *** Default servers are not available

nslookup は問合せ先のDNSサーバを逆引きする 問合せ先DNSを逆引き登録すれば上記のエラーは解消されるが、nslookupはやめてdigを使用することを推奨します。

↑top
viewでスプリットDNS

内向け/外向けDNSサーバが分離してない環境においては、インターネット側から組織内のゾーン情報を参照 することができてしまいます。
このような問題を避けるために、スプリットDNS(1台のDNSサーバで同一のゾーン名を内向きと外向きで分離)が一般的 に利用されます。
bind9ではview機能を利用することで比較的簡単にスプリットDNSを構築することが可能です。
view が使用される別の例としては、自社の公開WebへのDNS問い合わせで、アクセス元に応じてグループ化して 組織内からの問い合わせはプライベートIPアドレス(実アドレス)を返すことで無駄なNAT変換を省略できます。

↑top

squid

リザルトコード

オリジンサーバから取得したかどうかは access.logのリザルトコードで判断できる。

リザルトコード 意味
TCP_IMS_HIT クライアントはIMS(If-Modified-Since)ヘッダを付けてリクエストを出した。
squidはキャッシュ情報をFRESHと判断してキャッシュから返した。
TCP_IMS_MISS クライアントはIMSヘッダを付けてリクエストを出したがcacheに存在しなかったため、サーバから取得した。
TCP_REFRESH_HIT squidはサーバにIMSを付けて問い合わせした。
サーバからは応答コード304(not modified)が返されたのでキャッシュにあるオブジェクトを返した。
TCP_REFRESH_MISS 上と同様のリクエスト。ただしキャッシュのオブジェクトは古い(STALE)と判断してサーバから取得した。

上記のリザルトコードを踏まえて、古いキャッシュ情報を返した場合のアクセスログを以下に示します。

コンテンツを更新した10:00前後のアクセスログを見ると"TCP_IMS_HIT"と記録があるのでキャッシュから 返したことが伺える。


access.log
 [DD/MM/YY Time] "GET http://www.example.co.jp/flash/xxx.jpg HTTP/1.0" 304 205
  TCP_IMS_HIT:NONE
 [DD/MM/YY Time] "GET http://www.example.co.jp/flash/xxx.jpg HTTP/1.1" 304 206
  TCP_IMS_HIT:NONE
 [DD/MM/YY Time] "GET http://www.example.co.jp/flash/xxx.jpg HTTP/1.1" 304 206
  TCP_IMS_HIT:NONE

<squidのキャッシュ最新チェック>

  • リクエストのあったキャッシュオブジェクトのFRESH/STALE の判断はキャッシュに存在するオブジェクトの経過時間(Expiresヘッダがない場合)
  • last-modified と age ヘッダを元にリソースの経過時間を計算 (頻繁に更新されないページになるほど誤って古いキャッシュ情報を返す)
■FRESHの場合
サーバに最新性の確認(If-Modified-Since)は行わずにローカルキャッシュを返す
したがってキャッシュにある古いオブジェクトを返す可能性がある
■STALEの場合
サーバに最新性の確認(If-Modified-Since)を行う。
オリジンサーバからのレスポンス(Last-Modified)と比較する。
  • キャッシュの有効期限が短いとキャッシュの効率が下がる
  • キャッシュの有効活用と帯域幅の節約とのトレードオフ

ブラウザを強制更新(IEの場合 ctrl+F5)することでリクエストに以下のヘッダが付与される。
この場合、キャッシュは無視してオリジンサーバからオブジェクトを取得する。

pragma:no-cache (HTTP1.0)
cache-controle:no-cache (HTTP1.1)

ただし動的コンテンツで画面が自動で遷移するような作りになっていて、遷移する前後でURLが同じ場合は、 強制更新してもコンテンツキャッシュから読み込む可能性がある。

<回避策>

  • ホームページ側で、プロキシでのキャッシュを抑制する(レスポンスのヘッダにmetaタグを埋め込む)
  • <meta http-equiv="pragma" content="no-cache">
    <meta http-equiv="cache-control" content="no-cache">  もしくは
  • プロキシ(suid)でキャッシュしないよう設定

アクセスリスト(acl dstdomain) の注意点

acl のdstdomain はURLから"www.hogehoge.jp" の文字列を探し出します。
接続先のURLにホスト名ではなくIPアドレスが指定されていた場合(例:http://192.168.255.XX)、 IPアドレスを名前解決し、アクセス制御を行います。
この為、そのIPアドレスが名前が解決できないとタイムアウト待ちが発生し、該当のサイトへのwebアクセスが遅延します。
別の方法としてurl_regexでアクセス制御する方法もあります。

例:acl EDI2 url_regex 61.197.187.92:8443

↑top

apache

BASIC認証のディレクトリ・レイアウト

【推奨するディレクトリ構成】

   / -- ${apache}/etc ← .htpasswdをここに移動
    |
    |
    +--- /Webコンテンツ -- /認証をかけるディレクトリ(.htpasswd, .htaccess)    

パスワードファイル(.htpasswd)は一般ユーザーが削除できない領域に
アクセスコントロールファイル(.htaccess)は主設定ファイル(httpd.conf)に記述

【説明】
BASIC認証に必要なパスワードファイル/アクセスコントロールファイル(.htpasswdと.htaccess) をコンテンツ領域に配置するとユーザーが誤って削除できてしまう。 そのような事故防止として、パスワードファイルは${apache}/etc に移動して、アクセスコントロールファイル はhttpd.confに記述することを推奨します。

BASIC認証に関連する部分 (httpd.conf)

(赤字の行が .htaccessからコピー)

<VirtualHost www.example.co.jp>
      ServerName www.example.co.jp
      ServerAdmin webmaster@example.co.jp
      DocumentRoot /www/example/htdocs
      <Directory "/www/example/htdocs">
        Options FollowSymLinks MultiViews
      </Directory>
      <Directory "/www/example/htdocs/besela/users">  
        #AllowOverride AuthConfig
        AllowOverride None
    AuthUserFile /usr/local/apache/conf/.htpasswd 
        AuthGroupFile "/dev/null"
        AuthName "Member Certification"
        AuthType Basic
        <Limit GET POST>
          require user userA
        </Limit>
     </Directory>

1台のサーバで複数のSSLサイトをホスティングする場合、サーバ証明書は1つ?

SSLの場合HTTPヘッダが暗号化されているため、どの仮想ドメインへのリクエストか特定できない。
したがって名前ベースのバーチャルホストにおいては、サーバ証明書が複数あったとしても、 どのサーバ証明書を使っていいかわからないのでサーバ証明書は1つ

↑top
秘密鍵とサーバ証明書が合致しない

【説明】
SSL暗号化通信で使用されるサーバ証明書を取得するには、CSR(申請書・署名リクエスト)をVeriSign, Inc. などの認証局に提出する。
CSRには公開鍵が含まれていて秘密鍵とペアで作成ます。
認証局はCSRに署名を付加して、サーバ証明書として発行します。
以下、サーバ証明書の組み込みにあたって、対になった秘密鍵であることを事前に検証するための方法です。


【手順】
秘密鍵とサーバ証明書の中身を見てmodulus が同一かどうかを確認する。

秘密鍵のmodulusを見るには
openssl rsa -noout -text -in [秘密鍵]
【出力結果】
% ./openssl  rsa -noout -text -in /export/home/msaito/hoge.key
Private-Key: (1024 bit)
modulus:
    00:ca:f7:39:24:dd:71:c0:bd:c4:9d:d0:64:05:31:
    cd:94:c6:0f:47:a5:70:bc:07:1c:99:ad:ca:9d:1c:
    a2:52:a8:8e:44:d9:bf:fa:16:ee:a3:00:66:50:f7:
    a0:63:ee:7b:c5:b5:b7:6b:8c:ee:1e:3c:c0:2e:02:
    30:96:f9:5b:56:57:09:fb:1f:f9:bf:89:09:89:36:
    4b:ee:8f:cd:ac:ca:6f:1b:75:4d:1d:d3:2d:bb:47:
    3e:12:eb:e4:72:e4:6a:e8:62:a9:4c:fa:ff:02:29:
    ad:32:d6:f5:b8:fc:b4:ad:ce:52:43:f1:b5:73:c4:
    25:f8:a4:80:13:52:91:94:8f
publicExponent: 65537 (0x10001)
privateExponent:

サーバ証明書のmodulusを見るには

# openssl x509 -noout -text -in [証明書]

csrのmodulusを見るには

# openssl req -in [csrファイル] -noout -text
% openssl req -in /export/home/msaito/hoge.csr -noout -text
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=JP, ST=TOKYO, L=TOSHIMAKU, O=hoge CORPORATION, \
        OU=INFORMATION SYSTEM DEPARTMENT, CN=www.ad
eka.co.jp
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ca:f7:39:24:dd:71:c0:bd:c4:9d:d0:64:05:31:
                    cd:94:c6:0f:47:a5:70:bc:07:1c:99:ad:ca:9d:1c:
                    a2:52:a8:8e:44:d9:bf:fa:16:ee:a3:00:66:50:f7:
                    a0:63:ee:7b:c5:b5:b7:6b:8c:ee:1e:3c:c0:2e:02:
                    30:96:f9:5b:56:57:09:fb:1f:f9:bf:89:09:89:36:
                    4b:ee:8f:cd:ac:ca:6f:1b:75:4d:1d:d3:2d:bb:47:
                    3e:12:eb:e4:72:e4:6a:e8:62:a9:4c:fa:ff:02:29:
                    ad:32:d6:f5:b8:fc:b4:ad:ce:52:43:f1:b5:73:c4:
                    25:f8:a4:80:13:52:91:94:8f
                Exponent: 65537 (0x10001)
        Attributes:

sendmail

データベース(DB)形式の確認方法

sendmailはDB形式に変換されたキーマップファイル(aliase等)を参照します。
DB形式にはいくつかの種類があり、sendmailがどのDB形式を使用するかは sendmailのコンパイル時に決定されます。
UNIXで一般的に使われるデータベース形式としては以下の種類があります。
異なる形式のDB間で互換性がないため、senmailのバージョンアップ時にどのDB形式を組み込むか要注意

DB形式 説明 生成ファイル
ndbm Solarisで採用されてる標準のデータベース *.dir(index)
*.pag(data)
newdb ハッシュ形式とも呼ばれる。
http://www.sleepycat.comから別途ダウンロードしてインストール後、sendmailコンパイル時にリンクさせます。
ndbmより検索処理が高速。DBのサイズが大きい場合はこちらを推奨。
*.db

sendmailがどちらのDB形式に対応しているかは /etc/mail 以下のDBファイル(例えば aliases.*)の 拡張子で判断してもいいのですが、以下のsendmailオプションで確認することができます。

■DB形式の確認(ndbmに対応)

% sendmail/sendmail -d0.1
Version 8.13.8
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
                NAMED_BIND NDBM NETINET NETINET6 NETUNIX NIS NISPLUS
                PIPELINING SCANF XDEBUG

■DB形式の確認(Berkeley DBに対応)

$ /usr/lib/sendmail -d0.1
Version 8.13.8
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
                NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS NISPLUS
                PIPELINING SCANF USERDB XDEBUG

※もし"NEWDB"と"NDBM"の両方が表示された場合は"NEWDB"のほうが優先されます。

↑top
特定の受信者に届いたメールを破棄(Discard)する設定

■sendmail.mc

VERSIONID(`$Id: generic-solaris.mc')dnl
OSTYPE(solaris2)dnl
DOMAIN(generic)dnl
define(`confTO_IDENT', `0s')dnl
Dwtc134
Dmfffccc.co.jp
FEATURE(`access_db')dnl
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`accept_unqualified_senders')dnl
FEATURE(`blacklist_recipients')dnl
dnl FEATURE(`mailertable')
MAILER(local)dnl
MAILER(smtp)dnl

■/etc/mail/access に追加

To:ahirunoko@fffccc.co.jp       DISCARD
localhost       RELAY
192.168.100     RELAY
fffccc.co.jp    RELAY

access.db を更新

# /usr/sbin/makemap hash /etc/mail/access < /etc/mail/access

sendmail の再起動なしで反映されます。

↑top

NTP

NTPによる時刻同期

■NTPクライアントの設定

雛形のファイルが /etc/inet/ntp.client にあるので、これをコピーします。

# cp /etc/inet/ntp.client /etc/inet/ntp.conf
# vi /etc/inet/ntp.conf
server ntp1.jst.mfeed.ad.jp ← NTPサーバを指定
driftfile /etc/ntp.drift ← ntpd起動時に作成される

■xntpd の起動

<Solaris8, 9 の場合>

# /etc/init.d/xntpd start 

<Solaris10の場合>

# svcs -a|grep ntp
disabled       21:46:34 svc:/network/ntp:default

# svcadm enable svc:/network/ntp

# svcs -a|grep ntp
online         21:52:03 svc:/network/ntp:default

■確認方法

# ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*ntp1.jst.mfeed. fs-monntp2.mfee  2 u   18   64  377    15.73    3.945   27.45

5分程待って、左端に*(アスタリスク)が付いていれば同期が取れています。

↑top

PostgreSQL

バックアップとリストア

バックアップコマンド

# pg_dump -h localhost -U [DATABASE所有者] [DATABASE名] > /tmp/pg.dump

DB の再構築/リストアコマンド

# dropdb -h localhost -U [DATABASE所有者] [DATABASE名] 
# createdb -h localhost -U [DATABASE所有者] [DATABASE名] 
# psql -h localhost -U [DATABASE所有者] [DATABASE名] < /tmp/pg.dump
↑top

その他

各ソフトのバージョン確認方法 バージョン確認コマンド
アプリケーション コマンド
gcc % pkginfo |grep gcc <-パッケージ名を特定
application SMCgcc gcc
% pkginfo -l SMCgcc | grep VERSION
VERSION: 3.4.6
OpenSSH # ssh -V
wu-ftpd % ${wu-ftpd}/sbin/in.ftpd -V
Version wu-2.6.2(2) Fri Oct 22 17:18:48 JST 2004
i-FILTER cat ${i-FILTER}/version.txt
5.50R04-20050202
ntp $ /usr/local/bin/ntpq
ntpq> version
ntpq 4.1.1c-rc1@1.836 Mon Apr 14 03:58:17 JST 2003 (1)
ntpq> quit
openssl # openssl version
OpenSSL 0.9.8d 28 Sep 2006
mod_ssl
IMSS # /opt/trend/imss/script/S99IMSS version
Version 5.11-Build_SOL_1194 $Date: 05/10/2006 11:58:0056$
検索エンジン
# /opt/trend/imss/bin/vscan -v
Virus Scanner v3.1, VSAPI v8.310-1002
↑top
URL フィルタリング

【事象】

URL フィルタリング製品で Web 閲覧制限をかけている。
通常、ブロック設定されたサイトへアクセスするとブロックページが表示されるが HTTPS の場合、ブラウザの画面にエラー画面が表示される(“Internet Explorer cannot display the webpage”)

【原因】

URL フィルタリングソフトでは、ブロック設定されたサイトへのアクセス要求に対して Redirection ステータスコードを返して、ブロックページにリダイレクトさせる。
通常ブラウザは自動的にリダイレクト先のブロックページを読みに行くが IE 7 では HTTPS 通信時のステータスコードに対する振る舞いが変更されて HTTPS から HTTP へのリダイレクトをしないよう仕様が変更された。