miyuki – セキュリティエンジニアの雑多ブログ

DNSSEC検証 DNSSEC破壊・検証編

miyuki — Sat, 12 Sep 2026 13:24:46 +0000

はじめに

何をしたいか

DNSSECの信頼の連鎖を実際に構築し、DNS応答がどのように署名・検証されるのかを確認する。また、DNSSECに関する設定や署名を意図的に破壊し、検証失敗時にフルリゾルバやクライアントからどのように見えるのかを確認する。
前回の「DNSSEC構築編」では、Parent DNSとChild DNSにDNSSECを導入し、UnboundにTrust Anchorを設定することで、lab.test から child.lab.test までの信頼の連鎖を構築した。
本記事では、構築したDNSSEC環境を意図的に破壊し、署名の不整合や信頼の連鎖の破損が発生した際に、UnboundによるDNSSEC検証およびClientからの名前解決がどのような結果になるのかを確認する。

準備・DNS構築編　https://cybermemo.blog/dnssec-lab-setup
DNSSEC構築編　https://cybermemo.blog/dnssec-lab-configuration
DNSSEC破壊・検証編　本記事

本記事で検証する構成

前回構築したDNSSEC環境を使用し、DNSSECに関する設定やDNSデータを意図的に変更して検証を行う。
正常な状態では、Unboundに設定した lab.test のTrust Anchorを起点として、Parent DNSのDNSKEY、Child DNSのDS・DNSKEY、各RRsetのRRSIGへと信頼の連鎖が成立している。
本記事では、この正常な状態を基準としてDNSSECを意図的に破壊し、正常時と異常時の応答を比較する。

              ┌─────────────┐
              │ Parent DNS  │　192.168.56.10/24
              │    BIND9    │　権威ゾーン: lab.test
              │             │　DNSKEY / RRSIG
              └──────┬──────┘
                     │
            child.lab.test を委任
              ＋ DSレコード
                     │
                     ▼
              ┌─────────────┐　192.168.56.20/24
              │  Child DNS  │　権威ゾーン: child.lab.test
              │    BIND9    │　DNSKEY / RRSIG
              │             │　└─ www.child.lab.test → 192.168.56.100
              └─────────────┘
                     ▲
                     │ DNS問い合わせ
                     │ ＋ DNSSEC署名情報
                     │
              ┌─────────────┐
              │  Resolver   │ 192.168.56.30/24
              │   Unbound   │ DNSSEC検証
              │             │ Trust Anchor: lab.test
              └──────┬──────┘
                     ▲
                     │ DNS問い合わせ
                     │
              ┌─────────────┐
              │   Client    │ 192.168.56.40/24
              └─────────────┘

【正常時のDNSSECの信頼の連鎖】

Trust Anchor
（lab.test KSK / DNSKEY）
        │
        ▼
lab.test DNSKEY RRset
        │
        │ ParentのDSによってChild KSKを信頼
        ▼
child.lab.test DNSKEY RRset
        │
        │ Child ZSKの公開鍵でRRSIGを検証
        ▼
www.child.lab.test A

検証環境

仮想化ソフトウェア：Oracle VirtualBox
ゲストOS：Ubuntu Server 26.04.1 LTS（amd64）
権威DNS：BIND 9.20.24
フルリゾルバ：Unbound 1.24.2
DNS確認ツール：DiG 9.20.24
内部ネットワーク：192.168.56.0/24
検証ドメイン：lab.test / child.lab.test

検証

検証1：署名済みAレコードを改ざんし、DNSSEC検証失敗を確認する

本検証では、攻撃者などによって署名済みDNSデータが改ざんされた状況を模擬するため、Child DNSのAレコードを変更し、A RRsetに対応するRRSIGは更新しない。これにより、RRsetとRRSIGが不整合となった際にUnboundがどのように検知するかを確認する。

署名済みファイルのAレコードを直接変更

Child DNS で作業。

# www.child.lab.test. 3600 IN A 192.168.56.100 → www.child.lab.test. 3600 IN A 192.168.56.200
# Serialを変更
$ sudo vim /etc/bind/db.child.lab.test.signed
※一部抜粋
; File written on Wed Sep  9 13:25:36 2026
; dnssec-signzone version 9.20.24-1ubuntu0.3-Ubuntu
child.lab.test.         3600    IN SOA  ns.child.lab.test. dnsmaster.child.lab.test. (
                                        2026091001 ; serial
（中略）
www.child.lab.test.     3600    IN A    192.168.56.200
                        3600    RRSIG   A 13 4 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuS
                                        mi+J8jcqgW8NQhR+Fi8sFaHbAEZuw691gEoZ
                                        22rXmWlCL5sbOQ== )

今回の検証の構成は下記。

署名時
www.child.lab.test A 192.168.56.100
              │
              └── ZSKで署名
                       ↓
                    RRSIG A

                ↓ Aレコードを改ざん

www.child.lab.test A 192.168.56.200
                    +
以前の192.168.56.100に対するRRSIG
                    ↓
                 不一致

BINDに改ざん後のゾーンを読み込ませる

# reload
$ sudo rndc reload child.lab.test

# Serialを確認
$ sudo rndc zonestatus child.lab.test
name: child.lab.test
type: primary
files: /etc/bind/db.child.lab.test.signed
serial: 2026091001
nodes: 3
last loaded: Thu, 10 Sep 2026 13:24:27 GMT
secure: yes
inline signing: no
key maintenance: none
next resign node: ns.child.lab.test/NSEC
next resign time: Fri, 02 Oct 2026 12:25:36 GMT
dynamic: no
reconfigurable via modzone: no

# Childが改ざん後のデータを配信していることを確認
$ dig +dnssec @192.168.56.20 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.20 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65390
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 194a0690a20c4f2e010000006aa2b07b18a3ea84a17f5fad (good)
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:
www.child.lab.test.     3600    IN      A       192.168.56.200
www.child.lab.test.     3600    IN      RRSIG   A 13 4 3600 20261009122536 20260909122536 7661 child.lab.test. XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuSmi+J8jcqgW8NQhR+Fi8s FaHbAEZuw691gEoZ22rXmWlCL5sbOQ==

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Thu Sep 10 13:28:27 UTC 2026
;; MSG SIZE  rcvd: 201

Client → Unbound で確認

# Resolverで作業。キャッシュ削除
$ sudo unbound-control flush_zone child.lab.test

# Clientで作業。
$ dig +dnssec @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32814　　# status: SERVFAIL,　ANSWER: 0 = 問い合わせ失敗
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1　　# 正常時に存在していた ad フラグなし

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; Query time: 21 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Thu Sep 10 13:32:32 UTC 2026
;; MSG SIZE  rcvd: 47

# ジャーナル確認
$ sudo journalctl -u unbound --since "2 minutes ago" > log
$ grep -E "validated DS|validated DNSKEY|signature mismatch|failed ANSWER|bad rrsets" log
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validated DS child.lab.test. DS IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validated DNSKEY child.lab.test. DNSKEY IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] debug: verify: signature mismatch
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: validator: response has failed ANSWER rrset: www.child.lab.test. A IN
Sep 10 13:44:58 resolver unbound[1538]: [1538:0] info: Validate: message contains bad rrsets

下記の流れでエラー発生。

Client
   │
   ▼
Unbound
   │
   │ www.child.lab.test A = 192.168.56.200
   │ RRSIG A = 以前の署名
   │
   ▼
Child ZSKの公開鍵（DNSKEY）でRRSIGを検証
   │
   └── ✕ 署名が一致しない
          │
          ▼
        Bogus
          │
          ▼
       SERVFAIL

ジャーナルから読み取れる挙動は下記。

validated DS
    ↓
ChildのDSは正常

validated DNSKEY
    ↓
ChildのDNSKEYも正常

signature mismatch
    ↓
AレコードとRRSIGが一致しない

failed ANSWER rrset
    ↓
www.child.lab.test のA RRsetを検証できない

bad rrsets
    ↓
DNSSEC検証失敗

検証結果

Resolverのキャッシュを削除した後、ClientからUnboundを経由して www.child.lab.test のAレコードを問い合わせた。結果は SERVFAIL となり、ANSWER SECTIONは0件だった。また、正常時に存在していた ad フラグも付与されていない。これにより、AレコードとRRSIGが不整合な状態では、UnboundがDNSSEC検証を正常に完了できないことを確認した。

検証2：DSレコードを不整合にする

本検証では、Parent DNSに登録されている child.lab.test のDSレコードを意図的に変更し、Child DNSのKSKと不整合な状態を作成する。これにより、ParentからChildへの信頼の連鎖が成立しなくなった際に、Unboundがどのように検知するかを確認する。

Parent DNSのDSレコードを変更

Parent DNS で作業。

# 元ゾーンのDSを確認
$ grep " IN DS " /etc/bind/db.lab.test
child       IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5D

# Serialを変更
# digestの最後の1文字だけ変更　D → E
$ sudo vim /etc/bind/db.lab.test
2026091201 ; Serial
child       IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5E

# ファイル確認
$ cat /etc/bind/db.lab.test
$TTL 3600

@   IN  SOA ns dnsmaster (
        2026091201 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN  NS  ns.lab.test.

ns  IN  A   192.168.56.10

child       IN NS ns.child
ns.child    IN A  192.168.56.20
child       IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5E
; This is a key-signing key, keyid 25095, for lab.test.
; Created: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Publish: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Activate: 20260910122739 (Thu Sep 10 12:27:39 2026)
lab.test. IN DNSKEY 257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ==
; This is a zone-signing key, keyid 42600, for lab.test.
; Created: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Publish: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Activate: 20260910122712 (Thu Sep 10 12:27:12 2026)
lab.test. IN DNSKEY 256 3 13 XGx8XP7w7bqg8k9cBXoPvDLsZQFUOAuUbdr8Bd8ZSH25ip1Bq75BGFYO yZhxy0DNqEsEPPpDt2qHAW/kdlJs3g==

ここで作った状態は下記。

Child KSK
    │
    └─ 本来のSHA-256 digest
             ↓
        ...2742BF5D

Parentに登録したDS
             ↓
        ...2742BF5E
             ↑
          不一致

変更後のDSレコードを含むParentゾーンを再署名

# ゾーンファイルを確認
$ sudo named-checkzone lab.test /etc/bind/db.lab.test

# Parentゾーンを再署名
$ cd /etc/bind/keys/lab.test
$ sudo dnssec-signzone \
  -S \
  -o lab.test \
  -f /etc/bind/db.lab.test.signed \
  /etc/bind/db.lab.test
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db.lab.test.signed

改ざん後のDSに対して新しいRRSIG DSが生成される。

偽DS
  │
  └─ Parent ZSKで正常に署名
             ↓
       RRSIG DSは正常

しかし

偽DS
  ↕　一致しない　　　　　　
Child KSK

BINDに再署名後のゾーンを読み込ませる

$ sudo rndc reload lab.test
$ sudo rndc zonestatus lab.test
name: lab.test
type: primary
files: /etc/bind/db.lab.test.signed
serial: 2026091201
nodes: 4
last loaded: Sat, 12 Sep 2026 10:49:13 GMT
secure: yes
inline signing: no
key maintenance: none
next resign node: lab.test/DNSKEY
next resign time: Mon, 05 Oct 2026 09:49:13 GMT
dynamic: no
reconfigurable via modzone: no

# 変更後のDSレコードとRRSIGを確認
$ dig +dnssec +norecurse @192.168.56.10 child.lab.test DS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec +norecurse @192.168.56.10 child.lab.test DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7197
;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: c5bb3449b7fa9da2010000006aa53041466bb4c96a8f1c6c (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      DS

;; ANSWER SECTION:
child.lab.test.         3600    IN      DS      26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F653 2742BF5E　　# D → E に変更されている
child.lab.test.         3600    IN      RRSIG   DS 13 3 3600 20261012094913 20260912094913 42600 lab.test. BI3iajICF5rg6gHFcItF2XATrIZuHwPiGrBnNN/Bde02gBYnc8n62dI0 N8K3+/7d6wECpKNOjFcsUwBcnfhkQA==

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Sat Sep 12 10:58:09 UTC 2026
;; MSG SIZE  rcvd: 223

Child KSKから生成されるDSとの不一致を確認する

Child DNS で作業。

# Child KSK側の設定を確認
$ cd /etc/bind/keys/child.lab.test
$ dnssec-dsfromkey -2 Kchild.lab.test.+013+26145.key
child.lab.test. IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5D

Client → Unbound で確認

# キャッシュ削除(Resolverで作業)
$ sudo unbound-control flush_zone lab.test

# Clientから確認
$ dig +dnssec @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; Query time: 17 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Sat Sep 12 11:06:35 UTC 2026
;; MSG SIZE  rcvd: 47

# ジャーナル確認　※ログは一部抜粋
$ sudo journalctl -u unbound --since "2 minutes ago" > log
$ grep -Ei "DS|DNSKEY|bogus|fail|mismatch|validate|bad|key" log
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: adding trusted key lab.test. DNSKEY IN
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: validator operate: query . DNSKEY IN
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: resolving . DNSKEY IN
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] debug: request has exceeded the maximum number of sends with 33
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] debug: return error response SERVFAIL
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: iterator operate: query . DNSKEY IN
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: processQueryTargets: . DNSKEY IN
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] debug: Failed to get a delegation, giving up
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] debug: return error response SERVFAIL
Sep 12 11:11:01 resolver unbound[1661]: [1661:0] info: validator operate: query . DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: generate keytag query _ta-6207.lab.test. NULL IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validator operate: query lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving (init part 2):  lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving (init part 3):  lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: processQueryTargets: lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: sending query: lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: iterator operate: query lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: response for lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: finishing processing for lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validator operate: query lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validate keys with anchor(DS): sec_status_secure
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: Successfully primed trust anchor lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validated DS child.lab.test. DS IN
(中略)
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validator operate: query child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving (init part 2):  child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: resolving (init part 3):  child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: processQueryTargets: child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: sending query: child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: iterator operate: query child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: response for child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: finishing processing for child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: validator operate: query child.lab.test. DNSKEY IN
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] debug: DS fail: digest is different
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] debug: Failed to match any usable DS to a DNSKEY.
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: Did not match a DS to a DNSKEY, thus bogus.
Sep 12 11:11:05 resolver unbound[1661]: [1661:0] info: Could not establish a chain of trust to keys for child.lab.test. DNSKEY IN

下記の流れでエラー発生。

Unbound
  |
  | ParentのDSを取得
  v
DS RRset + RRSIG DS
  |
  +-- ○ Parent側の署名検証は成功
  |
  v
Child DNSKEYを取得
  |
  | DNSKEYからdigestを計算
  v
Parent DS     Child KSK由来
...BF5E       ...BF5D
     \         /
      \       /
       × 不一致
          |
          v
Failed to match any usable DS to a DNSKEY
          |
          v
Bogus
          |
          v
SERVFAIL

ジャーナルから読み取れる挙動は下記。

validated DS
    ↓
ParentのDS RRset自体の署名検証は成功

DS fail: digest is different
    ↓
DSのdigestとChild DNSKEYから算出したdigestが一致しない

Failed to match any usable DS to a DNSKEY.
    ↓
DSに対応するChild DNSKEYを確認できない

Did not match a DS to a DNSKEY, thus bogus.
    ↓
DNSSEC検証でBogusと判定

Could not establish a chain of trust to keys
    ↓
ParentからChildへの信頼の連鎖を構築できない

検証結果

Resolverのキャッシュを削除した後、ClientからUnboundを経由して www.child.lab.test のAレコードを問い合わせた。結果は SERVFAIL となり、ANSWER SECTIONは0件だった。また、正常時に存在していた ad フラグも付与されていない。これにより、Parent DNSのDSレコードとChild KSKが不整合な状態では、UnboundがDNSSEC検証を正常に完了できないことを確認した。

検証3：DSレコードを削除し、Insecureになることを確認する

本検証では、Parent DNSに登録されている child.lab.test のDSレコードを削除し、ParentからChildへのDNSSECの信頼の連鎖が存在しない状態を作成する。DSレコードが存在するもののChild DNSKEYと不整合だった検証2とは異なり、DSレコードが正しく存在しない場合に、UnboundがChildゾーンをどのように扱うかを確認する。

Parent DNSからDSレコードを削除する

Parent DNS で作業。

# Serialを変更
# 元ゾーンファイルのDSレコードを削除
$ sudo vim /etc/bind/db.lab.test
$TTL 3600

@   IN  SOA ns dnsmaster (
        2026091201 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN  NS  ns.lab.test.

ns  IN  A   192.168.56.10

child       IN NS ns.child
ns.child    IN A  192.168.56.20
; This is a key-signing key, keyid 25095, for lab.test.
; Created: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Publish: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Activate: 20260910122739 (Thu Sep 10 12:27:39 2026)
lab.test. IN DNSKEY 257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ==
; This is a zone-signing key, keyid 42600, for lab.test.
; Created: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Publish: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Activate: 20260910122712 (Thu Sep 10 12:27:12 2026)
lab.test. IN DNSKEY 256 3 13 XGx8XP7w7bqg8k9cBXoPvDLsZQFUOAuUbdr8Bd8ZSH25ip1Bq75BGFYO yZhxy0DNqEsEPPpDt2qHAW/kdlJs3g==

DS削除後のParentゾーンを再署名する

# ゾーンファイルを確認
$ sudo named-checkzone lab.test /etc/bind/db.lab.test

# Parentゾーンを再署名
$ cd /etc/bind/keys/lab.test
$ sudo dnssec-signzone \
  -S \
  -o lab.test \
  -f /etc/bind/db.lab.test.signed \
  /etc/bind/db.lab.test
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db.lab.test.signed

BINDに再署名後のゾーンを読み込ませる

$ sudo rndc reload lab.test
$ sudo rndc zonestatus lab.test
name: lab.test
type: primary
files: /etc/bind/db.lab.test.signed
serial: 2026091201
nodes: 4
last loaded: Sat, 12 Sep 2026 11:42:06 GMT
secure: yes
inline signing: no
key maintenance: none
next resign node: lab.test/DNSKEY
next resign time: Mon, 05 Oct 2026 10:42:06 GMT
dynamic: no
reconfigurable via modzone: no

# DSがANSWER SECTIONに返らないことと、DNSSECによる不在証明に関係する情報が返ってくることを確認
$ dig +dnssec +norecurse @192.168.56.10 child.lab.test DS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec +norecurse @192.168.56.10 child.lab.test DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10626
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 1a9ae6c7bc8bf2dc010000006aa53b4245473b3175ed38ac (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      DS

;; AUTHORITY SECTION:
lab.test.               3600    IN      SOA     ns.lab.test. dnsmaster.lab.test. 2026091201 3600 900 604800 86400
lab.test.               3600    IN      RRSIG   SOA 13 2 3600 20261012104206 20260912104206 42600 lab.test. 3+/zAO/gAc+/0RLsZz5+9bxCTlKo9CM8It0vjtxFVgNTl89h//QS0bs7 O7JqjCRdIkMLGTxKMyoygiKlvMEq3A==
child.lab.test.         3600    IN      NSEC    ns.lab.test. NS RRSIG NSEC
child.lab.test.         3600    IN      RRSIG   NSEC 13 3 3600 20261012104206 20260912104206 42600 lab.test. JLf3igQqIgx0gh+uwOY/axOws/jSS+95NhlsvegrziN3Qn1bobeVLGcO iw66jM2zqD4ihBqS5IR4ga/reXh8/Q==

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Sat Sep 12 11:45:06 UTC 2026
;; MSG SIZE  rcvd: 361

NSECとそれに付いたRRSIGによって、「child.lab.test にはDSレコードが存在しない」ことがDNSSECで認証されている。

Unbound
   |
   | child.lab.test のDSは？
   v
Parent DNS
   |
   | DSは存在しない
   v
NSEC
「child.lab.testには
 NS / RRSIG / NSEC はあるが
 DSはない」
   |
   | Parent ZSK 42600によるRRSIG
   v
認証されたDSの不在

Client → Unbound で確認

# キャッシュ削除(Resolverで作業)
$ sudo unbound-control flush_zone lab.test

# Clientから確認
$ dig +dnssec @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20363
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:
www.child.lab.test.     3600    IN      A       192.168.56.100
www.child.lab.test.     3600    IN      RRSIG   A 13 4 3600 20261009122536 20260909122536 7661 child.lab.test. XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuSmi+J8jcqgW8NQhR+Fi8s FaHbAEZuw691gEoZ22rXmWlCL5sbOQ==

;; Query time: 10 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Sat Sep 12 11:54:26 UTC 2026
;; MSG SIZE  rcvd: 173

# ジャーナル確認　
$ sudo journalctl -u unbound --since "2 minutes ago" > log
$ grep -Ei "DS|DNSKEY|secure|insecure|bogus|validate|NSEC|trust" log
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: adding trusted key lab.test. DNSKEY IN
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: validator operate: query . DNSKEY IN
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: resolving . DNSKEY IN
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] debug: request has exceeded the maximum number of sends with 33
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: iterator operate: query . DNSKEY IN
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: processQueryTargets: . DNSKEY IN
Sep 12 11:54:17 resolver unbound[1611]: [1611:0] info: validator operate: query . DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: prime trust anchor
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: validator operate: query lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: resolving lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: resolving (init part 2):  lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: resolving (init part 3):  lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: processQueryTargets: lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: sending query: lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: iterator operate: query lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: response for lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: finishing processing for lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: validator operate: query lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: validate keys with anchor(DS): sec_status_secure
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: Successfully primed trust anchor lab.test. DNSKEY IN
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: NSEC RRset for the referral proved no DS.
Sep 12 11:54:26 resolver unbound[1611]: [1611:0] info: Verified that response is INSECURE

本検証の流れは下記。

Parent
  |
  | DSなし
  | NSEC + RRSIG NSECで不在を証明
  v
Unbound
  |
  | 「このChildはDNSSECの信頼の連鎖に接続されていない」
  v
Insecure
  |
  | 名前解決は継続
  v
A = 192.168.56.100 を返す
  |
  v
adフラグは付かない

ジャーナルから読み取れる挙動は下記。

validate keys with anchor(DS): sec_status_secure
    ↓
lab.test のTrust Anchorは正常

Successfully primed trust anchor
    ↓
Parent側の信頼の起点を正常に確立

NSEC RRset for the referral proved no DS.
    ↓
child.lab.test にDSが存在しないことをNSECで確認

Verified that response is INSECURE
    ↓
ChildゾーンをInsecureとして扱う

検証結果

Resolverのキャッシュを削除した後、ClientからUnboundを経由して www.child.lab.test のAレコードを問い合わせた。結果は NOERROR となり、Aレコード 192.168.56.100 が正常に返された。一方、正常時に存在していた ad フラグは付与されていない。Unboundのログでは、NSECによってDSレコードが存在しないことが確認され、INSECURE と判定されていた。これにより、Parent DNSにDSレコードが存在しない場合、Childゾーンは Bogus ではなく Insecure として扱われ、DNSSECによる検証済みとはならないものの、名前解決自体は正常に行われることを確認した。

疑問に思ったこと

「DNSSECによる検証ができていないのに、名前解決を成功させてしまってよいのか？」という疑問を持ったので調べてみた。

なぜDNSSECが設定されていなくても名前解決ができるのか

DNSSECは、DNSSECを利用していないドメインの名前解決を拒否する仕組みではない。
インターネット上にはDNSSECを利用していないドメインも存在するため、DNSSECによる信頼の連鎖が存在しないという理由だけで名前解決を拒否してしまうと、DNSSECを利用していないドメインを名前解決できなくなってしまう。

攻撃者がDSレコードを削除してDNSSECを回避できるのではないか

攻撃者がDNS応答からDSレコードを単純に削除しただけでは、Insecure にすることはできない。
DNSSECでは、DSレコードが存在しない場合、NSEC とその RRSIG によって「DSレコードが存在しないこと」自体を認証できている。つまりUnboundは、単に「DSが返ってこなかったから Insecure」と判断したのではなく、ParentゾーンのDNSSEC署名によってDSの不在が認証されたことを確認したうえで Insecure と判定している。

実務との関連

今回の検証はDNSSECに関する攻撃そのものを再現したものではなく、攻撃や設定ミスによって発生し得るDNSSECの異常状態を意図的に作り、その際の挙動を確認したものである。

検証1：DNSデータの改ざん

検証1では、署名済みのAレコードを変更し、A RRsetとRRSIGの不整合を発生させた。
実環境では、DNSキャッシュポイズニングや通信経路上でのDNS応答改ざんなどによって、攻撃者が正規のDNSデータとは異なる情報を返そうとする状況が考えられる。
DNSSECでは、攻撃者が正しい秘密鍵を持っていなければ改ざん後のデータに対する有効なRRSIGを生成できない。そのため、検証リゾルバはRRsetとRRSIGの不整合を検知し、改ざんされたDNSデータを正当な応答として扱わない。
今回の検証では、この状態がUnboundの signature mismatch として確認でき、最終的に SERVFAIL となった。

DNSデータの改ざん
        ↓
RRsetとRRSIGが不一致
        ↓
DNSSEC検証失敗
        ↓
Bogus
        ↓
SERVFAIL

検証2：DNSSECの設定・鍵管理の不整合

検証2では、Parent DNSに登録されたDSレコードのdigestを変更し、Child KSKと対応しない状態を作成した。
実環境では、KSKロールオーバー時のDS更新ミスなどにより、Parent側のDSとChild側のDNSKEYが対応しなくなる可能性がある。
この状態では、DSレコード自体の署名検証には成功しても、DSとChild DNSKEYを結び付けることができない。そのため、ParentからChildへの信頼の連鎖を構築できず、DNSSEC検証は失敗する。
今回の検証では、Unboundのログから DS fail: digest is different および Could not establish a chain of trust を確認し、最終的に SERVFAIL となった。

DSとChild DNSKEYの不整合
        ↓
DSに対応するDNSKEYを確認できない
        ↓
信頼の連鎖を構築できない
        ↓
Bogus
        ↓
SERVFAIL

検証3：DSレコードが存在しない状態

検証3では、Parent DNSからChildのDSレコードを削除し、ParentからChildへのDNSSECの信頼の連鎖が存在しない状態を作成した。
検証2との重要な違いは、「存在するDSとDNSKEYが不整合」なのか、「そもそもDSが存在しない」のかという点にある。
DSが存在するにもかかわらず対応するDNSKEYを確認できない場合は Bogus となり、名前解決は SERVFAIL となる。一方、DSが存在しないことをNSECとRRSIGによって正当に確認できる場合、そのChildゾーンは Insecure として扱われ、DNSSECによる検証済みではないものの、名前解決自体は継続される。
実環境では、DNSSECを廃止してDSレコードを削除した場合や、レジストラ側でDSレコードが削除された場合などに、このような状態が発生し得る。

ParentにDSが存在しない
        ↓
NSEC + RRSIGによって
DSの不在を正当に確認
        ↓
DNSSECの信頼の連鎖なし
        ↓
Insecure
        ↓
名前解決は可能
ただしDNSSECによる真正性の保証はない

なお、第三者がDNS応答から単純にDSレコードを除去するだけで Insecure にできるわけではない。DSレコードが存在しないこと自体もNSECとRRSIGによって認証されるためである。ただし、本来DNSSECで保護されるべきドメインから正規のDSレコードが削除された場合は、名前解決が継続していてもDNSSECによる保護が失われるため、運用上は注意が必要となる。

まとめ

今回の検証では、DNSSECの正常な環境を意図的に破壊し、Unboundの挙動を確認した。AレコードとRRSIGが不整合な場合、およびParentのDSとChild DNSKEYが不整合な場合はBogusとなり、名前解決はSERVFAILとなった。一方、DSレコードが存在しないことをDNSSECによって正当に確認できる場合はInsecureとなり、DNSSECによる真正性は保証されないものの、名前解決自体は継続された。
今回の検証から、DNSSECでは単に「名前解決に成功するか、失敗するか」だけではなく、Secure、Bogus、Insecureの状態を区別し、信頼の連鎖のどの段階で問題が発生しているのかを確認することが重要だと分かった。

DNSSEC検証 DNSSEC構築編

miyuki — Sat, 12 Sep 2026 13:12:39 +0000

はじめに

何をしたいか

DNSSECの信頼の連鎖を実際に構築し、DNS応答がどのように署名・検証されるのかを確認する。また、DNSSECに関する設定や署名を意図的に破壊し、検証失敗時にフルリゾルバやクライアントからどのように見えるのかを確認する。
前回の「準備・DNS構築編」では、DNSSECを使用しない通常のDNS環境を構築した。
本記事では、この環境にDNSSECを導入し、信頼の連鎖を構築する。

準備・DNS構築編　https://cybermemo.blog/dnssec-lab-setup
DNSSEC構築編　本記事
DNSSEC破壊・検証編　https://cybermemo.blog/dnssec-lab-testing

本記事で構築する構成

前回構築したDNS環境にDNSSECを導入する。

              ┌─────────────┐
              │ Parent DNS  │　192.168.56.10/24
              │    BIND9    │　権威ゾーン: lab.test
              │             │　DNSKEY / RRSIG
              └──────┬──────┘
                     │
            child.lab.test を委任
              ＋ DSレコード
                     │
                     ▼
              ┌─────────────┐　192.168.56.20/24
              │  Child DNS  │　権威ゾーン: child.lab.test
              │    BIND9    │　DNSKEY / RRSIG
              │             │　└─ www.child.lab.test → 192.168.56.100
              └─────────────┘
                     ▲
                     │ DNS問い合わせ
                     │ ＋ DNSSEC署名情報
                     │
              ┌─────────────┐
              │  Resolver   │ 192.168.56.30/24
              │   Unbound   │ DNSSEC検証
              │             │ Trust Anchor: lab.test
              └──────┬──────┘
                     ▲
                     │ DNS問い合わせ
                     │
              ┌─────────────┐
              │   Client    │ 192.168.56.40/24
              └─────────────┘

【DNSSECの信頼の連鎖】

Trust Anchor
（lab.test KSK / DNSKEY）
        │
        ▼
lab.test DNSKEY RRset
        │
        │ ParentのDSによってChild KSKを信頼
        ▼
child.lab.test DNSKEY RRset
        │
        │ Child ZSKの公開鍵でRRSIGを検証
        ▼
www.child.lab.test A

検証環境

構築

ChildゾーンをDNSSEC署名

Child DNS で作業。

鍵生成

# ゾーンファイルを確認
$ sudo cat /etc/bind/db.child.lab.test
$TTL 3600

@   IN SOA ns dnsmaster (
        2026090401 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN NS ns

ns  IN A 192.168.56.20
www IN A 192.168.56.100

# DNSSEC鍵を置くディレクトリを作る
$ sudo mkdir -p /etc/bind/keys/child.lab.test

# ZSKを生成
$ cd /etc/bind/keys/child.lab.test
$ sudo dnssec-keygen -a ECDSAP256SHA256 -n ZONE child.lab.test
Generating key pair.
Kchild.lab.test.+013+07661

# KSKを生成
$ sudo dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE child.lab.test
Generating key pair.
Kchild.lab.test.+013+26145

# 生成ファイルを確認
$ sudo ls -l /etc/bind/keys/child.lab.test
total 16
-rw-r--r-- 1 root bind 347 Sep  9 12:59 Kchild.lab.test.+013+07661.key
-rw------- 1 root bind 187 Sep  9 12:59 Kchild.lab.test.+013+07661.private
-rw-r--r-- 1 root bind 347 Sep  9 13:00 Kchild.lab.test.+013+26145.key
-rw------- 1 root bind 187 Sep  9 13:00 Kchild.lab.test.+013+26145.private

# 公開鍵の中身を確認　
$ sudo cat Kchild.lab.test.+013+07661.key && sudo cat Kchild.lab.test.+013+26145.key
; This is a zone-signing key, keyid 7661, for child.lab.test.
; Created: 20260909125923 (Wed Sep  9 12:59:23 2026)
; Publish: 20260909125923 (Wed Sep  9 12:59:23 2026)
; Activate: 20260909125923 (Wed Sep  9 12:59:23 2026)
child.lab.test. IN DNSKEY 256 3 13 of3bj/PGoJ9JAF2HN02sQ4xKhSjPBt8c0iLmok/IcnloBP0A+Wm+vqj6 ZM7v1/HXQmi6odv+eJ/+O4lfOMEkiQ==
; This is a key-signing key, keyid 26145, for child.lab.test.
; Created: 20260909130016 (Wed Sep  9 13:00:16 2026)
; Publish: 20260909130016 (Wed Sep  9 13:00:16 2026)
; Activate: 20260909130016 (Wed Sep  9 13:00:16 2026)
child.lab.test. IN DNSKEY 257 3 13 RfvhGg1akSrUMv7Ub87SsXXHUJt0NRWW7hUtG8rS0x6gLM9b8+vpx0A1 qNvm10S/hEEPaa9SAz/7Hrq87Rcyiw==

Childのゾーンファイルを署名

# ディレクトリ移動
$ cd /etc/bind

# バックアップ取得
$ sudo cp db.child.lab.test db.child.lab.test.bak

# 2つの.keyをゾーンファイルへ追加
$ sudo sh -c 'cat keys/child.lab.test/*.key >> db.child.lab.test'　　

# Serialを変更
$ sudo vim /etc/bind/db.child.lab.test　　
$TTL 3600

@   IN SOA ns dnsmaster (
        2026090901 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN NS ns

ns  IN A 192.168.56.20
www IN A 192.168.56.100
; This is a zone-signing key, keyid 7661, for child.lab.test.
; Created: 20260909125923 (Wed Sep  9 12:59:23 2026)
; Publish: 20260909125923 (Wed Sep  9 12:59:23 2026)
; Activate: 20260909125923 (Wed Sep  9 12:59:23 2026)
child.lab.test. IN DNSKEY 256 3 13 of3bj/PGoJ9JAF2HN02sQ4xKhSjPBt8c0iLmok/IcnloBP0A+Wm+vqj6 ZM7v1/HXQmi6odv+eJ/+O4lfOMEkiQ==
; This is a key-signing key, keyid 26145, for child.lab.test.
; Created: 20260909130016 (Wed Sep  9 13:00:16 2026)
; Publish: 20260909130016 (Wed Sep  9 13:00:16 2026)
; Activate: 20260909130016 (Wed Sep  9 13:00:16 2026)
child.lab.test. IN DNSKEY 257 3 13 RfvhGg1akSrUMv7Ub87SsXXHUJt0NRWW7hUtG8rS0x6gLM9b8+vpx0A1 qNvm10S/hEEPaa9SAz/7Hrq87Rcyiw==

# 構文チェック
$ sudo named-checkzone child.lab.test /etc/bind/db.child.lab.test
zone child.lab.test/IN: loaded serial 2026090901
OK

# ディレクトリ移動
$ cd /etc/bind/keys/child.lab.test

# dnssec-signzoneで署名
$ sudo dnssec-signzone \　　
  -S \
  -o child.lab.test \
  -f /etc/bind/db.child.lab.test.signed \
  /etc/bind/db.child.lab.test
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db.child.lab.test.signed

# 署名済みゾーンファイルが生成されたことを確認
$ sudo ls -l /etc/bind/db.child.lab.test*　　
-rw-r--r-- 1 root bind  947 Sep  9 13:22 /etc/bind/db.child.lab.test
-rw-r--r-- 1 root bind  253 Sep  9 13:18 /etc/bind/db.child.lab.test.bak
-rw-r--r-- 1 root bind 2726 Sep  9 13:25 /etc/bind/db.child.lab.test.signed

# 署名済みゾーンを確認
$ sudo cat /etc/bind/db.child.lab.test.signed
; File written on Wed Sep  9 13:25:36 2026
; dnssec-signzone version 9.20.24-1ubuntu0.3-Ubuntu
child.lab.test.         3600    IN SOA  ns.child.lab.test. dnsmaster.child.lab.test. (
                                        2026090901 ; serial
                                        3600       ; refresh (1 hour)
                                        900        ; retry (15 minutes)
                                        604800     ; expire (1 week)
                                        86400      ; minimum (1 day)
                                        )
                        3600    RRSIG   SOA 13 3 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        lPLC99bWrcmgzGCGwL20o7A8yPGr/w7wMtIo
                                        9XVRflFmyorQ01L1PHOj1n/s6ZG3DwtYsgjE
                                        1Uklg/WEIQdbPA== )
                        3600    NS      ns.child.lab.test.
                        3600    RRSIG   NS 13 3 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        U2708D42QzU3kgqX0gcaoOLQD9H7pNVG8/IH
                                        VnrNK5InPpyeNCRyq5sSa1oxdXuVITovo+eB
                                        QSkKU/OAlGeM+Q== )
                        3600    NSEC    ns.child.lab.test. NS SOA RRSIG NSEC DNSKEY
                        3600    RRSIG   NSEC 13 3 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        Gt28Z9fQT56l0ONZa1YpEL7+22gH7RgxT178
                                        n5Zf3/4TH7UPSSx0lQE5nWpUb52A7+VlF5ix
                                        8K1v9MX31Psl/w== )
                        3600    DNSKEY  256 3 13 (
                                        of3bj/PGoJ9JAF2HN02sQ4xKhSjPBt8c0iLm
                                        ok/IcnloBP0A+Wm+vqj6ZM7v1/HXQmi6odv+
                                        eJ/+O4lfOMEkiQ==
                                        ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 7661
                        3600    DNSKEY  257 3 13 (
                                        RfvhGg1akSrUMv7Ub87SsXXHUJt0NRWW7hUt
                                        G8rS0x6gLM9b8+vpx0A1qNvm10S/hEEPaa9S
                                        Az/7Hrq87Rcyiw==
                                        ) ; KSK; alg = ECDSAP256SHA256 ; key id = 26145
                        3600    RRSIG   DNSKEY 13 3 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        FgbLJ9v+yNnKLs6sMEWIk8smobeazyZoFiPm
                                        XA0HU4EAHnthv8olg7KmNGjgm/tcuPvUQgMs
                                        f7lK3BgevwukFQ== )
                        3600    RRSIG   DNSKEY 13 3 3600 (
                                        20261009122536 20260909122536 26145 child.lab.test.
                                        NYOgC1JsircR22X5nwPl1S+XfF4hhRlWBiEA
                                        MYhf0gKxJcupAUy1rMSj25VMcbvx0jurFW76
                                        VVjxFmMXOrfGIg== )
