やめよう DNSSEC

中京大学工学部 鈴木常彦
Dec 14, 2024 DNS温泉番外編in大阪 vol.3
http://www.e-ontap.com/misc/onsenkansai3/

お詫び

DNSSEC を dis りますが
皮肉ながら DNSSEC の知識が増えるので
詳しくなりたくない方も推進派の方々も
生暖かくお許しください。

読むべき DNSSEC 関連 RFC

その他諸々

DNSSEC の仕組み

DNSSEC 普及度

APNIC Labs Measurements (2024/12/7)


未署名 な Big Tech たち

DNSSEC の弱点 その1 : 難しすぎる

DNSSEC の弱点 その2 : ゾーン列挙可能

(参考) Compact Denial of Existence in DNSSEC (黒い嘘) の例

左は従来、右が黒い嘘 (但し RFC 化が進められているものではなく Cloudflare の独自実装 / TYPE128 が NXNAME になる予定)

% dig nxname.se @a.ns.se +norec +dnssec +multi				  
; <<>> DiG 9.20.3 <<>> nxname.se @a.ns.se +norec +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17913
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 9eb2f57f6edd9c2801000000675769786f443574d908da36 (good)
;; QUESTION SECTION:
;nxname.se.   IN A

;; AUTHORITY SECTION:
se.     7200 IN SOA catcher-in-the-rye.nic.se. registry-default.nic.se. (
        1733780021 ; serial
        300        ; refresh (5 minutes)
        1800       ; retry (30 minutes)
        864000     ; expire (1 week 3 days)
        7200       ; minimum (2 hours)
        )
se.     7200 IN RRSIG SOA 8 1 172800 (
        20241223213342 20241209200342 12976 se.
        GkvnhCG9Jy6qnM/FqQQCF8LqN49+EZmQSYQh8jrGhuhS
        k1TQkL6sIse0Am0TgdrRGSTXFbqcFEol2jcc0if/zGFN
        BUczYM6X4zpQMOnxw7SkTHdfGDHIk6QZuGmK/GHFZ/8A
        lljBmAlszYKveSgvdG3sRZsfxUI9feq9UKu3Xh45skaj
        uUYxzM9r+4SW+Sp9iQVdOXzqsZzGq4GJjDOJmCztYfsS
        Ky+zxgWiWs2QmdXzY47e56Guam3UgReR7ZyTDmVHwwXk
        WSmuXqJUjBT9NcPWmusZnkiZdAv1YfTlBwwi+1vISmMO
        uH5l97u1wN5l/IfgSeib8I2OZcpbU44ANA== )
se.     7200 IN NSEC 0.se. NS SOA TXT RRSIG NSEC DNSKEY ZONEMD
se.     7200 IN RRSIG NSEC 8 1 7200 (
        20241222003029 20241207230029 12976 se.
        PMoP74jYNR0YiS23uY5arWzFKcBrizgGH3NDpbeMOBCq
        fGk6zLFylcINKlXhIlqMWd5bRR3bCZqzxFJxEnFmVzSj
        fkoCLEu05IEw8vYW/0WHpR9WBsS1kDsThUiJy/bah6uZ
        cjNDs+u6P4Uibe2Wp73VnZ6hpDCrydaMDMoiVAKOGS26
        NDH+6my/ek4IX74K3r6B5C+ZIOEzE2Pwe2CSUemsygJu
        rMFFEdi8gl+Nfi3v8thhJUdhDm6S67eCiuqdjbNoU9vo
        2kYGnMUGXSlynyWs3sfxzwMgmpNhzi8AWs9jfzdAwcju
        NkprQISS5wxW4JFh66x4jlRBs4PNyoaBYA== )
