自宅内のホスト名解決にbindを立てているが、自動で外を見に行く。正確には、家の中はIPV4だけで管理しているのだ。内部と外部で見えるDNSの情報に差異をを作って管理しているが、プロパイダのIPV６のDNS情報を取り込んで混ぜてしまった上で、IPV6を優先してしまう。dhcp6やraを使ってプロパイダの設定を読み込んでくるのだ。そもそもIPV6をIPoEで受けるとセグメント分けられないので、必要なものだけ通すのが難しいからなのだ。L2 FW(?)が使いこなせればできるのかもしれないが、今はその方向はノウハウ不足。IPV4はセグメントが別れてるのでコントロールできている。ubuntuを導入する毎に複数の手段を組み合わせするため、どうやったかわからないことになるので記録することとした。Windows、iOS、Androidはどう動いてるか気になるが、内部用の名前解決ができないくても外部と混じっても今の使い方なら問題ないと思う。

方針

ubuntu systemd-resolvedを使わない。resolv.confを直接編集し内部で立てたDNSに問い合わせさせる。他OSは問題が出たら考える。組み合わせが多すぎる。いずれはL2FWでRDNSをブロックし一網打尽たい。

設定作業

sytemd-resolvedの自動起動停止　今回はアンインストールしない。

root@ts2:~# systemctl disable systemd-resolved
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.
root@ts2:~# systemctl stop systemd-resolved

/etc/resolv.confを編集

元

nameserver 127.0.0.53
options edns0 trust-ad
search greet.jp flets-east.jp iptvf.jp

optionsて何だ？

編集後

nameserver 127.0.0.1
search greet.jp

様子見

記憶によると、この方法ではresolv.confが消されててしまった記憶がある。よくわからないが systemd-resolvd以外でも編集しているのではなかろうか？　今回は、これで様子見として問題が出たら記録を修正する。

顛末１

再起動したら、resolv.confのリンク先が消えていた。何もないので、名前解決ができなくなってしまった。新規作成して対処した。

mv resolv.conf resolv.conf.bak
vi resolv.conf

resolv.confの中身(ルータで自身がDNSのサーバの場合）

nameserver 192.168.1.32  (自身の代表IP　localhost　172.0.0.1でもいいのだが）
search greet.jp

顛末2

やっぱり、Windowsで問題が出た。外のDNSを参照していた。内部用のWEBサーバのつもりで外部用のWEBサーバをアクセスしていた。想定外の動きされると何が起こるのかわからないので、内部のDNSをを参照するように調整することにした。

プロバイダのルータが広報する情報を取り込んだのに間違いないはずだ。RDNSかdhcpv6だと思われる。FWでブロックしようと試みたが、L2での制御ができなかった。dhcpv6は何故か通ってしまう。RDNSはRAごと止まってしまって、ルータが見つからなくなる。しょうがないので諦めて、セグメントを分けるしかないとの結論に達した。

以後、IPV6ルータの構築の顛末を参照。