By

Contents

https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients/

在ubuntu下观察系统的域名解析总是会碰到非常奇异的case，比如当你ping一个自定义的域名时，你会发现在某些情况下，并没有触发相应的udp 53端口访问，这种没有触发的原因还不像是简单的cache机制造成的。

深入观察systemd的域名解析服务，systemd-resolved.service，可以看到它调用的是/lib/systemd/systemd-resolved, 如果进一步man systemd-resolved会看到它有一个说明，建议在特定的操作系统环境下，可以调用由systemd所提供的api来查询域名而不是传统的glibc的方法，主要优点是这是一个异步的查询。

它所推荐的调用api说明在：https://www.freedesktop.org/wiki/Software/systemd/resolved/
,在这个文档里面提供了一个调用的例子，可编译使用：https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients/。

根据这些信息，可以查到在ubuntu里面，最终systemd所使用的解析服务器，在运行的时候，归集在/run/systemd/resolve/resolv.conf文件中，在里面可以看到所有系统能搜索到的dns配置。引起我配置干扰的选项在于我曾经有一次设置在wifi的接口上配置了特定的dns地址。
令人困扰的表现在于，当调用ping的时候，它优先选择从接口地址上配置的域名服务器，而在调用例子的时候，它优先查询的是/etc/resolve.conf配置的域名地址。

2017年11月2日更新

1
2
3
经过仔细阅读文档和实际使用观察，确认了长久以来使用systemd-resolve的一个困惑。
当在/etc/resolv.conf中配置一个vpn隧道的地址时候，当笔记本合上又开启时，systemd-resolve会验证这个地址的有效性，当vpn隧道地址不能正确获得的时候，它就会自动转向到从dhcp上获得的dns地址，从而导致域名解析混乱。
所以解决这个问题的办法就是在wifi或者物理网口的配置界面上，把接收来自dhcp的dns选项关闭即可。
Contents