nxn.se.     7200 IN NSEC nxp.se. NS DS RRSIG NSEC
nxn.se.     7200 IN RRSIG NSEC 8 2 7200 (
        20241222151522 20241208134522 12976 se.
        kgAs2vJqpFcC0kFGOjRsP5GKe0KV8u/bQxLpXOsAq8Z8
        Y8XfJ34AV8yz0uxjzrEEM2JIZPTnZmjs27Lo6QDqCWat
        7RDs7fy5VLtf25WwsQYIop2udxhpDMsSSNY9IKGx5q2n
        o6NfOx4dKvMCjF60y+yQe94qhcUrkfn67RLVFcpYoeYp
        jyqljUc/yUwoLqFY8ZGzLwCenI2BJJ9JnY1OJPYAiezt
        H3+M3AnIFU1Vc1AEIs7TW/1WBaP8zXFVvDpVq6hla+La
        myo+n9iJYQM6ZjxQbYypoFQaehAWT6t0PAn0BLZ0YALL
        sJeANgGNp34wzdl9g+FBTXxmc/wuF0bWPQ== )

;; Query time: 284 msec
;; SERVER: 2a01:3f0:0:301::53#53(a.ns.se) (UDP)
;; WHEN: Tue Dec 10 07:04:40 JST 2024
;; MSG SIZE  rcvd: 1074
		
% dig nxname.cloudflare.com @ns3.cloudflare.com +norec +dnssec +multi

; <<>> DiG 9.20.3 <<>> nxname.cloudflare.com @ns3.cloudflare.com +norec +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40218
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;nxname.cloudflare.com. IN A

;; AUTHORITY SECTION:
cloudflare.com.   300 IN SOA ns3.cloudflare.com. dns.cloudflare.com. (
        2359261535 ; serial
        10000      ; refresh (2 hours 46 minutes 40 seconds)
        2400       ; retry (40 minutes)
        604800     ; expire (1 week)
        300        ; minimum (5 minutes)
        )
nxname.cloudflare.com.  300 IN NSEC \000.nxname.cloudflare.com. RRSIG NSEC TYPE128
cloudflare.com.   300 IN RRSIG SOA 13 2 300 (
        20241210231111 20241208211111 34505 cloudflare.com.
        bQfWrNifoVVWXAzdVGVawXLyfZxMDNs4BqEeQURqqtmU
        stzKYeXSJ9QphELfwvFRgkRbpA7PGt1O9DkWJKplwg== )
nxname.cloudflare.com.  300 IN RRSIG NSEC 13 3 300 (
        20241210231111 20241208211111 34505 cloudflare.com.
        6ILs739cBQ/pidnkX8j7Az9RyfkIBElXUpPtpBGwrW7U
        9EtmndN6iyjnjEk5vu56gEemYzLDK9BbaNQbHxHyhw== )

;; Query time: 22 msec
;; SERVER: 2400:cb00:2049:1::a29f:7e2#53(ns3.cloudflare.com) (UDP)
;; WHEN: Tue Dec 10 07:02:02 JST 2024
;; MSG SIZE  rcvd: 370

DNSSEC の弱点 その3 : 応答が大きい

爆破

DNSSEC の弱点 その4 : CPU への負荷が大きい

爆破

DNSSEC の弱点 その5 : キャッシュポイズニングに弱い
(皮肉なことだ)

爆破

DNSSEC の弱点 その5 : キャッシュポイズニングに弱い (続き)

(参考) NSEC/NSEC3 Replacement Attack が狙う否定応答の NS

以前の Unbound は否定応答に付随する NS をキャッシュに入れていた。
(権威セクションに NS が付随する応答は愚かにも RFC2308 では普通の形式)

% dig hoge.sub.mufj.jp @ns.sub.mufj.jp +norec

; <<>> DiG 9.20.3 <<>> hoge.sub.mufj.jp @ns.sub.mufj.jp +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50035
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;hoge.sub.mufj.jp.      IN A

;; AUTHORITY SECTION:
sub.mufj.jp.            60 IN SOA ns.sub.mufj.jp. admin.e-ontap.com. (
                                1729647022 ; serial
                                1200       ; refresh (20 minutes)
                                900        ; retry (15 minutes)
                                3600000    ; expire (5 weeks 6 days 16 hours)
                                60         ; minimum (1 minute)
                                )
sub.mufj.jp.            120 IN NS ns.e-ontap.com.

Unbound 1.8.2 released : "The nameserver records in large returned negative responses are scrubbed out of the packet to avoid fragmentation based DNS cache poisoning, from a report from T.Suzuki."

注意: dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt などと二度 (負荷分散されている環境では多数回) 繰り返して "Your_cache_server_is_vulnerable." と出るようなキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられますから乗り換えましょう。

