mochikoAsTechのdig日記

当方好きなコマンドはdigです!お友達から!!よろしくお願いします!!!

ネガティブキャッシュのキャッシュ残り時間が知りたい

DNSキャッシュサーバにネガティブキャッシュ(status:NXDOMAINなどのときの「そんなリソースレコードは存在しない」という情報のキャッシュのこと)が残ってしまって、あとどれだけ待ったらネガティブキャッシュが消えるのか知りたい。

そんなときは、digでキャッシュの残り時間を確認できる。

  1. 存在しない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
  2. 再度、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
  3. 380秒も待てない!ネガティブキャッシュ消したい!というときはrndc flushでDNSキャッシュサーバのキャッシュを消す
    # rndc flush
  4. 再度、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を使う)のケースだと正解!なんだけど、「ApacheApache-SSL」(ApacheApache-SSLのパッチを当ててSSLを使う)のケースだと、逆にSSLCACertificateFileディレクティブを使うのが正解っぽい。

Apache-SSLってなんですか・・・2009年のリリースが最後だし、もうほぼ使われてないと思っていいのかな・・・。

SSL証明書をSHA-2に変更するときの案内ページまとめ

SHA-1SSL証明書を発行できる期間もあと半年を切り、SSL Pulseの統計情報で見るSSL/TLS (2015年6月版) によると、割合としては既にSHA-1が40%、SHA-2が60%と、SHA-2の方が多くなってきた模様。

非対応になる端末も把握し、さあいよいよ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以降で発生する模様)

解決方法は?

  1. アンダーバー使わない ←こっちがあるべき姿
  2. どうしても使いたい場合は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で買えるか試したらちゃんとはねられたわ・・・。

によると、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

その辺の矛盾から、昔のサイトとかWindowsActive Directoryだと普通にアンダーバー使ってたり、BIND9.3.1でcheck-namesのデフォルト値が変更になったり、今でもignoreにすれば使えたりするのかなー。

まあハイフン使えよ、という話だと思うので、取りあえず私は「アンダーバー使わない」で行こー。

あ、でもこれみたいにアスタリスク使ってると、アンダーバー入りでも普通に引けるのね。

wとかlastlogを叩いても、WinSCPでログインしたユーザがNever Logged Inなのはなんで?

このユーザって今も使われてるのかなー?を確認したくて、wとかlastlogを叩くと、過去絶対にログインしてたはずのユーザで「一度もログインしていません」とか「Never Logged In」と出ることがあって、なんぞこれ?と思ってたので調べてみた。

結論から言うと、SCPやSFTPでログインしてもwやlastlogにログイン履歴は残らない。これは仕様。

私もこの辺の質問者とまったく同じ気持ちでした・・・。

回答欄にも書いてあるけど、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)にしておいて。