工作桌面刚刚迁移到Ubuntu,遇到一个怪异到问题,Ubuntu解析外网正常,但不能解析内网域名(.local结尾的域名)。下面是我解决问题的过程。
已知的现象,如下:
1.由于我在Ubuntu上安装到XP,在XP上通过NAT网络链接可以正常解析内网域名。
2.在Ubuntu用dig命令可以正常解析到内网域名
3.ping 内网域名无法ping通
通过以上三点可以看出内网DNS解析是ok的(XP虚拟机能解析内网)。但是Ubuntu上ping内网域名不能解析,而dig能正常解析。域名解析顺序:本地hosts文件解析,DNS服务器解析。可以判定很可能是Ubuntu系统在解析域名相关记录。猜想有可能所域名解析被系统服务给劫持了。但不知道如何下手,于是google了下关键字 Ubuntu local 。得到该文章http://www.linuxidc.com/Linux/2011-04/34433p2.htm
文中提到可能和avahi相关。avahi什么东东?搜之得一下结果:Avahi 是 zeroconf 协议的实现。它可以在没有 DNS 服务的局域网里发现基于 zeroconf 协议的设备和服务。它跟 mDNS 一样。除非你有兼容的设备或使用 zeroconf 协议的服务,否则应该关闭它。
用ps -ef|grep avahi 查看了下。果然有该服务。利用sudo service avahi-daemon stop 关闭该服务后,ping 内网域名,能够ping通。
Ubuntu .local domain resolving issue’s and iptables prerouting
In the past few days I’ve been helping a new colleague at my current job with getting his development area setup in Ubuntu. Most of us work with Windows, including myself since I’m not working on my laptop but on a provided desktop, so helping someone with Ubuntu is nice for a change.
But we ran into a problem that I couldn’t explain right away, if we tried to “ssh” to our svn repository it didn’t resolve the hostname, while “normal” host lookup programs had no trouble with resolving it at all. So I posted the problem on the Ubuntu forums. Unfortunately the first response was a bit disappointing: “does it work when you try to ssh via ip?”… So I thought lets call a friend who helps me out more often in cases like these. And indeed he knew the answer. It seems that avahi is causing this problem. I’ve not yet found out why avahi is doing this, but I guess it’s a bad idea to use avahi while you need to work with a “.local” domain.
I wanted to know why avahi did this, so I thought lets join the Ubuntu IRC channel. Unfortunately I didn’t get an explanation. But I got to see something about iptables that I didn’t know about before, prerouting. Someone asked the following question:
2008-11-11 21:53:48 < deus> It is possible to use the iptables to redirect http traffic to a proxy server, for example by using iptables -t nat -A PREROUTING -p tcp -i br0 –dport 80 -j DNAT
–to-destination <ip proxy>:3128 But how does the proxy server know which site he has to lookup since the destination is changed to its own address?
I didn’t know the answer to that, guess it works via the HTTP protocol itself, but well, perhaps I’ll find this out some other time. But while I was looking into this prerouting thingy I found a nice blog post about using prerouting for flash remoting. I’ve no use for this information yet, but you never know.