(参考) 誰が正しい?

ダウングレード攻撃そのものではないが未知の (あるいは不適切な) アルゴリズムへの応答を見てみる。これは DS は RSA の KSK だが署名が ED448 なパターン。(他に fake.ed448.mufj.jp (無署名), fake2.ed448.mufj.jp (偽署名) もあるのでお試しあれ)

DNSSEC の弱点 その5 : キャッシュポイズニングに弱い (続き)

  • 重要な点: 署名しても検証してくれるサイトは少なく、検証しても署名しているドメインは少ない。
      (つまり DNSSEC の大きな応答でリスクを増大させているだけ)
  • Shulman らの論文 5 Conclusions and Defenses の指摘はとても重要 
     We want to caution against drawing the conclusion that DNSSEC should not be used. In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out); this will certainly prevent many of our poisoning attacks, and even defend against more powerful Man-in-the-Middle adversaries. However, incremental DNSSEC deployment is vulnerable to our cache poisoning attacks, and complete adoption of DNSSEC may take considerable time, since it depends on adoption by both name server and resolver.
    (以下 DeepL 訳) 
    DNSSECを使用すべきではないという結論を導き出さないように注意したい。実際、最善の防御は、（NSEC3のオプトアウトを使用せずに）すべてのリゾルバと ドメインでDNSSECを正しく適用することである。これにより、我々のポイズニング攻撃の 多くを確実に防ぐことができ、さらに強力な中間者攻撃（Man-in-the-Middle）からも防御できる。しかし、漸進的なDNSSECの展開はキャッシュポイズニング攻撃に対して脆弱であり、DNSSECの完全な採用はネームサーバーとリゾルバの両方による採用に依存するため、かなりの時間がかかる可能性があります。

    • DNSSEC の弱点 その6 : 暗号化されない

    悩むおねいさん

    DNSSEC 推進のまやかし その1 : 逆引き DNSSEC は必要?

    DNSSEC 推進のまやかし その1 : 逆引き DNSSEC は必要? (続)

    DNSSEC 推進のまやかし その2 : ルート鍵変更での騒動

    2018年に初めてのルート KSK (鍵署名鍵) ロールオーバが行われることになり騒動が起きた。(2017年の予定が延期されていた)

  • 「インターネットユーザの4人に1人、または7億5千万人がKSKの更新による影響を受ける可能性がある」というデマも (DNSSEC はそんなに普及していない)
  • 当時の記事「いよいよ明日10月11日深夜に実施、「ルートゾーンKSKロールオーバー」は過度に恐れる必要は無い!?（普段からきちんと管理されているネットワークであれば）」 (INTERNET Watch)

    以下の ルートゾーンの KSK の部分の交換の話

    KSK

    • DNSSEC 推進のまやかし その2 : ルート鍵変更での騒動 (FUD)

  • ICANN からの協力要請文書
  • ＤＮＳの世界的な運用変更に伴うキャッシュＤＮＳサーバーの設定更新の必要性について (内閣官房 内閣サイバーセキュリティセンター)
  • DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性 (総務省)
    ... 以下、ミスリードな点を抜粋 
    (1) 「鍵の更改」に追従するために、
  ③念のため、「キャッシュ DNS サーバー」において、「DNSSEC」が有効になっており、また「DNSSEC の検証」が有効になっていることを確認する。
(2) 「鍵の移行期間」のデータ量増大に対応するために、
  ①「キャッシュ DNS サーバー」において、UDP 受信サイズを 4096 バイトの検索結果が受信できる設定（RFC6891 による推奨設定）を行う。

    ICANN, JPRS, JPCERT/CC からの注意喚起にはこのような余計な文言はない。
    JPRS は関連文書「ルートゾーンKSKロールオーバーの概要と影響の確認方法」に以下の記述

    ① サイズの大きなDNS応答（少なくとも1425バイト）を正しく受け取れるかの確認
② DNSSEC検証を実施している場合、トラストアンカーの更新方法の確認
  • IGCJ members ML (アーカイブ非公開) への私のメール 
    注意喚起をするのは結構なことですけれども、混乱を引き起こすのはやめて頂きたい旨を高村さんにお伝えしたところ、
