鯖缶

現状:

• chima (DHCP): pihole をプライマリな DNS として広報
• chima (DNS): .home.arpa のみ coredns1 に転送
• pihole (DNS): chima に転送
• coredns1 (DNS): .home.arpa のみ内部的に処理。特に転送はしない
  • ネガティブキャッシュは保持しない (cache { disable denial })。

client → pihole → chima (→ coredns1)? → internet という流れになっている。直接 chima を使ってみるか。

chima を直接使っているのに Nextcloud Notes の Android アプリでの同期エラーが発生した。
少なくとも Pi-hole のみが問題の原因というわけではないことが確認できた。
次は coredns1 を抜いて chima 側に直接 DNS エントリを仕込んで様子見してみるか。

PC 側での名前解決エラーは頻度がかなり落ちた気がするが、キャッシュ系とかなにか他の問題がないとも限らないので、まだ様子見したい。

ルータ(RTX830) 組み込みの DNS 機能だけ使ってもやっぱりおかしい。
とりあえずルータを再起動してもう少し様子見してみることにする。

Android の Nextcloud Notes アプリで、前回から少し時間をおいての起動だと起動時にかなりの高確率で (体感でほぼ毎回) 出るエラー。
宅内での確認。

App Version: 4.1.0
App Version Code: 40010090
App Flavor: fdroid

Files App Version Code: 30260090 (PROD)

---

OS Version: 5.4.210-qgki-g55a0c74ba38a(061002D000015301830216392)
OS API Level: 33
Device: SOG05
Manufacturer: Sony
Model (and Product): SOG05 (SOG05_jp_kdi)

---

java.lang.RuntimeException: com.nextcloud.android.sso.exceptions.NextcloudFilesAppAccountNotFoundException: The requested account was not found in Nextcloud Files app
	at io.reactivex.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:46)
	at io.reactivex.internal.observers.BlockingMultiObserver.blockingGet(BlockingMultiObserver.java:93)
	at io.reactivex.Maybe.blockingGet(Maybe.java:2321)
	at io.reactivex.Observable.blockingSingle(Observable.java:5381)
	at it.niedermann.owncloud.notes.persistence.NotesServerSyncTask.pullRemoteChanges(NotesServerSyncTask.java:219)
	at it.niedermann.owncloud.notes.persistence.NotesServerSyncTask.run(NotesServerSyncTask.java:96)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:487)
	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at java.lang.Thread.run(Thread.java:1012)
Caused by: com.nextcloud.android.sso.exceptions.NextcloudFilesAppAccountNotFoundException: The requested account was not found in Nextcloud Files app
	at com.nextcloud.android.sso.api.AidlNetworkRequest.performNetworkRequestV2(AidlNetworkRequest.java:197)
	at com.nextcloud.android.sso.api.NextcloudAPI.performNetworkRequestV2(NextcloudAPI.java:180)
	at com.nextcloud.android.sso.api.NextcloudAPI.lambda$performRequestObservableV2$0$com-nextcloud-android-sso-api-NextcloudAPI(NextcloudAPI.java:122)
	at com.nextcloud.android.sso.api.NextcloudAPI$$ExternalSyntheticLambda0.subscribe(Unknown Source:6)
	at io.reactivex.internal.operators.observable.ObservableFromPublisher.subscribeActual(ObservableFromPublisher.java:31)
	at io.reactivex.Observable.subscribe(Observable.java:12284)
	at io.reactivex.internal.operators.observable.ObservableSingleMaybe.subscribeActual(ObservableSingleMaybe.java:31)
	at io.reactivex.Maybe.subscribe(Maybe.java:4290)
	at io.reactivex.Maybe.blockingGet(Maybe.java:2320)
	... 8 more

# $?=0 2023-12-24 08:21:15 pts/12
# nopth@atri:~
$ drill A toka.home.arpa
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 2303
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; toka.home.arpa.	IN	A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
home.arpa.	2861	IN	SOA	prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.53
;; WHEN: Sun Dec 24 08:21:15 2023
;; MSG SIZE  rcvd: 109
# $?=0 2023-12-24 08:21:21 pts/12
# nopth@atri:~
$ drill @192.168.160.1 A toka.home.arpa
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 21094
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; toka.home.arpa.	IN	A

;; ANSWER SECTION:
toka.home.arpa.	1	IN	A	192.168.160.18

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.160.1
;; WHEN: Sun Dec 24 08:21:21 2023
;; MSG SIZE  rcvd: 48
# $?=0 2023-12-24 08:21:28 pts/12
# nopth@atri:~
$ resolvectl status
Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/unsupported
  resolv.conf mode: stub
Current DNS Server: 192.168.160.1
       DNS Servers: 192.168.160.1

