はじめに
OCI DNS の Private DNS で Query Response Logs を有効化し、Private Resolver の名前解決ログが OCI Logging に出力されることを確認した。
この記事では、通常の Private DNS 解決と Forwarding rule 経由の解決について、ログにどのような値が出力されるかを整理する。
参照情報
- DNS Resolver Log: https://docs.oracle.com/en-us/iaas/Content/Logging/Reference/details_for_privatedns.htm#details_for_privatedns
- Logging service log reference: https://docs.oracle.com/en-us/iaas/Content/Logging/Reference/service_log_reference.htm#service_log_reference
- OCI Blog: https://blogs.oracle.com/cloud-infrastructure/post/announcing-oci-private-dns-response-logging
検証構成
| 項目 | 内容 |
|---|---|
| Region | ap-tokyo-1 |
| Service | DNS |
| DNS endpoint | 169.254.169.254:53 |
| Client | OCI Compute instance: 10.1.0.163 |
| Private zone | testzone.example |
| Test record | www.testzone.example A 10.1.5.5 |
| Forwarding target | 10.0.0.150 |
ログの有効化
OCI Logging のサービス・ログ作成画面で、Service に DNS、Resource に対象 VCN の Private Resolver、Log category に Query Response Logs - Resolvers を指定する。
プライベートゾーンの作成
今回の検証では、プライベートゾーン testzone.example を作成し、www.testzone.example に対する A レコード 10.1.5.5 を登録した。
通常の Private DNS 解決
まず、Compute インスタンスから Private DNS 名を解決した。パケット上は、クライアント 10.1.0.163 から OCI の VCN resolver endpoint 169.254.169.254:53 へ DNS 問合せが送られている。
$ sudo tcpdump -i ens3 port 53 -nn
01:33:14.815421 IP 10.1.0.163.45939 > 169.254.169.254.53: 60129+ A? www.testzone.example. (38)
01:33:14.819210 IP 169.254.169.254.53 > 10.1.0.163.45939: 60129 1/0/0 A 10.1.5.5 (54)
01:33:14.819599 IP 10.1.0.163.58869 > 169.254.169.254.53: 64830+ AAAA? www.testzone.example. (38)
01:33:14.820218 IP 169.254.169.254.53 > 10.1.0.163.58869: 64830 0/1/0 (113)
Logging の検索画面で対象ログを選択し、logContent に example を含むイベントで絞り込むと、www.testzone.example に対するログを確認できた。
A レコードの応答ありのログでは、answer、answerCount、rcodeName、sourceAddress、destinationAddress などが確認できる。
{
"logContent": {
"data": {
"answer": "[A 10.1.5.5]",
"answerCount": 1,
"destinationAddress": "169.254.169.254",
"destinationPort": "53",
"latency": 2,
"path": "private",
"protocol": "udp",
"qclass": "IN",
"qname": "www.testzone.example.",
"qtype": "A",
"rcode": "0",
"rcodeName": "NOERROR",
"sourceAddress": "10.1.0.163",
"ttl": 3600
},
"oracle": {
"resourceType": "dns.privateResolver"
},
"type": "com.oraclecloud.dns.private.resolver"
},
"regionId": "ap-tokyo-1"
}
ログの見え方
Logging のビジュアル化で data.answer をグループ化すると、回答値ごとの分布を確認できる。少数の検証問合せの場合は以下。
検証インスタンス上では OCI サービスや外部名の名前解決も発生する。検索条件を広くすると、検証対象以外の CNAME / A レコードも同じログに含まれる。
このため、調査でログを示す場合は、qname、sourceAddress、時間範囲、検証用ドメインなどで絞り込む方が読みやすい。
Forwarding rule 経由の解決
次に、Private Resolver の forwarding rule に一致する名前を解決した。Forwarding 先の IP アドレスは 10.0.0.150 である。Forwarding rule 経由のログでは、path が rule:forwarded になり、forwardDestinationAddress と forwardSourceAddress が追加で記録される。
転送先が応答する場合
転送先 DNS サーバーから応答が返る場合、answer に回答値が入った。レイテンシも確認できる。
{
"data": {
"answer": "[A 10.0.10.10]",
"answerCount": 1,
"forwardDestinationAddress": "10.0.0.150",
"forwardSourceAddress": "10.1.0.13",
"latency": 14,
"path": "rule:forwarded",
"qname": "test.testsubnet.example.",
"qtype": "A",
"rcode": "0",
"rcodeName": "NOERROR",
"ttl": 300
}
}
転送先が応答しない場合
フォワーディング先のIPアドレスに対してセキュリティリストを使って通信を弾き、わざと応答を返さないようにした場合はクライアント側では nslookup が timeout した。
このときの resolver log では、answer: "drop"、latency: 5000 が記録された。
{
"data": {
"answer": "drop",
"answerCount": 0,
"destinationAddress": "169.254.169.254",
"forwardDestinationAddress": "10.190.0.31",
"forwardDestinationPort": 53,
"forwardSourceAddress": "10.1.0.13",
"latency": 5000,
"path": "rule:forwarded",
"qname": "www.testzone1.example.",
"qtype": "A",
"rcode": "nil",
"rcodeName": "nil",
"sourceAddress": "10.1.0.163",
"ttl": 0
}
}
最後に
今回の検証では、同じ名前を繰り返し解決した場合に、キャッシュの影響で期待した回数分のログが出ないことがあった。検証時は、問合せ名、TTL、実行間隔を意識した方がよい。
Private DNS の Query Response Logs は、名前解決の性能調査やセキュリティ調査に使える。たとえば、特定のクエリで遅延が発生していないか、想定外の名前解決が行われていないかを確認できる。
一方で、ログを取るだけでは分析にはならない。性能確認、監査、不正通信の調査など、目的を決めたうえで、検索条件や可視化方法を設計するのがよさそうである。