「広く注意喚起をするのが目的なので Terrible Story としてこのような文書にしてある。どこの組織でも問題が発生する可能性があるので、SIer など分かるところへ投げるアクションをとってもらえたらそれでよい」
ということでした。
 
教育者としては間違った知識を広めてもらうのは困るとお伝えしましたが、あなたはあなたの立場、我々は我々の立場で行動する。鈴木さんが注意喚起を抑えることで何か障害が発生したらあなたは責任を取れるのかということでした。
 
このような FUD のような手法で注意喚起を行って、社会を混乱させるのが果たして正しいインターノットガバナンスなのでしょうか。問題提起としてここに振らせて頂きましたので御議論頂ければと思います。

    • DNSSEC 推進のまやかし その2 : ルート鍵変更での騒動
    (続: 当時の私)

    「DNSSEC に関する一連の注意喚起で混乱中の皆様へ」というブログを書いた

    (参考) DNS Flag Day 2020

    DNS Flag Day 2020 では以下のように UDP のサイズを抑えるようキャンペーンが行われた。

    IP フラグメンテーションは、現在のインターネットでは正しく動作するか信頼できないものです。 また、 UDP で 大きなサイズの DNS メッセージが送信された際に、転送の失敗を引き起こす原因になりえます。 たとえ IP フラグメンテーションが正しく動作したとしても、セキュリティの面では不十分でしょう。 なぜなら、フラグメントされた DNS メッセージの 一部 を偽装することは理論的に可能であり、 受信側で簡単にそれを検知する方法はないからです。
    DNS ソフトウェアのデフォルト値としては、最小で安全なサイズである 1232 を反映するべきでしょう。

    注:1232 でも安全とは言えない。私は 512 を推奨。Google も 512。
    (未対策の Linux は最小 552 までフラグメントさせられる)
    Cloudflare は最近まで 512 にしていたが、一部のサイトで問題があったとして 2024年7月5日に 1232 にした。理由は ratelimit らしいので追従する必要はないと思う。(記事)

    総務省、NISC に従って 4096 のままなサーバは見直しが必要。手動で conf 書き換えていたら実装のバージョンアップでは値はそのままなはず。

    総務省高村氏には「鈴木さんが注意喚起を抑えることで何か障害が発生したらあなたは責任を取れるのか」と言われたけれど総務省の注意喚起で何か障害が発生したら総務省は責任を取れるのか?

    (参考) DNSSEC でなくとも大きな応答はよくありますね

    ゾーン頂点に TXT レコード書き並べ(させ)るのは頭悪いよね

    ;; ANSWER SECTION:
