mochikoAsTechのdig日記

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

ChromeでCT(Certificate Transparency)非対応のSSL EV証明書は警告表示

少し前から、ChromeHTTPSのページを開いたときに、「○○により確認済みですが、公開監査記録がありません」っていうメッセージが出るようになってて、何それ?と気になっていた。

どうやら、使用されているSSL証明書Certificate Transparency(以下CT)に対応していないと、このメッセージが出る模様。でもTwitterやらFacebookやらの証明書すら非対応ってどういうこっちゃ?と思ったら、各社まだCT対応の証明書の販売が間に合っていない様子。

認証局のCT対応状況(2015年3月1日時点)

  1. シマンテック →「対応済み」のリリース見つけられず。恐らくCT未対応
    シマンテックグループではCTに準拠するために、EV SSL証明書にProof情報を追加する対応を2014年(予定)より順次提供することを計画しています。 http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency
  2. サイバートラスト →CT未対応。2015年3月中旬から対応予定
    2015 年 3 月中旬に CT に対応したサーバー証明書の提供を開始する予定です。 https://www.cybertrust.ne.jp/ssl/sureserver/ct.html
  3. digicert →CT対応済み。
    Digicert は本年、Google ともに CT(Certificate Transparency:透かし入り証明書)実現の準備に取り組み、CTをサポートする最初の CA(認証局)として、Digicert CT プラットフォームを準備しました。 http://www.digicert.ne.jp/topics/CertificateTransparency.html
  4. Trend Micro SSL →CT対応済み。
    Trend Micro SSL では、2014 年 12 月 22 日のシステム改修により、CT への対応を開始します。システム改修後は、新規に発行されるすべての EV 証明書に対し、CT Log から SCT が発行されるようになります。 http://esupport.trendmicro.com/solution/ja-JP/1106400.aspx?cm_re=Sup-_-tmssl-_-news_05
  5. グローバルサイン →「対応済み」のリリース見つけられず。恐らくCT未対応
    GlobalSignでは、2014年末までにEVの証明書についてCTへの対応を完了する予定です。 https://jp.globalsign.com/blog/2014/certificate_transparency.html
  6. Rapid SSL →「対応済み」のリリース見つけられず。恐らくCT未対応

非対応のEV証明書はChromeでグリーンバーが表示されなくなる

ChromeにはCTの検証機能が導入されているので、今までも証明書の詳細を見れば「○○により確認済みですが、公開監査記録がありません」というメッセージが表示されていた。とはいえぱっと見じゃ何もわからないので影響はなかった。

でも2015年2月にリリースされたChrome 41(ベータ版)以降は、警告度合いがより厳しくなっているようで、

  • 2015 年 1 月 1 日以降に発行した
  • CT非対応の
  • EV証明書

という3つの条件が揃うと、折角EV証明書なのにグリーンバーが表示されず、OVやDVと同じ表示になってしまうとのこと。

今は上記のような限定された条件だけど、SHA-1→SHA-2のときみたいに、順次警告度合いが厳しくなっていくとしたら、そのうちOVやDVも「CT対応でないと鍵マークが出ない」みたいになっていくのでは・・・と予想。

恐らくは「グリーンバーが出るから、一目でフィッシングサイトと見分けがつく!」というメリットのために、高いお金出してシマンテックのEV証明書を買ってるんだろうに、SHA-1だしCT非対応だしで、グリーンバーどころか三角の警告マークが出ているみずほダイレクトとか本当に可哀想で涙なしには見られない。

DNSで使える便利な*(アスタリスク)

DNSの設定で*(アスタリスク)使えるとか知らなかった!
$ORIGIN infra.xyz.
(中略)
@       IN      A       153.121.58.159
www     IN      A       153.121.58.159
ns1     IN      A       153.121.58.159
ns2     IN      A       54.64.115.59
*       IN      A       153.121.58.159
infra.xyz.zoneにこんな感じで書いておくと、@とかwwwとかns2みたいに存在するレコードはそっちの値が返るし、それ以外(hoge.infra.xyzとか、fuga.infra.xyzとか、hoge.fuga.infra.xyzとか)は全部「153.121.58.159」が返ってくるよー。
サブドメインいっぱい作って、全部同じウェブサーバに向けるようなときは*(アスタリスク)便利! BINDだけじゃなくて、お名前.comのネームサーバ(お名前.comの管理画面で登録するあれ)でも使えたー。

nslookupよりdig!DNS初心者向けのdig解説

