LPIC-3 Security331.4Weight 5BIND / DNSSECは実践
331.4 DNS and Cryptography
DNSSECを「暗号化DNS」と誤解しないところから始める。DNSの通常処理を土台に、署名・Chain of Trust・否定応答・BINDの署名/Validation運用へ進み、最後にCAA/DANE/TSIGとDoT/DoH/mDNSを位置付ける。
最終到達点：DNS Zone/RRを読み、KSK/ZSK・DNSKEY/DS/RRSIG/NSEC/NSEC3を使ったChainを説明できる。BINDでSigned Zoneを提供・再署名・Rolloverし、Recursive Validationを設定・切り分けできる。CAA/DANE/TLSAとTSIGを実際のRecord/設定へ落とし込める。
Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は 末尾の問題へ。
DNSの土台Zone / RR / Authoritative / Recursiveを先に固定。
DNSSECDNS Dataへ署名し、真正性・完全性を検証。
BIND運用Key生成・署名・Rollover・Validation・Troubleshoot。
周辺技術CAA / DANE / TSIG / DoT / DoH / mDNS。
01 DNS基礎02 DNSSEC/KSK/ZSK03 DNSKEY/DS/RRSIG04 NSEC/NSEC305 Key/署名06 Authoritative07 運用/障害08 Validation09 CAA/DANE10 TSIG/Awareness
深度：DoT/DoH/mDNSはAwareness。逆にAuthoritative BIND、Signed Zone管理、Recursive Validation、CAA/DANE publishing、TSIGは設定・利用まで要求される。
331.4 · 01/1001 DNS Foundation
🟡 UnderstandDNS / Zone / RR
DNSSECの前にDNSを固定する：Zone・RR・Authoritative・Recursive
このページの到達点：DNS QueryがRecursive ResolverからAuthoritative Serverへ進む位置関係を説明し、ZoneとResource Recordを混同しない。
公式要求：Understand the concepts of DNS, zones and resource records.
通常DNSの流れ
Client
↓ query: www.example.test A
Recursive Resolver
↓ 必要ならRoot/TLD/Authoritativeを辿る
Authoritative Server for example.test
↓ Zone内のRRを回答
A / AAAA / MX / NS / SOA ...
↓
ClientへResponse
Zone
あるDNS Name Spaceの管理単位。例：
example.test Zone。RR
Resource Record。Zone内の個々のData。Name / TTL / Class / Type / RDATA等からなる。
Authoritative Server
自分が権威を持つZone Dataを回答するServer。
Recursive Resolver
Clientの代わりに他Serverを辿り、最終回答を取得・CacheするServer。
RRを「種類 → 何を表す」で読む
| RR | 主な役割 |
|---|---|
| A / AAAA | Name → IPv4 / IPv6 Address |
| NS | Zoneを担当するName Server |
| SOA | ZoneのAuthority/Serial/Timer等 |
| MX | Mail Exchanger |
| TXT | Text Data。各種Policy情報等にも利用 |
DNSSECで変わるのは「DNS Dataを秘密にすること」ではない。通常DNSのRRに署名・検証用RRを追加し、受け取ったDataが正しいか検証できるようにする。
EXAM DECISION
まず役割を分ける
- Zone Dataを持つ → Authoritative
- Clientの代わりに辿る → Recursive
- Zone内の個別Data → Resource Record
331.4 · 02/1002 DNSSEC / Keys
🟡 UnderstandKSK / ZSK
DNSSECは「署名されたDNS Dataを検証する」仕組み
このページの到達点：DNSSECが真正性・完全性を提供する仕組みを説明し、KSKとZSKを「何へ署名するか」で区別できる。
公式要求：Understand DNSSEC, including key signing keys and zone signing keys.
通常RRset (A / MX / NS ...)
↓ ZSKのPrivate Keyで署名
RRSIG
↓ DNSKEY(ZSK Public Key)で検証
DNSKEY RRset
↓ KSKのPrivate Keyで署名
RRSIG
↓ KSK DNSKEYを親ZoneのDSへ結ぶ
↓
Root Trust AnchorまでChain
ZSK = Zone Signing Key
主にZone内の各RRsetへ署名するKey。公開側はDNSKEYとしてZoneに載る。
KSK = Key Signing Key
主にDNSKEY RRsetへ署名し、親ZoneのDSとのChainを作るKey。
なぜ2種類？
KSKとZSKを分ける伝統的な運用では、頻繁に使うZone署名Keyと、親ZoneのDS更新に関係するKeyを分離できる。現在はCSK等のPolicyもあるが、303ではKSK/ZSKの役割区別が公式範囲。
KSKとZSKを分ける伝統的な運用では、頻繁に使うZone署名Keyと、親ZoneのDS更新に関係するKeyを分離できる。現在はCSK等のPolicyもあるが、303ではKSK/ZSKの役割区別が公式範囲。
DNSSECとDoT/DoHを混同しない
| 守る対象 | 秘密になる? | |
|---|---|---|
| DNSSEC | DNS Dataの真正性・完全性 | 通常のDNS Data自体を暗号化しない |
| DoT / DoH | Client/Resolver等のTransport | 通信路を暗号化する |
EXAM DECISION
Key名ではなく署名対象を見る
- Zone RRsetを署名 → ZSK
- DNSKEY RRsetを署名 → KSK
- DNS内容の秘匿 → DNSSECの主目的ではない
331.4 · 03/1003 DNSSEC Records
🟡 UnderstandDNSKEY / DS / RRSIG
DNSKEY・DS・RRSIGをChain of Trustとして読む
このページの到達点：DNSKEY、DS、RRSIGを「Public Key・親との接続・署名」の3役に分け、Parent→Childの検証関係を追える。
公式要求：Understand DNSSEC records including DS, DNSKEY and RRSIG.
ParentからChildへ信頼をつなぐ
Parent Zone
└─ DS(example.test)
↓ Child KSK DNSKEYのDigest/Key Tag等
Child Zone: example.test
├─ DNSKEY(KSK / ZSK)
├─ RRSIG(DNSKEY) ← KSKで署名
└─ A/MX/... + RRSIG ← ZSKで署名
DNSKEYZoneのDNSSEC Public Keyを公開。Flag 257はKSKとしてよく見られ、256はZSKとしてよく見られる。
DSDelegation Signer。Parent Zoneに置き、ChildのDNSKEYと親の信頼を結ぶ。
RRSIG対象RRsetのDigital Signature。どのAlgorithm/Key Tagで署名したか等を持つ。
DSはCertificateそのものではない
DSはChild KSK DNSKEYの情報をHash等で表し、Parent Zoneへ置く。ResolverはParent側DSとChild側DNSKEYの対応を確認してChainを下へ進める。
example.test. 3600 IN DNSKEY 257 3 8 (...KSK public key...)
example.test. 3600 IN DS 54321 8 2 ABCD...
www.example.test. 300 IN A 192.0.2.10
www.example.test. 300 IN RRSIG A 8 3 300 ... 12345 example.test. ...
読む位置：DNSKEYはPublic Key、DSはParent側の接続情報、RRSIGはRRsetに対する署名。例では
54321がKSK側、AのRRSIGにある12345はZSK側のKey Tagという想定。Key Tagで「どのDNSKEYで署名したか」を結び付ける。EXAM DECISION
3語を役割で固定
- Public Keyを公開 → DNSKEY
- ParentからChildへつなぐ → DS
- RRsetの署名 → RRSIG
331.4 · 04/1004 Negative Answers
🟡 UnderstandNSEC / NSEC3
「存在しない」を署名付きで証明する：NSEC / NSEC3 / NSEC3PARAM
このページの到達点：NXDOMAIN等の否定応答でもDNSSECが必要な理由を説明し、NSECとNSEC3、NSEC3PARAMの役割を区別できる。
公式要求：Understand NSEC, NSEC3 and NSEC3PARAM.
Query: nohost.example.test A
↓
「そんなNameは存在しない」
↓ でも攻撃者が偽のNXDOMAINを返した可能性は?
Authenticated Denial of Existence
├─ NSEC → 存在Nameの並び/Typeを使って範囲を証明
└─ NSEC3 → NameをHashした値で同様の否定証明
↑
NSEC3PARAM
Hash Algorithm / Iterations / Salt等
NSEC
次に存在するNameとType Bitmap等を示し、「この間にNameはない」を証明。Zone walkingでNameを列挙しやすい面がある。
NSEC3
NameをHashして否定証明。単純なZone walkingを難しくするが、Zone内容を完全に秘密にする仕組みではない。
NSEC3PARAM：NSEC3で使うHash Algorithm、Flags、Iterations、Salt等のParameterをZone側で示すRR。NSEC3の「証明結果」そのものではない。
EXAM DECISION
否定応答に注目
- 存在しないことの証明 → NSEC / NSEC3
- NSEC3のParameter → NSEC3PARAM
- NSEC3 = DNS Data暗号化、ではない
331.4 · 05/1005 Key / Sign
🔴 Configure / Managednssec-keygen / signzone
Authoritative実践①：KSK/ZSKを生成しZoneを署名する
このページの到達点：
dnssec-keygenでZSK/KSKを生成し、dnssec-signzoneでSigned Zoneを作り、dnssec-dsfromkeyでParentへ渡すDSを生成できる。公式要求：Manage signed zones including key generation and re-signing. Partial utilities: dnssec-keygen, dnssec-signzone, dnssec-dsfromkey.
実習環境：このNotebook生成環境にはBIND utilitiesが入っていないため、掲載CommandはISC BIND 9 documentationと照合している。実際のZone DataはTraining環境で実行する。
1. 最小Zone Fileを用意
$TTL 300
@ IN SOA ns1.example.test. admin.example.test. (
2026082801 3600 900 604800 300 )
IN NS ns1.example.test.
ns1 IN A 192.0.2.53
www IN A 192.0.2.10
2. ZSK / KSKを生成
mkdir -p keys
# ZSK
ZSK=$(dnssec-keygen -K keys \
-a RSASHA256 -b 2048 example.test)
# KSK
KSK=$(dnssec-keygen -K keys \
-a RSASHA256 -b 2048 -f KSK example.test)
echo "$ZSK"
echo "$KSK"
-K keysKey Fileの出力Directory。
-a RSASHA256このTraining例で使うAlgorithm。試験では個別Algorithm暗記よりKSK/ZSKとToolの役割を優先。
-f KSKKSK Flagを付ける。指定しない通常KeyをZSKとして使う。
Kexample.test.+008+12345.key ← Public DNSKEY RR
Kexample.test.+008+12345.private ← Private signing material
3. ZoneへDNSKEYを含めて署名
cat keys/$ZSK.key keys/$KSK.key >> db.example.test
dnssec-signzone \
-o example.test \
-f db.example.test.signed \
db.example.test \
keys/$ZSK.key keys/$KSK.key
署名前
A / NS / SOA等
A / NS / SOA等
→
署名後
DNSKEY / RRSIG / NSEC等を含むSigned Zone
DNSKEY / RRSIG / NSEC等を含むSigned Zone
4. KSKからParent用DSを作る
dnssec-dsfromkey -2 keys/$KSK.key
重要：Child Zoneを署名しただけではInternet上のChainは完成しない。生成したDS相当情報をParent Zoneへ登録して、Parent→ChildのTrustをつなぐ。
EXAM DECISION
Toolを工程に置く
- Key生成 → dnssec-keygen
- Zone署名 → dnssec-signzone
- KSKからDS生成 → dnssec-dsfromkey
331.4 · 06/1006 Authoritative BIND
🔴 Configure / Troubleshootnamed.conf / dig / delv
Authoritative実践②：Signed ZoneをBINDでServeし、答えを検証する
このページの到達点：
named.confでSigned ZoneをLoadし、rndcでReloadし、dig/delvでDNSKEY・RRSIG・署名状態を切り分けられる。公式要求：Configure and troubleshoot BIND as an authoritative name server serving DNSSEC secured zones. Partial: named.conf, rndc, dig, delv.
Signed Zoneを指定
zone "example.test" {
type master;
file "/etc/bind/zones/db.example.test.signed";
};
type master：古くからのBIND設定名。新しいBINDではtype primaryも同義として利用できるが、試験対象がBIND 9.7以上なので教材例は広いVersionで読めるmasterを使う。Manual Signing方式：この例では
dnssec-signzoneが生成したSigned Zone FileをBINDへ読ませる。現代BINDにはdnssec-policyによる自動運用もあるが、303公式Partial utilitiesの関係を理解するためManual Flowを使う。# Config変更なら
rndc reconfig
# Zone File更新後なら
rndc reload example.test
# BIND設定/Zone FileのSyntaxを先に確認する補助Tool
named-checkconf
named-checkzone example.test /etc/bind/zones/db.example.test.signed
補助Tool：
named-checkconf/named-checkzoneはLPIのPartial listに明記された項目ではないが、Authoritative BINDのTroubleshootingで「設定自体が壊れていないか」を先に切るのに有用。digは「何をRequestしたか」と「何が返ったか」を見る
dig @192.0.2.53 example.test DNSKEY +dnssec
dig @192.0.2.53 www.example.test A +dnssec
;; ANSWER SECTION:
www.example.test. 300 IN A 192.0.2.10
www.example.test. 300 IN RRSIG A ...
+dnssec：DNSSEC関連DataをRequestするDO bitを使う。RRSIGが返ることは「署名Dataを受け取った」確認にはなるが、そのdig自身が完全なChain Validationをしたことと同義ではない。delvはValidation視点で見る
# delvはTrust Anchorを使ってValidationする
# Public DNSSEC Zoneや、Trust Anchorを構成したLabで確認
delv example.com A
使い分け：
digはAuthoritative Response/RR/Flagの観測に向く。delvはTrust Anchorを使ったDNSSEC Validation Toolなので、StandaloneなPrivate ZoneをAuthoritative Serverへ直接QueryするだけではChain検証は完成しない。よくある原因：Signed Fileを指定していない／署名期限切れ／Parent DSとChild DNSKEY不一致／Firewall等でTCP/UDP 53が通らない。DNSSECだけでなく通常DNSのSOA/NS/Aが正しいかも先に確認する。
EXAM DECISION
Authoritative側の切り分け
- Config読み直し → rndc reconfig
- Zone再読込 → rndc reload
- RR/RRSIGを観測 → dig +dnssec
- Validation観点 → delv
331.4 · 07/1007 Rollover / Troubleshoot
🔴 Managednssec-settime / re-sign
DNSSEC運用：Rollover・Re-sign・期限切れを「時間の状態」として管理する
このページの到達点：ZSK/KSK Rolloverの違いを説明し、
dnssec-settimeでKey timing metadataを扱い、Zone変更/署名期限切れ時に再署名できる。公式要求：Manage signed zones including key rollover and re-signing. Partial: dnssec-settime, rndc.
新Key生成→Publish→Activate→旧Key Inactive→Delete
Publish
DNSKEYをZoneへ公開し、Cache/Resolverが新Keyを見られる状態。
Activate
新Keyを実際の署名に使い始める時点。
Inactive
旧Keyで新しい署名を作らなくする時点。
Delete
安全な待機後にDNSKEY公開から外す時点。
# 例：Key timing metadataを設定
# 実運用ではTTL/署名寿命/Parent更新時間を考えて日時を設計する
dnssec-settime \
-P now \
-A now+1d \
-I now+31d \
-D now+38d \
Kexample.test.+008+12345
ZSK Rollover
Zone署名Keyの交代。新ZSKを事前Publishし、Cacheを考慮してActivate/旧Key停止へ進む。
KSK Rollover
Parent ZoneのDS更新と協調が必要。新KSKだけ入れ替えてParent DSが旧KeyのままだとChainが壊れる。
Zone Dataを変えたら再署名
dnssec-signzone \
-o example.test \
-f db.example.test.signed \
db.example.test \
keys/$ZSK.key keys/$KSK.key
rndc reload example.test
典型症状：通常のA RecordはあるのにValidating Resolverでは
SERVFAIL。→ RRSIG期限、DNSKEY/DS、Clock、署名Fileの更新漏れを確認。EXAM DECISION
KSKだけParentが絡む
- 署名期限/Zone更新 → Re-sign
- Key交代のTiming → dnssec-settime
- KSK変更 → Parent DS更新まで追う
331.4 · 08/1008 Recursive Validation
🔴 ConfigureValidating Resolver
Recursive BINDは「署名を作る」のではなくClientの代わりに検証する
このページの到達点：Authoritative DNSSECとRecursive Validationを区別し、
dnssec-validation autoの意味、AD Flag、Validation FailureのSERVFAILを説明できる。公式要求：Configure BIND as a recursive name server that performs DNSSEC validation on behalf of its clients.
Client
↓ www.example.test?
Validating Recursive Resolver
├─ A + RRSIG取得
├─ DNSKEY取得
├─ Parent DS取得
├─ Root Trust Anchorまで検証
└─ ValidならAnswer / BogusならSERVFAIL
↓
Client
named.conf
options {
recursion yes;
dnssec-validation auto;
};
Private Lab注意：
example.testのような閉じたTraining ZoneはPublic RootにDSがないため、dnssec-validation autoだけでそのZoneのChainが自動完成するわけではない。実際にLabでValidationするなら、親Zoneまで構築するか、Training用Trust Anchorを明示する。| 値 | 意味 |
|---|---|
auto | Validation有効。BINDに含まれるRoot Trust Anchorを利用し、自動管理する代表設定。現行BINDではDefault。 |
yes | Validation有効だがTrust Anchorを手動で用意する必要がある。 |
no | DNSSEC Validationを無効化。 |
Client側から確認
dig @192.0.2.54 www.example.test A +dnssec
# Public DNSSEC Zoneをdelv自身でも検証する例
delv example.com A
;; flags: qr rd ra ad; ...
AD = Authenticated Data：QueryしたResolverがDataをDNSSECでValidと判断したことを示すFlag。AuthoritativeからRRSIGが返っただけ、とは意味が違う。
Validation Failure：署名期限切れ・DS/DNSKEY mismatch等でBogusなら、Validating Resolverは通常
SERVFAILをClientへ返す。単純な「DNS Server故障」と決めつけずDNSSECを疑う。EXAM DECISION
署名側と検証側を分ける
- ZoneへRRSIGを作る → Authoritative側
- RootまでChainを検証 → Recursive Resolver側
- 検証済みAnswerの目印 → AD Flag
331.4 · 09/1009 CAA / DANE
🔴 Understand + UseCAA / TLSA
CAA / DANE：X.509とDNSを「発行許可」と「TLSA情報」で結び付ける
このページの到達点：CAAとDANE/TLSAを区別し、CAA RecordとTLSA Recordを読み書きできる。TLSAのAssociation DataをOpenSSLで作る考え方を説明できる。
公式要求：Understand CAA and DANE including CAA/TLSA records. Use CAA and DANE to publish X.509 certificate and CA information in DNS. Partial: openssl.
CAA
Certification Authority Authorization。Domain Ownerが「どのCAにCertificate発行を許可するか」をDNSへ示す。
DANE / TLSA
DNSSECで保護されたDNSへTLS Certificate/Public Key等との関連情報を公開する。代表RRがTLSA。
CAA Record
example.test. 300 IN CAA 0 issue "letsencrypt.org"
example.test. 300 IN CAA 0 issuewild "letsencrypt.org"
example.test. 300 IN CAA 0 iodef "mailto:pki@example.test"
issue
通常Certificateを発行してよいCAを指定。
issuewild
Wildcard Certificateを発行してよいCAを指定。
iodef
Policy違反等のReport先を指定。
TLSA Recordは4 Fieldを読む
_443._tcp.www.example.test. 300 IN TLSA 3 1 1 ABCD...
| Field | 例 | 意味 |
|---|---|---|
| Certificate Usage | 3 | DANE-EE等、PKIXとの関係/検証Model |
| Selector | 1 | Certificate全体かSubjectPublicKeyInfo等のどこを使うか |
| Matching Type | 1 | Exact / SHA-256 / SHA-512等の照合方法 |
| Association Data | ABCD... | 選択対象のDataまたはDigest |
# Selector=1 (SPKI), Matching=1 (SHA-256) のAssociation Data例
openssl x509 -in server.crt -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -binary \
| xxd -p -c 256
xxdは表示補助：TLSAのAssociation Dataへ載せるSHA-256 DigestをHex文字列として出すために使っている。331.4の主要Utilityとして暗記する対象ではない。DANE前提：TLSA自体をDNSSECで検証できなければ、攻撃者がTLSAを書き換えられるため信頼の土台にならない。
EXAM DECISION
発行許可かTLS接続情報か
- どのCAが発行してよい? → CAA
- Certificate/Public Key等をDNSSECと結ぶ → DANE/TLSA
- TLSAのService名 →
_port._tcp.hostname等
331.4 · 10/1010 TSIG / Awareness
🔴 Use TSIG⚪ DoT/DoH/mDNS Awareness
TSIGはDNS Messageを共有鍵で認証する。DoT/DoH/mDNSとは役割が別
このページの到達点：TSIG KeyをBIND設定へ組み込みZone Transfer等を認証する構造を説明し、DoT/DoH/mDNSをAwarenessレベルで識別できる。
公式要求：Use TSIG for secure communication with BIND. Awareness of DNS over TLS, DNS over HTTPS and Multicast DNS.
Primary BIND Secondary / Client
shared TSIG secret ←────────────→ same secret
↓ DNS MessageへMAC
AXFR / UPDATE等
↓
相手が「同じSecretを持つ正規Peerか」検証
TSIG = Transaction Signature。共有Secretを使うMessage Authentication。DNSSECの「Zone Dataを公開鍵で署名してResolverが検証」とは別の仕組み。
Training用Key File
# 共有Secretを作る例
openssl rand -base64 32
# /etc/bind/xfr.key
key "xfr-key" {
algorithm hmac-sha256;
secret "BASE64_SECRET";
};
named.confでZone TransferをTSIGへ限定
include "/etc/bind/xfr.key";
zone "example.test" {
type master;
file "/etc/bind/zones/db.example.test.signed";
allow-transfer { key "xfr-key"; };
};
# TSIG Key Fileを使ってAXFR Test
dig @192.0.2.53 example.test AXFR \
-k /etc/bind/xfr.key
Secret管理：TSIGは共有鍵方式なのでKey FileのPermission/配布を保護する。Command LineへSecret本文を直接書くよりKey File利用の方が扱いやすい。
Awareness 3項目
| 技術 | 最低限の識別 |
|---|---|
| DoT / DNS over TLS | DNSをTLS Transportで保護。一般に専用Port 853が知られる。 |
| DoH / DNS over HTTPS | DNS Query/ResponseをHTTPS Transportで運ぶ。 |
| mDNS / Multicast DNS | 通常のUnicast DNS Serverを介さずLocal Link上でMulticastを使って名前解決。.localで広く利用。 |
331.4 EXIT CHECK
Zone / RR / Authoritative / Recursiveを区別✓
KSK/ZSKとDNSKEY/DS/RRSIGをChainで説明✓
NSEC/NSEC3/NSEC3PARAMを区別✓
dnssec-keygen/signzone/dsfromkey/settime/rndcを工程へ配置✓
Recursive ValidationとAD/SERVFAILを説明✓
CAA/DANE/TLSAをRecordで判断✓
TSIGとDNSSECを区別✓
DoT/DoH/mDNSはAwareness✓
331.4 COMPLETE
DNSSECは「署名 → Chain → Validation → 運用」まで一続き
- Authoritativeで署名を提供
- Parent DSでChainをつなぐ
- Recursive ResolverがClientの代わりに検証
- Rollover/Re-signで時間変化を管理
- CAA/DANE/TSIGはそれぞれ別の目的
次に334.1へ進む理由： 331でKey・Certificate・暗号・DNS Trustまで作ったので、ここからNetwork上の「誰を認証するか」「何が流れているか」を観測する側へ視点を移す。
331.4 DNSSEC · CHECKPOINTObjective末尾
Weight 5客観判定50 → 75 → 100%
331.4 DNSSEC：学習直後にここで解く
本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。
合格条件： 50%は基礎選択式9問中8問以上、75%は選択肢なし再現9問中8問以上。75%到達から72時間後、専用実戦Bankから11問中10問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。
現在の到達度
選択式から開始
0%
小テーマ別履歴問題を解くと正答率を表示
Objective Check
100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当20問から出題する。各問は複数知識・近い誤答・設定/出力/状況判断のいずれかを含み、誤答時は全選択肢の違いまで確認する。
出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。実試験の出題再現ではないが、固定問題の暗記だけでは突破しにくい構成にする。