[Desktop-packages] [Bug 1327477] Re: dnsmasq not using all DHCPv6 provided nameservers
I think the following, much simpler, patch should solve the problem. Simon. diff --git a/src/dbus.c b/src/dbus.c index 93c597c..4696442 100644 --- a/src/dbus.c +++ b/src/dbus.c @@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message) dbus_message_iter_get_basic(iter, p[i]); dbus_message_iter_next (iter); if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_BYTE) - break; + { + i++; + break; + } } #ifndef HAVE_IPV6 my_syslog(LOG_WARNING, _(attempt to set an IPv6 server address via DBus - no IPv6 support)); #else - if (i == sizeof(struct in6_addr)-1) + if (i == sizeof(struct in6_addr)) { memcpy(addr.in6.sin6_addr, p, sizeof(struct in6_addr)); #ifdef HAVE_SOCKADDR_SA_LEN -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1327477 Title: dnsmasq not using all DHCPv6 provided nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Invalid Bug description: When receiving nameservers from a DHCPv6 server, NetworkManager reports receiving both my primary and secondary servers, but only advises dnsmasq about the secondary. Jun 6 13:59:29 daedalus dhclient: XMT: Info-Request on eth0, interval 910ms. Jun 6 13:59:29 daedalus dhclient: RCV: Reply message on eth0 from fe80::221:85ff:fe10:7749. Jun 6 13:59:29 daedalus NetworkManager[22306]: info (eth0): DHCPv6 state changed nbi - renew6 Jun 6 13:59:29 daedalus NetworkManager[22306]: info nameserver '2001:470:8:64f::4' Jun 6 13:59:29 daedalus NetworkManager[22306]: info nameserver '2001:470:8:64f:21b:fcff:fe43:bcff' Jun 6 13:59:29 daedalus NetworkManager[22306]: info domain search 'home.nivex.net.' Jun 6 13:59:29 daedalus NetworkManager[22306]: info Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... Jun 6 13:59:29 daedalus NetworkManager[22306]: info (eth0): DHCPv6 client pid 22638 exited with status 0 Jun 6 13:59:29 daedalus NetworkManager[22306]: info Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... Jun 6 13:59:29 daedalus avahi-daemon[991]: Registering new address record for 2001:470:8:64f:dcf5:dd0f:11f5:b6ed on eth0.*. Jun 6 13:59:30 daedalus NetworkManager[22306]: info (eth0): device state change: ip-config - secondaries (reason 'none') [70 90 0] Jun 6 13:59:30 daedalus NetworkManager[22306]: info Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. Jun 6 13:59:30 daedalus NetworkManager[22306]: info (eth0): device state change: secondaries - activated (reason 'none') [90 100 0] Jun 6 13:59:30 daedalus NetworkManager[22306]: info NetworkManager state is now CONNECTED_GLOBAL Jun 6 13:59:30 daedalus NetworkManager[22306]: info Policy set 'Ethernet connection 1' (eth0) as default for IPv6 routing and DNS. Jun 6 13:59:30 daedalus NetworkManager[22306]: info Writing DNS information to /sbin/resolvconf Jun 6 13:59:30 daedalus dnsmasq[22603]: setting upstream servers from DBus Jun 6 13:59:30 daedalus dnsmasq[22603]: using nameserver 2001:470:8:64f:21b:fcff:fe43:bcff#53 Jun 6 13:59:30 daedalus NetworkManager[22306]: info Activation (eth0) successful, device activated. I noticed this during the Turn IPv4 Off Day (http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn- off-ipv4-on-6-june-2014-for-one-day/) shakedown because my secondary was not configured to recurse over IPv6, resulting in an inability to resolve anything. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: network-manager 0.9.8.8-0ubuntu7 ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11 Uname: Linux 3.13.0-27-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: XFCE Date: Fri Jun 6 23:18:49 2014 EcryptfsInUse: Yes InstallationDate: Installed on 2011-12-09 (910 days ago) InstallationMedia: Xubuntu 11.10 Oneiric Ocelot - Release amd64 (20111012) IpRoute: default via 172.31.3.1 dev eth0 proto static 172.31.3.0/24 dev eth0 proto kernel scope link src 172.31.3.11 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes SourcePackage: network-manager UpgradeStatus: Upgraded to trusty on 2014-04-20 (47 days ago) nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless unavailable /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 06/02/13 09:18, Thomas Hood wrote: [...cont'd after in order to fix...] bug #1072899, dnsmasq will have to be enhanced such that proposition #1 is true. But we can discuss the details of that in bug #1072899. parenthesis There is a close analogy between the problem here (bug #1003842) and a problem we have with avahi. Avahi resolves names in the domain .local. Networks should not use this TLD, but many do and at least in the past Microsoft actually recommended doing so. When users connect to such networks with avahi enabled the result is malfunction. Upstream purisitically says[*] If you come across a network where .local is a unicast DNS domain, please contact the local administrator and ask him to move his DNS zone to a different domain. If this is not possible, we recommend not to use Avahi in such a network at all. In practice avahi attempts to detect bad networks and disables itself if it thinks it is on a bad network, subject unfortunately both to false positives (bug #327362) and false negatives (bug #80900). We aren't yet doing even that well. We say that networks ought to have equivalent nameservers and we make no attempt to detect networks that have non-equivalent nameservers, of which there are very many. [*]http://avahi.org/wiki/AvahiAndUnicastDotLocal /parenthesis Detect non-equivalent servers is hard. I'm very much in favour of doing it, if a way can be found. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 06/02/13 08:59, Thomas Hood wrote: Hi Simon. Before I forget to ask: can you please update dnsmasq(8) to include under --strict-order a description of what happens when nameserver addresses are passed in via D-Bus instead of via a file? You wrote, you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq Because NM doesn't use dnsmasq to cache, if NM were to give dnsmasq only one address then I guess the only service that dnsmasq would still provide is that of name-to-server mapping. And it turns out that the way NM currently uses dnsmasq to do this is seriously flawed. So I conclude that it's better for NM not to use dnsmasq at all until these problems are solved. [That NM only supplies one nameserver address per domain name] is a different problem, and could be solved. From the man page it's not completely clear how to solve it. Can you confirm (1) that it's possible to give multiple server options as follows server=/google.com/1.2.3.4 server=/google.com/5.6.7.8 and that the result will be that 1.2.3.4 and 5.6.7.8 will be treated equally for the purpose of resolving names in domain google.com? (2) And likewise via D-Bus? (3) What effect does strict-order have on this? Ironically, I think the problem arises because for nameservers associated with particular domains, the equivalent of --strict-order is always in play. What you say here suggests that my proposition #1 above is false. If #1 is false then it seems that in order to fix proposition #1 is true, as is #2: you can configure the same thing via DBus. Consider server=1.1.1.1 server=2.2.2.2 server=/google.com/3.3.3.3 server=/google.com/4.4.4.4 Queries not sent to *.google.com will behave in the normal dnsmasq manner, sent non-deterministically to 1.1.1.1 and/or 2.2.2.2 in a way which tries to favour the fastest/most up server. Queries sent to *google.com will be sent 3.3.3.3 or 4.4.4.4 in the same way as if strict order was set, ie, to 3.3.3.3 first, and only to 4.4.4.4 if 3.3.3.3 returns a SERVFAIL or REFUSED error, or doesn't reply at all. This should be changed, but the code which implements it is knarly and old, and won't stand more tinkering, it needs rewriting. I've not found the time, as of yet. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Belay my previous comment about 1072899, it looks like network manager is losing the second server before it ever gets to dnsmasq. Not a dnsmasq problem. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 04/02/13 22:05, Thomas Hood wrote: Simon in #49: It doesn't work [...] the order of servers given to the DBus interface isn't preserved internally Aha, so the answer to my question Will switching on strict-order have the same effect now that nameserver addresses are sent over D-Bus? (in comment #42) is No. So switching strict-order back on is no solution. And solutions depending on strict-order including mine in #28 also won't work. Unless dnsmasq is somehow changed such that it remembers the order in which nameserver addresses come in over D-Bus so that strict-order is useful in the D-Bus case, if we want to avoid breaking name service on machines connected to NNNs then we have to disable dnsmasq by default; or disable it initially and only enable it when we know that we aren't on a NNN. Note that setting --strict-order is pretty much equivalent to telling dnsmasq to use only the first nameserver, so you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq. Maybe provide a button in NM that does this - press here if you're in a captive portal. (NNN = nonequivalent-nameserver network. As discussed in comment #5, such networks are not properly configured. But as observed several times, there are many NNNs out there. Which is why *many* people have been commenting out dns=dnsmasq.) There is another problem with NM-dnsmasq (bug #1072899). Some VPNs have multiple nameservers. NM uses dnsmasq to direct VPN domain name queries to the *first* one. But then, if the first one goes down, the second one is not tried. Once again, for the sake of speed enhancement in the favorable case, users suffer radical name service failure in the unfavorable case. This is not a good deal, IMHO. NM-dnsmasq should be disabled by default until these problems are solved. That's a different problem, and could be solved. Ironically, I think the problem arises because for nameservers associated with particular domains, the equivalent of --strict-order is always in play. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 03/02/13 07:48, Thomas Hood wrote: there's still the unresolved question of whether re-enabling --strict-order will suffice as a workaround, since 12.10 relies on DBus to populate the nameservers. Is there any extra information on this? Please try it and report back. :-) (Put strict-order in a file in /etc/NetworkManager/dnsmasq.d/; stop network-manager; make sure all dnsmasq processes are dead; start network-manager.) It doesn't work: It will always use the same server first, but the order of servers given to the DBus interface isn't preserved internally, and actually changes each time the DBus interface is used. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 04/02/13 15:36, Sergio Callegari wrote: On 04/02/2013 15:40, Simon Kelley wrote: On 03/02/13 07:48, Thomas Hood wrote: there's still the unresolved question of whether re-enabling --strict-order will suffice as a workaround, since 12.10 relies on DBus to populate the nameservers. Is there any extra information on this? Please try it and report back. :-) (Put strict-order in a file in /etc/NetworkManager/dnsmasq.d/; stop network-manager; make sure all dnsmasq processes are dead; start network-manager.) It doesn't work: It will always use the same server first, but the order of servers given to the DBus interface isn't preserved internally, and actually changes each time the DBus interface is used. Cheers, Simon. Isn't it possible to change dnsmasq behavior to query the servers in any order or in parallel and in the case the first server to reply says I don't know avoid relying on that information, rather wait and see if in a reasonable time some other server answers I do? You're far from the first person to ask that question. The answer is that there is no possible response in the DNS protocol which means I don't know. NXDOMAIN or NODATA answers _don't_ mean that; they mean I know that this domain doesn't exist. They also make up quite a large proportion of the DNS results returned to the average host, so that all of those queries would suddenly take much longer. With the current behavior, whenever I need to access a captive portal, I basically have to press the reload page button 50 times until for some reasons the order in which the nameservers reply becomes the good one. The fundamental problem lies with the captive portal, and no good solution which can be implemented by dnsmasq has so far been devised. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 991308] Re: DNS Querying fails if any DNS server is unreachable
Simon, do you think that dnsmasq could misbehave as described here? The only way I can see for this to occur is if a DNS server is return wrong (ie NXDOMAIN or NODATA) answers, no answer shouldn't be a problem. I suggest adding --log-queries to the dnsmasq configuration to try and get a handle on what's happening. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/991308 Title: DNS Querying fails if any DNS server is unreachable Status in “dnsmasq” package in Ubuntu: New Status in “network-manager” package in Ubuntu: Incomplete Bug description: Release: 12.04 Hardware: HP Compaq 6910p Laptop If the backup DNS server is unreachable, dnsmasq does not try to reach primary DNS server. In the following default configuration (clean install of 12.04) 1 out of 4 DNS queries fail. (DNSMasq seems to rotate queries between the listed servers) wlightning@archon:~$ cat /run/nm-dns-dnsmasq.conf server=75.75.75.75 server=75.75.76.76 wlightning@archon:~$ wlightning@archon:~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search hsd1.or.comcast.net wlightning@archon:~$ wlightning@archon:~$ nm-tool NetworkManager Tool State: connected (global) - Device: ttyUSB0 -- Type: Mobile Broadband (CDMA) Driver:sierra State: disconnected Default: no Capabilities: - Device: wlan0 Type: 802.11 WiFi Driver:iwl4965 State: unavailable Default: no HW Address:00:1D:E0:35:69:AF Capabilities: Wireless Properties WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points - Device: eth0 [Wired connection 1] --- Type: Wired Driver:e1000e State: connected Default: yes HW Address:00:1B:38:E7:F5:02 Capabilities: Carrier Detect: yes Speed: 1000 Mb/s Wired Properties Carrier: on IPv4 Settings: Address: 10.0.0.11 Prefix: 24 (255.255.255.0) Gateway: 10.0.0.1 DNS: 75.75.75.75 DNS: 75.75.76.76 wlightning@archon:~$ mtr of 75.75.75.75 (anycast addr): My traceroute [v0.80] archon (0.0.0.0) Sun Apr 29 10:13:58 2012 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0%510.6 0.6 0.6 1.5 0.2 2. 73.94.124.1 0.0%519.0 9.2 7.1 14.7 1.5 3. 68.85.148.1 0.0%517.9 10.6 7.4 24.7 4.0 4. 68.87.216.13 0.0%519.2 19.8 8.5 150.8 29.0 5. 68.87.218.162 0.0%50 10.8 14.1 8.1 85.0 13.4 68.87.218.158 6. 68.87.216.41 0.0%509.5 13.2 9.5 67.4 8.6 7. 75.75.75.75 0.0%509.9 11.0 9.1 17.2 1.8 mtr of 75.75.76.76 (anycast addr): My traceroute [v0.80] archon (0.0.0.0) Sun Apr 29 10:12:42 2012 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0%510.6 0.8 0.5 3.6 0.5 2. 73.94.124.1 0.0%519.0 9.3 7.0 18.3 2.5 3. 68.85.148.9 0.0%517.3 9.6 7.2 22.3 2.9 4. 68.85.243.253 0.0%518.3 13.8 7.5 81.9 15.6 5. 68.86.95.97 0.0%51 14.5 17.2 11.9 33.0 4.4 68.86.91.197 68.86.90.213 68.86.95.93
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 20/06/12 10:56, Thomas Hood wrote: I can imagine that it will take a lot of care to avoid introducing races inside dnsmasq. It's OK: notification of new interfaces comes via netlink, so it gets synchronised via the select() call just like everything else. Have I mentioned yet that Simon is a hero? :-) New code is in git (and I released 2.63test1) change --bind-interfaces to --bind-dynamic as see how it goes. Do we have to worry about races outside of dnsmasq? Suppose someone was running dnsmasq in unbound mode and has now switched to the new improved dnsmasq in bind-interfaces-dynamically mode. Now an interface comes up but there is a delay before dnsmasq notices this and starts listening on it. Problem? Because it's using netlink rather than polling, the delay is pretty short (I know that's not a solution to races, but it does help.) Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 18/06/12 21:08, Thomas Hood wrote: @Simon: This is pretty much what I had in mind (comment #88) as a long- term solution. How difficult do you think that this would be? Don't know. I'm working on it now: seems to be behaving: dnsmasq: new IPv4: 192.168.3.1 dnsmasq: new IPv6: fe80::f0f6:48ff:fe15:70b0 (Moving nm-dnsmasq listening to another port than 53 is at best a veeery long-term solution since it requires first getting glibc enhanced, then getting all other resolver libraries enhanced, then waiting for third- party static binaries to be replaced by new versions built against enhanced libraries. That's a ten-year project.) If bind-interfaces-dynamically works well then I see no reason why it shouldn't be the default mode of operation. Indeed, I see no reason why it shouldn't be the *only* mode on OSs with support for it. I see reasons: I've been burned by releasing changes that won;t affect anything too many times, I like the idea of making the new behaviour opt-in. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 10:19, Thomas Hood wrote: $ cat /run/nm-dns-dnsmasq.conf server=/17.172.in-addr.arpa/172.17.1.2 server=192.168.1.254 server=... The first server= line reflects the fact that I am connected to a VPN. This can't be expressed in resolv.conf syntax. FYI only, It's possible to use the dnsmasq DBus interface to set servers/domains with full generality and without restarting dnsmasq. Simon. No doubt dnsmasq could be enhanced to poll its configuration files. But it remains a question whether it's advisable for NM to make use of the standalone dnsmasq for the purposes for which nm-dnsmasq was introduced. Effectively this revisits the discussion that led to the introduction of nm-dnsmasq in the first place. Part of that discussion (which I wasn't party to) can be read here: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 08:04, Thomas Hood wrote: Alkis: This relies on the assumption that NM's configuration text can be dropped in alongside whatever other configuration text is present and that dnsmasq will still work properly. This assumption is, er, questionable. There was an attempt, some time ago, to provide a way to allow something like libvirt to add its DHCP configuration to a system dnsmasq configuration without interfering with the existing config. It's basically a way to specify an interface and subnet for DHCP in a config line which overrides other access control, so for instance if the system dnsmasq config limits it to certain interfaces, then the interface specified by libvirt would be added to that set. To my knowledge this facility has never actually been used. And this is also one answer to my question in #72. The dnsmasq cascade may waste resources but it has maintenance advantages. One dnsmasq process is under the control of NM. The other is under the control of the admin. They communicate with each other via a well defined protocol, RFC 1035. This is a good argument, I think. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 15:01, Thomas Hood wrote: -- Solvable by moving nm-dnsmasq to another port: There's one more snippet after this dealing with the IPv6 case. That should be it. Any obvious problems I'm overlooking? Applications that don't use the libc resolver? I don't know if such exist be they might do. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 14/06/12 16:06, Thomas Hood wrote: @Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on any addresses assigned to interfaces after dnsmasq has started. So, yes, she would have to restart standalone dnsmasq if she wants it to listen on those newly assigned addresses. That's correct. The chief advantage of listening on the wildcard address is that it all works as interfaces come and go. You lose that with --bind-interfaces. It would be possible these days to have dnsmasq detect extra interfaces and bind to their addresses automatically, but the code to do that isn't portable. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: OK, so the ::1 idea fails as a quick hack. The alternatives seem to be as follows. 1. Either we accept that nm-dnsmasq is incompatible with every standalone nameserver and enforce this in a better way; 2. or we force every standalone nameserver into bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. For completeness, there's a #4 which is to dump bind-interfaces except-interface=lo into /etc/dnsmasq.d, but that won't work for other nameservers (though something analogous would, I expect) If you can make #2 happen without breaking things, that would seem to be worth doing, I guess the main problem is that you need dnsmasq 2.61 or a backport of the relevant code to 2.59. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: OK, so the ::1 idea fails as a quick hack. The alternatives seem to be as follows. 1. Either we accept that nm-dnsmasq is incompatible with every standalone nameserver and enforce this in a better way; 2. or we force every standalone nameserver into bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address=ip addr where ip addr is not on an interface, will listen on port 69 of ip addr even if tftp is not enabled. The fix is in git but not a release, but should be backported if you do #2. It's trivial: one line. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 10:05, Alkis Georgopoulos wrote: Note that while bind-interfaces can be specified multiple times, defining except-interfaces more than once is a syntax error in my dnsmasq 2.59-4. Are you sure? That should be allowed. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 11:24, Thomas Hood wrote: Hmm, just tested this myself. You can't use except-interface=lo; it seems you have to use listen-address=10.1.2.3. Perhaps Simon knows a better way. If you want to listen on an address which doesn't appear on an interface (ie 127.0.1.1) then you have to use --listen-address. The rules for 127.0.0.1 are slightly arcane too: If you use -interface and --except-interface, then dnsmasq will assume that you want it to listen on the address of any loopback interfaces it finds as well. In practise that means 127.0.0.1 So dnsmasq --interface=eth0 will listen on the address(es) of eth0 and 127.0.0.1. If you use --listen-address, then dnsmasq assumes you want more control and only uses the addresses you actually give so dnsmasq --listen-address=127.0.1.1 will _not_ listen on 127.0.0.1 Given this, it makes sense to use 127.0.1.1 (or any address in 127.0.0.0/8 that doesn't appear on lo) for nm-dnsmasq. Because 127.0.1.1 doesn't appear on lo, another dnsmasq instance will not try and listen on it, and the only thing required to get the two dnsmasq instances to co-exist is --bind-interfaces. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 20:31, Thomas Hood wrote: (Executive summary of the following: I think we should fix this by making nm-dnsmasq listen at ::1.) Thanks for your much-needed help, Simon. It is good to know that the except-interface avenue is available. We want, however, to be able to enjoy the advantages of non-bind-interfaces mode (unbound mode??) in standalone dnsmasq insofar as we can. Certainly standalone dnsmasq should continue to run in unbound mode when n-m is not installed or when nm-dnsmasq is not in use; so ideally we would ensure that /etc/NetworkManager/NetworkManager.conf contains dns=dnsmasq if and only if /etc/dnsmasq.d/nm-dnsmasq contains bind- interfaces except-interface=lo. I don't see a very easy way to ensure this. In any case it would be better if we never had to force dnsmasq into bind-interfaces mode. So instead of switching the nm-dnsmasq listen address from 127.0.0.1 to 127.0.1.1 it seems better to switch that address to ::1: no more difficult, yet in the latter case standalone dnsmasq can continue to run in unbound mode as it has traditionally done (unless forced into bind- interfaces mode by something like libvirt-bin, of course). I don't think that's true. In unbound mode, the standalone dnsmasq will bind the IPv6 wildcard address, which will stop the nm-dnsmasq from binding ::1 There's no escape in IPv6 land. Indeed the situation is worse, because as far a I know, you can't use any address in the defined subnet for loopback, it has to be ::1, so except-interface=lo is required. I think the 127.0.1.1 (or whatever) answer is the best. Unfortunately there's no way round having to set --bind-interfaces on the standalone dnsmasq, but except-interface=lo is not required as long as the 127.0.0.0/8 address in use by nm-dnsmasq doesn't appear on the lo interface. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 19:57, Thomas Hood wrote: But, second, there is a problem connecting the resolver to the NM- controlled dnsmasq such that the latter stays out of the way of the general local nameserver which currently wants to listen on the IPv4 wildcard address. Using address ::1 for nm-dnsmasq is a quick hack which might work without further ado But even if it works it clearly isn't a permanent solution. More satisfactory would be to use an another port than 53 for the special purpose of connecting the resolver with nm-dnsmasq. Another option is to use another address in 127.0.0.0/8, any will work. You'll need dnsmasq 2.61 or later for this to be a viable option. You could have the nm-dnsmasq run with --bind-interfaces --listen-address=127.0.100.1 and put 127.0.100.1 in /etc/resolv.conf. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 20:41, Thomas Hood wrote: Aha, I had tried this and it didn't work... in version 2.57. But I see that quantal already has 2.62. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Just to make sure I understand correctly: Do you mean here that --bind- interfaces has to be set on both instances of dnsmasq? Or will one instance (the NM-controlled one) with --bind-interfaces coexist nicely with another (the standalone dnsmasq) which doesn't use that option and listens on 0.0.0.0? It has to be set in both instances of dnsmasq. dnsmasq started as a system daemon reads config from /etc/dnsmasq.d/* so dropping a file there containing bind-interfaces and doing the relevant restart in postinst should make this automatic in most cases. NM already runs dnsmasq with --bind-interfaces and --listen-address (specifically, --listen-address=127.0.0.1) so we would only be changing the address. Mathieu mentioned earlier the possibility of using 127.0.1.1 which happens to be the address assigned (in /etc/hosts) to the system hostname on some (but not all) systems. Is there any advantage to using 127.0.1.1 as opposed to another 127.* address? I don't think so: they're all equivalent. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
On 31/05/12 08:47, Thomas Hood wrote: In addition to devising an algorithm for dnsmasq to detect all and only NNNs, the implementation of which will no doubt take a while, we should consider implementing a quick fix too, along the lines suggested by Sergio in #19. NM could be changed to do the following. If the nameserver address list to be fed to dnsmasq contains one or more local addresses followed by one or more non-local addresses then run dnsmasq with the --strict-order option. I must confess that I am not sure what exactly should fall under local addresses here. In IPv4 I presume that these would be the familiar ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, but what about IPv6? I think you're right for IPv4. For IPv6, I'm tempted to treat it as a tabula rasa and explicitly not support NNNs. the rationale being that NNN support is to work around historical bad practice and such bad practice is not supported in the brave new world of IPv6. If that won't fly, then the IPv6 equivalent would be link-local (fe80::/64), site-local (fec0::/10) and ULAs (block fc00::/7), I think. Nevertheless, I think we can safely proceed with this fix without being sure that we have exactly the right definition of local address since dnsmasq works no worse than libc in strict-order mode. ** Also affects: dnsmasq (Ubuntu) Importance: Undecided Status: New ** Also affects: resolvconf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: New Status in “network-manager” package in Ubuntu: Confirmed Status in “resolvconf” package in Ubuntu: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Simon, your suggestion (call it #18) differs from the suggestion in #17 in two ways. First, #18 sends the first-received reply back to the client without waiting for the results of comparison with other results whereas #17 does wait. Second, #18 switches to strict-order mode when *any* difference is found, whereas #17 proposed only looking for a particular pattern, that being: a NODATA/NXDOMAIN is received from a nameserver that is not listed first and an earlier-listed nameserver does return an address within the standard libc timeout period. In #17's defence... in #17 the client only has to wait for a reply in the case of a NODATA/NXDOMAIN from a non-first nameserver; the client does get the desired address from the earlier-listed nameserver if there is one --- even the first time; and dnsmasq only drops into strict-order mode under the circumstances when it is necessary for it to do so such that clients get needed addresses. There is no point, for example, in dropping into strict-order mode if it's the first nameserver returning NXDOMAIN and a later-listed nameserver returning an address! What do you think about the possibility of implementing such ideas? I think that both are implementable. I worry that #17 will make (real) NXDOMAIN/NODATA replies much slower, since there at least two round-trips, and possibly a timeout, if a server never replies. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Simon Kelley might have written dnsmaskq with the assumption that all DNS servers upstream have the same view about the namespace. However, this is not how RFC sees it nor how it is set up in a majority of installations. Can you provide an authoritative reference for that? As far as I can see, the internal DNS server can provide one of five different answers to a query (there are other possible answers, including delagations, but these are the five possible ones to a stub resolver which sets the RD bit in th query) 1) A valid answer 2) A NODATA answer asserting that the domain exists, but the domain has no information for the type (A, , MX..) queried. 3) A NXDOMAIN anser asserting that the domain does not exist. 4) No answer. 5) An error return code. 1) and 4) and 5) are not a probem, the next step is obvious. the argument is what to do in 2) and 3), we can either accept the valid reply that comes from DNS server or we can try again witha another one. Dnsmasq does the former, and that, I assert, is the correct thing to do. I believe it's what the libc resolver does too. Given the above, the only way to use an internal DNS server which knows about local records is to make sure it's always queried first: we can't sensibly send the query to the external server and then to the internal server when the external one says don't know since THERE IS NO VALID DON'T KNOW ANSWER. My comment about random failures due to UDP packet loss applies here, but if you want dnsmasq to work this way, there's a flag, --strict-order, which will do it. Assume --strict-order. Since we've decide that the only time we're going to use a second nameserver is when the first one doesn't reply, this affects the timeliness of anwers, if you always send to the one nameserver first, the only circumstance you can use an answer from the second server if after the first one times out. The second server isn't very useful if using it makes all DNS queries take 2-3 seconds. One the other hand, if you arrange that all the servers are equivalent, you can keep a note of which ones are up, or even send the query to all the servers, use the first reply, and discard the rest. Dnsmasq uses both these techniques to improve resilience. If you have very flaky servers, you can even tell it to send every query to all the available servers. Executive summary: non-equivalent servers are bad, but --strict-order will make things work, for the same value of work as the libc resolver). Non-equivalent servers are bad, so don't encourage their use by making --strict-order the default. HTH Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
To be frank, when changing the default system resolver, expected behavior should be the default. It's all well and good saying that non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that might be true - but that's a value judgement that shouldn't have a place in this scenario, since users haven't made the choice to enable dnsmasq, and so shouldn't have to be aware of the caveats (ie - My DNS worked fine before upgrade). It's a delicate trade-off, made all the more ironic by the fact that without dnsmasq, a second DNS server is practically useless (because you have to wait for the time-out on the first for each and every query). The easiest solution is just to delete the second nameserver. All I can say is that dnsmasq provides both modes, and the default is what it is for the reasons I outlined. If Ubuntu as a distro wants to flip the default, they can. My personal opinion is that it would be a mistake, but that's just my opinion. Question: does networkmanager's GUI expose the option to divert particular domains to a special nameserver? That's an alternative correct way to achieve layering local names over the global DNS. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Thomas in #17 A heuristic for this is difficult, because you have to prove a negative. If we can assume the first nameserver has local addresses, we can never return a reply from any other nameserver until we have the reply from the first one, in case the first one has different data. Once we see different data from different nameservers, we can go to --strict-order mode, but the opposite is not true: the same answer for a particular query doesn't guarantee that the answers to future queries will always agree. There's no way to be sure that the nameservers are equivalent based on the history of returned queries. Unless we can assume that, we always need to wait for the first nameserver to reply (or a timeout) and have to stay in --strict-order mode forever. There is one possibility, which is to assume that nameservers are equivalent, but switch to --strict-order mode if conflicting replies are seen. When a query is forwarded to all available servers, and the first reply sent back to the original requestor, keep the record of the reply (at least, a bit indicating NODATA/NXDOMAIN or a valid reply. If another reply comes in later from another nameserver which conflicts, then switch to --strict-order mode. This will not get the first queries right, but it will be triggered eventually (and it might be triggered, swicthing mode forever, by random server glitches) For a single-host cache, --strict-order might be the simplest fix.. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp