Comment 30 for bug 80900
Revision history for this message
| Chris Gilbert (marvincomputers) wrote Re: problems resolving fully qualified domain names in environments where .local is used as a TLD | #30 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
This bug is causing a lot of problems. As the avahi-daemon is enabled by default, you need a great deal of knowledge to know what is going on here. For instance, our Microsoft network in the office uses the popular .local pseudo domain.
When connected to the VPN:
ping server - Works fine
ping server.
When in the office, and on the local LAN, I can't resolve .local hostnames at all when using actual services (i.e. SSH, ping etc).
To compound things, lookups using dig, host or nslookup commands all work fine. Thereby confusing me even further.
If I do:
sudo /etc/init.
Magically, FQDN lookups work again. It took me a long time to find this out :)
FQDN lookups on .local domains are essential to a lot of people who use a Microsoft network and DNS servers. What about people connecting via a VPN? The avahi-daemon will start before the VPN connection, so detecting a '.local' domain at that point wouldn't help.
Changing the line to:
hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
....Works! Can this be the default,...and, can it be put into a Jaunty patch? Think it will help out a lot of people....
thanks,
Chris