ns.child.lab.test.      3600    IN A    192.168.56.20
                        3600    RRSIG   A 13 4 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        f6r7LraRZm76e0HcFZAP1sxMXz+FdGdNHZ1I
                                        R/58BloWPWrIxYtVorV7Yj5jYDHkGqsiB10W
                                        FItH0NhA3S2+FA== )
                        3600    NSEC    www.child.lab.test. A RRSIG NSEC
                        3600    RRSIG   NSEC 13 4 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        nI9GreBE6XjqVVTljaicF804VAnZS53p0hpr
                                        TU4h7qMdLL2frKJF5nEtZr1hH803Tw5MT0F8
                                        jE6nCtQBDmfZhA== )
www.child.lab.test.     3600    IN A    192.168.56.100
                        3600    RRSIG   A 13 4 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuS
                                        mi+J8jcqgW8NQhR+Fi8sFaHbAEZuw691gEoZ
                                        22rXmWlCL5sbOQ== )
                        3600    NSEC    child.lab.test. A RRSIG NSEC
                        3600    RRSIG   NSEC 13 4 3600 (
                                        20261009122536 20260909122536 7661 child.lab.test.
                                        QHkt5+ujPGQ/3UTapTfDNMUzvzt6C9LdBVJL
                                        xv/isAyQWFphEK/pkbAmTIMDBLKIoBRMyb4i
                                        LUpi1qvRa0CplA== )

BINDが署名済みファイルを使うよう変更

# 署名済みファイルを読み込むよう設定変更
# db.child.lab.test → db.child.lab.test.signed
$ sudo vim /etc/bind/named.conf.local
//
// Do any local configuration here
//

zone "child.lab.test" {
    type primary;
    file "/etc/bind/db.child.lab.test.signed";
};

# 設定をチェックして再読み込み
$ sudo named-checkconf
$ sudo named-checkzone child.lab.test /etc/bind/db.child.lab.test.signed
zone child.lab.test/IN: loaded serial 2026090901 (DNSSEC signed)
OK
$ sudo rndc reconfig
$ sudo rndc zonestatus child.lab.test
$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-09-09 12:39:27 UTC; 1h 0min ago

DNSKEYを問い合わせる