hp.com.			3600 IN	TXT "facebook-domain-verification=1f6jis8ngyl6xhtopb196nk2jzb6wm"
hp.com.			3600 IN	TXT "v=spf1 mx include:_spf.hp.com include:_spf.salesforce.com include:us._netblocks.mimecast.com" " include:spf.protection.outlook.com include:standardregisterSPF.smtp.com ip4:205.219.85.237 ip4:74.209.251.23 ip4:198.245.88.159 ip4:198.245.88.160 ip4:198.245.88.161 ip4:198.245.88.162 ~all"
hp.com.			3600 IN	TXT "adobe-sign-verification=8d7c98c65d9a78aa4fe83e40ac618269"
hp.com.			3600 IN	TXT "SFMC-ZWQ1KX6NcnbWgSDBdMcM5hev9zt7KIW2ujakv25u"
hp.com.			3600 IN	TXT "SFMC-z90jhAqnCFzmMAy46Qo1vy13u6YlOQ4afVWEPZmS"
hp.com.			3600 IN	TXT "SFMC-gC-INJ9awb38orE0daCKtYQOdTzA26V3zBYVruOP"
hp.com.			3600 IN	TXT "SFMC-TkI3rEvFMq3uO7c3713TrP-cg1S7j0K0iKyNVXIY"
hp.com.			3600 IN	TXT "SFMC-Gj1r4WT7h7LuH9CgR-ATrs4dQiyHzeRW5mkk_qg9"
hp.com.			3600 IN	TXT "SFMC-VXyPhU37JRfzHa1B_-XfXzHjl2WKI7af1rdKH-wR"
hp.com.			3600 IN	TXT "SFMC-MNg49ZTRiJXS6s5M39xVpTy1s_E-1IHXs9eMp9TV"
hp.com.			3600 IN	TXT "SFMC-aJMC0Gi9MPXTz-l4Iv3LtRXfhaeOB0OCsGwNXkzM"
hp.com.			3600 IN	TXT "SFMC-f7skz24QEr_YzGdBqMHR3sC2xGZPNQ3mZdXDFFow"
hp.com.			3600 IN	TXT "SFMC-CrddN9mLDmj3nCgVdj6F1xvJWHcDiUha4ypozOYM"
hp.com.			3600 IN	TXT "google-site-verification=lf2HoI19pw29dSNCWe1ex0zlgiGiMSUZjRWjW61SLXk"
hp.com.			3600 IN	TXT "C6ekla14kZc9ySs2tWLx5+qoT3uFAcPKfM9z8SnOjKPxduvwIiHCJI75yVt8cOynDwTRpNGAoAu7WBKTky3QhQ=="
hp.com.			3600 IN	TXT "google-site-verification=SYstg4r0qao99bYV9-4uWYGTHLSIL3Py60GZvR_OJ1c"
hp.com.			3600 IN	TXT "google-site-verification=K295XYTk_JOny2cGYgQiv5OBkqX-vsPbflRWCajmZmQ"
hp.com.			3600 IN	TXT "google-site-verification=7CCNFPK5u6aSDkOkTOxz_yOePZI8_thHJnaJl6EtSwk"
hp.com.			3600 IN	TXT "mongodb-site-verification=NNt4TMRanOtPk2qCvhWpTMXpY8SOb7BO"
hp.com.			3600 IN	TXT "atlassian-domain-verification=mjss59VLEmjHpiASn3FUy/Hfb/9QbLAAOR9fiqjavAJ6O1uCyNnChSTbNAxo7IIS"
hp.com.			3600 IN	TXT "google-site-verification=ior6EHEPCvMGbBIF1Cfzg3-yTDw30PaIbETytGrl1zY"
hp.com.			3600 IN	TXT "" "google-site-verification=iBm5BtEQIPx_1KICdm-iKrhED8pwZmS12JcztEGkEEw\"\"\""
hp.com.			3600 IN	TXT "google-site-verification=N-C2RScU5fi3a4_9J7hYoQhoL9H566pkx6gM8PI6Jqo"
hp.com.			3600 IN	TXT "google-site-verification=GdVvq6F-s2Vr-eD8eeZeo11J1HXnWdA2ZNM_M_IivjY"
hp.com.			3600 IN	TXT "google-site-verification=ajtjung8rHe1-msfHMrttoZdDlZeeoWJNpQ5jNZcqfo"
hp.com.			3600 IN	TXT "google-site-verification=ZKYzB8FoSfCdYZzesihRSd5OsBfrtDOvG6zrqYcMcd0"
hp.com.			3600 IN	TXT "docker-verification=ad83199a-7103-4f01-8acf-41979b12ba00"
hp.com.			3600 IN	TXT "teamviewer-sso-verification=9a8bdacd256d426aadef7c9435cc05f7"
hp.com.			3600 IN	TXT "teamviewer-sso-verification=14e16276afc843e58d056742e9f89d26"
hp.com.			3600 IN	TXT "atlassian-domain-verification=aD0fVXowmsHVk7AN3xQWoTk3fWQjFOAolW1g5Ae492aMfXofVIdEeASIKtjKtOjn"
hp.com.			3600 IN	TXT "hcp-domain-verification=d172505ee1cb87d71e2f402ab1e6123f01c858917022925ee9fe25ce1ea6a398"
hp.com.			3600 IN	TXT "asv=3ac585f916271e3615c45c5cc1c446af"
hp.com.			3600 IN	TXT "fastly-domain-delegation-ndopinwe32-10142022"
hp.com.			3600 IN	TXT "bv-domain-verification=ca416dec3e1078035e8f94141e8542a1207d3415febb81cdecc6f69d491ee03c"
hp.com.			3600 IN	TXT "airtable-verification=fd35e3a14eafa013a4ef8ec307159c57"
hp.com.			3600 IN	TXT "shopify-verification-code=U5Mvz3J5IScCrDvvcy49c7chv8Iwxp"
hp.com.			3600 IN	TXT "02.14.2024"
hp.com.			3600 IN	TXT "canva-site-verification=phuz1k47EJb7b9wGXtCeYw"
hp.com.			3600 IN	TXT "pendo-domain-verification=f79d1d3d-277a-4a70-982c-677c77a2f011"
hp.com.			3600 IN	TXT "Dynatrace-site-verification=fb0772f5-465e-4c26-9c6e-de883a321a31__ko3f16m3vui8oi46qls2l305im"
hp.com.			3600 IN	TXT "_ndgc16081saphv6ayms33rbsvl6rj68"
hp.com.			3600 IN	TXT "IQI2xT+r6hj2PuJ171J02xOMMXSUHl4I2VJ5a4CB2OsyfPJkfHXHbmJ5e2Ee6kbNjJQsERvcm3d4IeS2e7xPPQ=="
hp.com.			3600 IN	TXT "google-site-verification:2kiyv1SjebKUcEmaJ4QtapQe2EcbqPcYmhiJ-XJMZsY"
hp.com.			3600 IN	TXT "MS=ms38857149"
hp.com.			3600 IN	TXT "7155-7871-A6E8-AEB1-5764-4DE3-D4DD-6680"

