bind9
cache 情報のクリア方法bind9に付属のrndc(namedの制御やステータスを表示するツール)でサービスに影響なくクリアできる
[書式]
オプション | 説明 |
---|---|
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を使用することを推奨します。
↑topviewでスプリットDNS
内向け/外向けDNSサーバが分離してない環境においては、インターネット側から組織内のゾーン情報を参照
することができてしまいます。
このような問題を避けるために、スプリットDNS(1台のDNSサーバで同一のゾーン名を内向きと外向きで分離)が一般的
に利用されます。
bind9ではview機能を利用することで比較的簡単にスプリットDNSを構築することが可能です。
view が使用される別の例としては、自社の公開WebへのDNS問い合わせで、アクセス元に応じてグループ化して
組織内からの問い合わせはプライベートIPアドレス(実アドレス)を返すことで無駄なNAT変換を省略できます。
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)することでリクエストに以下のヘッダが付与される。
この場合、キャッシュは無視してオリジンサーバからオブジェクトを取得する。
cache-controle:no-cache (HTTP1.1)
ただし動的コンテンツで画面が自動で遷移するような作りになっていて、遷移する前後でURLが同じ場合は、 強制更新してもコンテンツキャッシュから読み込む可能性がある。
<回避策>
- ホームページ側で、プロキシでのキャッシュを抑制する(レスポンスのヘッダにmetaタグを埋め込む)
<meta http-equiv="pragma" content="no-cache"> <meta http-equiv="cache-control" content="no-cache"> もしくは
アクセスリスト(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
↑topapache
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つ
秘密鍵とサーバ証明書が合致しない
【説明】
SSL暗号化通信で使用されるサーバ証明書を取得するには、CSR(申請書・署名リクエスト)をVeriSign, Inc.
などの認証局に提出する。
CSRには公開鍵が含まれていて秘密鍵とペアで作成ます。
認証局はCSRに署名を付加して、サーバ証明書として発行します。
以下、サーバ証明書の組み込みにあたって、対になった秘密鍵であることを事前に検証するための方法です。
【手順】
秘密鍵とサーバ証明書の中身を見てmodulus が同一かどうかを確認する。
% ./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を見るには
csrのmodulusを見るには
% 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 の再起動なしで反映されます。
↑topNTP
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分程待って、左端に*(アスタリスク)が付いていれば同期が取れています。
↑topPostgreSQL
バックアップとリストアバックアップコマンド
# 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
その他
各ソフトのバージョン確認方法アプリケーション | コマンド |
---|---|
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 |
URL フィルタリング
【事象】
URL フィルタリング製品で Web 閲覧制限をかけている。
通常、ブロック設定されたサイトへアクセスするとブロックページが表示されるが
HTTPS の場合、ブラウザの画面にエラー画面が表示される(“Internet Explorer cannot display the webpage”)
【原因】
URL フィルタリングソフトでは、ブロック設定されたサイトへのアクセス要求に対して
Redirection ステータスコードを返して、ブロックページにリダイレクトさせる。
通常ブラウザは自動的にリダイレクト先のブロックページを読みに行くが
IE 7 では HTTPS 通信時のステータスコードに対する振る舞いが変更されて
HTTPS から HTTP へのリダイレクトをしないよう仕様が変更された。