$ dig +dnssec @192.168.56.20 child.lab.test DNSKEY

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.20 child.lab.test DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43976
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 69581b200025ce68010000006aa1633aa773dd222721ebe1 (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      DNSKEY

;; ANSWER SECTION:　　# DNSKEY RRsetに対する署名が応答に含まれている
child.lab.test.         3600    IN      DNSKEY  257 3 13 RfvhGg1akSrUMv7Ub87SsXXHUJt0NRWW7hUtG8rS0x6gLM9b8+vpx0A1 qNvm10S/hEEPaa9SAz/7Hrq87Rcyiw==
child.lab.test.         3600    IN      DNSKEY  256 3 13 of3bj/PGoJ9JAF2HN02sQ4xKhSjPBt8c0iLmok/IcnloBP0A+Wm+vqj6 ZM7v1/HXQmi6odv+eJ/+O4lfOMEkiQ==
child.lab.test.         3600    IN      RRSIG   DNSKEY 13 3 3600 20261009122536 20260909122536 7661 child.lab.test. FgbLJ9v+yNnKLs6sMEWIk8smobeazyZoFiPmXA0HU4EAHnthv8olg7Km NGjgm/tcuPvUQgMsf7lK3BgevwukFQ==
child.lab.test.         3600    IN      RRSIG   DNSKEY 13 3 3600 20261009122536 20260909122536 26145 child.lab.test. NYOgC1JsircR22X5nwPl1S+XfF4hhRlWBiEAMYhf0gKxJcupAUy1rMSj 25VMcbvx0jurFW76VVjxFmMXOrfGIg==

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Wed Sep 09 13:46:34 UTC 2026
;; MSG SIZE  rcvd: 451

$ dig +dnssec @192.168.56.20 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.20 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6047
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 2b33bf67976af0a4010000006aa1633f561edffaee841791 (good)
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:　　# RRsetに対する署名が応答に含まれている
www.child.lab.test.     3600    IN      A       192.168.56.100
www.child.lab.test.     3600    IN      RRSIG   A 13 4 3600 20261009122536 20260909122536 7661 child.lab.test. XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuSmi+J8jcqgW8NQhR+Fi8s FaHbAEZuw691gEoZ22rXmWlCL5sbOQ==

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Wed Sep 09 13:46:39 UTC 2026
;; MSG SIZE  rcvd: 201

Child DNSのKSKからDSレコードを生成し、Parent DNSに登録

Child DNSのKSKでDSレコードを生成

# 生成した鍵を確認
$ cd /etc/bind/keys/child.lab.test
$ ls -l
total 20
-rw-r--r-- 1 root bind 347 Sep  9 12:59 Kchild.lab.test.+013+07661.key
-rw------- 1 root bind 187 Sep  9 12:59 Kchild.lab.test.+013+07661.private
-rw-r--r-- 1 root bind 347 Sep  9 13:00 Kchild.lab.test.+013+26145.key
-rw------- 1 root bind 187 Sep  9 13:00 Kchild.lab.test.+013+26145.private
-rw-r--r-- 1 root bind 100 Sep  9 13:25 dsset-child.lab.test.

# KSKからDSレコードを生成
$ dnssec-dsfromkey -2 Kchild.lab.test.+013+26145.key
child.lab.test. IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5D

# Parent DNSへDSを登録(Parent DNSで作業)
# Serialを変更、DSレコードを追記
$ sudo vim /etc/bind/db.lab.test
$TTL 3600

@   IN  SOA ns dnsmaster (
        2026091001 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN  NS  ns.lab.test.

ns  IN  A   192.168.56.10

child       IN NS ns.child
ns.child    IN A  192.168.56.20
child       IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5D

# 設定をチェックして再読み込み
$ sudo named-checkzone lab.test /etc/bind/db.lab.test
$ sudo rndc reload lab.test

# 設定が反映されているか確認
$ dig +norecurse @192.168.56.10 child.lab.test DS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +norecurse @192.168.56.10 child.lab.test DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51525
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 575f15af146df5dc010000006aa2a1275fb9a529e926c9cf (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      DS

;; ANSWER SECTION:
child.lab.test.         3600    IN      DS      26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F653 2742BF5D

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Thu Sep 10 12:23:03 UTC 2026
;; MSG SIZE  rcvd: 119

Parent DNSをDNSSEC署名

Parent DNS で作業。

# ディレクトリ作成
$ sudo mkdir -p /etc/bind/keys/lab.test
$ cd /etc/bind/keys/lab.test

# ParentのZSKを生成
$ sudo dnssec-keygen -a ECDSAP256SHA256 -n ZONE lab.test
Generating key pair.
Klab.test.+013+42600

# ParentのKSKを生成
$ sudo dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE lab.test
Generating key pair.
Klab.test.+013+25095

# 生成結果を確認
$ ls -l /etc/bind/keys/lab.test
total 16
-rw-r--r-- 1 root bind 335 Sep 10 12:27 Klab.test.+013+25095.key
-rw------- 1 root bind 187 Sep 10 12:27 Klab.test.+013+25095.private
-rw-r--r-- 1 root bind 336 Sep 10 12:27 Klab.test.+013+42600.key
-rw------- 1 root bind 187 Sep 10 12:27 Klab.test.+013+42600.private

# 公開鍵を確認
$ cat /etc/bind/keys/lab.test/*.key
; This is a key-signing key, keyid 25095, for lab.test.
; Created: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Publish: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Activate: 20260910122739 (Thu Sep 10 12:27:39 2026)
lab.test. IN DNSKEY 257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ==
; This is a zone-signing key, keyid 42600, for lab.test.
; Created: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Publish: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Activate: 20260910122712 (Thu Sep 10 12:27:12 2026)
lab.test. IN DNSKEY 256 3 13 XGx8XP7w7bqg8k9cBXoPvDLsZQFUOAuUbdr8Bd8ZSH25ip1Bq75BGFYO yZhxy0DNqEsEPPpDt2qHAW/kdlJs3g==

# ParentのDNSKEYをゾーンファイルへ追加
$ sudo sh -c 'cat keys/lab.test/*.key >> db.lab.test'

# Serialを変更
$ sudo vim /etc/bind/db.lab.test　　
$TTL 3600

@   IN  SOA ns dnsmaster (
        2026091002 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN  NS  ns.lab.test.

ns  IN  A   192.168.56.10

child       IN NS ns.child
ns.child    IN A  192.168.56.20
child       IN DS 26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F6532742BF5D
; This is a key-signing key, keyid 25095, for lab.test.
; Created: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Publish: 20260910122739 (Thu Sep 10 12:27:39 2026)
; Activate: 20260910122739 (Thu Sep 10 12:27:39 2026)
lab.test. IN DNSKEY 257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ==
; This is a zone-signing key, keyid 42600, for lab.test.
; Created: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Publish: 20260910122712 (Thu Sep 10 12:27:12 2026)
; Activate: 20260910122712 (Thu Sep 10 12:27:12 2026)
lab.test. IN DNSKEY 256 3 13 XGx8XP7w7bqg8k9cBXoPvDLsZQFUOAuUbdr8Bd8ZSH25ip1Bq75BGFYO yZhxy0DNqEsEPPpDt2qHAW/kdlJs3g==

# 構文チェック
$ sudo named-checkzone lab.test /etc/bind/db.lab.test

# Parentゾーンを署名
$ cd /etc/bind/keys/lab.test
$ sudo dnssec-signzone \
  -S \
  -o lab.test \
  -f /etc/bind/db.lab.test.signed \
  /etc/bind/db.lab.test
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db.lab.test.signed

# 署名済みファイルを読み込むよう設定変更
# db.lab.test → db.lab.test.signed
$ sudo vim /etc/bind/named.conf.local
//
// Do any local configuration here
//

zone "lab.test" {
    type primary;
    file "/etc/bind/db.lab.test.signed";
};

# 設定をチェックして再読み込み
$ sudo named-checkconf
$ sudo rndc reconfig

# 本当に署名済みゾーンを読んでいるか確認
$ sudo rndc zonestatus lab.test
name: lab.test
type: primary
files: /etc/bind/db.lab.test.signed
serial: 2026091002
nodes: 4
last loaded: Thu, 10 Sep 2026 12:32:37 GMT
secure: yes
inline signing: no
key maintenance: none
next resign node: lab.test/DNSKEY
next resign time: Sat, 03 Oct 2026 11:32:37 GMT
dynamic: no
reconfigurable via modzone: no

# ParentのDNSKEYを直接確認
$ dig +dnssec @192.168.56.10 lab.test DNSKEY

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.10 lab.test DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61863
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 3ad54fc7b29e4940010000006aa2a4c8a84d54b456af230d (good)
;; QUESTION SECTION:
;lab.test.                      IN      DNSKEY

;; ANSWER SECTION:
lab.test.               3600    IN      DNSKEY  256 3 13 XGx8XP7w7bqg8k9cBXoPvDLsZQFUOAuUbdr8Bd8ZSH25ip1Bq75BGFYO yZhxy0DNqEsEPPpDt2qHAW/kdlJs3g==
lab.test.               3600    IN      DNSKEY  257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ==
lab.test.               3600    IN      RRSIG   DNSKEY 13 2 3600 20261010113237 20260910113237 25095 lab.test. m/UN/LdqgXsjAQTzPkqY/72gzpJyLH5THJlrhrwhnXzvYPqZ29UIK7Dg yyR4y2kbghbxg2bsePGxUngUUoz4rw==
lab.test.               3600    IN      RRSIG   DNSKEY 13 2 3600 20261010113237 20260910113237 42600 lab.test. +c+NJo2m+DDpeUGVRfYZQxXKDe3MT/LfWspon14H8PTlJH+Z/JgH4XZG OIPaDr26IwXsqMt+lzPB809OeQ+SzA==

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Thu Sep 10 12:38:32 UTC 2026
;; MSG SIZE  rcvd: 433

# ParentのDSを直接確認
$ dig +dnssec +norecurse @192.168.56.10 child.lab.test DS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec +norecurse @192.168.56.10 child.lab.test DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42626
;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 5ab6af9666fe5062010000006aa2a50259f77941809ff655 (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      DS

;; ANSWER SECTION:
child.lab.test.         3600    IN      DS      26145 13 2 C0F99483CDF9CE53B7EFBCE8607A73DCAA7B6FA728F24ECFEB01F653 2742BF5D
child.lab.test.         3600    IN      RRSIG   DS 13 3 3600 20261010113237 20260910113237 42600 lab.test. nAmsL7wGWZzUk27uPO/aSFuwSOwC1oQPrbsvkuJbKjHgvh1QZ6EN4x0v CTTAopk9zi9kDC1d/c++aNfBZYwSOA==

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Thu Sep 10 12:39:30 UTC 2026
;; MSG SIZE  rcvd: 223

Unboundに lab.test のTrust Anchorを設定して、DNSSEC検証を有効化

Resolver で作業。

Trust Anchor用のUnbound設定ファイルを作成する

# 専用ファイルを作成
# lab.test のDNSKEYは最初から信頼してよい と設定
$ sudo vim /etc/unbound/unbound.conf.d/lab-test-trust-anchor.conf
server:
    trust-anchor: "lab.test. IN DNSKEY 257 3 13 nzPV3+LMX633npZfI3Seu2cR8SrTegHIi1sCK2OtNTQyRZg/v6yVkRDl nmr52oumop7xFxsx6vcZk3emfTsFbQ=="

# domain-insecure: "lab.test." を削除
$ sudo vim /etc/unbound/unbound.conf.d/dns-lab.conf
server:
    interface: 192.168.56.30
    access-control: 192.168.56.0/24 allow

    local-zone: "test." transparent

stub-zone:
    name: "lab.test."
    stub-addr: 192.168.56.10

# Unboundの設定をチェックし、再読み込み
$ sudo unbound-checkconf
$ sudo systemctl restart unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-09-10 12:53:24 UTC; 4s ago

# Resolver自身からDNSSEC検証
$ dig +dnssec @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41055
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1　　# ad = Authenticated Data(UnboundがDNSSEC検証に成功し、応答をSecureとして扱った)

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:
www.child.lab.test.     3600    IN      A       192.168.56.100
www.child.lab.test.     3600    IN      RRSIG   A 13 4 3600 20261009122536 20260909122536 7661 child.lab.test. XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuSmi+J8jcqgW8NQhR+Fi8s FaHbAEZuw691gEoZ22rXmWlCL5sbOQ==　　# ChildのZSK(7661)によって署名されている

;; Query time: 13 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Thu Sep 10 12:53:57 UTC 2026
;; MSG SIZE  rcvd: 173

Client → Unboundまで含めて正常に動作することを確認

Client で作業。

$ dig +dnssec @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +dnssec @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50729
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1　　# Authenticated Data

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:
www.child.lab.test.     3334    IN      A       192.168.56.100
www.child.lab.test.     3334    IN      RRSIG   A 13 4 3600 20261009122536 20260909122536 7661 child.lab.test. XX27GC+TFLVYuz+Jd8Ox7SyC5yxL1ifF+cuSmi+J8jcqgW8NQhR+Fi8s FaHbAEZuw691gEoZ22rXmWlCL5sbOQ==

;; Query time: 3 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Thu Sep 10 12:58:23 UTC 2026
;; MSG SIZE  rcvd: 173

まとめ

以上で、UnboundのTrust Anchorを起点として、Parent DNSの lab.test からChild DNSの child.lab.test、最終的に www.child.lab.test のAレコードまでDNSSECによる信頼の連鎖を構築できた。Unboundからの応答には ad フラグが付与され、DNSSEC検証に成功していることも確認できた。次回は、この正常な状態を基準として、署名やDSレコードを意図的に破壊し、DNSSEC検証がどのように失敗するかを確認する。

DNSSEC検証準備・DNS構築編

miyuki — Sat, 12 Sep 2026 12:50:49 +0000

はじめに

何をしたいか

DNSSECの信頼の連鎖を実際に構築し、DNS応答がどのように署名・検証されるのかを確認する。また、DNSSECに関する設定や署名を意図的に破壊し、検証失敗時にフルリゾルバやクライアントからどのように見えるのかを確認する。本記事では検証前の準備を記載。

準備・DNS構築編　本記事
DNSSEC構築編　https://cybermemo.blog/dnssec-lab-configuration
破壊・検証編　https://cybermemo.blog/dnssec-lab-testing

本記事で構築する構成

下記の通り、本記事ではDNSSECを使わず、普通のDNS名前解決を成立させることを目的とする。

              ┌─────────────┐
              │ Parent DNS  │　192.168.56.10/24
              │    BIND9    │　権威ゾーン: lab.test
              └──────┬──────┘
                     │
            child.lab.test を委任
                     │
                     ▼
              ┌─────────────┐　192.168.56.20/24
              │  Child DNS  │　権威ゾーン: child.lab.test
              │    BIND9    │　　　　　　　└─ www.child.lab.test → 192.168.56.100
              └─────────────┘
                     ▲
                     │ DNS問い合わせ
                     │
              ┌─────────────┐
              │  Resolver   │ 192.168.56.30/24
              │   Unbound   │
              └──────┬──────┘
                     ▲
                     │ DNS問い合わせ
              ┌─────────────┐
              │   Client    │ 192.168.56.40/24
              └─────────────┘

検証環境

構築

IP設定とシステムインストール

共通設定

IP設定

# IP情報確認(一部結果を抜粋)
$ ip addr

3: enp0s8:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

#設定ファイルの確認
$ sudo cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      dhcp4: true
      dhcp6: true
      match:
        macaddress: mac
      set-name: enp0s3
  version: 2

#バックアップ
$ sudo cp /etc/netplan/00-installer-config.yaml \
/etc/netplan/00-installer-config.yaml.bak

#編集
$ sudo vim /etc/netplan/00-installer-config.yaml

# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      dhcp4: true
      dhcp6: true
      match:
        macaddress: mac
      set-name: enp0s3

    enp0s8:
      dhcp4: false
      addresses:
        - 192.168.56.10(20,30,40)/24

  version: 2

#構文チェック
$ sudo netplan generate

#接続チェック
$ sudo netplan try
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in  xxx seconds
Configuration accepted.

#IP確認(一部結果を抜粋)
$ ip route
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.10

BIND（Parent DNS/Child DNS）のインストール

BINDと関連ツールのインストール

# システムのパッケージリストを更新
$ sudo apt update

# システムのインストール
$ sudo apt install bind9 bind9-utils dnsutils

# BINDのバージョンを確認
$ named -v
BIND 9.20.24-1ubuntu0.3-Ubuntu (Stable Release) 

# サービスの状態を確認
$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-09-02 13:32:41 UTC; 10min ago

bind9 → DNSサーバー本体（named）
bind9-utils → BIND/DNSSEC管理用ツール
dnsutils → digなどのDNS調査ツール

Unbound（Resolver）のインストール

フルリゾルバーのインストール

# システムのパッケージリストを更新
$ sudo apt update
# システムのインストール
$ sudo apt install unbound dnsutils
# サービスの状態を確認
$ systemctl status unbound
● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-09-04 12:07:41 UTC; 1min 19s ago

dnsutils（Client）のインストール

DNS調査ツールのインストール

# システムのパッケージリストを更新
$ sudo apt update
# システムのインストール
$ sudo apt install dnsutils
# バージョン確認
$ dig -v
DiG 9.20.24-1ubuntu0.3-Ubuntu

DNS設定

Parent DNS の基本設定

# BINDの設定ファイルを確認
$ ls -l /etc/bind/
total 20
-rw-r--r-- 1 xxxx yyyy 455 Jul 10 20:52 named.conf
-rw-r--r-- 1 xxxx yyyy  42 Jul 10 20:52 named.conf.local
-rw-r--r-- 1 xxxx yyyy  43 Jul 10 20:52 named.conf.options
-rw-r--r-- 1 xxxx yyyy 116 Jul 10 20:52 named.conf.root-hints
-rw-r----- 1 xxxx yyyy 100 Sep  2 13:32 rndc.key

# named.conf.local のバックアップ
sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

# ゾーンを定義
# 「lab.test について聞かれたら、/etc/bind/db.lab.test を見て答えます」という設定を記載
$ sudo vim /etc/bind/named.conf.local

zone "lab.test" {
    type primary;
    file "/etc/bind/db.lab.test";
};

# Parentのゾーンファイルを作成
$ sudo vim /etc/bind/db.lab.test

$TTL 3600

@   IN  SOA ns dnsmaster (
        2026090401 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN  NS  ns.lab.test.

ns  IN  A   192.168.56.10

# BIND全体の設定チェック
$ sudo named-checkconf

# ゾーンファイルをチェック
$ sudo named-checkzone lab.test /etc/bind/db.lab.test
zone lab.test/IN: loaded serial 2026090401
OK

# BINDを再読み込み
$ sudo systemctl reload bind9

# サービスの状態を確認
$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-09-04 12:25:10 UTC; 41min ago

# Parent自身に直接問い合わせる
$ dig @192.168.56.10 lab.test SOA

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.10 lab.test SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12120　　# エラーなし
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1　　# aa = Authoritative Answer。権威回答であることを示す

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a277f9c47bc5fcc9010000006a9ac27bfc5d5131662f9b64 (good)
;; QUESTION SECTION:
;lab.test.                      IN      SOA　　# lab.test.のSOAレコード要求

;; ANSWER SECTION:
lab.test.               3600    IN      SOA     ns.lab.test. dnsmaster.lab.test. 2026090401 3600 900 604800 86400　　# 設定したSOAレコードが反映されている

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Fri Sep 04 13:07:07 UTC 2026
;; MSG SIZE  rcvd: 114

$ dig @192.168.56.10 lab.test NS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.10 lab.test NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63569
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0a6d1db6342fb2d1010000006a9ac29ddae1218c4b0305b2 (good)
;; QUESTION SECTION:
;lab.test.                      IN      NS　　# lab.test.のNSレコード要求

;; ANSWER SECTION:
lab.test.               3600    IN      NS      ns.lab.test.　　# 設定したNSレコードが反映されている

;; ADDITIONAL SECTION:
ns.lab.test.            3600    IN      A       192.168.56.10　　# 追加情報 → ちなみに ns.lab.test. のIPアドレスは 192.168.56.10

;; Query time: 0 msec　　# 同じVMから同じラボ内のDNSへ問い合わせているので非常に高速
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)　　# 意図したParent BINDに問い合わせられている
;; WHEN: Fri Sep 04 13:07:41 UTC 2026
;; MSG SIZE  rcvd: 98

Child DNS の基本設定

# BINDの設定ファイルを確認
$ ls -l /etc/bind/
total 20
-rw-r--r-- 1 xxxx yyyy 455 Jul 10 20:52 named.conf
-rw-r--r-- 1 xxxx yyyy  42 Jul 10 20:52 named.conf.local
-rw-r--r-- 1 xxxx yyyy  43 Jul 10 20:52 named.conf.options
-rw-r--r-- 1 xxxx yyyy 116 Jul 10 20:52 named.conf.root-hints
-rw-r----- 1 xxxx yyyy 100 Sep  2 13:32 rndc.key

# named.conf.local のバックアップ
sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

# ゾーンを定義
# 「child.lab.test について聞かれたら、/etc/bind/db.child.lab.test を見て答えます」という設定を記載
$ sudo vim /etc/bind/named.conf.local

zone "child.lab.test" {
    type primary;
    file "/etc/bind/db.child.lab.test";
};

# Childのゾーンファイルを作成
$ sudo vim /etc/bind/db.child.lab.test

$TTL 3600

@   IN SOA ns dnsmaster (
        2026090401 ; Serial
        3600       ; Refresh
        900        ; Retry
        604800     ; Expire
        86400      ; Negative Cache TTL
)

    IN NS ns

ns  IN A 192.168.56.20
www IN A 192.168.56.100

# BIND全体の設定チェック
$ sudo named-checkconf

# ゾーンファイルをチェック
$ sudo named-checkzone child.lab.test /etc/bind/db.child.lab.test
zone child.lab.test/IN: loaded serial 2026090401
OK

# BINDを再読み込み
$ sudo systemctl reload bind9

# サービスの状態を確認
$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-09-04 12:25:13 UTC; 1h 15min ago

# Child自身に直接問い合わせる
$ dig @192.168.56.20 child.lab.test SOA

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.20 child.lab.test SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45719
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2235b8f90298a6ac010000006a9aca9e4d064bf9ef5ff1fb (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      SOA

;; ANSWER SECTION:
child.lab.test.         3600    IN      SOA     ns.child.lab.test. dnsmaster.child.lab.test. 2026090401 3600 900 604800 86400　　# 設定したSOAレコードが反映されている

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Fri Sep 04 13:41:50 UTC 2026
;; MSG SIZE  rcvd: 120

$ dig @192.168.56.20 child.lab.test NS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.20 child.lab.test NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22244
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 18cc501e70a95b5a010000006a9acaad689bc4f2bd82ac21 (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      NS

;; ANSWER SECTION:
child.lab.test.         3600    IN      NS      ns.child.lab.test.　　# 設定したNSレコードが反映されている

;; ADDITIONAL SECTION:
ns.child.lab.test.      3600    IN      A       192.168.56.20　　# 追加情報 → ちなみに ns.child.lab.test. のIPアドレスは 192.168.56.20

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Fri Sep 04 13:42:05 UTC 2026
;; MSG SIZE  rcvd: 104

$ dig @192.168.56.20 www.child.lab.test A　　# ここが ParentDNS と違う部分

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.20 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38021
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 572e7d93946f04eb010000006a9acbc2c6834dc08c91a8ae (good)
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; ANSWER SECTION:
www.child.lab.test.     3600    IN      A       192.168.56.100　　# 設定したwwwのAレコードが反映されている

;; Query time: 0 msec
;; SERVER: 192.168.56.20#53(192.168.56.20) (UDP)
;; WHEN: Fri Sep 04 13:46:42 UTC 2026
;; MSG SIZE  rcvd: 91

Parent DNS に child.lab.test の委任を設定

# ゾーンファイルをバックアップ
$ sudo cp /etc/bind/db.lab.test /etc/bind/db.lab.test.bak

$ sudo vim /etc/bind/db.lab.test        
2026090402 ; Serial　　　　　　　　# ゾーンファイルのシリアルを更新
child       IN NS ns.child
ns.child    IN A  192.168.56.20　　# ゾーンファイルの最下部に以下設定を追加

# BIND全体の設定チェック
$ sudo named-checkconf

# ゾーンファイルをチェック
$ sudo named-checkzone lab.test /etc/bind/db.lab.test
zone lab.test/IN: getaddrinfo(ns.child.lab.test) failed: Temporary failure in name resolution
zone lab.test/IN: loaded serial 2026090402
OK

# BINDを再読み込み
$ sudo systemctl reload bind9

# サービスの状態を確認
$ systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-09-04 12:25:10 UTC; 1h 40min ago

# Parent自身に直接問い合わせる(再帰問い合わせを要求する)　→　再帰処理では名前解決に失敗しSERVFAILとなった
dig @192.168.56.10 child.lab.test NS
; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.10 child.lab.test NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19522　　# SERVFAIL(サーバー側の異常で名前解決に失敗)
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fe9a881e33cb98ad010000006a9ad0c464bcd0c3c80d2cfc (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      NS

;; Query time: 3 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Fri Sep 04 14:08:04 UTC 2026
;; MSG SIZE  rcvd: 71

# Parent自身に直接問い合わせる(再帰問い合わせを要求しない)
$ dig +norecurse @192.168.56.10 child.lab.test NS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +norecurse @192.168.56.10 child.lab.test NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27945
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2　　## aa = Authoritative Answer のフラグなしなので、権威回答ではなく参照応答

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 79d7c1aedd81ea0e010000006a9ad0ba20d4d76f47b1c251 (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      NS

;; AUTHORITY SECTION:　　# child.lab.test については ns.child.lab.test に聞いてください。と返答されている
child.lab.test.         3600    IN      NS      ns.child.lab.test.　　# 設定したNSレコードが反映されている

;; ADDITIONAL SECTION:
ns.child.lab.test.      3600    IN      A       192.168.56.20　　# 追加情報 → ちなみに ns.child.lab.test. のIPアドレスは 192.168.56.20(グルーレコード)

;; Query time: 5 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Fri Sep 04 14:07:54 UTC 2026
;; MSG SIZE  rcvd: 104

$ dig +norecurse @192.168.56.10 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> +norecurse @192.168.56.10 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7879
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d24b4a0ee76a5063010000006a9ad5a7cc24a0022b2a437a (good)
;; QUESTION SECTION:
;www.child.lab.test.            IN      A

;; AUTHORITY SECTION:　　# child.lab.test については ns.child.lab.test に聞いてください。と返答されている
child.lab.test.         3600    IN      NS      ns.child.lab.test.　　# 設定したNSレコードが反映されている

;; ADDITIONAL SECTION:
ns.child.lab.test.      3600    IN      A       192.168.56.20　# 追加情報 → ちなみに ns.child.lab.test. のIPアドレスは 192.168.56.20(グルーレコード)。child.lab.test はChildDNSへ委任されているため、Parentは www.child.lab.test のAレコードを権威回答せず、委任先の情報を返す

;; Query time: 0 msec
;; SERVER: 192.168.56.10#53(192.168.56.10) (UDP)
;; WHEN: Fri Sep 04 14:28:55 UTC 2026
;; MSG SIZE  rcvd: 108

Resolver の設定

# 設定ファイルを確認
$ sudo cat /etc/unbound/unbound.conf
$ sudo find /etc/unbound -maxdepth 2 -type f -print

# ラボ用設定ファイルを新規作成
$ sudo vim /etc/unbound/unbound.conf.d/dns-lab.conf
server:
    interface: 192.168.56.30
    access-control: 192.168.56.0/24 allow

    local-zone: "test." transparent
    domain-insecure: "lab.test."

stub-zone:
    name: "lab.test."
    stub-addr: 192.168.56.10

# 構文チェック
$ sudo unbound-checkconf

# Unboundを再起動
$ sudo systemctl restart unbound

# サービスの状態を確認
$ systemctl status unbound
● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-09-08 13:27:42 UTC; 36s ago

$ dig @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62746
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A　　# www.child.lab.test のAレコードを問い合わせ

;; ANSWER SECTION:
www.child.lab.test.     3600    IN      A       192.168.56.100　　# 名前解決できている

;; Query time: 8 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Tue Sep 08 13:36:29 UTC 2026
;; MSG SIZE  rcvd: 63

Client で名前解決ができるか確認

$ dig @192.168.56.30 www.child.lab.test A

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.30 www.child.lab.test A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.child.lab.test.            IN      A　　# www.child.lab.test のAレコードを問い合わせ

;; ANSWER SECTION:
www.child.lab.test.     3187    IN      A       192.168.56.100　　# 名前解決できている

;; Query time: 3 msec
;; SERVER: 192.168.56.30#53(192.168.56.30) (UDP)
;; WHEN: Tue Sep 08 13:43:22 UTC 2026
;; MSG SIZE  rcvd: 63

おまけ

SERVFAIL エラーの検証

「Parent DNS に child.lab.test の委任を設定」で +norecurse（再帰問い合わせを要求しない）をつけないとSERVFAIL（サーバー側の異常で名前解決に失敗）となる原因を調査した。

検証

ターミナル1

# パケットキャプチャ(Parent DNS)
~$ sudo tcpdump -ni any port 53
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:12:22.481102 lo    In  IP 192.168.56.10.45482 > 192.168.56.10.53: 40442 [1au] NS? child.lab.test. (55)
12:12:22.481720 lo    In  IP 192.168.56.10.53 > 192.168.56.10.45482: 40442 0/1/2 (104)
12:12:32.346678 lo    In  IP 192.168.56.10.37116 > 192.168.56.10.53: 65160+ [1au] NS? child.lab.test. (55)
12:12:32.347314 enp0s8 Out IP 192.168.56.10.33827 > 192.168.56.20.53: 15920 [1au] NS? child.lab.test. (55)
12:12:32.348661 enp0s8 In  IP 192.168.56.20.53 > 192.168.56.10.33827: 15920* 1/0/2 NS ns.child.lab.test. (104)
12:12:32.350616 lo    In  IP 192.168.56.10.53 > 192.168.56.10.37116: 65160 ServFail 0/0/1 (71)

ターミナル2

$ dig +norecurse @192.168.56.10 child.lab.test NS
$ dig @192.168.56.10 child.lab.test NS

検証結果

+norecurse で問い合わせたとき

12:12:22.481102 lo    In  IP 192.168.56.10.45482 > 192.168.56.10.53: 40442 [1au] NS? child.lab.test. (55)

が問い合わせ。

Parent自身 → ParentのDNS(53番ポート)
「child.lab.test のNSを教えてください」
+norecurseなので「他のDNSへ問い合わせに行かなくていいです」

12:12:22.481720 lo    In  IP 192.168.56.10.53 > 192.168.56.10.45482: 40442 0/1/2 (104)

が回答。

Parent DNS → Parent DNS(dig)
0/1/2 = ANSWER 0件 / AUTHORITY 1件 / ADDITIONAL 2件

この 0/1/2 は、以前 dig で見た、

ANSWER: 0
AUTHORITY: 1
ADDITIONAL: 2

と同じもの。

このログから読み取れる全体の動きは下記。

dig
 │
 │「child.lab.testのNSは？」
 │「再帰しなくていいよ」
 ▼
Parent
 │
 │ 自分が持っている委任情報を見る
 │
 │「ns.child.lab.testに聞いて」
 ▼
dig

重要なのは、この通信にParent→Childの通信がないこと。
これが +norecurse の動き。

+norecurse なし

12:12:32.346678 lo    In  IP 192.168.56.10.37116 > 192.168.56.10.53: 65160+ [1au] NS? child.lab.test. (55)

が問い合わせ。

Parent自身 → Parent DNS
「child.lab.test のNSを教えてください」
今回は再帰要求あり

+norecurse とよく似たログだが、65160+ の + がポイント。
tcpdumpのDNS表示では、この + はRD（Recursion Desired）が立っていることを示す。

※tcpdump 公式GitHubリポジトリを参照
https://github.com/the-tcpdump-group/tcpdump/blob/master/print-domain.c
else { /* this is a request */ ND_PRINT("%u%s%s%s", GET_BE_U_2(np->id), ns_ops[DNS_OPCODE(flags)], DNS_RD(flags) ? "+" : "", DNS_CD(flags) ? "%" : "");

12:12:32.347314 enp0s8 Out IP 192.168.56.10.33827 > 192.168.56.20.53: 15920 [1au] NS? child.lab.test. (55)

が Child DNS への問い合わせ。

Parent DNS → Child DNS
Parentが「child.lab.test のNSを教えてください」とChildへ問い合わせた

12:12:32.348661 enp0s8 In  IP 192.168.56.20.53 > 192.168.56.10.33827: 15920* 1/0/2 NS ns.child.lab.test. (104)

が Child DNS からの回答。

Child DNS → Parent DNS
「child.lab.test のNSは ns.child.lab.test です」と回答
* はAA(Authoritative Answer)が立っていることを示す(上述のGitHubリポジトリを参照)

12:12:32.350616 lo    In  IP 192.168.56.10.53 > 192.168.56.10.37116: 65160 ServFail 0/0/1 (71)

が最終回答。

Parent DNS → Parent DNS(dig)
なぜか最終的に「名前解決に失敗しました(SERVFAIL)」と回答

このログから読み取れる全体の動きは下記。

dig
 │
 │ child.lab.test NS?
 │ RD=1「必要なら代わりに調べて」
 ▼
Parent
 │
 │ 委任情報を確認
 │
 ▼
Child
 │
 │「NSはns.child.lab.testです」
 │ AA=1
 ▼
Parent
 │
 │ ここまでは成功
 │
 ▼
dig

SERVFAIL(?)

tcpdump だけでは分からないので追加調査

# ジャーナル確認
journalctl -n 20
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 199.7.91.13#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 199.7.91.13#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 192.203.230.10#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 198.97.190.53#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 192.112.36.4#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 192.203.230.10#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 192.36.148.17#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 192.112.36.4#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 193.0.14.129#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 192.36.148.17#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 170.247.170.2#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 193.0.14.129#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving 'test/DS/IN': 192.33.4.12#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 170.247.170.2#53
Sep 08 12:55:33 dns-parent named[962]: network unreachable resolving './NS/IN': 192.33.4.12#53
Sep 08 12:55:33 dns-parent named[962]: broken trust chain resolving 'child.lab.test/NS/IN': 192.168.56.20#53
Sep 08 12:55:33 dns-parent named[962]: resolver priming query complete: failure

ルートDNSサーバーへの test/DS や ./NS の問い合わせが network unreachable となっている
broken trust chain resolving からDNSSECの信頼の連鎖を正常に検証できなかったことが判明

このログから読み取れる全体の動きは下記。

RD=1
 ↓
Parentが再帰処理開始
 ↓
自分の委任情報を利用
 ↓
192.168.56.20のChildへ問い合わせ
 ↓
Childが正常な権威回答
 ↓
Parentの再帰処理でDNSSEC検証を行おうとする
 ↓
test/DSなどを確認しようとする
 ↓
外部DNSへ到達できない
 ↓
broken trust chain
 ↓
SERVFAIL

ParentでDNSSECバリデータを無効化

SERVFAILの原因がDNSSEC validationにあるかを切り分けるため、Parent DNSのDNSSECバリデータを一時的に無効化して、同じ問い合わせを再度実行する。

# 現在の設定を確認
$ sudo named-checkconf -p | grep -i dnssec-validation

# バリデータを無効化
$ sudo vim /etc/bind/named.conf.options
options {
        dnssec-validation no;
        directory "/var/cache/bind";
};

# 設定を反映
$ sudo named-checkconf
$ sudo named-checkconf -p | grep -i dnssec-validation
        dnssec-validation no;
$ sudo systemctl restart bind9
$ sudo systemctl status bind9
● named.service - BIND Domain Name Server
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-09-14 05:13:14 UTC; 3s ago

# 応答確認
$ dig @192.168.56.10 child.lab.test NS

; <<>> DiG 9.20.24-1ubuntu0.3-Ubuntu <<>> @192.168.56.10 child.lab.test NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30374
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ebc0d93e19cce794010000006aa78836b8c315cc6e40ac14 (good)
;; QUESTION SECTION:
;child.lab.test.                        IN      NS

;; ANSWER SECTION:
child.lab.test.         2130    IN      NS      ns.child.lab.test.

ここまでの検証で分かるエラーまでの動きは下記。

Childから child.lab.test のNS応答を取得
        ↓
BINDのDNSSEC validationが有効
        ↓
この未署名応答を受け入れてよいか確認
        ↓
child.lab.test
        ↓
lab.test
        ↓
test
        ↓
「test にDSがあるか？」
        ↓
ルートサーバーへ test/DS を問い合わせ
        ↓
外部ネットワークなし
        ↓
network unreachable
        ↓
信頼状態を確定できない
        ↓
broken trust chain
        ↓
SERVFAIL

結論

Parent DNSではDNSSEC validationが有効だったので、再帰問い合わせ時にBINDはDNSSECの信頼状態を確認するため、ルートDNSへ test のDSレコードを問い合わせていた。
しかし、検証サーバーは外部ネットワークに接続していなかったため問い合わせに失敗し、DNSSECの信頼の連鎖を正常に検証できず、broken trust chain となってSERVFAILが返された。dnssec-validation no; として検証を無効化すると、同じ問い合わせは正常に名前解決できた。

まとめ

今回は、Parent DNS、Child DNS、Unbound、Clientを構築し、DNSSECを使用しない通常のDNS名前解決が正常に行えることを確認した。
次回は、この環境にDNSSECを導入し、Parent DNSとChild DNSの署名、DSレコードの登録、UnboundへのTrust Anchor設定を行い、DNSSECによる信頼の連鎖を構築する。

ファイル名にRLOが使われていたらRecentのLNKファイルもRLO表記になるの？

miyuki — Sun, 16 Aug 2026 05:53:41 +0000

はじめに

Microsoft Defender for Endpoint（MDE）でRLOに関連する検知が発生した際、RecentのLNKファイルにもRLOを含むファイル名がログ上で確認された事例があると聞き、今回の検証を実施。

検証の目的

セキュリティ製品上のログ分析において、RLOを含むファイル名やLNKファイル名がどのように表示される可能性があるのか確認したい。

セキュリティ製品上でのログ分析における懸念事項

セキュリティ製品によって収集するログや表示するフィールドが異なるため、アラート上に表示されるファイル名がWindows上のどの情報を基にしているのか判断しにくい。

懸念事項を解消するために検証をする

複数の条件で検証し、エクスプローラー上の表示、実際のUnicode文字列、LNKのメタデータがそれぞれどのように見えるか確認する。

実行環境と使用ツール

実行環境

エディション：Windows 11 Home
バージョン：25H2
OSビルド：26200.9168

使用ツール

LECmd

Windowsのショートカットファイルを解析するための無料のコマンドラインツール。

前提知識

RLO（Right-to-Left Override）とは

Unicode制御文字の一種で、RLOを挿入した位置から文字の表示方向を右から左へ強制的に変更するために使用される。本来はアラビア語など右から左へ読む言語を含む双方向テキストを扱うための仕組みの一つだが、ファイル名の表示順を変化させることで拡張子偽装などに悪用されることがある。
対になる制御文字として、左から右方向に上書きするLRO（Left-to-Right Override / U+202D）がある。

例.)
通常の表示例
sample.txt
RLOによって表示順が反転した場合の例
txt.elpmas

RLOがどのように悪用されるのか

文字列そのものを書き換えるのではなく、表示時の文字方向を上書きできるため、ファイル名の視覚的な偽装に悪用されることがある。

例. batファイルをPDFに偽装

サンプルファイルを用意

@echo off
echo ==============================
echo WARNING: TEST FILE EXECUTED
echo ==============================
echo.
echo This is an RLO test file.
echo.
pause

2. サンプルファイル名をRLOで「fdp.bat」とする

　F2（名前を変更）→ 右クリック → Unicode制御文字の挿入 → RLOを選択

　→ ファイル名「fdp.bat」と入力すると「tab.pdf」と表示される

3. 「tab.pdf」を実行すると、batファイルが起動する

4. 項番2の手順で簡単な偽装は完成。今回のサンプルではアイコンや種類を見ればbatファイルと気づけるが、実際の攻撃では他の手法と組み合わせて高度な偽装がされることがある。

5. おまけ

今回の検証では、少し時間差があったもののMicrosoft Defenderによってサンプルファイルが検知・検疫された。検証を行う際は、セキュリティ製品によって検知される可能性がある点にも注意。

RecentのLNKファイル

Recentフォルダとは

ユーザーが最近開いたファイルやフォルダのショートカットを自動的に保存するシステムフォルダ。
フォルダパス：C:\Users\ユーザー名\AppData\Roaming\Microsoft\Windows\Recent
※C: は環境依存。

LNKファイルとは

Windowsで使用されるショートカットファイル。リンク先のファイル本体を格納するのではなく、リンク先を特定・参照するための情報や各種メタデータを保持している。

RecentのLNKファイル

ユーザーが最近開いたファイルやフォルダのショートカット。Windowsが自動的に作成し、「最近使った項目」や「クイックアクセス」などに表示させるための履歴として使われる。

検証

ファイル名にRLOが含まれている場合のLNKファイル情報確認

1. テストファイル「xslx.tset」（RLO適用後の表示）を作成し、開いておく。

2. Recentフォルダへ移動し、テストエクセルのショートカットが作成されていることを確認。エクスプローラー上ではRLOによる表示順の変化がLNKファイル名にも引き継がれている。

3. PowerShellでLNKファイル名にRLOのコードポイントが入っているか確認。U+202E（RLOのコードポイント）が含まれているので、LNKファイル名のUnicode文字列にRLOが含まれていることをコマンド上からも確認できた。

> $file = Get-ChildItem | Where-Object { $_.Extension -eq ".lnk" -and $_.Name -like "*test.xlsx*" } | Select-Object -First 1
> $file.Name.ToCharArray() | ForEach-Object {
>>     "U+{0:X4}  {1}" -f [int]$_, $_
>> }
U+202E  ‮
U+0074  t
U+0065  e
U+0073  s
U+0074  t
U+002E  .
U+0078  x
U+006C  l
U+0073  s
U+0078  x
U+002E  .
U+006C  l
U+006E  n
U+006B  k

4. LECmdでメタ情報確認。

実行コード

LECmd.exe -f "E:\test.xlsx.lnk"

結果（一部抜粋）

    --------- Block 0 (Beef0004) ---------
    Long name: ?test.xlsx
    Created:     2026-08-15 09:34:06
    Last access: 2026-08-15 09:34:08
    MFT entry/sequence #: 463271/4 (0x711A7/0x4)

5. 項番4の結果から以下の情報が分かる。

①Long name: ?test.xlsx について

・「?」の部分がRLOに相当する位置と思われる。ただし、LECmdによる解析またはコンソールへの出力過程で「?」と表示されている可能性もあるため、この結果のみからLNK内部でU+202Eが「?」に置換されて保存されているとは判断できない。

・RLOを挿入した位置は「?」と表示され、それ以降のファイル名は「test.xlsx」と論理順で確認できた。エクスプローラー上のRLOによる視覚的な表示とは異なる結果となった。

②MFT entry/sequence #: 463271/4 (0x711A7/0x4)

・今回は検証しないが、LECmdの解析結果からMFTエントリ番号とシーケンス番号を取得できているため、MFTECmdなどを用いて $MFT を解析し、対象ファイルのMFTレコードと照合することで、さらに調査を深掘りできそう。

本文にRLOが含まれている場合のLNKファイル情報確認

1. テストファイル「test2.xlsx」を作成し、ファイル内にRLOを含む文字を入力。

2. Recentフォルダへ移動し、テストエクセルのショートカットが作成されていることを確認。エクスプローラー上では通常の左から右の順序で表示されている。

3. PowerShellでLNKファイル名にRLOのコードポイントが入っていないことを確認。U+202E（RLOのコードポイント）が含まれていないので、LNKファイル名のUnicode文字列にRLOが含まれていないことをコマンド上からも確認できた。

> $file = Get-ChildItem | Where-Object {
>>     $_.Extension -eq ".lnk" -and $_.Name -like "*test2.xlsx*"
>> } | Select-Object -First 1
> $file.Name.ToCharArray() | ForEach-Object {
>>       "U+{0:X4}  {1}" -f [int]$_, $_
>>   }
U+0074  t
U+0065  e
U+0073  s
U+0074  t
U+0032  2
U+002E  .
U+0078  x
U+006C  l
U+0073  s
U+0078  x
U+002E  .
U+006C  l
U+006E  n
U+006B  k

4. ファイル内の文字列にRLOが含まれていることを確認。

4-1. test2.xlsx の拡張子を変更し、test2.zip とする。

4-2. zipファイルを展開し、test2\xl\sharedStrings.xml のコードを確認。ブログ上の表示では分かりにくいが、このコードの線を引いた部分にはRLOが含まれており、エディタ上でカーソルを移動させると文字方向の変化も確認できた。











‮









test.xlsx

4-3. PowerShellでも確認。Trueが返ってくるので、RLOが含まれている。

> Get-ChildItem sharedStrings.xml
> $text = Get-Content ".\sharedStrings.xml" -Raw -Encoding UTF8
> $text.Contains([char]0x202E)
True

5. LECmdでメタ情報確認。

実行コード

LECmd.exe -f "E:\test2.xlsx.lnk"

結果（一部抜粋）

    --------- Block 0 (Beef0004) ---------
    Long name: test2.xlsx
    Created:     2026-08-15 12:41:26
    Last access: 2026-08-15 12:41:26
    MFT entry/sequence #: 463313/4 (0x711D1/0x4)

6. 本文にRLOが含まれていても、Recentに生成されたLNKファイル名への影響は確認できなかった。また、LECmdのLong nameにもRLOに相当する表示は確認されなかった。

ファイル名にRLOを含むファイルをコピー後、RLOを削除してリネームした場合のLNKファイル情報確認

1. ファイル名にRLOを含むファイル「xslx.tset」（RLO適用後の表示）をコピーし、「test3.xlsx」にリネーム後開いておく。

> $file = Get-ChildItem | Where-Object {
>>      $_.Extension -eq ".lnk" -and $_.Name -like "*test3.xlsx*"
>>  } | Select-Object -First 1
>  $file.Name.ToCharArray() | ForEach-Object {
>>        "U+{0:X4}  {1}" -f [int]$_, $_
>>    }
U+0074  t
U+0065  e
U+0073  s
U+0074  t
U+0033  3
U+002E  .
U+0078  x
U+006C  l
U+0073  s
U+0078  x
U+002E  .
U+006C  l
U+006E  n
U+006B  k

4. LECmdでメタ情報確認。

実行コード

LECmd.exe -f "E:\test3.xlsx.lnk"

結果（一部抜粋）

    --------- Block 0 (Beef0004) ---------
    Long name: test3.xlsx
    Created:     2026-08-16 04:01:58
    Last access: 2026-08-16 04:03:00
    MFT entry/sequence #: 463356/5 (0x711FC/0x5)

5. 項番3、4の結果から、RLOを含むファイルをコピーした後、ファイル名からRLOを削除してリネームした場合、今回生成されたLNKファイル名およびLECmdで確認したLong nameにはRLOの痕跡は確認できなかった。

その他

ファイル名にRLOが含まれている場合、Windowsのショートカットエラーに表示されるファイル名にもRLOによる表示順の変化が反映されることを確認できた。

検証結果

今回の検証では、「ファイル名にRLOを含めた場合」「Excelファイルの本文にのみRLOを含めた場合」「RLOを含むファイルをコピー後、ファイル名からRLOを削除した場合」の3パターンについて、Recentフォルダに生成されるLNKファイルを比較した。

検証内容	ファイル名のRLO	本文のRLO	LNKファイル名のRLO	LECmdのLong name
ファイル名にRLOを設定	あり	なし	あり	?test.xlsx
本文にRLOを設定	なし	あり	なし	test2.xlsx
ファイル名にRLOを含むファイルをコピー後、RLOを削除してリネームした場合	なし（コピー元はあり）	なし	なし	test3.xlsx

ファイル名にRLO（U+202E）が含まれている場合、Recentフォルダに生成されたLNKファイル名にもU+202Eが含まれていることを確認できた。一方、本文にのみRLOを含めた場合や、RLOを含むファイルをコピーした後にRLOを削除してリネームしてから開いた場合には、生成されたLNKファイル名からU+202Eは確認されなかった。
以上から、今回の検証環境および検証した条件ではRecentに生成されたLNKファイル名のRLOは文書本文やコピー元の過去のファイル名に由来する挙動は確認されず、対象ファイルを開いた時点のファイル名が反映されている可能性が高いと考えられる。

最後に

アラート分析の際にRLOを含むLNKファイル名が確認された場合や、?test.xlsx のようにファイル名に通常とは異なる記号が表示されている場合は、RLOなどのUnicode制御文字を利用したファイル名偽装の可能性も考慮して調査するのがよさそう。
MDEのログ上では、LNKファイル名にもRLOが含まれているように表示された事例があったようだが、セキュリティ製品によって取得するログや表示するフィールド、文字の表現方法などが異なる可能性があるため、アラート上の表示だけで判断せず、可能であれば実ファイル名のUnicodeコードポイントやLNKファイルの情報もあわせて確認したい。

『OSINT実践ガイド』紹介ツールまとめ

miyuki — Sun, 15 Feb 2026 11:05:31 +0000

はじめに

「サイバー攻撃から企業システムを守る！　OSINT実践ガイド」を読んだので、2章で紹介されていたツールのまとめ。

1章 OSINTの基礎
2章 OSINT必携ツールの使い方
3章 OSINT情報の可視化
4章グローバルでのOSINT活用事例

日経Linux

サイバー攻撃から企業システムを守る！　OSINT実践ガイド

2章で紹介されていたツールまとめ

リンクが変わっていたり、廃止になっていたりしたので、後で見返しやすいように記録。
※2026年2月時点

ユースケース	サービス名	URL	用途¹	備考
資産の外部公開状況を把握する	Shodan	https://developer.shodan.io/	公開サーバー、サービス、IoTデバイス、OTデバイスなど幅広い検索エンジン	画像検索は有償に変更
	Binary Edge	https://app.binaryedge.io	廃止
	Censys	https://platform.censys.io/search	詳細な検索フィルターで検索範囲を絞り込んで検索できる	クエリの仕様変更あり https://platform.censys.io/home/examples
	ZoomEye	https://www.zoomeye.ai/	中国企業が運営する検索エンジン	個人情報の登録が必要なので、個人学習の範囲では使わない
	FOFA	https://fofa.info/	中国企業が運営する検索エンジン	個人学習の範囲では使わない
パスワードが漏洩していないか調査する	Have I Been Pwned	https://haveibeenpwned.com/	パスワードや個人情報が漏洩していないか調べる
	DeHashed	https://dehashed.com/	パスワードや個人情報が漏洩していないか調べる
	BugMeNot	https://bugmenot.com/	認証情報が誰かと共有されていないか調べる
マルウェア情報を調査する	VirusTotal	https://www.virustotal.com/gui/home/upload	Googleが提供するマルウェア対策用のオンラインスキャナー
	ANY.RUN	https://any.run/	マルウェアを仮想環境で安全に実行する仕組みを提供する「サンドボックス」サービス	個人アカウントの登録は個別連絡をして審査が通った場合のみ可
	Joe Sandbox	https://www.joesandbox.com/#windows	ANY.RUNに類似するサンドボックス
	HYBRID ANALYSIS	https://hybrid-analysis.com/	VirusTotalに類似するオンラインスキャナー VirusTotal、CrowdStrike Falcon、MetaDefender 3種類のスキャンサービスの結果をまとめて確認できる
	Intezer	https://intezer.com/	ANY.RUNに類似するサンドボックス
Webサイトのレピュテーションを調査する	aguse	https://www.aguse.jp/	Webブラウザへ代理アクセス、日本企業が運営
	urlscan.io	https://urlscan.io/	Webブラウザへ代理アクセス
	urlquery	https://urlquery.net/	Webブラウザへ代理アクセス	UI変更あり List、Summary、Grid から選ぶ形式へ変更されているハッシュ値からURLを追跡できて便利
	Sucuri SiteCheck	https://sitecheck.sucuri.net/	Webサイトのレピュテーション調査可能な内容は、マルウェア感染の可能性があるかどうかとブラックリストに載っているかどうかのみ
	URLVoid	https://www.urlvoid.com/	Webサイトのレピュテーションマルウェア検知特化
	AbuseIPDB	https://www.abuseipdb.com/	ドメイン名やIPアドレス、IPアドレスレンジを指定してサイトが悪性か確認できる	レンジは/24まで、それ以上は不可
ゼロデイやエクスプロイトの有無を調査する	Zero-day Vulnerability Database	https://www.zero-day.cz/database/	「ソフトウェア種別」や「ベンダーごと」などの切り口でゼロデイ脆弱性を調べられる
	Published Advisories	https://www.zerodayinitiative.com/advisories/published/	トレンドマイクロの脆弱性情報提供サービス Upcoming Advisoriesにはゼロデイ脆弱性の一覧が掲載されている
	Exploit Database	https://www.exploit-db.com/	エクスプロイトの情報を集約したデータベース集約されているエクスプロイトの総数は多くないので補助的に使うのがいい
	Security home.eu	https://www.securityhome.eu/	セキュリティ関連情報を扱うWebサイト「Exploits」ページには、比較的新しいエクスプロイト情報が掲載されている
	Exploitalert	https://www.exploitalert.com/browse-exploit.html	廃止
Microsoft月齢セキュリティパッチについて情報収集する	Zero Day Initiative – Blog	https://www.zerodayinitiative.com/blog	トレンドマイクロ運営の脆弱性発見コミュニティーサイト
	Bleeping Computer	https://www.bleepingcomputer.com/	コンピューター関連の情報発信サイト
	SANS Internet Storm Center	https://isc.sans.edu/	米SANS Internet が運営している政府や企業、各種団体に所属する人々に対するITセキュリティ教育を目的としたサイト
自社に関する脆弱性情報収集を収集する	NVD	https://nvd.nist.gov/vuln/search	NISTが管理している脆弱性情報のデータベース	UI変更あり Advanced→Platform Applicability →Applicability Statement から各項目を入力して検索
	JVN iPedia	https://jvndb.jvn.jp/	日本国内向けの脆弱性対策情報ポータルサイト JPCERTコーディネーションセンターとIPAの共同運営
	Vulmon	https://vulmon.com/	CVE番号、会社名、製品名で検索可能な脆弱性データベース補助的利用推奨
	Vulnerability Database	https://www.cybersecurity-help.cz/	脆弱性データベース閲覧サイトエクスプロイトが公開されているかどうか、セキュリティパッチが提供されてるかどうかなども調べられる
	Vumetric Cybersecurity Portal	https://www.vumetric.com/	ダッシュボード形式で脆弱性情報を掲載しているポータルサイト
SSL/TLSのセキュリティ強度を確認する	SSL Server Test	https://www.ssllabs.com/ssltest	SSL/TLSのセキュリティ強度を調査できるサービス	アクティブスキャンサービス許可のないサイトを無暗にスキャンするのは非推奨スキャン結果をダッシュボードに表示させたくない場合は「Do not show the results on the boards」にチェック
SSL/TLSのセキュリティ強度を確認する	Test TLS	https://testtls.com/	SSL/TLSを利用しているサーバーを調査できるサービス	アクティブスキャンサービス許可のないサイトを無暗にスキャンするのは非推奨
失効したサーバー証明書の有無を確認する	Entrust Certificate Search	https://ui.ctsearch.entrust.com/ui/ctsearchui	廃止
失効したサーバー証明書の有無を確認する	Certificate Checker	https://ssltools.godaddy.com/views/certChecker	サーバー証明書の有効期間チェックやOCSPを利用した失効状態の確認、 SSL/TLS通信に関する脆弱性がサーバーに存在するかどうかの調査など
自己署名証明書(オレオレ証明書)の有無を調べる	SSL/TLS Certificate Test Tool	https://network-tools.webwiz.net/ssl-certificate-checker.htm	自己署名証明書が使用されていないかどうかや、証明書の有効期間、 SSL/TLSプロトコルの状況(有効/無効)などを確認できるアクティブスキャン型のサービス	アクティブスキャンサービス許可のないサイトを無暗にスキャンするのは非推奨
自己署名証明書(オレオレ証明書)の有無を調べる	Self Signed Certificate Checker	https://s4e.io/tools/self-signed-certificate-checker	自己署名証明書が使用されていないかどうかを確認できるアクティブスキャン型のサービス	アクティブスキャンサービス許可のないサイトを無暗にスキャンするのは非推奨
投稿写真から住所などを特定されないか調べる	Google画像検索	https://images.google.com/	画像ファイルをアップロードして検索すると、類似の画像を検索するとともに、それが何であるかを判定してくれる
	Bing画像検索	https://www.bing.com/	画像ファイルをアップロードして検索すると、類似の画像を検索するとともに、それが何であるかを判定してくれる
	TinEye	https://tineye.com/	画像ファイルをアップロードして検索すると、類似の画像を検索するとともに、それが何であるかを判定してくれる
メールアドレス漏洩の有無を調べる	Hunter	https://hunter.io/	世の中に出回っているメールアドレスを多数収集していて、それらを検索できるサービス命名規則も表示してくれる
メールアドレス漏洩の有無を調べる	Anymail Finder	https://anymailfinder.com/	インターネット上のメールアドレスを収集し検索できるようにしているサービス
IPアドレスの使用場所を特定する	MaxMind	https://www.maxmind.com/en/geoip-web-services-demo	IPアドレスから「経度・緯度」や「IPアドレスの正確さ(IPアドレスの観測地点から半径○○kmという距離」)などを調査できるサービス
IPアドレスの使用場所を特定する	eXTReMe-IP-Lookup.com	https://extreme-ip-lookup.com/	IPアドレスから場所の特定ができるサービス MaxMindよりは精度が高くない
WifiのSSIDが知れ渡っていないか調べる	WiGLE.net	https://www.wigle.net/	SSIDから場所を特定できるサービス
Exifデータの埋め込みをチェックする	EXIF Data Viewer Online	https://linangdata.com/exif-reader/	Exifデータを確認できるオンラインサービス
	exifdata	https://www.exifdata.com/	Exifデータを確認できるオンラインサービス
	EXIF確認君	http://exif-check.org/	Exifデータを確認できるオンラインサービス
アーカイブやキャッシュを活用する	Googleキャッシュ	なし	廃止
	Internet Archive	https://web.archive.org/	インターネット上の各種コンテンツをアーカイブしているサイト
	archive.today	https://archive.md/	インターネット上の各種コンテンツをアーカイブしているサイト URLを指定してアーカイブしてもらう機能も備えている
	ウェブ魚拓	https://megalodon.jp/	インターネット上のWebサイトをアーカイブしているサイト
自社のIPアドレス(レンジ)を把握する	WhatisMyIPaddress.com	https://whatismyipaddress.com/	インターネット側から見て自社の端末にどのようなIPアドレスが割り当てられているかを確認できるサービス
	確認君+	https://env.b4iine.net/	インターネット側から見て自社の端末にどのようなIPアドレスが割り当てられているかを確認できるサービス
	ipinfo.io	https://ipinfo.io/	IPアドレスからホスト名や都市名、国名、IPアドレスレンジなどを確認できるサービス
	IP WHOIS Lookup	https://dnschecker.org/ip-whois-lookup.php	IPアドレスやドメイン名などの登録者に関する情報などを検索できる、いわゆる「whois」サービス
使用しているWebテクノロジーを把握する	BuiltWith	https://builtwith.com/ja/	Webサイトで使われているWebテクノロジーを確認できるサイト
使用しているWebテクノロジーを把握する	Wappalyzer	https://www.wappalyzer.com/	Webサイトで使われているWebテクノロジーを確認できるサイト
IPアドレスやドメイン名の利用履歴を調べる	SecurityTrails	https://securitytrails.com/	様々なOSINT調査に使える「OSINT便利サイト」
	AbuseIPDB	https://www.abuseipdb.com/	IPアドレスが過去に悪用されていたか確認できるサイト
	DNS History	https://dnshistory.org/	IPアドレスの変更を含むDNSレコード変更履歴を確認できるサイト
送信ドメイン認証の対応状況をチェックする	EasyDMARK	https://easydmarc.com/tools	SPFやDKIM、DMARCの設定がされているかどうかを確認できるサイト
送信ドメイン認証の対応状況をチェックする	DKIM Record Checker	https://www.mimecast.com/products/dmarc-analyzer/dkim-check/	主にDKIMの設定がされているかどうかを確認できるサイト	リンクが変更され、セレクターの入力必須化
IoC情報を入手してインシデントに備える	AlienVaultOpenThreatExchange	https://otx.alienvault.com/	各種IoC情報を検索できるサービス
	ThreatMiner	https://www.threatminer.org/	IPアドレスやドメイン名、ファイルハッシュ値、メールアドレスなどのIoC情報を検索できるサービス
	ThreatFox IOC Database	https://threatfox.abuse.ch/browse/	IoCを格納したデータベースサービスを提供するサイト
フィッシング関連情報を入手する	PhishTank	https://www.phishtank.com/	フィッシング情報を集めたサイト
	OpenPhish	https://openphish.com/	更新頻度の高いフィッシング情報が集められているサイト
	isItPhishing	https://www.isitphishing.org/	URLを入力するだけでフィッシングに使われている疑いがあるサイトか判定してくれるサービス

一部文面は「OSINT実践ガイド」より引用 ↩︎

その他

所要時間

1～4章までを23時間48分で読了。
各サービスを実際に利用したり、規約の確認をしたり、メモを取ったりしながらだと時間がかかる。

著作権について

本記事は「サイバー攻撃から企業システムを守る！ OSINT実践ガイド」を参考に、
紹介されているツールを整理したものです。

表中の「ユースケース」「サービス名」は書籍の目次構成に基づいています。
「用途」については書籍の表現を必要最小限の範囲で引用しています。
「備考」および「URL」は、2026年2月時点で筆者が確認・検証の上記載しています。

本記事は書籍の内容を代替するものではありません。

外部結合ってどんな時に使うの？

miyuki — Sun, 14 Dec 2025 08:09:43 +0000

はじめに

SQLの勉強をしていて、外部結合をどんな時に使うのかイメージできなかったので調べてみた。

内部結合と外部結合の違い

内部結合（INNER JOIN）

両方のテーブルに 一致するデータがある行だけ 出す。
「関係が成立しているものだけ見たい」

外部結合（OUTER JOIN）

一致しない行も 欠けたまま（NULL）で出す。
「関係が成立していないものも把握したい」

”存在していない事実”を確認したいときが外部結合の出番。

サンプルデータを用意

シナリオ

登録だけして注文をしたことがない人を確認したい。

usersテーブル

登録ユーザーが記録されたテーブル。

user_id	name
1	Sato
2	Suzuki
3	Tanaka

ordersテーブル

注文履歴が記録されたテーブル。

order_id	user_id	amount
101	1	3000
102	3	1500

外部結合でデータを抽出する

SQLで左外部結合

SELECT
  u.user_id, u.name,
  o.order_id, o.order_date, o.amount
FROM users u
LEFT OUTER JOIN orders o
  ON u.user_id = o.user_id
ORDER BY u.user_id, o.order_id;

結果

Suzukiさんは ordersテーブルに対応するデータがないため、注文していないことが分かる。

user_id	name	order_id	order_date	amount
1	Sato	101	2025-12-06	3000
2	Suzuki	NULL	NULL	NULL
3	Tanaka	102	2025-12-07	1500

解説

左外部結合なので usersテーブルに ordersテーブルをくっつけている。
そのため、ordersテーブルに値がなくてもNULL表示される。
ordersテーブルの値がNULL = 注文をしたことがない人が分かる。

結論

外部結合は「ある／ない」を確認したいときに使える。

SQL構文メモ

miyuki — Sun, 14 Dec 2025 06:33:52 +0000

はじめに

自分用のSQL構文メモ。
MySQL用。

MySQLへのログイン

mysql -u ユーザー名 -p

データベース操作

データベース作成

CREATE DATABASE データベース名;

データベース削除

DROP DATABASE データベース名;

データベース一覧確認

SHOW DATABASES;

使用するデータベースの切り替え

USE データベース名;

現在使用中のデータベース確認

SELECT DATABASE();

テーブル操作

テーブル作成（基本）

CREATE TABLE テーブル名 (
フィールド名1 データ型,
フィールド名2 データ型
);

プライマリーキー・AUTO_INCREMENT付きテーブル作成

CREATE TABLE テーブル名 (
id INT AUTO_INCREMENT,
フィールド名 データ型,
PRIMARY KEY (id)
);

テーブル削除

DROP TABLE テーブル名;

テーブル一覧確認

SHOW TABLES;

テーブル定義確認

SHOW FIELDS FROM テーブル名;

フィールド（カラム）操作

フィールド追加

ALTER TABLE テーブル名 ADD 追加フィールド データ型 AFTER 既存フィールド;

フィールド削除

ALTER TABLE テーブル名 DROP 削除対象フィールド;

フィールド名変更

ALTER TABLE テーブル名 CHANGE 旧フィールド名 新フィールド名 データ型;

フィールドのデータ型変更

ALTER TABLE テーブル名 MODIFY フィールド名 データ型;

NOT NULL 制約の設定

ALTER TABLE テーブル名
MODIFY フィールド1 データ型 NOT NULL,
MODIFY フィールド2 データ型 NOT NULL;

デフォルト値の設定

ALTER TABLE テーブル名
ALTER フィールド名 SET DEFAULT 'デフォルト値';

プライマリーキー設定

ALTER TABLE テーブル名 ADD PRIMARY KEY (フィールド名);

外部キー制約設定

ALTER TABLE テーブル名
ADD FOREIGN KEY (外部キー列)
REFERENCES 参照先テーブル (主キー列);

ユーザー・権限管理

ユーザー作成

CREATE USER 'ユーザー名'@'localhost';

現在のユーザー確認

SELECT USER();

パスワード設定・変更

ALTER USER 'ユーザー名'@'localhost'
IDENTIFIED BY '新しいパスワード';

権限付与

GRANT 権限 ON データベース名.* TO 'ユーザー名'@'localhost';

主要権限一覧

権限名	対象	できること	実務での主な用途	危険度
SELECT	データ	データ参照のみ	参照専用、分析、レポート	低
INSERT	データ	レコード追加	登録処理、ログ保存	中
UPDATE	データ	レコード更新	ステータス・数量更新	中
DELETE	データ	レコード削除	物理削除が必要な処理	高
CREATE	構造	テーブル作成	開発作業	高
DROP	構造	テーブル削除	管理作業	非常に高
ALTER	構造	テーブル定義変更	カラム追加・変更	非常に高
INDEX	構造	インデックス作成・削除	パフォーマンス調整	中
REFERENCES	構造	外部キー制約作成	リレーション設計	中
ALL / ALL PRIVILEGES	全体	そのスコープ内の全権限	管理者・開発環境	非常に高
GRANT OPTION	権限	権限を他人に付与	DBA	非常に高

データ操作

レコード追加

INSERT INTO テーブル名 (フィールド1, フィールド2)
VALUES ('データ1', 'データ2');

レコード追加（全カラム指定）

INSERT INTO テーブル名 VALUES ('データ1', 'データ2');

レコード更新

UPDATE テーブル名
SET 更新方法¹
WHERE 条件;

レコード削除

DELETE FROM テーブル名 WHERE 条件;

SELECT文（検索）

全件取得

SELECT * FROM テーブル名;

重複除外

SELECT DISTINCT フィールド名 FROM テーブル名;

条件付き検索

SELECT フィールド名
FROM テーブル名
WHERE フィールド名 比較演算子 '条件'
AND / OR / NOT フィールド名 比較演算子 '条件';

主要な比較演算子一覧

演算子	意味	使用例	実務での主な用途
`=`	等しい	`age = 30`	完全一致検索（ID、コードなど）
`!=<>`	等しくない	`status != '削除'`	特定値を除外
`>`	より大きい	`score > 80`	閾値超過の判定
`<`	より小さい	`price < 1000`	上限チェック
`>=`	以上	`created_at >= '2025-01-01'`	開始日以降
`<=`	以下	`pdate <= CURDATE()`	今日以前など
`BETWEEN`	範囲指定（含む）	`age BETWEEN 20 AND 29`	年齢・期間指定
`IN`	いずれかに一致	`status IN ('未処理','保留')`	OR条件の簡略化
`NOT IN`	いずれにも一致しない	`id NOT IN (1,2,3)`	除外リスト
`LIKE`	部分一致	`name LIKE '%山田%'`	あいまい検索
`NOT LIKE`	部分一致しない	`name NOT LIKE '%テスト%'`	不要データ除外
`IS NULL`	NULL判定	`deleted_at IS NULL`	未設定データ抽出
`IS NOT NULL`	NULLでない	`memo IS NOT NULL`	入力済み判定
`EXISTS`	存在確認	`EXISTS (SELECT 1 …)`	サブクエリ存在チェック
`NOT EXISTS`	存在しない	`NOT EXISTS (SELECT 1 …)`	未対応データ抽出

よく一緒に使う論理演算子

演算子	意味	使用例
`AND`	両方満たす	`age >= 20 AND age < 30`
`OR`	どちらか満たす	`role = 'admin' OR role = 'user'`
`NOT`	否定	`NOT status = '削除'`

並び替え

SELECT フィールド名
FROM テーブル名
ORDER BY フィールド名 ASC / DESC;

件数制限

SELECT フィールド名
FROM テーブル名
ORDER BY フィールド名
LIMIT 件数;

集計・グループ化

GROUP BY + 集計関数

SELECT フィールド名, 集計関数
FROM テーブル名
GROUP BY フィールド名;

主要な集計関数一覧

集計関数	意味	使用例	実務での主な用途
`COUNT(*)`	行数を数える（NULL含む）	`COUNT(*)`	件数集計、レコード数確認
`COUNT(フィールド)`	NULLを除いた件数	`COUNT(score)`	入力済み件数の把握
`SUM(フィールド)`	合計値	`SUM(amount)`	売上合計、数量合計
`AVG(フィールド)`	平均値	`AVG(score)`	平均点、平均金額
`MIN(フィールド)`	最小値	`MIN(price)`	最安値、最古日付
`MAX(フィールド)`	最大値	`MAX(price)`	最高値、最新日付

別名（エイリアス）

SELECT フィールド名 AS 別名
FROM テーブル名;

JOIN（結合）

内部結合（INNER JOIN）

SELECT t1.フィールド, t2.フィールド
FROM テーブル1 AS t1
INNER JOIN テーブル2 AS t2
ON 条件²

外部結合（LEFT / RIGHT JOIN）

SELECT t1.フィールド, t2.フィールド
FROM テーブル1 AS t1
LEFT / RIGHT OUTER JOIN テーブル2 AS t2
ON 条件;

完全外部結合（FULL OUTER JOIN）

MySQLでは FULL OUTER JOIN は未対応

SELECT t1.フィールド, t2.フィールド
FROM テーブル1 AS t1
FULL OUTER JOIN テーブル2 AS t2
ON 条件;

MySQLでの代替方法（UNION）

SELECT t1.フィールド, t2.フィールド
FROM テーブル1 AS t1
LEFT JOIN テーブル2 AS t2
ON 条件
UNION
SELECT t1.フィールド, t2.フィールド
FROM テーブル1 AS t1
RIGHT JOIN テーブル2 AS t2
ON 条件;

※ UNION は重複行を除外する。重複を許可したい場合は UNION ALL を使用する。
※ WHERE 句で結合先テーブルの条件を指定すると、外部結合の意味が失われることがあるため注意。

インデックス

インデックス作成

CREATE INDEX インデックス名 ON テーブル名 (フィールド名);

インデックス削除

DROP INDEX インデックス名 ON テーブル名;

インデックスの利用状況確認

EXPLAIN SELECT 文;

トランザクション

トランザクション開始

BEGIN;

確定

COMMIT;

取り消し

ROLLBACK;

SQLファイルの実行（データ展開）

SOURCE ファイルパス;

フィールド名 = フィールド名 + 1 など ↩︎
t1.フィールド = t2.フィールドなど ↩︎

Nmapでポートスキャンをしてみる

miyuki — Sun, 26 Oct 2025 07:50:12 +0000

はじめに

Nmapで実際にポートスキャンをしてみた。
検証環境は TryHackMe の Nmap ルーム。

TCPスキャン

使用頻度上位 100 ポートのみ（–top-ports 100）、スキャン中の詳細を表示（-vv）、pingをスキップ（-Pn）して
TCPスキャン（-sT）。

$ sudo nmap -sT --top-ports 100 -vv -Pn target ip

openポートを発見。

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-23 23:57 JST
Initiating Parallel DNS resolution of 1 host. at 23:57
Completed Parallel DNS resolution of 1 host. at 23:57, 0.00s elapsed
Initiating Connect Scan at 23:57
Scanning target ip [100 ports]
Discovered open port 3389/tcp on target ip
Discovered open port 135/tcp on target ip
Discovered open port 80/tcp on target ip
Discovered open port 21/tcp on target ip
Discovered open port 53/tcp on target ip
Completed Connect Scan at 23:57, 7.02s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set (0.37s latency).
Scanned at 2025-10-23 23:57:10 JST for 7s
Not shown: 95 filtered tcp ports (no-response)
PORT     STATE SERVICE       REASON
21/tcp   open  ftp           syn-ack
53/tcp   open  domain        syn-ack
80/tcp   open  http          syn-ack
135/tcp  open  msrpc         syn-ack
3389/tcp open  ms-wbt-server syn-ack

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 7.03 seconds

tshark でログを取っていたので確認してみる。

# tshark の結果を sT_result.txt へ出力
$ sudo tshark -i tun0 > sT_result.txt 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'tun0'
237 ^C

# cat で全体のログを確認
$ cat sT_result.txt             
    1 0.000000000   host ip → target ip TCP 60 34450 → 111 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    2 0.000013296   host ip → target ip TCP 60 47774 → 113 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    3 0.000018708   host ip → target ip TCP 60 38474 → 135 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    4 0.000025294   host ip → target ip TCP 60 55670 → 5900 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    5 0.000030624   host ip → target ip TCP 60 46124 → 25 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    6 0.000035786   host ip → target ip TCP 60 59490 → 554 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    7 0.000041544   host ip → target ip TCP 60 38960 → 3306 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    8 0.000048233   host ip → target ip TCP 60 57882 → 110 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
    9 0.000052118   host ip → target ip TCP 60 42396 → 3389 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
   10 0.000059820   host ip → target ip TCP 60 37896 → 8888 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245774735 TSecr=0 WS=128
   11 0.377319586 target ip → host ip   TCP 52 135 → 38474 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   12 0.377390839   host ip → target ip TCP 40 38474 → 135 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   13 0.378715797   host ip → target ip TCP 40 38474 → 135 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   14 0.378932212   host ip → target ip TCP 60 47616 → 23 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245775114 TSecr=0 WS=128
   15 0.378957703   host ip → target ip TCP 60 43838 → 995 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245775114 TSecr=0 WS=128
   16 1.027607473   host ip → target ip TCP 60 [TCP Retransmission] 37896 → 8888 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245775763 TSecr=0 WS=128
（省略）

ログを絞って確認。

# SYN 以外のログで絞ってみる
$ cat sT_result.txt | grep -v -F "[SYN]"
   11 0.377319586 target ip → host ip   TCP 52 135 → 38474 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   12 0.377390839   host ip → target ip TCP 40 38474 → 135 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   13 0.378715797   host ip → target ip TCP 40 38474 → 135 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   28 2.268681269 target ip → host ip   TCP 52 135 → 38490 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   29 2.268724628   host ip → target ip TCP 40 38490 → 135 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   30 2.268783378   host ip → target ip TCP 40 38490 → 135 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   61 3.272603426 target ip → host ip   TCP 52 21 → 43260 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   62 3.272698420   host ip → target ip TCP 40 43260 → 21 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   63 3.273334678 target ip → host ip   TCP 52 53 → 58022 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   64 3.273357934   host ip → target ip TCP 40 58022 → 53 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   65 3.273693028   host ip → target ip TCP 40 43260 → 21 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   66 3.274013386   host ip → target ip TCP 40 58022 → 53 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   77 3.274796974 target ip → host ip   TCP 52 80 → 49068 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   78 3.274865411   host ip → target ip TCP 40 49068 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   79 3.274951087   host ip → target ip TCP 40 49068 → 80 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
   84 3.387604406 target ip → host ip   TCP 52 3389 → 42396 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288 WS=1 SACK_PERM
   85 3.387628199   host ip → target ip TCP 40 42396 → 3389 [RST] Seq=1 Win=0 Len=0
  150 4.998246831 target ip → host ip   TCP 52 135 → 38502 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
  151 4.998329872   host ip → target ip TCP 40 38502 → 135 [ACK] Seq=1 Ack=1 Win=64256 Len=0
  152 4.998587904   host ip → target ip TCP 40 38502 → 135 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0
  232 6.277318520 target ip → host ip   TCP 52 3389 → 42398 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288 WS=1 SACK_PERM
  233 6.277337412   host ip → target ip TCP 40 42398 → 3389 [RST] Seq=1 Win=0 Len=0
  235 6.857444881 target ip → host ip   TCP 52 135 → 38504 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
  236 6.857524021   host ip → target ip TCP 40 38504 → 135 [ACK] Seq=1 Ack=1 Win=64256 Len=0
  237 6.858089282   host ip → target ip TCP 40 38504 → 135 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0

# SYN/ACK（open）で絞ってみる
$ cat sT_result.txt | grep -F "[SYN, ACK]"
   11 0.377319586 target ip → host ip   TCP 52 135 → 38474 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   28 2.268681269 target ip → host ip   TCP 52 135 → 38490 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   61 3.272603426 target ip → host ip   TCP 52 21 → 43260 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   63 3.273334678 target ip → host ip   TCP 52 53 → 58022 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   77 3.274796974 target ip → host ip   TCP 52 80 → 49068 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   84 3.387604406 target ip → host ip   TCP 52 3389 → 42396 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288 WS=1 SACK_PERM
  150 4.998246831 target ip → host ip   TCP 52 135 → 38502 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
  232 6.277318520 target ip → host ip   TCP 52 3389 → 42398 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288 WS=1 SACK_PERM
  235 6.857444881 target ip → host ip   TCP 52 135 → 38504 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM

# openポートの確認
$ cat sT_result.txt | grep -F "[SYN, ACK]" | awk '{print $8}' | sort -n -u
21
53
80
135
3389

SYN/ACK を返しているポートが open と判定されており、nmap のスキャン結果と tshark のログが一致していることが確認できた。

最後に、awk を使って TCP ハンドシェイク（SYN → SYN/ACK → ACK）が実際に成立しているかを確認してみる。

$ awk '    
  # 行中の「 → 」を1組だけ抜き出す
  match($0, /[[:space:]]([0-9]+)[[:space:]]*→[[:space:]]*([0-9]+)[[:space:]]/, m) {
    if (m[1]==21 || m[2]==21) print  
  }      
' sT_result.txt
   52 2.896504834   host ip → target ip TCP 60 43260 → 21 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=245777632 TSecr=0 WS=128
   61 3.272603426 target ip → host ip   TCP 52 21 → 43260 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1288 WS=256 SACK_PERM
   62 3.272698420   host ip → target ip TCP 40 43260 → 21 [ACK] Seq=1 Ack=1 Win=64256 Len=0
   65 3.273693028   host ip → target ip TCP 40 43260 → 21 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0

TCP ハンドシェイクが成立していることが分かる。

SYNスキャン（ハーフオープンスキャン）

使用頻度上位 100 ポートのみ（–top-ports 100）、スキャン中の詳細を表示（-vv）、pingをスキップ（-Pn）して
SYNスキャン（-sS）。

$ sudo nmap -sS --top-ports 100 -vv -Pn target ip

openポートを発見。

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-26 13:06 JST
Initiating Parallel DNS resolution of 1 host. at 13:06
Completed Parallel DNS resolution of 1 host. at 13:06, 0.00s elapsed
Initiating SYN Stealth Scan at 13:06
Scanning target ip [100 ports]
Discovered open port 80/tcp on target ip
Discovered open port 21/tcp on target ip
Discovered open port 3389/tcp on target ip
Discovered open port 135/tcp on target ip
Discovered open port 53/tcp on target ip
Completed SYN Stealth Scan at 13:06, 6.14s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set (0.34s latency).
Scanned at 2025-10-26 13:06:36 JST for 7s
Not shown: 95 filtered tcp ports (no-response)
PORT     STATE SERVICE       REASON
21/tcp   open  ftp           syn-ack ttl 124
53/tcp   open  domain        syn-ack ttl 124
80/tcp   open  http          syn-ack ttl 124
135/tcp  open  msrpc         syn-ack ttl 124
3389/tcp open  ms-wbt-server syn-ack ttl 124

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 6.20 seconds
           Raw packets sent: 197 (8.668KB) | Rcvd: 7 (308B)

今度は pcap でログを取ってみる。

$ sudo tshark -i tun0 -w /tmp/Ss_result.pcap                                 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'tun0'
211 ^C

# tshark で全体のログを確認
$ sudo tshark -r Ss_result.pcap                     
Running as user "root" and group "root". This could be dangerous.
    1 0.000000000   host ip → target ip TCP 44 63626 → 993 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    2 0.000010601   host ip → target ip TCP 44 63626 → 445 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    3 0.000011875   host ip → target ip TCP 44 63626 → 110 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    4 0.000012902   host ip → target ip TCP 44 63626 → 23 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    5 0.000013856   host ip → target ip TCP 44 63626 → 111 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    6 0.000014615   host ip → target ip TCP 44 63626 → 80 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    7 0.000015329   host ip → target ip TCP 44 63626 → 3389 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    8 0.000016047   host ip → target ip TCP 44 63626 → 113 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    9 0.000016757   host ip → target ip TCP 44 63626 → 21 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
   10 0.000017461   host ip → target ip TCP 44 63626 → 587 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
   11 0.338039856 target ip → host ip   TCP 44 80 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   12 0.338076236   host ip → target ip TCP 40 63626 → 80 [RST] Seq=1 Win=0 Len=0
   13 0.338747181 target ip → host ip   TCP 44 21 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   14 0.338809373   host ip → target ip TCP 40 63626 → 21 [RST] Seq=1 Win=0 Len=0
   15 0.339557912 target ip → host ip   TCP 44 3389 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288
   16 0.339571791   host ip → target ip TCP 40 63626 → 3389 [RST] Seq=1 Win=0 Len=0
(省略)

ログを絞って確認。

# SYN 以外のログで絞ってみる
$ sudo tshark -r sS_result.pcap -Y "not (tcp.flags.syn==1 && tcp.flags.ack==0)"
Running as user "root" and group "root". This could be dangerous.
   11 0.338039856 target ip8 → host ip   TCP 44 80 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   12 0.338076236   host ip → target ip8 TCP 40 63626 → 80 [RST] Seq=1 Win=0 Len=0
   13 0.338747181 target ip8 → host ip   TCP 44 21 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   14 0.338809373   host ip → target ip8 TCP 40 63626 → 21 [RST] Seq=1 Win=0 Len=0
   15 0.339557912 target ip8 → host ip   TCP 44 3389 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288
   16 0.339571791   host ip → target ip8 TCP 40 63626 → 3389 [RST] Seq=1 Win=0 Len=0
   23 0.677269837 target ip8 → host ip   TCP 44 135 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   24 0.677332313   host ip → target ip8 TCP 40 63626 → 135 [RST] Seq=1 Win=0 Len=0
   55 3.165016037 target ip8 → host ip   TCP 44 53 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   56 3.165076706   host ip → target ip8 TCP 40 63626 → 53 [RST] Seq=1 Win=0 Len=0
   57 3.165703655 target ip8 → host ip   TCP 44 80 → 63631 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   58 3.165753573   host ip → target ip8 TCP 40 63631 → 80 [RST] Seq=1 Win=0 Len=0
  173 4.863356730 target ip8 → host ip   TCP 44 80 → 63633 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
  174 4.863426175   host ip → target ip8 TCP 40 63633 → 80 [RST] Seq=1 Win=0 Len=0

# SYN/ACK（open）で絞ってみる
$ sudo tshark -r sS_result.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==1"
Running as user "root" and group "root". This could be dangerous.
   11 0.338039856 target ip8 → host ip   TCP 44 80 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   13 0.338747181 target ip8 → host ip   TCP 44 21 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   15 0.339557912 target ip8 → host ip   TCP 44 3389 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64000 Len=0 MSS=1288
   23 0.677269837 target ip8 → host ip   TCP 44 135 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   55 3.165016037 target ip8 → host ip   TCP 44 53 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   57 3.165703655 target ip8 → host ip   TCP 44 80 → 63631 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
  173 4.863356730 target ip8 → host ip   TCP 44 80 → 63633 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288

# openポートの確認
$ sudo tshark -r sS_result.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==1" -T fields -e tcp.srcport | sort -n -u
Running as user "root" and group "root". This could be dangerous.
21
53
80
135
3389

SYN/ACK を返しているポートが open になっているので、nmap の結果と tshark のログは一致している。

ハーフオープンスキャン（SYN→SYN/ACK→RST）を本当にしているか確認してみる。

$ sudo tshark -r sS_result.pcap -Y "tcp.port == 21"                            
Running as user "root" and group "root". This could be dangerous.
    9 0.000016757   host ip → target ip TCP 44 63626 → 21 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
   13 0.338747181 target ip → host ip   TCP 44 21 → 63626 [SYN, ACK] Seq=0 Ack=1 Win=64400 Len=0 MSS=1288
   14 0.338809373   host ip → target ip TCP 40 63626 → 21 [RST] Seq=1 Win=0 Len=0

SYN/ACK に対して RST で切断しているため、ハーフオープンスキャンの挙動。

UDPスキャン

使用頻度上位 100 ポートのみ（–top-ports 100）、スキャン中の詳細を表示（-vv）、pingをスキップ（-Pn）して
UDPスキャン（-sU）。

$ sudo nmap -sU --top-ports 100 -vv -Pn target ip

openポートを発見。

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-26 14:03 JST
Initiating Parallel DNS resolution of 1 host. at 14:03
Completed Parallel DNS resolution of 1 host. at 14:03, 0.00s elapsed
Initiating UDP Scan at 14:03
Scanning target ip [100 ports]
Discovered open port 53/udp on target ip
Completed UDP Scan at 14:03, 12.09s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set (0.36s latency).
Scanned at 2025-10-26 14:03:17 JST for 11s
Not shown: 99 open|filtered udp ports (no-response)
PORT   STATE SERVICE REASON
53/udp open  domain  udp-response ttl 124

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 12.15 seconds
           Raw packets sent: 261 (16.044KB) | Rcvd: 4 (262B)

pcap でログを取ってみる。

$ sudo tshark -i tun0 -w /tmp/sU_result.pcap                                            
Running as user "root" and group "root". This could be dangerous.
Capturing on 'tun0'
273 ^C

今回は Wireshar でログを確認してみる。

$ sudo wireshark sU_result.pcap

ip.src == target ip で応答のあったものだけ絞る。

ip.src == target ip && not icmp

DNS のみ表示されたので、nmap の結果と一致。

特殊スキャン（NULL／FIN／Xmas）

検証環境でopenポートが見つからなかったので、今回はフラグだけ確認。

NULLスキャン

# NULLスキャン
$ sudo nmap -sN --top-ports 100 -vv -Pn target ip

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-26 14:57 JST
Initiating Parallel DNS resolution of 1 host. at 14:57
Completed Parallel DNS resolution of 1 host. at 14:57, 0.00s elapsed
Initiating NULL Scan at 14:57
Scanning target ip [100 ports]
Completed NULL Scan at 14:57, 21.11s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set.
Scanned at 2025-10-26 14:57:12 JST for 22s
All 100 scanned ports on target ip are in ignored states.
Not shown: 100 open|filtered tcp ports (no-response)

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 21.15 seconds
           Raw packets sent: 200 (8.000KB) | Rcvd: 0 (0B)

フラグはすべて0。

FINスキャン

# FINスキャン
$ sudo nmap -sF --top-ports 100 -vv -Pn target ip

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-26 14:52 JST
Initiating Parallel DNS resolution of 1 host. at 14:52
Completed Parallel DNS resolution of 1 host. at 14:52, 0.00s elapsed
Initiating FIN Scan at 14:52
Scanning target ip [100 ports]
Completed FIN Scan at 14:52, 21.09s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set.
Scanned at 2025-10-26 14:52:08 JST for 21s
All 100 scanned ports on target ip are in ignored states.
Not shown: 100 open|filtered tcp ports (no-response)

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 21.18 seconds
           Raw packets sent: 200 (8.000KB) | Rcvd: 0 (0B)

FIN = 1。

Xmasスキャン

# Xmasスキャン
$ sudo nmap -sX --top-ports 100 -vv -Pn target ip

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-26 14:52 JST
Initiating Parallel DNS resolution of 1 host. at 14:52
Completed Parallel DNS resolution of 1 host. at 14:52, 0.01s elapsed
Initiating XMAS Scan at 14:52
Scanning target ip [100 ports]
Completed XMAS Scan at 14:53, 21.09s elapsed (100 total ports)
Nmap scan report for target ip
Host is up, received user-set.
Scanned at 2025-10-26 14:52:53 JST for 21s
All 100 scanned ports on target ip are in ignored states.
Not shown: 100 open|filtered tcp ports (no-response)

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 21.16 seconds
           Raw packets sent: 200 (8.000KB) | Rcvd: 0 (0B)

FIN = 1、PSH = 1、URG = 1。

おまけ

UDPスキャンでホストIPとターゲットIP以外に 239.255.255.250（SSDP¹用マルチキャストアドレス）への通信を発見。

nmapはスキャン中に「このネットワーク内にUPnP²デバイスがいるか？」を自動的にチェックすることがあり、その時にこの宛先へ M-SEARCH * HTTP/1.1 パケットを送信するそう。

家庭内ネットワークなどで機器同士が自動的に見つけ合うための通信プロトコル。UPnPの一部として定義されており、主にUDPの1900番ポートを使う。 ↩︎
Universal Plug and Play。家庭やオフィス内のネットワーク機器が自動的に見つけ合い、設定なしで通信できるようにする仕組み。 ↩︎

Nmapの基礎

miyuki — Sun, 26 Oct 2025 07:05:12 +0000

Nmapとは

Nmap（Network Mapper）は、ネットワーク上の機器やサービスを調べるための最もポピュラーなツール。IPアドレスの“生死確認（ホストが生きているか）”から、どのポートでどんなサービスが動いているか、さらに一部の脆弱性の有無まで発見できる。

スキャンの種類

実際にスキャンを実行した記事はこちら。

セキュリティエンジニアの雑多ブロ…

Nmapでポートスキャンをしてみる | セキュリティエンジニアの雑多ブログはじめに Nmapで実際にポートスキャンをしてみた。検証環境は TryHackMe の Nmap ルーム。本記事の内容は教育目的のみに記載しています。実環境での悪用は犯罪行為です。…

TCPスキャン

何をするか：TCP接続（SYN→SYN/ACK→ACK）を完了させる。
返ってくるもの：SYN/ACK（open）／RST（closed）／無応答（filtered）。
長所：確実で簡単（OS 標準の接続なので結果は信頼できる）。
短所：ログに残りやすく検出されやすい。
オプション：-sT

SYNスキャン

何をするか：SYNを送り、SYN/ACKを受けたら自分はRSTで接続を切る（3ウェイを完了させない）。
返ってくるもの：SYN/ACK（open）、RST（closed）、無応答（filtered）。
長所：早くてステルス寄り（ログに残りにくい）。多くの場合デフォルトで使われる。
短所：root権限が必要。IDSに検出される可能性はある。
オプション：-sS

UDPスキャン

何をするか：UDPパケットを送って応答（ICMP unreachable や UDP 応答）を待つ。
返ってくるもの：UDP応答（open|filtered判定）、ICMP Port Unreachable（closed）、無応答（open|filtered）。
長所：TCP以外のサービス（DNS, SNMP 等）を見つけられる。
短所：遅い（再送や ICMP 制限のため）、ファイアウォールやICMPレート制限で誤判定しやすい。
オプション：-sU

NULLスキャン

何をするか：TCPフラグをすべて 0 にしたパケットを送る（SYN/ACK/FIN/… いずれも 0）。
返ってくるもの（一般）：
Linux/UNIX系：何も返さない（open）かRSTで返す（closed）など実装差がある。
Windows系：通常すべてのポートで RST を返す（これだと区別つかない）。
長所：一部のOSでステルスに振る舞う。
短所：実装依存で結果が解釈しづらい。ファイアウォールで無効化されることが多い。
オプション：-sN

FINスキャン

何をするか：TCPの FIN フラグのみを立てたパケットを送る。
返ってくるもの：TCP 実装により、閉じているポートは RST を返し、開いているポートは無応答（特定OSでは）→ これで判別する。
長所：一部の環境で検出されにくい。
短所：Windows系は常に RST を返すため無意味。ファイアウォールでドロップされると判別不能。
オプション：-sF

Xmasスキャン

何をするか：TCPの FIN, PSH, URG フラグを同時に立てた「派手な」パケットを送る（ツリーが光るから Xmas）。
返ってくるもの：FIN と同様、ある実装では無応答＝open、RST＝closed。
長所：NULL/FIN と同じく、一部OSでステルスに有効。
短所：同じく実装依存で不確実。Windowsでは通用しないことが多い。
オプション：-sX

ICMPスキャン

何をするか：ICMP Echo Request（ping）や他のICMP型を使ってホストがオンラインかを調べる。
返ってくるもの：Echo Reply（Up）／無応答（Down or filtered）／ICMP unreachable（到達不可）など。
長所：ホストの存在確認が速く簡単。
短所：多くのホストやファイアウォールがICMPをブロックするため誤判定が起きやすい。ARP ping はローカルで有効。
オプション：-sn -PE（ICMP echo）、–disable-arp-ping 等で挙動調整

TCPフラグ

フラグ、ビット、フラグの意味を記載。
ビット(値)は tshark のフィルターとかで結構使う。

ビット(値)	フラグ	意味
0 (0x01)	FIN	コネクション終了
1 (0x02)	SYN	コネクション開始要求
2 (0x04)	RST	リセット（接続拒否/異常終了）
3 (0x08)	PSH	受信側にデータを即座に渡す（push）
4 (0x10)	ACK	応答番号を有効にする（確認応答）
5 (0x20)	URG	緊急ポインタ有効（ほぼ使われない）
6 (0x40)	ECE	ECN related（輻輳制御）
7 (0x80)	CWR	ECN related（輻輳制御）

視覚的ビット列図（よく見る組み合わせ）

フラグ	ビット	値
FIN	0000 0001	0x01
SYN	0000 0010	0x02
RST	0000 0100	0x04
PSH	0000 1000	0x08
ACK	0001 0000	0x10
URG	0010 0000	0x20
ECE	0100 0000	0x40
CWR	1000 0000	0x80
SYN+ACK	0001 0010	0x12
FIN+ACK	0001 0001	0x11
SYN only	0000 0010	0x02
RST only	0000 0100	0x04
Xmas scan (FIN+PSH+URG)	0000 1001 + 0000 0001 + 0010 0000 = 0010 1001	0x29
NULL scan	0000 0000	0x00

代表的なオプション

オプション	何をするか（短く）	使い方の例	備考
`-sS`	SYNスキャン	`sudo nmap -sS -p1-1000 10.0.0.5`	速くて一般的。root権限推奨。
`-sT`	TCPスキャン	`nmap -sT -p22,80 10.0.0.5`	root不要だがログに残りやすい。
`-sU`	UDPスキャン	`sudo nmap -sU --top-ports 20 10.0.0.5`	非常に遅い。`--top-ports` 推奨。
`-p`	ポート指定（単一／範囲／複数）	`-p80,443` `-p1-65535`	明示的にポートを限定。
`-Pn`	ホスト発見をスキップ（ping無視）	`sudo nmap -sS -p1-1000 -Pn 10.0.0.5`	Pingがブロックされた環境で必須。
`-sn`	ホスト発見のみ（ポートスキャンしない）	`sudo nmap -sn 10.0.0.0/24`	ping sweep 用。
`-sV`	サービス／バージョン検出	`sudo nmap -sS -sV -p80,22 10.0.0.5`	サービス名・バージョン推定。
`-O`	OS 推定	`sudo nmap -O 10.0.0.5`	root権限が必要な場合あり。誤判定もある。
`-A`	総合検出（sV + O + script 等）	`sudo nmap -A 10.0.0.5`	強力だが騒がしい（検出されやすい）。
`--script`	NSE スクリプト実行	`sudo nmap --script=vuln -p445 10.0.0.5`	カテゴリ指定や複数指定が可能。
`--script-args`	スクリプトへ引数を渡す	`--script http-put --script-args http-put.url='/dav',http-put.file=./f`	スクリプト固有の引数。
`-oN` / `-oG` / `-oX` / `-oA`	出力保存（通常/Grep/XML/全形式）	`-oA scan1`	`-oA` で N,G,X を一括出力。
`-v` / `-vv`	冗長（詳細）出力	`sudo nmap -sS -p1-1000 -Pn -vv 10.0.0.5`	進捗や reason が見やすくなる。
`--reason`	各判定の理由を表示	`sudo nmap --reason -p80 10.0.0.5`	`no-response` / `syn-ack` 等を表示。
`-T0` … `-T5`	タイミングテンプレート（速度）	`-T4`（速め）	高速ほどノイズ大・検出されやすい。
`--stats-every`	定期的な進捗表示	`--stats-every 10s`	長時間スキャン時に便利。
`-F`	fast（/etc/services に基づく上位ポート）	`sudo nmap -F 10.0.0.5`	手早くスキャンしたいとき。
`--top-ports`	使用頻度上位 N ポートのみ	`sudo nmap --top-ports 100 10.0.0.5`	UDPスキャン時に特に有用。
`--open`	open のポートだけ表示	`sudo nmap -sS -p1-1000 --open 10.0.0.5`	出力ノイズを減らす。
`-sN` / `-sF` / `-sX`	NULL / FIN / Xmas スキャン	`sudo nmap -sN -p1-1000 10.0.0.5`	OS依存（Windowsでは効果薄）。
`-6`	IPv6 スキャン	`sudo nmap -6 -sS -p80 fd00::1`	IPv6 ネットワーク用。
`-oG -`	grep しやすい stdout 出力	`sudo nmap -oG - -p1-1000 10.0.0.5`	パイプで `grep` に加工しやすい。

最後に

色々まとめたけどリファレンスガイドを見るのが正確で早い。

Chrome DevTools による簡易調査メモ

miyuki — Sat, 18 Oct 2025 09:51:47 +0000

はじめに

不審サイトの調査などで Chrome DevTools をよく使うので自分用メモ。
ここでは概要をつかむための簡単な解説だけ。詳細はいずれ別記事で書けたら書く。

DevTools とは

DevTools（デブツールズ）は、Webブラウザに標準搭載されている「開発者向けツール」。
画面上の要素を調べてデザイン崩れを修正したり、ネットワーク通信を確認して読み込みエラーを特定したり、
コンソールでエラーメッセージやログを確認したりできる。
名前の通り、本来は開発者向けツールだがセキュリティ調査でも補助ツールとして使われる。

今回は Chrome に搭載されている DevTools の機能を解説。

DevTools の概要

DevTools の開き方

Macの場合
Cmd + option + I

Windowsの場合
Ctrl + Shift + C もしくは F12

DevTools 画面例

DevTools のパネルメニュー

セキュリティの観点で各パネルをどのように利用するか記載。

Elements（エレメンツ）

用途：Webページの構造（HTML）やクライアント側のDOM要素¹を確認。

使用例：
悪意あるスクリプト（例：

miyuki – セキュリティエンジニアの雑多ブログ

DNSSEC検証 DNSSEC破壊・検証編

はじめに

何をしたいか

本記事で検証する構成

検証環境

検証

検証1：署名済みAレコードを改ざんし、DNSSEC検証失敗を確認する

署名済みファイルのAレコードを直接変更

BINDに改ざん後のゾーンを読み込ませる

Client → Unbound で確認

検証結果

検証2：DSレコードを不整合にする

Parent DNSのDSレコードを変更

変更後のDSレコードを含むParentゾーンを再署名

BINDに再署名後のゾーンを読み込ませる

Child KSKから生成されるDSとの不一致を確認する

Client → Unbound で確認

検証結果

検証3：DSレコードを削除し、Insecureになることを確認する

Parent DNSからDSレコードを削除する

DS削除後のParentゾーンを再署名する

BINDに再署名後のゾーンを読み込ませる

Client → Unbound で確認

検証結果

疑問に思ったこと

なぜDNSSECが設定されていなくても名前解決ができるのか

攻撃者がDSレコードを削除してDNSSECを回避できるのではないか

実務との関連

検証1：DNSデータの改ざん

検証2：DNSSECの設定・鍵管理の不整合

検証3：DSレコードが存在しない状態

まとめ

DNSSEC検証 DNSSEC構築編

はじめに

何をしたいか

本記事で構築する構成

検証環境

構築

ChildゾーンをDNSSEC署名

鍵生成

Childのゾーンファイルを署名

BINDが署名済みファイルを使うよう変更

DNSKEYを問い合わせる

Child DNSのKSKからDSレコードを生成し、Parent DNSに登録

Child DNSのKSKでDSレコードを生成

Parent DNSをDNSSEC署名

Unboundに lab.test のTrust Anchorを設定して、DNSSEC検証を有効化

Trust Anchor用のUnbound設定ファイルを作成する

Client → Unboundまで含めて正常に動作することを確認

まとめ

DNSSEC検証 準備・DNS構築編

はじめに

何をしたいか

本記事で構築する構成

検証環境

構築

IP設定とシステムインストール

共通設定

BIND（Parent DNS/Child DNS）のインストール

Unbound（Resolver）のインストール

dnsutils（Client）のインストール

DNS設定

Parent DNS の基本設定

Child DNS の基本設定

Parent DNS に child.lab.test の委任を設定

Resolver の設定

Client で名前解決ができるか確認

おまけ

SERVFAIL エラーの検証

検証

検証結果

結論

まとめ

ファイル名にRLOが使われていたらRecentのLNKファイルもRLO表記になるの？

はじめに

検証の目的

セキュリティ製品上でのログ分析における懸念事項

懸念事項を解消するために検証をする

実行環境と使用ツール

DNSSEC検証準備・DNS構築編