dnspythonのサンプルコードをさらします。 dnspythonで非再帰問い合わせをしつつ、ついでにNSIDも取得してます。
NSIDは、EDNSオプションで使うことのできるもので、実際に応答をした権威DNSサーバー（IP Anycastなどで負荷分散されているDNSサーバーへの問い合わせはどこに吸い込まれたか容易には分からないので）を特定することができます。
但し、NSIDは全ての権威DNSサーバーが対応しているオプションではありません。
以下、MルートサーバーにルートゾーンのSOAを問い合わせるサンプルです。
自分の環境では以下のような結果になりました。
$ ./sample.py M-NRT-JPNAP-3 a.root-servers.net. nstld.verisign-grs.com. 2019111100
証明書を発行しようとする認証局は、必ず対象のドメインについてCAAレコードをチェックする必要があります。
Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set.
ドメイン、example.comのissuewildプロパティに;が指定されている場合、
*.example.comは発行できないはずですが、example.comの証明書は発行することができるのか気になりましたので調べてみました。
CAAレコードを設定して証明書を発行してみます。ドメインはmtcq.jpを使います。
$ dig +norec +short @ns2.mtcq.jp mtcq.jp CAA 128 issuewild "\;" $ sudo letsencrypt certonly --standalone -d mtcq.jp
無事発行することができました。
そもそも、ワイルドカードでない証明書を発行するときは、issuewildを無視する必要があること
記載されていました。
セミコロン;が指定されていても一元的に発行できなくなるわけではない（プロパティを正しく解釈する必要がある）ということですね。
issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain.
Nginxをリバースプロキシにして、Plotly Dashで作ったサンプルアプリを動かしてみます。
uWSGIとNginxは、Unixドメインソケットでつないでみます。
dash.DashのインスタンスからFlaskのアプリをapp.serverとして取り出しています。
以下、コマンドラインからのuWSGIアプリの起動。
$ uwsgi --socket /tmp/unix-domain.sock \
--mount "/=sample-uwsgi:server" \
--chmod-socket=777
以下、Nginxの設定抜粋。
location / {
try_files $uri @wsgiapp;
}
location @wsgiapp {
include uwsgi_params;
uwsgi_pass unix:/tmp/unix-domain.sock;
}
フロントエンド周りの勉強を目的に、Plotly Dash*1を用いて 権威DNSサーバーのRTT等の可用性を可視化するウェブアプリケーションを作ってみました。
実装はシンプルで、下記のような感じ。
DNSをモニタリングするツールは、そもそもいろいろあったります。
*1:Introduction to Dash https://dash.plot.ly/introduction
*2:A DNS toolkit for Python http://www.dnspython.org/
aureportコマンドをcrontabで実行した際、何度やっても<no events of interest were found>と出力されてしまっていました。
結論としては、--input-logsオプションをつけることで想定通り動作するようになりました。
--input-logs Use the log file location from auditd.conf as input for analysis. This is needed if you are using aureport from a cron job.
SCTに存在するLogIDがどのように作成されているのか書きたいと思います。
ここで言っているLogIDとは、下記のものです。
例としてgoogle.co.jpにChromeでアクセスして表示させています。
まずLogIDがなんなのかCertificate TransparencyのRFC 6962を確認してみます。
3.2. Structure of the Signed Certificate Timestampによれば
LogIDは、key_idをフィールドにもつ構造体の様です。そして、key_idはCTログサーバーの公開鍵を
DER形式でSHA256ハッシュをとったものと書いてあるように見えます。
CTログサーバーの公開鍵があれば、LogIDを作れそうです。 CTログサーバー（Chromeのポリシーに対応する）の公開鍵は次から取得することができます。
www.certificate-transparency.org
始めの図の一つ目のLogIDである、Google 'Pilot' logを作ってみます。Google 'Pilot' logの公開鍵は下記のようです。
{
"description": "Google 'Pilot' log",
"key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA==",
"url": "ct.googleapis.com/pilot/",
"maximum_merge_delay": 86400,
"operated_by": [
0
],
"dns_api_endpoint": "pilot.ct.googleapis.com"
}
KEYにある値をEC鍵（Elliptic Curve）としてopensslでSHA256ハッシュをとってみます。
$ cat << EOF | openssl ec -outform der -pubin | openssl dgst -SHA256 -binary | hexdump -C -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEfahLEimAoz2t01p3uMziiLOl/fHTDM0YDOhBRuiBARsV4UvxG2LdNgoIGLrtCzWE0J5APC2em4JlvR8EEEFMoA== -----END PUBLIC KEY----- EOF read EC key writing EC key 00000000 a4 b9 09 90 b4 18 58 14 87 bb 13 a2 cc 67 70 0a |......X......gp.| 00000010 3c 35 98 04 f9 1b df b8 e3 77 cd 0e c8 0d dc 10 |<5.......w......| 00000020
すると、はじめの図に記載した通りのLogIDを得ることができました。
ちなみに、CTでの署名アルゴリズムはRFC 6962に下記のように記載されているように
NIST P-256に記載される楕円曲線暗号を使うか、RSAの最低2048bitの鍵で署名する必要があるようです。
2.1.4. Signatures
Various data structures are signed. A log MUST use either elliptic curve signatures using the NIST P-256 curve (Section D.1.2.3 of the Digital Signature Standard [DSS]) or RSA signatures (RSASSA-PKCS1- V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at least 2048 bits.