このサイト(例えばhttps://infra.xyz/)って、どこのウェブサーバ使ってるんだっけ?というときは、

host infra.xyz

とか

nslookup
> set type=a
> infra.xyz

でもいけますが、nslookupは既に開発も止まっていて、ゆくゆくは無くなると言われているので、nslookupよりはdigを使おう!と思っています。

でもdig、叩くとこんな感じでべろべろっと色々出るので最初驚くんだよね。

$ dig infra.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns1.infra.xyz.
infra.xyz.              600     IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       153.121.58.159
ns2.infra.xyz.          600     IN      A       54.64.115.59

;; Query time: 272 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:24:44 JST 2015
;; MSG SIZE  rcvd: 122

どこ見たらいいの・・・という訳で一つずつ解説。

先ず、いちばん上にあるのがHEADER。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33266
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

今回は「status: NOERROR」となってるけど、これは普通に聞いて、普通に返ってきたのでNOERROR(正常)。 他には、NXDOMAIN(リクエストされた名前が存在しない)、REFUSED(リクエストが拒否された)、FORMERR(DNSメッセージのフォーマットが不正)、SERVFAIL(DNSサーバ側の状態が異常)などがある。

「flags: qr rd ra;」は、qr(問い合わせたクエリに対する回答であること)、rd(再帰的問い合わせに対する回答であること)、ra(キャッシュサーバが再帰問い合わせを許可していること)を表している。

なので、どこかのサーバから

dig infra.xyz @ns1.infra.xyz

DNSコンテンツサーバを指定して叩くと、「flags: qr aa rd;」とrdの代わりにaa(権威を持つ応答であること)になる。

あとは、ns1.infra.xyzは外からの再帰問い合わせは許可していない(=オープンリゾルバではない)ので、

dig yahoo.com @ns1.infra.xyz

のように叩くと、「status: REFUSED」で「flags: qr rd;」になる。

HEADERの下が、QUESTION SECTIONとANSWER SECTION。

;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

名前の通り、問い合わせとそれに対する回答。(慣れないとQUESTION SECTIONだけ見ちゃって、あれ値が返ってこない!ってなる)

ちなみに「infnya.xyz」みたいに存在しないドメインを問い合わせて「status: NXDOMAIN」になったときは、ANSWERセクションそのものがなくて、リクエストしたドメイン(infnya.xyz)の親ドメイン(xyz)のSOAレコードが、その下のAUTHORITYセクションで返ってくる。

$ dig infnya.xyz

; <<>> DiG 9.10.0-P1 <<>> infnya.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8329
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infnya.xyz.                    IN      A

;; AUTHORITY SECTION:
xyz.                    3600    IN      SOA     ns0.centralnic.net. hostmaster.centralnic.net. 3000169304 900 1800 6048000 3600

;; Query time: 590 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:33:48 JST 2015
;; MSG SIZE  rcvd: 104

AUTHORITY SECTIONとADDITIONAL SECTION。

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns1.infra.xyz.
infra.xyz.              600     IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       153.121.58.159
ns2.infra.xyz.          600     IN      A       54.64.115.59

リクエストしたドメイン(infra.xyz)のネームサーバ(ns1.infra.xyz, ns2.infra.xyz)と、そのIPアドレス(153.121.58.159, 54.64.115.59)が表示される。(間違えやすいけど、ここで表示されるのは親のDNSコンテンツサーバに登録されているグルーレコードではなく、実際のns1.infra.xyzにあるinfra.xyz.zoneに書いてあるNSレコードとAレコード)

ちなみにDNSキャッシュサーバのnamed.confのoptionsセクションで、

minimal-responses yes;

にすると、AUTORITY SECTIONとADDITIONAL SECTIONセクションは省略される。(DNSコンテンツサーバとして返す情報に変化はない)

最後に一番下にある色々。

Query time(クエリの応答時間)と、SERVER(応答したDNSサーバのIPアドレスとポート番号)、MSG SIZE(メッセージサイズ)。

;; Query time: 590 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 28 22:33:48 JST 2015
;; MSG SIZE  rcvd: 104

今回はns1.infra.xyzの中でdigを叩いたので、SERVERは自分自身(127.0.0.1)になってます。

という感じなので、何かDNSがうまく引けない・・・というときは、

  • STATUSはNXDOMAINか?REFUSEDか?
  • flagsにrdがあるか?ないか?
  • SERVERのIPはGIPか?LIPか?

辺りを確認して、DNSキャッシュサーバ側の問題なのか、DNSコンテンツサーバ側の問題なのか、を切り分けるようにしています。 +traceオプションつけると、Rootから引いてくれてわーい、とかもありますが、その辺の便利オプションは言い出すときりがないのでまた別途。

最後になりましたが、digはdomain information groperの略です。

WS000450

参考資料:

AWSのEC2で、CentOS7のホスト名を変更する方法

ホスト名の恒久的な変更ね、/etc/hostsでしょー!と思ったらCentOS7からファイルが/etc/hostnameに変わっていた。(名前まんまだ) しかも直接書き換えるのは推奨されない様子で、専用のコマンドが用意されてた。

hostnamectl set-hostname 変更後のホスト名

を叩くと、/etc/hostnameが変更される。hostnamectlで結果も確認できる。でもrebootすると元に戻る。

なんだこれ・・・と思ったらAWS(EC2)の独自設定があった。

vi /etc/cloud/cloud.cfg

で# - update_hostnameしとけばOK。

グルーレコードの確認方法

いったん、+traceで親のDNSコンテンツサーバを調べて、

$ dig infra.xyz +trace

; <<>> DiG 9.10.0-P1 <<>> infra.xyz +trace
;; global options: +cmd
.                       346259  IN      NS      h.root-servers.net.
.                       346259  IN      NS      j.root-servers.net.
.                       346259  IN      NS      k.root-servers.net.
.                       346259  IN      NS      g.root-servers.net.
.                       346259  IN      NS      l.root-servers.net.
.                       346259  IN      NS      i.root-servers.net.
.                       346259  IN      NS      f.root-servers.net.
.                       346259  IN      NS      c.root-servers.net.
.                       346259  IN      NS      b.root-servers.net.
.                       346259  IN      NS      m.root-servers.net.
.                       346259  IN      NS      d.root-servers.net.
.                       346259  IN      NS      a.root-servers.net.
.                       346259  IN      NS      e.root-servers.net.
.                       347445  IN      RRSIG   NS 8 0 518400 20150224050000 20150214040000 16665 . 49XDs9Icoki4ReHy1mUexld6E7w8xCb7NTXMlie4bckAQ2p61KjzkhbJ 89DT98Xpc2IcfJy1TWgee2CTthYXXbLuuhEJdZEUrlJW2ku2IjSaEH3L JlriAwtHgrziIKgWseXAxUVJc7/w+QoYd9XV7oIOHwL3Q8MH65ako+z2 nm8=
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 14 ms

xyz.                    172800  IN      NS      z.nic.xyz.
xyz.                    172800  IN      NS      y.nic.xyz.
xyz.                    172800  IN      NS      x.nic.xyz.
xyz.                    172800  IN      NS      generationxyz.nic.xyz.
xyz.                    86400   IN      DS      3599 8 1 3FA3B264F45DB5F38BEDEAF1A88B76AA318C2C7F
xyz.                    86400   IN      DS      3599 8 2 B9733869BC84C86BB59D102BA5DA6B27B2088552332A39DCD54BC4E8 D66B0499
xyz.                    86400   IN      RRSIG   DS 8 1 86400 20150226050000 20150216040000 16665 . 2wVBaGY2zO+b1jX12HPs7Ly0za90q+AtGM5tm3fRyOrDpCQt1XD0iJnc ij2jWuXWWXL8005Qqvi5C/gRiGJswfChKuX4J4/OKGGPzSVjxGynuEQu m3hTUtFWNESuGRAqS1zlsypFRP9O8mpaTamHRxamcQuvDSrbZBLpTbb3 sOU=
;; Received 537 bytes from 192.33.4.12#53(c.root-servers.net) in 122 ms

infra.xyz.              3600    IN      NS      ns1.infra.xyz.
infra.xyz.              3600    IN      NS      ns2.infra.xyz.
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN NSEC3 1 1 1 - 1KKABMBG1LO63FOI21UHUBCQJDM5D2RM NS SOA RRSIG DNSKEY NSEC3PARAM
1h97h2oec2juov8dlbbjj6i7ik26bm8d.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150311130404 20150209214037 38328 xyz. teRlK0XJ4/Z4SmzTdI3idnwN4Zf4rLHYBap/w0KV34CB6ICtkWsBM1bk hWS4jSQ6XrjFO/OrOEKvgl/DcoyYiEsijJkcqo364JYAVUCzK1cdHlJQ efbZjruxLPEoe+34jb6gZvuY15huradsTnEnyDKQraMuOnLCUpqqiKun L9E=
jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN NSEC3 1 1 1 - JTBA28MNE9VHFM3561JQOEB66MS83DLK NS DS RRSIG
jap3nebfhkg51v8uie6lh8n8fm536euf.xyz. 3600 IN RRSIG NSEC3 8 2 3600 20150315190829 20150213161936 38328 xyz. ctm4qzSZRJt9gww/VHZ7PhDS8bEkpaRdkSi2FqyIf+hBA83Z7nWvQGUN Ubxd/kgR37gd3NDXoFXiJ3jhYBqJn6Ejfv9kPCv08kjEJ2lQ9W6wfSnA z8Fw67+SvQlwOIntcuDGvW7eL7He5B0C2VmQXVhLhI8dBzpbYR8tMove VCc=
;; Received 591 bytes from 185.24.64.42#53(y.nic.xyz) in 137 ms

infra.xyz.              600     IN      A       153.121.58.159
infra.xyz.              600     IN      NS      ns2.infra.xyz.
infra.xyz.              600     IN      NS      ns1.infra.xyz.
;; Received 122 bytes from 153.121.58.159#53(ns1.infra.xyz) in 0 ms

親(z.nic.xyz)に向かって問い合わせると、AUTHORITY SECTIONとADDITIONAL SECTIONにグルーレコードの情報が表示される。

$  dig infra.xyz @z.nic.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz @z.nic.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37776
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; AUTHORITY SECTION:
infra.xyz.              3600    IN      NS      ns1.infra.xyz.
infra.xyz.              3600    IN      NS      ns2.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          3600    IN      A       153.121.58.159
ns2.infra.xyz.          3600    IN      A       153.121.58.159

;; Query time: 55 msec
;; SERVER: 2a04:2b00:13ee::42#53(2a04:2b00:13ee::42)
;; WHEN: Mon Feb 16 23:22:27 JST 2015
;; MSG SIZE  rcvd: 106

ちなみに、何も指定せずに普通に問い合わせた時に出るAUTHORITY SECTIONとADDITIONAL SECTIONは、グルーレコードの値ではなく、実際のDNSコンテンツサーバ(今回の例で言えばns1.infra.xyzとns2.infra.xyz)で設定されているNSレコードとAレコードの値なので注意。

グルーレコードのNSと、DNSコンテンツサーバのNSレコードはどっちが優先されるか?

グルーレコードに

infra.xyz. 3600 IN NS ns1.infra.xyz.
infra.xyz. 3600 IN NS ns2.infra.xyz.

ns1.infra.xyz. 3600 IN A 153.121.58.159
ns2.infra.xyz. 3600 IN A 153.121.58.159

と登録して、でも実際のDNSコンテンツサーバ(153.121.58.159と54.64.115.59)に置いてあるゾーンファイルには、

infra.xyz. 600 IN NS ns2.infra.xyz.
infra.xyz. 600 IN NS ns1.infra.xyz.

ns1.infra.xyz. 600 IN A 54.64.115.59
ns2.infra.xyz. 600 IN A 54.64.115.59

と書いてある状態で、

dig infra.xyz @ns1.infra.xyz

したら、153.121.58.159と54.64.115.59のどっちに聞きにいくでしょう?

私、153.121.58.159だと思ってたんだけど、54.64.115.59だった。

$ dig infra.xyz @ns2.infra.xyz

; <<>> DiG 9.10.0-P1 <<>> infra.xyz @ns2.infra.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16672
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;infra.xyz.                     IN      A

;; ANSWER SECTION:
infra.xyz.              600     IN      A       153.121.58.159

;; AUTHORITY SECTION:
infra.xyz.              600     IN      NS      ns2.infra.xyz.
infra.xyz.              600     IN      NS      ns1.infra.xyz.

;; ADDITIONAL SECTION:
ns1.infra.xyz.          600     IN      A       54.64.115.59
ns2.infra.xyz.          600     IN      A       54.64.115.59

;; Query time: 5 msec
;; SERVER: 54.64.115.59#53(54.64.115.59)
;; WHEN: Mon Feb 16 23:10:30 JST 2015
;; MSG SIZE  rcvd: 122

グルーレコードに書いてあるDNSコンテンツサーバに行って、そこでもう1回NS引いてからA引くんだね。勉強になった。

digの+shortとか+norecursionとかは、後半何文字か省略しても通る

digの+shortは+shorでも通る(さすがに+shoはダメだった)し、+norecurseは+norでも通る。 なんか「あ、いまtypoした?」って時に普通に応答返ってきて、ん?と思ってたんだけど、まさか後半何文字か省略しても通る仕様だったとは。