Link 2 (sit0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 3 (enp18s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/unsupported
Current DNS Server: 192.168.160.1
       DNS Servers: 192.168.160.1

Link 4 (wlp20s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
# $?=0 2023-12-24 08:21:44 pts/12
# nopth@atri:~
$ resolvectl status
Global
         Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/unsupported
  resolv.conf mode: stub
Current DNS Server: 192.168.160.1
       DNS Servers: 192.168.160.1

Link 2 (sit0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported

Link 3 (enp18s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/unsupported
Current DNS Server: 192.168.160.1
       DNS Servers: 192.168.160.1

Link 4 (wlp20s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
# $?=0 2023-12-24 08:27:05 pts/12
# nopth@atri:~
$

不可解。
prisoner.iana.org に行っているということは明らかにクエリが外へ出ているのだが、 resolvectl status を見る限りだと 192.168.160.1 (chima) へクエリが飛んでいる。
つまり、 chima が何らかの要因で静的 DNS レコードの設定を無視して外へクエリを飛ばして得た NXDOMAIN を返してしまい、それが systemd-resolved にキャッシュされているとしか考えられない。
これだと resolvectl flush-caches 実行後に名前解決が問題なく成功するようになることの説明もつく。

参考:

• 24.11 静的 DNS レコードの登録
• 24.16 DNS フォールバック動作をルーター全体で統一するか否かの設定
• RTシリーズのTCP/IPに関するFAQ - FAQ for YAMAHA RT Series / TCP/IP

RTX830 の設定では dns private address spoof off と dns service fallback on が指定されている。弄れるとすればこの辺りしかなさそうだが……

RTX830 に DNS をさせるのをやめて別で unbound なり何なりを立てる手もあるにはあるのだが、可用性の不安を考えるとルータがやってくれる方が圧倒的に楽。

nop_thread さんは #note-13 で書きました:

RTX830 の設定では dns private address spoof off と dns service fallback on が指定されている。弄れるとすればこの辺りしかなさそうだが……

dns private address spoof off してみたが、やはり名前解決の失敗が発生した。
そもそもこの設定は PTR レコードの解決についてのものなので、想定通りの結果。

cp.feng.home.arpa が resolvectl flush-caches から数秒以内 (2秒以内のことも多い) に名前解決に失敗するようになる。驚異的。

while true ; do drill @192.168.160.1 cp.feng.home.arpa ; echo '--------' ; sleep 1 ; done と while true ; do drill @127.0.0.53 cp.feng.home.arpa ; echo '--------' ; sleep 1 ; done を眺めてみたが、 chima 側は安定して正しい結果を返していたのに対して、 systemd-resolved 側は何故か十数秒で home.arpa. 3917 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800などと返してくるようになった。

systemd-resolved が悪さをしているらしい……

ping をはじめとした drill 外のアクセスを契機に結果が狂い始めているようだ。

systemd-resolved stops quering local DNS servers · Issue #21174 · systemd/systemd · GitHub

かなり怪しいが、この挙動自体は経験的に既知だったので、 8.8.8.8 等をフォールバックとして出てこないようにしていた。
現状 resolvectl status は "DNS Srevers" として 192.168.160.1 しか返していないわけで、失敗したら別サーバを使うようになって戻ってこないという挙動だけではやはりまだ説明ができない。
失敗したとき試すべき別サーバは皆無のはずである。

しかし systemd-resolved の問題となると Nextcloud Notes アプリの同期失敗の説明がつかないから、やはり chima 側で何かしら妙なことが起きていると考える方が自然に思われる。
#note-17 で簡単に実験した限りではそのような兆候はなかったのだが。
どう調査したものか……

/etc/resolve.conf を書き換えても resolvectl flush-caches の影響が出ているように見える現象に遭遇し不可解だったので、一時的に systemd-resolved を完全に無効化している。
それでも PC (atri) からの接続エラーは発生しており、たとえば BookStack で下書きの一時保存に失敗した通知が出る (手動で保存は成功する) などの症状がある。
やはりルータ側なのか？

パブリックな DNS にして試す手はあるのだが、それをやってしまうとローカルのサービスへのアクセスが面倒になる (/etc/hosts に全てを突っ込んでも良いが……) ので避けていた。
やるしかないか。

1. 出先でスマホ1からキャリア回線 (IPv6) で Nextcloud Notes アプリを起動すると同期エラーの通知が出た
   • その後の編集と同期は問題なかった
2. スマホ1のテザリングを通してスマホ2から Nextcloud Notes アプリを起動すると、同期エラーの通知はなかった

これは解釈が難しい。そもそもテザリングの仕組みを知らないので深く考えようがないが。
とりあえずクライアントの高レベルなレイヤーの問題である可能性が低いというくらいか。

とりあえず resolv.conf 弄りによってデスクトップ PC 側での名前解決とサーバ接続性問題が独立して存在していた可能性が出てきたので、チケットを分割すべきかもしれない。

共通の要因がないとも言いきれないので、このチケットも閉じずにおく。

分岐:

• バグ #86: 宅内ネットワークで Pi-hole を使ったとき名前解決に失敗しやすい？
• バグ #87: chuable 上のサーバへ Android の Nextcloud Notes アプリで接続するとアプリ起動時に同期エラーが発生しやすい
• バグ #106: 宅内で Android 端末から ICSx⁵ の同期がたまに失敗する

関係ないと思うがメモ。

FAQ for YAMAHA RT Series / TCP/IP:

DNSリカーシブサーバ機能を使うとアドレスが引けなくなる¶

DNSには、比較的小さなレコードをUDPによって配送する方法と、 大きなレコードをTCPで配送する方法とがあります。 DNSの問い合わせを行う場合には、まずUDPによって配送を試してみて、 それでうまくいかない場合にはTCPに切り替えるようになっています。 ほとんどの場合は、UDPで配送できてしまいますが、 ごくまれに1つのIPアドレスに20以上もの名前がついているような場合もあり、 そのような時にはTCPでの配送となります。

RTシリーズのDNSリカーシブサーバ機能は、UDPによる配送にしか対応していません。 ほとんどの場合はこれで問題ありませんが、ごくまれにレコードが大きくなって、 TCPによる配送に切り替わってしまうと、 それを扱えないためにアドレスが引けないということが起こります。 このような場合は、RTシリーズのDNSリカーシブサーバ機能を使わないようにして下さい。