ネガティブキャッシュのキャッシュ残り時間が知りたい
DNSキャッシュサーバにネガティブキャッシュ(status:NXDOMAINなどのときの「そんなリソースレコードは存在しない」という情報のキャッシュのこと)が残ってしまって、あとどれだけ待ったらネガティブキャッシュが消えるのか知りたい。
そんなときは、digでキャッシュの残り時間を確認できる。
- 存在しないhogehoge.yahoo.com を引いてみる
SOAレコードで設定されている値から、ネガティブキャッシュのTTLが600秒であることが分かる。
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21575 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 164 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:02:54 2016 ;; MSG SIZE rcvd: 97
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュの残り時間が380秒であることが分かる
$ dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 380 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 11 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:06:34 2016 ;; MSG SIZE rcvd: 97
- 380秒も待てない!ネガティブキャッシュ消したい!というときはrndc flushでDNSキャッシュサーバのキャッシュを消す
# rndc flush
- 再度、hogehoge.yahoo.com を引いてみる
ネガティブキャッシュが消えて、問い合わせに行き、そして再びネガティブキャッシュのTTLが600秒になっている。
# dig hogehoge.yahoo.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> hogehoge.yahoo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30397 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;hogehoge.yahoo.com. IN A ;; AUTHORITY SECTION: yahoo.com. 600 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2016052509 3600 300 1814400 600 ;; Query time: 418 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 26 00:09:29 2016 ;; MSG SIZE rcvd: 97
これでやきもき待たなくて済むー。
MXレコードやTXTレコードでは*(アスタリスク)は使えない?
hoge.infra.xyzでもfuga.infra.xyzでもメールを受信できるように、BINDのinfra.xyz.zoneでこんな設定を書いてみた。
mx1 IN A 153.126.198.20 * IN MX 10 mx1.infra.xyz. * IN TXT "v=spf1 a:mx1.infra.xyz -all"
named-checkzoneでエラーはでない、よしよし、とnamedをrestartして、digで
dig hoge.infra.xyz mx dig hoge.infra.xyz txt
を叩いてみたら、なんと何も出ない。 statusはNOERRORなのに、ANSWERは0・・・MXとかTXTだと*(アスタリスク)でワイルドカードの指定はできないのかな?と思ったら、ワイルドカードは「個別の設定があればそちらが優先、なければワイルドカードが適用される」ということらしく、そもそも個別の設定が1つもないとワイルドカードも適用されない模様。
つまり、以下のようにワイルドカードしかない状態だと、hoge.infra.xyzのAを引いても、MXを引いても、TXTを引いても、ANSWERは0なんだけど、
* IN A 153.126.198.20 * IN MX 10 mx1.infra.xyz. * IN TXT "v=spf1 a:mx1.infra.xyz -all"
以下のように、hoge.infra.xyzという個別の設定をした上で、ワイルドカードの設定をした状態で、fuga.infra.xyzを引くと、AもMXもTXTもちゃんと値が返ってきた。
hoge IN A 153.126.198.20 * IN A 153.126.198.20 hoge IN MX 10 mx1.infra.xyz. * IN MX 10 mx1.infra.xyz. hoge IN TXT "v=spf1 a:mx1.infra.xyz -all" * IN TXT "v=spf1 a:mx1.infra.xyz -all"
というわけで、AレコードやMXレコードやTXTレコードでは*(アスタリスク)は使える。 但し、同じ種類のレコードにおいて個別の設定が1つもないと、ワイルドカードも適用されない模様。
という一旦の理解。BINDのDOCUMENTATIONとかちゃんと読めば、説明見つかるかな。
Apache2.2系で中間証明書ファイルを指定するのはSSLCertificateChainFile?SSLCACertificateFile?
Apache2.2系で、SSLサーバ証明書を設置する際に、中間証明書ファイルを指定するディレクティブがSSLCertificateChainFileか、SSLCACertificateFileか、分からなくなってしまったのでメモ。
結論から言うと、SSLCertificateChainFileディレクティブを使うのが正しい。けど、どっち使ってもちゃんとSSLの設定は出来る。
mod_sslの公式ドキュメント(http://httpd.apache.org/docs/2.2/mod/mod_ssl.html)でDescriptionを見ると、
SSLCertificateChainFileディレクティブ:File of PEM-encoded Server CA Certificates SSLCACertificateFileディレクティブ:File of concatenated PEM-encoded CA Certificates for Client Auth
ということなので、同じ「中間証明書を指定する」ディレクティブでも、SSLCertificateChainFileは「SSLサーバ証明書」の中間証明書、SSLCACertificateFileは「SSLクライアント証明書」の中間証明書を指定するディレクティブな模様。
はーすっきり。
でもSSLCertificateChainFileディレクティブを使うのは、「Apache+mod_ssl」(Apacheにmod_sslモジュールを追加してSSLを使う)のケースだと正解!なんだけど、「Apache+Apache-SSL」(ApacheにApache-SSLのパッチを当ててSSLを使う)のケースだと、逆にSSLCACertificateFileディレクティブを使うのが正解っぽい。
Apache-SSLってなんですか・・・2009年のリリースが最後だし、もうほぼ使われてないと思っていいのかな・・・。
SSL証明書をSHA-2に変更するときの案内ページまとめ
SHA-1のSSL証明書を発行できる期間もあと半年を切り、SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) によると、割合としては既にSHA-1が40%、SHA-2が60%と、SHA-2の方が多くなってきた模様。
非対応になる端末も把握し、さあいよいよSHA-2に変更するぞー!というときに、さてエンドユーザにどう告知したものか・・・と迷うところも多そうなので、参考になりそうな各社のサイトをまとめてみた。
- 楽天銀行ウェブサイト/インターネットバンキングの証明書「SHA-2」方式への変更について | 2015年 | お知らせ | 楽天銀行
- Tサイト[Tポイント/Tカード] SHA-2のSSL証明書への移行について
- ガラケーなど一部端末での閲覧終了について(ハッシュ関数「SHA-2」対応)|エコめがね
- 【再掲】サーバー証明書の更新により一部コンテンツがご利用いただけなくなるPC・スマホ環境について 安藤証券
- よくあるご質問 リクルートの適性検査SPI お知らせ
- カブドットコム証券(ネット証券会社) サーバ証明書更新に伴うPC、携帯端末の動作確認のお願い
- ネットストアで使用している暗号化アルゴリズム変更のお知らせ | お知らせ | 無印良品
- ホットペッパービューティー ハッシュアルゴリズム「SHA-1」から「SHA-2」への移行について
丁寧に説明しているところもあれば、さらっと流しているところもあり、各社さまざま。
しかし上のリストの中にも1つだけあるけど、案内ページをHTTPSでしか見られないのはよくないと思うのですよ。「ガラケーで開いたら見られない!なんで!」って人が、理由を書いてあるページに辿りつけないって、誰のための案内ページなのかと・・・。
イオンシネマ、リニューアル前のドメインをドロップキャッチされるの巻
イオンシネマ(http://www.aeoncinema.com/)のトップページに、こんなお知らせが出てた。
【重要なお知らせ(ご注意)】 当社HPへアクセスされる場合、旧ドメインはご利用にならないようご注意ください。
どうやら2013年7月にワーナーマイカルシネマズがイオンシネマに統合された後、旧ドメイン(warnermycal.com)を手放したら、まんまと業者にドロップキャッチされて、業者が「あなたのコンピュータにウイルスが検出されました」系の詐欺サイトを開設。詐欺サイトへ「ワーナーマイカルのサイトを見ようとしたエンドユーザ」がアクセスして、何かしらの被害が出ている模様。
ちなみに旧ドメイン(warnermycal.com)にアクセスすると、リダイレクト地獄の末にこんな感じになるので、開かないことを強くお勧めします。
Internet Archive Wayback Machineで見る限り、2013年7月にサイトをクローズした後も、1年以上は新ドメイン(www.aeoncinema.com)へ302 Moved Temporarily(=一時的な移動)でリダイレクトをかけていた模様。旧ドメインの有効期限から推察するに、サイトクローズから1年半以上経った2015年3月頃に旧ドメインを手放したら、4月にドロップキャッチされたものと思われる。
クローズ直後に手放した訳じゃないみたいだし、一応は配慮してたんだね。
ただ2001年ごろに取得したドメインみたいなので、更新料も年々高くなって1年で1万円ちょっと・・・手放したくなる気持ちも分からなくもないけど、結局エンドユーザから「サイトにアクセスしたら、変なページが表示された!」とクレームが来て、トップページにお知らせ出して、といった対応をすることを考えたら、あと何年かはドメイン持ったままの方が安かったんじゃないの?と思う。リダイレクトのログを見てれば、手放す直前に旧ドメインへどれくらいアクセス来てたのか分かるだろうし。
あと、リダイレクトするときのステータスコードを、なぜ301 Moved Permanently(=恒久的な移動)にしなかったのか!302じゃなくて301にしてれば、ブラウザ側がリダイレクトをキャッシュするので、2回目以降は旧ドメインにアクセスしようとした時点で、最初から新ドメインに行ってたはずで、そうすればエンドユーザが旧ドメインをブックマークしててもまだましだったと思うのに。
しかもちょっと面白いのが、旧ドメインのWhois情報を見ると、「Registrar: DROPCATCH.COM 462 LLC」とある。わっかりやすい名前だな!ドロップキャッチしてるのは、一般人じゃなくて、レジストラなのか!(レジストラ=お名前.comみたいに、レジストリからドメインを卸してもらって一般人やリセラーに売ってる業者)
Re: ドロップ・キャッチ・システム構築に関する問い合わせ:IT's my business:オルタナティブ・ブログを読んで初めて知ったんだけど、再度売りに出されたドメインをレジストリから確実に買うために存在する、ドロップキャッチ専門のレジストラっていうのが居るんだねー。
最後に、イオンシネマ・・・URLにカンマ入ってる・・・一番大事なところ間違えてるよ!
今後、当社HPへアクセスされる場合は、必ず(www,.aeoncinema.com/)をご利用ください。
ドメインで_(アンダーバー)使おうとしたらbad owner name (check-names)になった
「hoge_fuga.infra.xyz」っていうサブドメインが作りたくて、自前のBINDでinfra.xyz.zoneに
hoge_fuga IN A 153.121.58.159
っていうレコードを追加して、再起動前に
named-checkzone infra.xyz infra.xyz.zone
でゾーンファイルのチェックしたら、
/var/named/chroot/var/named/infra.xyz.zone:22: hoge_fuga.infra.xyz: bad owner name (check-names)
って出た。
どうやらリソースレコードで_(アンダーバー)を使うと、named-checkzoneしたときにこういうエラーが出るらしい。(named.confで設定するcheck-namesのデフォルト値がfailになったBIND9.3.1以降で発生する模様)
解決方法は?
- アンダーバー使わない ←こっちがあるべき姿
- どうしても使いたい場合はnamed.confの中で、
zone "infra.xyz" { type master; file "infra.xyz.zone"; };
を、
zone "infra.xyz" { type master; file "infra.xyz.zone"; check-names ignore; };
にして、念のため
named-checkconf
も叩いて、named.confに間違いがないか確認する。
named.confにcheck-namesの行を足しても、named-checkzoneすると相変わらず「bad owner name (check-names)」っていうメッセージは出るんだけど、それでもnamed restartするとちゃんとhoge_fuga.infra.xyzが引けるようになってる。
もしbad owner name (check-names)出てるけどいいや!と、check-namesの行を足さずにBIND再起動を強行すると、「ゾーン情報にアンダーバー使っているという問題がある(とみなされる)」ため、そのゾーン全体が無効になってしまい、BINDが起動しなくなります。
# /etc/init.d/named restart named を停止中: . [ OK ] named を起動中: Error in named configuration: infra.xyz.zone:22: hoge_fuga.infra.xyz: bad owner name (check-names) zone infra.xyz/IN: loading from master file infra.xyz.zone failed: bad owner name (check-names) zone infra.xyz/IN: not loaded due to errors. _default/infra.xyz/IN: bad owner name (check-names)
こんな感じです。これでもかっていうくらいbad owner name (check-names)出てます。BIND起動しないので、普通にinfra.xyz.zoneに書いてある全部のリソースレコードが引けなくなります。ぎゃー。
ドメインってアンダーバーダメなのね。知らなかった。確かにお名前.comで買えるか試したらちゃんとはねられたわ・・・。
- ホスト名とかドメイン名とかFQDNでアンダースコア - S_a_k_Uの日記みたいなDB ~サクゥーと呼ばないで~
- Windows 2000 - Deployment Guide for DNS & DHCP
によると、RFC952で定義されている「ホスト名に使える文字」にはアンダーバーが入っていなくて、
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.).
でもRFC1033で定義されている「ドメイン名に使える文字」には、アンダーバーが入っているんだね。
Because of other protocol restrictions, only the following characters are recommended for use in a host name (besides the dot separator): "A-Z", "a-z", "0-9", dash and underscore
その辺の矛盾から、昔のサイトとかWindowsのActive Directoryだと普通にアンダーバー使ってたり、BIND9.3.1でcheck-namesのデフォルト値が変更になったり、今でもignoreにすれば使えたりするのかなー。
まあハイフン使えよ、という話だと思うので、取りあえず私は「アンダーバー使わない」で行こー。
wとかlastlogを叩いても、WinSCPでログインしたユーザがNever Logged Inなのはなんで?
このユーザって今も使われてるのかなー?を確認したくて、wとかlastlogを叩くと、過去絶対にログインしてたはずのユーザで「一度もログインしていません」とか「Never Logged In」と出ることがあって、なんぞこれ?と思ってたので調べてみた。
結論から言うと、SCPやSFTPでログインしてもwやlastlogにログイン履歴は残らない。これは仕様。
私もこの辺の質問者とまったく同じ気持ちでした・・・。
- linux - User logged in by sftp does not show up in `w` - Unix & Linux Stack Exchange
- Command last does not show logins through sFTP, is there something similar or any logs? - Ask Ubuntu
回答欄にも書いてあるけど、wやlastやlastlogがログイン情報のソースとして参照しているのは、/var/run/utmpや/var/log/wtmpや/var/log/lastlog。
んで、sshdはSCPやSFTPでログインした情報を、/var/run/utmpや/var/log/wtmpや/var/log/lastlogに渡さない。だからSCPでログインしてるユーザが「Never Logged In」になる。
sshd_configの設定でどうにかならんかなーと思ったけど、どうにもならなさそう。
という訳で、SCPやSFTPでログインした履歴が見たかったら、/var/log/secure見るのが正解かな、と思う。勿論、必要な情報がちゃんと出るように、事前にsshd_configでSyslogFacilityをAUTHPRIV、LogLevelをVERBOSE(デフォルトはINFO)にしておいて。