ゾーン転送のチェック
@ITに記載があるが、Windowsのクライアント端末からもゾーン情報の内容をチェックしたり、転送が正しく行えるかをチェックすることが出来る。
nslookupコマンドでインタラクティブモードに入った後
server (プライマリDNS)
ls -d (ゾーン情報を転送したいドメイン)
で調べることが出来る。
あんじーのテクニカルブログ技術評価やIT系の情報などについて個人的な意見をつらつらと・・・
|
|
モバイルでもご覧いただけます。 (QRコードは株式会社デンソーウェーブの登録商標です) |
DNSサーバー(bind)
2007年10月29日
2007年10月10日
DNSの変更を早く伝播させるか方法
違うホスティングサーバーにドメインを移行したりするときには、DNS情報が早く切り替わったほうがメールが旧サーバーと新サーバーにばらばらに届いたりする時間を短くできる。さて、DNSの変更をできる限り早く伝播させるにはどうしたらよいか？
キーポイントは、TTLとSOAレコードのRefreshにある。TTLについては、DNSのTTLで記載をしているが、SOAレコードのTTLではなく、$TTLの値を変更しておかなければならない。この時間は、セカンダリDNSを除くDNSサーバーがDNS情報に対する問い合わせ結果を保持している時間となる。
$TTLをいくら変更しても、DNSがプライマリDNSサーバーを参照するか、セカンダリDNSを参照するかまでは制御できないので、セカンダリDNSの情報をいかにはやく更新するかもポイントになる。（プライマリDNSの情報が更新されても、セカンダリDNSの情報が更新されず、その古いDNS情報を全世界のDNSサーバーのうちの一部が参照しているからだ）
@IT SOAレコードには何が記述されている？にもあるが、セカンダリDNSが定期的にプライマリDNSからデータを更新し続けることができてさえいれば、その更新間隔は、Refresh値に基づく。SOAレコードのTTLはDNS情報がないということを保持している時間でしかない。
まとまると、引越しをするにあたって必要なのは、$TTLとSOAレコードのRefresh値を短くすればするだけ良い。しかしながら、$TTLを短くしすぎると更新負荷が急激に上がる。ただ、SOAレコードのRefresh間隔は短くしておいてもゾーン情報のコピーがされるセカンダリサーバーの数が限られているので、さほど負荷は上がらない。（自分の管理していないサーバーで勝手にゾーン情報をコピーしているようなサーバーがなければの話だが。。。）
たとえば、$TTLを1800秒、Refresh値を600秒とかにしたらどうだろうか？もし変更したらしばらくはサーバーの負荷をチェックしておいたほうがDNSの設定を変更したばっかりにサーバーダウンになるようでは洒落にならない。
2007年9月16日
DNSのTTL
DNSのTTL設定といえば、SOAレコードのTTLだとずっと思っていたのだが、実はSOAレコードのTTLはスレーブDNSサーバーがプライマリDNSサーバーからDNS情報をキャッシュし続ける時間であり、ネガティブキャッシュと呼ばれているそうだ。
実は、それ以外のDNSサーバー（DNSサーバーでなくてもローカルマシンがDNSをキャッシュする場合においても）がDNS情報をキャッシュする時間は、SOAレコードに指定されたTTL時間ではない。
＠IT 第2回 すべての基礎、マスター・ゾーンサーバの設定にあるように、zoneファイルの先頭のほうにあるにある$TTL指定がゾーン全体のTTLとなり、レコード個別のTTLも指定可能である。
以上の理由により、サーバー間で引越しをするようなことがあれば、事前にTTLを減らしておいて変更を早く適用できるようにする必要があるが、SOAレコードのTTLだけでなく、$TTLの値も減らしておく必要があるというわけだ。
それでは各端末において、特定のドメインの残りキャッシュ時間を知るためにはどうすればよいか。
Linuxにおいては、digコマンドが利用できるので、以下のようにやると良い。
dig @localhost www.development-network.net a ※localhostにDNSサーバーがたっている場合
※一部省略
;; ANSWER SECTION:
www.development-network.net. 900 IN A 124.98.21.52
ここに 900 という数値があれば、残り900秒でキャッシュが更新されることを示している。何度か実行してみると、900の数値が経過時間分だけ減っていることがわかる。
Windows XPにおいては、ipconfig /displaydns とするとローカルキャッシュの残り時間を知ることが出来る。
www.development-network.net
----------------------------------------
Record Name . . . . . : www.development-network.net
Record Type . . . . . : 1
Time To Live . . . . : 845
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 124.98.21.52
ローカルキャッシュがクリアされる条件は、DNSサーバーを変更するか、マシンを再起動するか、ipconfig /flushdnsコマンドが発行されたときである。
2006年11月22日
ダイナミックDNS
ダイナミックDNSとは固定のグローバルIPアドレスを取得できないユーザーが自宅サーバーを公開する際にマイドメインでアクセスするために必要なDNSのこと。一般的にはDiceのようなソフトウエアを使って、IPアドレスの変更をダイナミックDNSに通知する必要がある。
ダイナミックDNSには国内にも複数サービスがあるが、実際に僕が使っているのは以下の2つ。
ddo.jp
ddo.jpのサブドメインであればフリー。それ以外は月額500円。メール転送やオフライン時のWeb転送、MXレコードの複数設定ができるので、より安定したサービスを行いたい場合に向いている。
フリーのダイナミックDNS。マイドメインも無料で登録できる。POP認証によりIPアドレスの変更を通知できる。MXレコードとCNAME(最大5つ、なお*指定可)レコードが設定できる。
2006年8月13日
フィッシングとファーミング
フィッシングとファーミングの違いは以下の通り
フィッシング
何らかの方法（URL偽装）などを利用して正規のサイトとそっくりの偽サイトに誘導し、実際にログインさせることでログイン情報などを取得する。URLを注意深くチェックすればフィッシングサイトに引っかかることは少ないが、Basic認証対応のURLの場合、ライトユーザーにはチェックが難しい。このURLでアクセスできなくなっているブラウザも存在する。
Basic認証対応のURLパターン：http://(ユーザー名):(パスワード)@(ドメイン名)/
http://www.yahoo.co:jp@hogehoge.com/
というサイトがYahooのサイトと認識されても不思議はない??（でも実際のところ無理がありそうな。。。）
ファーミング
DNSの解決の仕組みを悪用して、ホスト名の解決を正規のIPアドレスではなく、悪意あるホストのIPアドレスを返答させる。これを実現するには、DNSサーバーのキャッシュ情報を書き換える（DNSポイズニング）か、hostsファイルをウィルスなどによって書き換える。
この方法が成功すれば、ユーザーが良く訪れる信用あるURLが実は詐称サイトということになる。
この検出はかなり難しい。正しいhostsファイルのMD5を保存しておいて、それが変わった時点でhostsファイルを信頼しないしかない。あとは信頼あるDNSサーバーを登録するとか。。。もはやDNSサーバーが信頼できないなんて、ありえない事態だ。