【日記】Creality K2 Plusの異常なDNSクエリ問題【備忘録】

結論

/etc/hosts に以下の1行を追記してとりあえず止めた。

root@K2Plus-XXXX:\~\# vi /etc/hosts

\# \--- 追記内容 \---  
104.18.29.114   api.crealitycloud.com

同様の問題がK1でも発生しているので同じように対処する予定。

以下、調査協力してくれたGeminiくんがやり取りとログをもとにまとめてくれたレポートです。

概要

Creality K2 Plus（および同等のOSを搭載する3Dプリンタ）において、宅内のローカルDNSサーバに対し、1日40万回を超えるDNSクエリを送信し続ける事象が発生した。
調査の結果、プリンタ内部のOSからDNSキャッシュ機構が完全に排除されており、クラウド連携デーモンが通信のたびに名前解決を行っていることが判明。クラウド連携機能を維持しつつスパム通信を無効化するため、/etc/hosts とCloudflareのAnycast IPを活用した静的解決を実施した。

環境・前提

• 対象機器: Creality K2 Plus
• 搭載OS: Tina 5.0 (OpenWrt 21.02-SNAPSHOT ベース)
• CPUアーキテクチャ: armv7l
• 事象: api.crealitycloud.com 宛てのDNS問い合わせが異常な頻度（約4〜5回/秒、1日40万回以上）で発生。

調査プロセス

当初はOS（OpenWrt）の標準的な設定を修正し、ローカルにDNSキャッシュを持たせるアプローチを試みた。しかし、徹底的なアプライアンス化・軽量化により、一般的な解決策がことごとく塞がれていることが判明した。

1. DNSキャッシュ機構の不在
   dnsmasq のプロセスもバイナリも存在せず、uci によるネットワーク設定エントリも削除されていた。resolv.conf は宅内DNSを直接向いている状態だった。
2. パッケージマネージャの削除
   不足しているパッケージを外部からインストールしようとしたが、opkg コマンド自体が存在しなかった。
3. 代替手段の枯渇
   nscd などの代替キャッシュデーモンが存在しないだけでなく、軽量化環境のコアである busybox のDNSアプレットすら無効化された状態でビルドされていた。

実際の調査ログ

 _____  _              __     _
|_   _||_| ___  _ _   |  |   |_| ___  _ _  _ _
  | |   _ |   ||   |  |  |__ | ||   || | ||_'_|
  | |  | || | || _ |  |_____||_||_|_||___||_,_|
  |_|  |_||_|_||_|_|  Tina is Based on OpenWrt!
 -----------------------------------------------------
 Tina 5.0, OpenWrt 21.02-SNAPSHOT r0-0b5de290a
 -----------------------------------------------------
root@K2Plus-XXXX:\~\# uci show dhcp  
uci: Entry not found  
root@K2Plus-XXXX:\~\# cat /etc/resolv.conf  
\# Interface lan  
nameserver 192.168.aaa.bbb (ローカルのDNSサーバーのIP）  
search 自宅のドメイン  
root@K2Plus-XXXX:\~\# ps | grep dnsmasq  
 5446 root      0:00 grep dnsmasq  
root@K2Plus-XXXX:\~\# which dnsmasq  
root@K2Plus-XXXX:\~\# ls \-l /etc/init.d/dnsmasq  
ls: /etc/init.d/dnsmasq: No such file or directory  
root@K2Plus-XXXX:\~\# opkg update  
\-ash: opkg: not found  
root@K2Plus-XXXX:\~\# which nscd  
root@K2Plus-XXXX:\~\# busybox \--list | grep dns  
\-list: applet not found  
root@K2Plus-XXXX:\~\# uname \-m  
armv7l

対策：Hostsへの静的IP登録（Cloudflare Anycast IPの活用）

スパムの元凶となっている api.crealitycloud.com を 127.0.0.1 （シンクホール）に向けてしまうと、Creality Cloudの機能が完全に使えなくなってしまう。
そこでPowerShellから nslookup を実行し、対象ドメインのインフラを調査した。

PS \~\> nslookup api.crealitycloud.com  
サーバー:  nsv\-ubuadg01  
Address:  192.168.aaa.bbb

権限のない回答:  
名前:    api.crealitycloud.com.cdn.cloudflare.net  
Addresses:  2606:4700::6812:1d72  
          2606:4700::6812:1c72  
          104.18.29.114  
          104.18.28.114  
Aliases:  api.crealitycloud.com

CrealityのAPIサーバーはCloudflareを経由していることが判明。CloudflareのエッジIPは安定して稼働し続ける性質があるため、この「正解のIPアドレス」をプリンタの /etc/hosts に直接書き込むことで、外部へのDNS問い合わせをバイパスする手法を採用した。

設定手順

SSHでプリンタにログインし、/etc/hosts に以下の1行を追記する。

root@K2Plus-XXXX:\~\# vi /etc/hosts

\# \--- 追記内容 \---  
104.18.29.114   api.crealitycloud.com

結論

この設定により、プリンタ内部のプロセスは宅内DNSサーバ（192.168.aaa.bbb）へクエリを投げることなく、ローカルの hosts ファイルから直接CloudflareのIPを解決してAPI通信を行うようになった。
結果として、Creality Cloudの機能を一切損なうことなく、1日40万回を超える異常なDNSクエリスパムを完全に沈静化させることに成功した。
運用上の注意点
万が一、Creality側がインフラをCloudflareから他環境（AWS等）へ移行したり、DNSの向き先を大きく変更した場合はクラウド機能がオフラインになる可能性がある。その際は、再度最新のIPアドレスを引き直して hosts を書き換える必要がある。