DNS by Twisted もうちょっと調べとく
別記事で記載したとおり、TwistedをDNSで使う場合微妙な実装があり、どうなのかなぁ、、という感想を書きました。
その時脳内にあった懸案の１つの、DNSSECについてもうちょっと深堀しておきます。
DNSSECとは
端的に言うと、DNSにHTTPのSSL証明書のような「改ざん防止」の機能をもたせようという仕組みですね。
https://www.nic.ad.jp/ja/newsletter/No43/0800.html
記事自体も2009年であるものからわかるように、かなり古くからある技術ですが、浸透してるかというと、、、
https://blog.nic.ad.jp/2020/4513/
以下、DNSは「どのDNS」の話をしているのがこんがらがるので、極力以下の表現に揃えます。
https://atmarkit.itmedia.co.jp/ait/articles/1706/23/news042.html
さておき。
理解を間違えてたら恥ずかしいのですが、、上記で言う「検証」というのはフルリゾルバやキャッシュサーバとしてのDNSの話で、Googleの8.8.8.8みたいなユーザの名前解決要求を代行するひとが、DNSコンテンツサーバ（権威サーバ）に聞きに行く際にDNSSECを使うかどうかだと思います。
一方「署名」というのは、フルリゾルバから問い合わせを受けたDNSコンテンツサーバ側がDNSSECを使っているかどうかなのかなと。
- リゾルバがDNSSECを使おうとしなけれれば、コンテンツサーバがDNSSEC対応をしていようがいまいが、以前通りの処理を行う。
- リゾルバがDNSSECを使おうとして、コンテンツサーバがDNSSEC対応していれば、晴れてDNSSECでの処理が行われる。
- リゾルバがDNS SECを使おうとしているが、コンテンツサーバがDNSSEC対応していなければ、以前通りの処理。
「検証」については、結局はソフトやオープンリゾルバが対応するかどうかの話で、有名どころは対応が済んでいるような気がします。
今回の関係でリゾルバとして使っていたunboundも、以下のように、「当然実装してるし、無効化も完全にはさせない」というような仕様になってます。
↑モジュール外せば無効化できますね。。お恥ずかしい。
https://unbound.jp/unbound/howto_turnoff_dnssec/
一方「署名」についてですが、google.co.jpがどうしているのかなと見てみると、、
$ dig +dnssec -t A google.co.jp @ns1.google.com
; <<>> DiG 9.16.1-Ubuntu <<>> +dnssec -t A google.co.jp @ns1.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29846
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;google.co.jp. IN A
;; ANSWER SECTION:
google.co.jp. 300 IN A 172.217.175.35
;; Query time: 92 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sat Dec 11 12:26:13 UTC 2021
;; MSG SIZE rcvd: 57
RRSIGなどのDNS SECを使っている際のレコードの応答がありません。
一方、普及が進んでいるというスウェーデンのサイトということで、Wikiで見つけたスウェーデン王国政府サイトはというと、こんな感じ。
Aレコードに対してRRSIGがついて返ってきます。
$ dig +dnssec -t A regeringen.se @sto.excedodns.se
; <<>> DiG 9.16.1-Ubuntu <<>> +dnssec -t A regeringen.se @sto.excedodns.se
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38504
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;regeringen.se. IN A
;; ANSWER SECTION:
regeringen.se. 3600 IN A 185.195.92.41
regeringen.se. 3600 IN RRSIG A 8 2 3600 20211223000000 20211202000000 46143 regeringen.se. AA3/tSQ1Yi7d+UvhKiN9h3ibL+QWvLunvhbFB1q6q3gEcP3u4RHTCwnI neLyBiQTTCDGFJkwQ0SWgnNE4uL+wkIQSxVgQBxAJyfKyh3Nt6z1tDMW vAfno435OidxIXde4Q5Kxhcjqi7LvViHexVHJdpIxrgqb6jSnLhpxXgl 5TydKvdk7HbBapyYjZYTkc0LWjTvtjRRzFXK3YO3Ei43rrmw3mK1/A6g t/u2nKSasdlxELVllV3mVnaNL4CfKEHsbLEaxQiTQ9JpyHAmD6doLPfQ hjre4TIzVNPxe73Vi12TZvHB6rCduhbuR3PLyCzQVkJLXkdbSWnwPTmN bTIbjA==
;; AUTHORITY SECTION:
regeringen.se. 86400 IN NS sto.excedodns.se.
regeringen.se. 86400 IN NS emea.excedodns.eu.
regeringen.se. 86400 IN NS world.excedodns.org.
regeringen.se. 86400 IN NS global.excedodns.com.
regeringen.se. 86400 IN NS nordic.excedodns.net.
regeringen.se. 86400 IN RRSIG NS 8 2 86400 20211223000000 20211202000000 46143 regeringen.se. QJP6hhA5JOMkYutUmqwZU3Yqk/U8JGykk9R96ynXnF1dNv+wO92lkmw8 78NfLIpw3UUkz+b+akD0xjdAz1oDaEaqYlg3PO5/WQ2UBUX1dxU1nI9S +C9a7tKPjIKmFMltyPkCe5jHMVbUsp/xOMSBb6IupZGUW5sLADCkr3Yz U6QX6dClkByKECWX9qBMZJ7sA6QLyXUaqQS7+6Uw42+0G32VN3HuWm2X 0QbYHfH9dSXA6maA3ru0xnkdsrhOyt1VCvtC02C7ucXN8o75jc4Fxw3Z J1HXVHRYqSMN8sqSAdQKlKWmTzdqvNRSEFHILsYsuUPrblk5/Mlc5Uoi U4XqsQ==
ミーハーな考え方ですが、グーグルさんが使ってないところからしても、やはり署名は確かに進んでない感じなのですかね。
脱線 試して見るときの注意
今回は手元のubuntuで試しているのですが、systemd-resolveに聞くとRRSIGの値が返って来ませんでした。
上記で、直に権威サーバに聞きに行っているのはそういう理由です。
ちなみにブロードバンドルータや8.8.8.8に聞きに行く場合でもRRSIGちゃんと取れます。
どうやらsystemd-resolveはDNSSECを使わないのがディフォ設定になっているからのようなのですが、、単純にDNSSEC=trueにすると名前解決できなくなります。
というか、パケットを眺めている限り、リクエスト時にDNSSE用のDD bitを立てて無いような、、
https://wiki.archlinux.jp/index.php/Systemd-resolved
まぁリゾルバによって結果がフィルタされてているかもしれない、というのは念頭に置いとく必要があるということで。
TwistedのDNSSEC対応
Twistedのnamedライブラリも、スタブリゾルバとしての振る舞い（多分DNSSEC Clientという表現）や、権威サーバ、キャッシュ、フォワーダとしての振る舞いができるので、混ぜないように注意しないといけないのですが、ざっと上記と現時点で最新のコード（21.7.0)を見た感じ、どれとしてもDNSSECには対応してないように見受けられます。
DNSSEC Clientとしてのロードマップは以下にも示されているのですが、随分前に提示されて進んでない感じです。。
https://twistedmatrix.com/trac/milestone/DNSSEC_Client
そもそもソースでリクエストを受け取ったときの処理を眺めているとdnssecokという名前でDNSSEC利用有無のフラグのデータを読み取って格納しているようなのですが、これを他の処理で使っている様子が無い、、、
https://github.com/twisted/twisted/blob/twisted-21.7.0/src/twisted/names/dns.py
権威サーバの方ですが、こっちもそもそもDNSSECで使用されるレコードタイプであるRRSIGやDS,DNSKEYなどのデータを扱えるクラスや変数が実装されていないです。
最初の記事だと、一部の実装をしてくれたひとがいるそうなのですが、実際のコードへの取り込みはされてないようですね。。
https://github.com/twisted/twisted/blob/twisted-21.7.0/src/twisted/names/dns.py
と、いうことで、道は遠い。
まとめ
静的な偽レコードを配るくらいならBindやUnboundで実装できるのですが、リクエストに合わせて動的に応答を変えようとすると、自由度高く実装できるTwistedのようなライブラリが必要です。
でもTwistedでDNSを実装する場合、DNSSECが実装できません。
現状世の中でもDNSSEC対応をしないコンテンツサーバも多くあるのは事実ですが、将来的にどうなるか。。
少なくとも、rootコンテンツサーバやjpなどの上位のドメインはDNSSEC対応してますので、こいつらを詐称するDNSサーバを作ろうとするときは考慮せにゃならんかなと。
（まぁそんな特殊用途で使うときに几帳面にDNSSECまで実装するか、、？という話ではありますが）
そして、、、ここらへんも視野に入れないといけません。
https://support.mozilla.org/ja/kb/firefox-dns-over-https
https://www.isc.org/blogs/doh-talkdns/
。。。bindやubnoundのプラグインとしてねじ込む方法が正しいのかもしれません。
腰を据えて勉強するかぁ、、、
とりあえずこんなところで。