;; Query time: 213 msec
;; SERVER: 15.72.96.180#53(ns1.hp.com) (TCP)
;; WHEN: Wed Dec 11 12:33:31 JST 2024
;; MSG SIZE  rcvd: 3477

    DNSSEC 推進のまやかし その3 : DNSSEC こそが毒入れ対策?

    DNSSEC を導入すれば良いのだというばかりで他の対策の啓発が行われていない。

    ドメインハイジャックも DNSSEC で守れるという嘘もある。(レンタルサーバは危険)

    以下に他の主なキャッシュポイズニング対策を記載する。

    DNSSEC を褒めてあげよう (ツンデレ)

    Unbound (1.22.0) や 9.9.9.9 の一部インスタンスで insecure.mufj.jp を引くと SERVFAIL になって引けない。 

    % dig insecure.mufj.jp +dnssec

; <<>> DiG 9.20.2 <<>> insecure.mufj.jp +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45047
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

% dig insecure.mufj.jp +dnssec +cd +noall +ans
insecure.mufj.jp.	60	IN	CNAME	www.e-ontap.com.
insecure.mufj.jp.	60	IN	RRSIG	CNAME 13 3 60 20371231000000 20211224060353 18023 mufj.jp. NszsqOsZNRFfiUBqH4USYMEaTOytdbXZe072KG5sc8xEZ8L5SZ54ia2P 06WIsNCb5qZEINBe+Q0CCmqB70zdkA==
www.e-ontap.com.	1800	IN	A	49.212.171.172

    これは初期の jp.sharp と同じ設定。insecure ゾーンに鍵と署名を含む mufj.jp ゾーンのコピーがある (つまり偽ゾーン)。但し mufj.jp ゾーンに insecure ゾーンの DS がなく本来なら insecure なゾーンのはずだが、RFC 4035 に以下の記述がありこれが insecure なゾーンでも機能したと考えられる。(詳しくは 2020 年の DNS温泉番外編in大阪 「否定応答がわからなくなる話」をどうぞ)

    RFC 4035 5.3.1. Checking the RRSIG RR Validity
(snip)
o The RRSIG RR’s Signer’s Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone’s apex DNSKEY RRset.
(snip)
Note that this authentication process is only meaningful if the validator authenticates the DNSKEY RR before using it to validate signatures.

    ちなみに Unbound のログには "debug: verify: could not find appropriate key" というエラーが出る。

    インチキ設定 (偽ゾーン) を見抜けた DNSSEC と Unbound は素晴らしい。他の実装はダメだけれど。

    まともでない DNS 運用にダメ出ししてくれるのは DNSSEC で唯一の褒められる点かもしれない。

    科学技術全般に言えること

    Tools for Conviviality

    終わり

    自分の頭で考えましょう

    void さんじゃないよ
    温泉でも入って