Re: [Bug 1974230] [NEW] Negative cache results from dnsmasq do not include SOA as required in RFC2308
Acknowledge that RFC non-compliance. Fixing this is actually a fairly big ask, since the problem is not that dnsmasq omits the SOA when answering from cache, but that dnsmasq doesn't cache SOA records. The design philosophy was (and is) to cache only a few RR types to make the code and data structures simple and small (remember that dnsmasq's niche is "lightweight", for low capability hardware). There's been a implied assumption that clients using dnsmasq would typically be stub-resolvers, and not full-service DNS servers. That said, the set of cached RR types has increased over the years, notably with the introduction of DNSSEC and the RR types needed to suuport that. Adding caching of SOA records is possible, but I'm not sure it's worth the effort. A reasonable workaround might be to disable negative caching in dnsmasq and rely on systemd-resolved to do that for itself. Simon. On 19/05/2022 20:51, Eric Blevins wrote: > Public bug reported: > > RFC2308 states: > 6 - Negative answers from the cache > > When a server, in answering a query, encounters a cached negative > response it MUST add the cached SOA record to the authority section > of the response with the TTL decremented by the amount of time it was > stored in the cache. This allows the NXDOMAIN / NODATA response to > time out correctly. > > The effect is that the negative cache results returned by dnsmasq cannot > be cached by other resolvers such as systemd-resolved. > > A good example of why this is a problem: > Two clients with systemd-resolved send DNS queries to dnsmasq for the same > record > The first one makes a query and gets NXDOMAIN with SOA. > This results in systemd-resolved caching the negative result. > > The second client makes a query and gets NODATA without the SOA. > This results in systemd-resolved not caching the negative result. > > Consider a domain name that only has an A record published. > When connecting to that domain a lookup happens for the and A record. > One can end up in a situation where systemd-resolved has the A record cached > locally, but it still goes out to the network to perform the lookup only > to get the same negative cache result that is missing the SOA > > I see this behavior in 18.04 and 22.04 > > > First query to dnsmasq can be cached: > dig @10.0.1.21 a.google.com > > ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3107 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;a.google.com. IN A > > ;; AUTHORITY SECTION: > google.com. 60 IN SOA ns1.google.com. > dns-admin.google.com. 449437361 900 900 1800 60 > > ;; Query time: 15 msec > ;; SERVER: 10.0.1.21#53(10.0.1.21) > ;; WHEN: Thu May 19 15:00:12 EDT 2022 > ;; MSG SIZE rcvd: 91 > > > Cached response from dnsmasq cannot be cached: > dig @10.0.1.21 a.google.com > > ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.1.21 a.google.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61408 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;a.google.com. IN A > > ;; Query time: 0 msec > ;; SERVER: 10.0.1.21#53(10.0.1.21) > ;; WHEN: Thu May 19 15:00:13 EDT 2022 > ;; MSG SIZE rcvd: 41 > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1974230 Title: Negative cache results from dnsmasq do not include SOA as required in RFC2308 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1974230/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1862157] [NEW] dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles
tftp-root is a security feature. The tftp protocol is entirely unauthenticated, and if a request was allowed to go outside the specified root directory, than that effectively makes all readable files on the host available for internet-wide access, which is not generally desirable. If you want TFTP to be able to access any file on the machine, don't set a tftp-root. Simon. On 06/02/2020 11:02, Thomas Schweikle wrote: > Public bug reported: > > dnsmasq does in all cases prepend "tftp_root" to tftp-files. > > tftp-root=/data/tftp > dhcp-boot=grub/i386-pc/core.0 > > now have some config files for different subnets: > dhcp-boot=net:172-18-1,grub/i386-pc/core.0,172.18.1.1 > dhcp-boot=net:172-18-8,pxelinux.0,172.18.8.1 > dhcp-boot=net:172-18-7,/var/lib/tftpboot/pxelinux.0,spacewalk-ber.bfs.de > > Now booting clients within subnet 172.18.1.0/24 will boot grub with: > /data/tftp/grub/i386-pc/core.0 > > Booting clients within subnet 172.18.2.0/24 will boot pxelinux.0 with: > /data/tftp/pxelinux.0 > > And in subnet 172.18.7.0/24 clients will boot with: > /data/tftp/var/lib/tftpboot/pxelinux.0 > > and return a "File not found" error. > > I'd expected: > 172.18.1: grub/i386-pc/core.0 (file found within /data/tftp -- > without exposing path) > 172.18.2: pxelinux.0(file found within /data/tftp -- > without exposing path) > 172.18.3: /pxelinux.0 (file found within /) > 172.18.7: /var/lib/tftpboot/pxelinux.0 (file found within > /var/lib/tftpboot/pxelinux.0) > > or even better: some way to set tftp-root for every subnet-config and > having only relative paths to access files regardless of giving absolute > or relative paths. > > ProblemType: Bug > DistroRelease: Ubuntu 18.04 > Package: dnsmasq 2.79-1 > ProcVersionSignature: Ubuntu 4.15.0-87.87-generic 4.15.18 > Uname: Linux 4.15.0-87-generic x86_64 > ApportVersion: 2.20.9-0ubuntu7.10 > Architecture: amd64 > Date: Thu Feb 6 11:43:07 2020 > InstallationDate: Installed on 2014-01-31 (2197 days ago) > InstallationMedia: Ubuntu-Server 13.10 "Saucy Salamander" - Release amd64 > (20131016) > PackageArchitecture: all > ProcEnviron: > TERM=xterm > PATH=(custom, no user) > XDG_RUNTIME_DIR= > LANG=de_DE.UTF-8 > SHELL=/bin/bash > SourcePackage: dnsmasq > UpgradeStatus: Upgraded to bionic on 2018-11-23 (439 days ago) > mtime.conffile..etc.default.dnsmasq: 2014-02-19T17:19:28.429595 > mtime.conffile..etc.dnsmasq.conf: 2016-08-17T12:18:41.225353 > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New > > > ** Tags: amd64 apport-bug bionic > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1862157 Title: dnsmasq does in all cases prepend "tftp_root" to tftp-bootfiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1862157/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1800347] [NEW] Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not start - subnet other than /24 not accepted?
dhcp-range for static ranges is dhcp-range=,static,.. ie, there's only one address before the static keyword. Simon. On 28/10/2018 12:55, Lutz Heitmüller wrote: > Public bug reported: > > Description:Ubuntu 18.04.1 LTS > Release:18.04 > __ > dnsmasq: > Installiert: 2.79-1 > Installationskandidat: 2.79-1 > Versionstabelle: > *** 2.79-1 500 > 500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages > 500 http://de.archive.ubuntu.com/ubuntu bionic/universe i386 Packages > 100 /var/lib/dpkg/status > __ > > #Configuration excerpt: > listen-address=127.0.0.1 > listen-address=192.168.115.18 > dhcp-range=192.168.114.100,192.168.114.250,255.255.254.0,6h > > #dhcp-range=192.168.115.21,192.168.115.250,static > #dhcp-range=192.168.114.31,192.168.114.99,static,255.255.254.0,infinite > > As soon as I activate one of the last lines, dnsmasq refuses to start with > the error msg that the range was incorrect, although there is no overlap in > range, nor is the range incorrect. > I am starting to think that this might be a bug, maybe dnsmasq cannot cope > with subnets other than /24? > > Thanks for your support! > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New > > ** Summary changed: > > - Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not > start > + Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not > start - subnet other than /24 not accepted? > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800347 Title: Defining 2 dhcp ranges for static dhcp definition causes dnsmasq to not start - subnet other than /24 not accepted? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1800347/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1782362] [NEW] dnsmasq segfaults on cnames referring to themselves
This was fixed upstream, in release 2.77. Simon. On 18/07/18 14:59, Frank Klaassen wrote: > Public bug reported: > > If one would add a CNAME-record that would point to itself like so: > CNAME=test.example.com,test.example.com > > This will result in a segfault and crash of the dnsmasq process. > > Segfault on 14.04 / dnsmasq 2.68: > dnsmasq[22762]: segfault at 7ffe1727dff8 ip 7f7c60cde755 sp > 7ffe1727dff0 error 6 in libc-2.19.so[7f7c60c5e000+1be000] > > Segfault on 16.04 / dnsmasq 2.75: > dnsmasq[21097]: segfault at 7ffc4bf90ff8 ip 7f268bf7ebbc sp > 7ffc4bf90ff0 error 6 in libc-2.23.so[7f268befd000+1c] > > > Ubuntu versions affected: Ubuntu 14.04.5 LTS & Ubuntu 16.04.4 LTS > > dnsmasq version (14.04) 2.68-1ubuntu0.2 > dnsmasq version (16.04): 2.75-1ubuntu0.16.04.5 > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782362 Title: dnsmasq segfaults on cnames referring to themselves To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1782362/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1702726] [NEW] dnsmasq fails when the ARP cache is full
Testing this, the results are not quite as clear-cut as the example. I don't always see the same errors. Also, I don't understand why the send() calls in dig, which are sending UDP packets over the loopback interface, should return the invalid argument. ARP is not needed over loopback, surely? Looking at an strace of dnsmasq, what I see is that either the query never arrives at dnsmasq, or it gets answered correctly but the answers never makes it back to dig: the UDP packets are being dropped in the kernel. (In the later case, the send() of the reply gets the same invalid argument error that dig is seeing) The lesson here is that if the arp-cache overflows, UDP, (even over lo) drops packets. There's really not much dnsmasq can do about that. I guess the only answer is "don't let your arp-cache overflow". (or possibly, work on getting the kernel to behave better under these circumstances) TL;DR not a dnsmasq bug. Cheers, Simon. On 06/07/17 18:17, Christopher Berner wrote: > Public bug reported: > > Test setup: > OS: Ubuntu 16.04 > Hardware: D15_v2 VM on Azure > > Steps to reproduce: > 1) sudo apt-get install dnsmasq > 2) sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1 > 3) sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=1 > 4) sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=1 > 5) dig @127.0.0.1 google.com > > Result: > ~$ dig @127.0.0.1 google.com > ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid > argument > ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid > argument > ../../../../lib/isc/unix/socket.c:2104: internal_send: 127.0.0.1#53: Invalid > argument > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 google.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > However, an external DNS server still works fine (dig @8.8.8.8 > google.com, for example). > > We discovered this as the default max ARP cache size is 1024, and we're > running a large cluster with a lot of intra-cluster network traffic. > Increasing the size of the ARP cache solves this problem, but it seems > like dnsmasq should still work and just be slow, like other applications > (curl for example just takes longer to connect) > > ** Affects: dnsmasq (Ubuntu) > Importance: Undecided > Status: New > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1702726 Title: dnsmasq fails when the ARP cache is full To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1702726/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time
Looking again. the loop probably involves systemd-resolverd too, dnsmasq forwards to 127.0.0.53 which is systemd-resolverd, and systemd-resolverd then returns it to dnsmasq at 127.0.0.1 Why, oh why is Ubuntu running both? Cheers, Simon. On 14/03/17 11:15, Paul wrote: > I have cpulimit(1) watching dnsmasq now, so it only goes berserk for a > second before being killed, but the attached syslog extract captures the > moments before and during the DNS storm. These particular lookups are > mostly originated by Transmission, but previously the storms have > happened when there were no Transmission processes running, with queries > from Firefox or perhaps some unidentified Gnome weather applet. > > ** Attachment added: "syslog_dns_storm.txt" > > https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+attachment/4837521/+files/syslog_dns_storm.txt > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672099 Title: DNS loop, >5,000 queries per second for minutes at a time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time
Ok, so the amplification is arising from dnsmasq looping queries around 127.0.0.1 -> 127.0.0.53 -> 127.0.0.1 -> . It would be really useful to get dnsmasq's idea of what it's upstreams are. We know that 127.0.0.1 is in the list from your previous post, and I guess that dnsmasq has successfully worked out not to use that as it loops back to itself. It's very likely that it didn't work out that 127.0.0.53 also loops back to itself too, but it's not clear how that's getting into the list of upstreams. This is starting to look like an Ubuntu/systemd plumbing problem, rather than a dnsmasq bug. Simon. On 14/03/17 11:15, Paul wrote: > I have cpulimit(1) watching dnsmasq now, so it only goes berserk for a > second before being killed, but the attached syslog extract captures the > moments before and during the DNS storm. These particular lookups are > mostly originated by Transmission, but previously the storms have > happened when there were no Transmission processes running, with queries > from Firefox or perhaps some unidentified Gnome weather applet. > > ** Attachment added: "syslog_dns_storm.txt" > > https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+attachment/4837521/+files/syslog_dns_storm.txt > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672099 Title: DNS loop, >5,000 queries per second for minutes at a time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time
Are we clear that this is a dnsmasq problem, and not a systemd-resolved
one? Can you add --log-queries to the dnsmasq configuration and see what
dnsmasq is doing? That should demonstrate if the loop is dnsmasq
forwarding to itself, of if the problem is something else.
Cheers,
Simon.
On 13/03/17 08:46, Paul wrote:
> There aren't any such entries in syslog, presumably because I had
> hardcoded two upstream servers (208.67.222.222 and 208.67.220.220) using
> the GUI Wi-Fi settings dialog in 16.10 and they're not changing. Oddly,
> I can't see that setting in the 17.04 dialog, even though "systemd-
> resolve --status" correctly reports them:
>
> Global
> DNS Servers: 127.0.0.1
> DNSSEC NTA: 10.in-addr.arpa
> 16.172.in-addr.arpa
> 168.192.in-addr.arpa
> 17.172.in-addr.arpa
> 18.172.in-addr.arpa
> 19.172.in-addr.arpa
> 20.172.in-addr.arpa
> 21.172.in-addr.arpa
> 22.172.in-addr.arpa
> 23.172.in-addr.arpa
> 24.172.in-addr.arpa
> 25.172.in-addr.arpa
> 26.172.in-addr.arpa
> 27.172.in-addr.arpa
> 28.172.in-addr.arpa
> 29.172.in-addr.arpa
> 30.172.in-addr.arpa
> 31.172.in-addr.arpa
> corp
> d.f.ip6.arpa
> home
> internal
> intranet
> lan
> local
> private
> test
>
> Link 2 (wlp2s0)
> Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
>LLMNR setting: yes
> MulticastDNS setting: no
> DNSSEC setting: allow-downgrade
> DNSSEC supported: no
> DNS Servers: 208.67.222.222
> 208.67.220.220
> DNS Domain: local
>
> The requests against the upstream server are disturbingly fast, I'm
> surprised I haven't been blacklisted yet.
>
> 19:40:12.000415 IP hostname.50776 > resolver1.opendns.com.domain: 42051+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...X.5.=nB.C...4.1.168.192.in-addr.arpa...)
> 19:40:12.000920 IP hostname.59219 > resolver1.opendns.com.domain: 14223+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...S.5.=..74.1.168.192.in-addr.arpa...)
> 19:40:12.001411 IP hostname.51647 > resolver1.opendns.com.domain: 2501+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=.Z
> 4.1.168.192.in-addr.arpa...)
> 19:40:12.001885 IP hostname.33104 > resolver1.opendns.com.domain: 30929+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...P.5.=..x4.1.168.192.in-addr.arpa...)
> 19:40:12.002412 IP hostname.47231 > resolver1.opendns.com.domain: 46563+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=j{.4.1.168.192.in-addr.arpa...)
> 19:40:12.004238 IP hostname.57292 > resolver1.opendns.com.domain: 61082+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=
> w.4.1.168.192.in-addr.arpa...)
> 19:40:12.008187 IP hostname.49786 > resolver1.opendns.com.domain: 14681+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C...z.5.=.
> 9Y...4.1.168.192.in-addr.arpa...)
> 19:40:12.008926 IP hostname.53171 > resolver1.opendns.com.domain: 24423+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=.._g...4.1.168.192.in-addr.arpa...)
> 19:40:12.009629 IP hostname.37811 > resolver1.opendns.com.domain: 55231+%
> [1au] PTR? 4.1.168.192.in-addr.arpa. (53)
> E..Q..@.@C.5.=mk.4.1.168.192.in-addr.arpa...)
>
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1672099
Title:
DNS loop, >5,000 queries per second for minutes at a time
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1672099] Re: DNS loop, >5, 000 queries per second for minutes at a time
Whenever the set of servers to which dnsmasq is forwarding queries changes, the whole set is logged to syslog. It would be useful to have that information. On 13/03/17 00:01, Paul wrote: > Restarting dnsmasq immediately stops an ongoing DNS storm. > The actual upstream server used can change unpredictably, so that's no surprise. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672099 Title: DNS loop, >5,000 queries per second for minutes at a time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1672099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1501189] Re: DNS breaks when port=0 is used in dnsmasq.conf
*** This bug is a duplicate of bug 1042275 *** https://bugs.launchpad.net/bugs/1042275 On 06/10/15 11:08, Alkis Georgopoulos wrote: > Hi Robie, > > while this also happens in Debian, the use case is more common in Ubuntu, > because NetworkManager is patched to use a spawned dnsmasq instance as a > local resolver, and mixing the two DNS servers is problematic (neither > bind-dynamic nor bind-interfaces work very well). > In Debian they more frequently use the normal dnsmasq/DNS service as it was > designed, because NM doesn't spawn a local resolver there. > > For upstream report, Simon (the upstream dnsmasq developer and Debian > maintainer) already answered here, Simon would you like me to file a > debian bug as well? It's easy to work around this issue, so we can even > close it with won't fix if you prefer. > > Thank you. > No need to file a Debian bug, whatever fix goes in will go into upstream and Debian anyway. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1501189 Title: DNS breaks when port=0 is used in dnsmasq.conf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1501189] Re: DNS breaks when port=0 is used in dnsmasq.conf
*** This bug is a duplicate of bug 1042275 *** https://bugs.launchpad.net/bugs/1042275 On 06/10/15 11:08, Alkis Georgopoulos wrote: > Hi Robie, > > while this also happens in Debian, the use case is more common in Ubuntu, > because NetworkManager is patched to use a spawned dnsmasq instance as a > local resolver, and mixing the two DNS servers is problematic (neither > bind-dynamic nor bind-interfaces work very well). > In Debian they more frequently use the normal dnsmasq/DNS service as it was > designed, because NM doesn't spawn a local resolver there. > > For upstream report, Simon (the upstream dnsmasq developer and Debian > maintainer) already answered here, Simon would you like me to file a > debian bug as well? It's easy to work around this issue, so we can even > close it with won't fix if you prefer. > > Thank you. > No need to file a Debian bug, whatever fix goes in will go into upstream and Debian anyway. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1501189 Title: DNS breaks when port=0 is used in dnsmasq.conf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1502226] [NEW] error message "dnsmasq: failed to create listening socket for 0.0.0.0: Address already in use" doesn't explain which port number it refers to
What configuration was in use to get that exact error message. If dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a message like dnsmasq: failed to create listening socket for port 53 Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect to see something like dnsmasq: failed to create listening socket for 192.168.151.1 So I'm confused how you're getting the message with an IP address, but for the 0.0.0.0 wildcard address. Cheers, Simon On 02/10/15 17:24, Karl-Philipp Richter wrote: > Public bug reported: > > The error message "dnsmasq: failed to create listening socket for > 0.0.0.0: Address already in use" doesn't explain which port number it > refers to. In case it's an OS message it needs to be catched and > enhanced with necessary information (in order to get any use of the > message). > > ProblemType: Bug > DistroRelease: Ubuntu 15.04 > Package: dnsmasq 2.72-3ubuntu0.1 > ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6 > Uname: Linux 3.19.0-30-generic x86_64 > NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx > ApportVersion: 2.17.2-0ubuntu1.5 > Architecture: amd64 > Date: Fri Oct 2 18:22:22 2015 > InstallationDate: Installed on 2015-04-20 (165 days ago) > InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 > (20141022.2)a > PackageArchitecture: all > ProcEnviron: > TERM=screen > PATH=(custom, no user)dig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > XDG_RUNTIME_DIR= > LANG=de_DE.UTF-8 > SHELL=/bin/bash > SourcePackage: dnsmasq > UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago) > mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888 > > ** Affects: dnsmasq (Ubuntu)dig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > Importance: Undecided > Status: New > > > ** Tags: amd64 apport-bug vivid > > ** Description changed: > > - error message "dnsmasq: failed to create listening socket for 0.0.0.0: > - Address already in use" doesn't explain which port number it refers to > + The error message "dnsmasq: failed to create listening socket for > + 0.0.0.0: Address already in use" doesn't explain which port number it > + refers to. In case it's an OS message it needs to be catched and > + enhanced with necessary information (in order to get any use of the > + message). > > ProblemType: Bug > DistroRelease: Ubuntu 15.04 > Package: dnsmasq 2.72-3ubuntu0.1 > ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6 > Uname: Linux 3.19.0-30-generic x86_64 > NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx > ApportVersion: 2.17.2-0ubuntu1.5 > Architecture: amd64 > Date: Fri Oct 2 18:22:22 2015 > InstallationDate: Installed on 2015-04-20 (165 days ago) > InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 > (20141022.2) > PackageArchitecture: all > ProcEnviron: > - TERM=screendig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > - PATH=(custom, no user) > - XDG_RUNTIME_DIR= > - LANG=de_DE.UTF-8 > - SHELL=/bin/bash > + TERM=screen > + PATH=(custom, no user) > + XDG_RUNTIME_DIR= > + LANG=de_DE.UTF-8 > + SHELL=/bin/bash > SourcePackage: dnsmasq > UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago) > mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888 > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1502226 Title: error message "dnsmasq: failed to create listening socket for 0.0.0.0: Address already in use" doesn't explain which port number it refers to To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1502226/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1501189] [NEW] Don't put 127.0.0.1 in resolvconf when port=0
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to override things in /etc/default/dnsmasq.
A better solution might be to extend the IGNORE_RESOLVCONF setting in
/etc/default/dnsmasq so that it inhibits adding 127.0.0.1 to resolvconf,
as well as stopping dnsmasq from using the resolvconf output as upstream.
Simon.
On 30/09/15 07:38, Alkis Georgopoulos wrote:
> Public bug reported:
>
> The following function is defined in /etc/init.d/dnsmasq:
>
> start_resolvconf()
> {
> # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
> # Then dnsmasq won't be providing local DNS, so don't add it to
> # the resolvconf server set.
> for interface in $DNSMASQ_EXCEPT
> do
> [ $interface = lo ] && return
> done
>
> if [ -x /sbin/resolvconf ] ; then
> echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
> fi
> return 0
> }
>
> When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it
> only as a (proxy)DHCP/TFTP server,
> 127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens
> there.
>
> One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
> But that doesn't make much sense, we don't want to exclude some interface,
> we're not running a DNS server at all.
>
> So it would be nice if dnsmasq checked if port=0 is defined in its
> configuration, and didn't add 127.0.0.1 to resolvconf then.
>
> Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf
> ]`:
> grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
>
> ** Affects: dnsmasq (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: patch
>
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1501189
Title:
Don't put 127.0.0.1 in resolvconf when port=0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1501189] [NEW] Don't put 127.0.0.1 in resolvconf when port=0
I'm sympathetic to aim, but this solution is rather fragile, there are
plenty of ways to get dnsmasq to read configuration from places other
than /etc/dnsmasq.conf and /etc/dnsmasq.d/*, for instance adding
conf-file=/path/to/more/configuration
to the existing config files.
It's also possible to override things in /etc/default/dnsmasq.
A better solution might be to extend the IGNORE_RESOLVCONF setting in
/etc/default/dnsmasq so that it inhibits adding 127.0.0.1 to resolvconf,
as well as stopping dnsmasq from using the resolvconf output as upstream.
Simon.
On 30/09/15 07:38, Alkis Georgopoulos wrote:
> Public bug reported:
>
> The following function is defined in /etc/init.d/dnsmasq:
>
> start_resolvconf()
> {
> # If interface "lo" is explicitly disabled in /etc/default/dnsmasq
> # Then dnsmasq won't be providing local DNS, so don't add it to
> # the resolvconf server set.
> for interface in $DNSMASQ_EXCEPT
> do
> [ $interface = lo ] && return
> done
>
> if [ -x /sbin/resolvconf ] ; then
> echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
> fi
> return 0
> }
>
> When someone puts port=0 in dnsmasq.conf, because e.g. he wants to use it
> only as a (proxy)DHCP/TFTP server,
> 127.0.0.1 is added to resolvconf, and DNS is broken because nothing listens
> there.
>
> One workaround is to put DNSMASQ_EXCEPT=lo in /etc/default/dnsmasq.
> But that doesn't make much sense, we don't want to exclude some interface,
> we're not running a DNS server at all.
>
> So it would be nice if dnsmasq checked if port=0 is defined in its
> configuration, and didn't add 127.0.0.1 to resolvconf then.
>
> Sample implementation code, to be inserted before `if [ -x /sbin/resolvconf
> ]`:
> grep -qr port=0 /etc/dnsmasq.d/ /etc/dnsmasq.conf && return
>
> ** Affects: dnsmasq (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: patch
>
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1501189
Title:
Don't put 127.0.0.1 in resolvconf when port=0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1501189/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1502226] [NEW] error message "dnsmasq: failed to create listening socket for 0.0.0.0: Address already in use" doesn't explain which port number it refers to
What configuration was in use to get that exact error message. If dnsmasq is binding the wildcard address (0.0.0.0), I'd expect to see a message like dnsmasq: failed to create listening socket for port 53 Whilst if dnsmasq is configured to bind the hosts addresses, I'd expect to see something like dnsmasq: failed to create listening socket for 192.168.151.1 So I'm confused how you're getting the message with an IP address, but for the 0.0.0.0 wildcard address. Cheers, Simon On 02/10/15 17:24, Karl-Philipp Richter wrote: > Public bug reported: > > The error message "dnsmasq: failed to create listening socket for > 0.0.0.0: Address already in use" doesn't explain which port number it > refers to. In case it's an OS message it needs to be catched and > enhanced with necessary information (in order to get any use of the > message). > > ProblemType: Bug > DistroRelease: Ubuntu 15.04 > Package: dnsmasq 2.72-3ubuntu0.1 > ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6 > Uname: Linux 3.19.0-30-generic x86_64 > NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx > ApportVersion: 2.17.2-0ubuntu1.5 > Architecture: amd64 > Date: Fri Oct 2 18:22:22 2015 > InstallationDate: Installed on 2015-04-20 (165 days ago) > InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 > (20141022.2)a > PackageArchitecture: all > ProcEnviron: > TERM=screen > PATH=(custom, no user)dig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > XDG_RUNTIME_DIR= > LANG=de_DE.UTF-8 > SHELL=/bin/bash > SourcePackage: dnsmasq > UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago) > mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888 > > ** Affects: dnsmasq (Ubuntu)dig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > Importance: Undecided > Status: New > > > ** Tags: amd64 apport-bug vivid > > ** Description changed: > > - error message "dnsmasq: failed to create listening socket for 0.0.0.0: > - Address already in use" doesn't explain which port number it refers to > + The error message "dnsmasq: failed to create listening socket for > + 0.0.0.0: Address already in use" doesn't explain which port number it > + refers to. In case it's an OS message it needs to be catched and > + enhanced with necessary information (in order to get any use of the > + message). > > ProblemType: Bug > DistroRelease: Ubuntu 15.04 > Package: dnsmasq 2.72-3ubuntu0.1 > ProcVersionSignature: Ubuntu 3.19.0-30.33-generic 3.19.8-ckt6 > Uname: Linux 3.19.0-30-generic x86_64 > NonfreeKernelModules: zfs zunicode zcommon znvpair zavl fglrx > ApportVersion: 2.17.2-0ubuntu1.5 > Architecture: amd64 > Date: Fri Oct 2 18:22:22 2015 > InstallationDate: Installed on 2015-04-20 (165 days ago) > InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 > (20141022.2) > PackageArchitecture: all > ProcEnviron: > - TERM=screendig @172.17.42.1 > d8607ce495db.node.aws-us-east-1.consul > - PATH=(custom, no user) > - XDG_RUNTIME_DIR= > - LANG=de_DE.UTF-8 > - SHELL=/bin/bash > + TERM=screen > + PATH=(custom, no user) > + XDG_RUNTIME_DIR= > + LANG=de_DE.UTF-8 > + SHELL=/bin/bash > SourcePackage: dnsmasq > UpgradeStatus: Upgraded to vivid on 2015-04-24 (160 days ago) > mtime.conffile..etc.dnsmasq.conf: 2015-06-13T18:46:46.597888 > -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1502226 Title: error message "dnsmasq: failed to create listening socket for 0.0.0.0: Address already in use" doesn't explain which port number it refers to To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1502226/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1468611] Re: dnsmasq fails to start in lxc-net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The underlying problem is that 2.73 accidentally change the meaning of dnsmasq --conf-file from don't read any conf-file to read the default conf-file. This is a bug, not a feature, and I've just committed a fix to git. Cheers, Simon. On 26/06/15 20:41, Christopher Townsend wrote: Hey Serge, Yes, I can confirm that setting LXC_DHCP_CONFILE=/dev/null does indeed make it work. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVmZu1AAoJEBXN2mrhkTWiX0YP/jN8smIOJxSj5A+aXsNhNvAL P+awNJoTV+qh+CEAaYQkNv+A+2pDbPlggJeJl24jHIsBOURcPM32ziqP9NyOFoQ+ +ryeK9pRLLE2TrrFc7JguM8DYSKlHRzBldTtCzU5Lfiom2PJm3iB96uAdNNsLU5J dLjicEBhQjs/PnM5x+tonWinGbpyJYJ0Kh9gRg9VG7aG571oyFn56Tj9PxEhZV7c 2rpVomrm2FL+C+9ozRJHcwj+Wv76IeUXSEk1nyjEbr0U+F5AvzdU/wXfydHxQlv/ igB8RivZozaWp2Xz62lnHaRRBA7QSeuCu08vngsKqBmP5HURgejzhOGfmBhnt7ZK HI35CNXAqAL/RFDiSbSXzzdQOEHN30Ferr0hZr57UxHbOgtFZV+c57wBciEU/gRv k6tkC/eJ7OuzrPrfK4cxSli2aeQEIDKmesQTrFP63pD11QwSXgBhRousArLqljgE 13RRwDkPXLYF9iKXem5z9qXAAxocmjYqmrQhjq51VUqOM6Svk0vSuZEk2K7TuS2L tsYNRZDUwIRYpJfzKKnQK1+flh7Y5WorcxWbNfMDBDhtLhUNoCvg4yH5+tI7x7eF oZAVBXo0mpdJkrmKGjhQkMunssIujsY4Nbc22guv9LWh/OpXteYFAmQRVmZcPHYO c5soqxgCzoOJNm3KBf2s =Dj/i -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1468611 Title: dnsmasq fails to start in lxc-net To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1468611/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1468611] Re: dnsmasq fails to start in lxc-net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The underlying problem is that 2.73 accidentally change the meaning of dnsmasq --conf-file from don't read any conf-file to read the default conf-file. This is a bug, not a feature, and I've just committed a fix to git. Cheers, Simon. On 26/06/15 20:41, Christopher Townsend wrote: Hey Serge, Yes, I can confirm that setting LXC_DHCP_CONFILE=/dev/null does indeed make it work. Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVmZu1AAoJEBXN2mrhkTWiX0YP/jN8smIOJxSj5A+aXsNhNvAL P+awNJoTV+qh+CEAaYQkNv+A+2pDbPlggJeJl24jHIsBOURcPM32ziqP9NyOFoQ+ +ryeK9pRLLE2TrrFc7JguM8DYSKlHRzBldTtCzU5Lfiom2PJm3iB96uAdNNsLU5J dLjicEBhQjs/PnM5x+tonWinGbpyJYJ0Kh9gRg9VG7aG571oyFn56Tj9PxEhZV7c 2rpVomrm2FL+C+9ozRJHcwj+Wv76IeUXSEk1nyjEbr0U+F5AvzdU/wXfydHxQlv/ igB8RivZozaWp2Xz62lnHaRRBA7QSeuCu08vngsKqBmP5HURgejzhOGfmBhnt7ZK HI35CNXAqAL/RFDiSbSXzzdQOEHN30Ferr0hZr57UxHbOgtFZV+c57wBciEU/gRv k6tkC/eJ7OuzrPrfK4cxSli2aeQEIDKmesQTrFP63pD11QwSXgBhRousArLqljgE 13RRwDkPXLYF9iKXem5z9qXAAxocmjYqmrQhjq51VUqOM6Svk0vSuZEk2K7TuS2L tsYNRZDUwIRYpJfzKKnQK1+flh7Y5WorcxWbNfMDBDhtLhUNoCvg4yH5+tI7x7eF oZAVBXo0mpdJkrmKGjhQkMunssIujsY4Nbc22guv9LWh/OpXteYFAmQRVmZcPHYO c5soqxgCzoOJNm3KBf2s =Dj/i -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1468611 Title: dnsmasq fails to start in lxc-net To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1468611/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1416895] Re: /etc/dnsmasq.conf does not contain an ending newline character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, this is fixed upstream. I'll add (LP: #1416895) to the changelog. Cheers, Simon. On 01/02/15 21:04, Thomas Hood wrote: Confirmed that the bug affects 2.72-2. $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a directory which end in .conf #conf-dir=/etc/dnsmasq.d/*.conf$ od -t c /etc/dnsmasq.conf | tail -n 2 0062620 / * . c o n f 0062627 $ ** Changed in: dnsmasq (Ubuntu) Status: New = Confirmed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUz+wdAAoJEBXN2mrhkTWi/gwP/1QL4kncy+NHv4u9XUu7C3Nf ilfwOPmZquxXL6Xe2SyoLcM6O5cMPamfMRNvp6upVozZqvn3buBSflXn5I5lgl6j J3/fmHwOl2uUg+GT7kM+6lca8SrFVaWuyOVLsCzlH1PVIuucrVoQmCGjMxo/3dy2 PB6fvMve21vGYYXs39rsmhoPFIOB+Xz10cbDeeyF4GIwFB15s3dPaL/9yy4y8x9O TUNivrrUVBAKqTFjx9rWx8Xi/h98sy2WJ0dZWnWCJuA0Vy01lnzwMK6WRDaZ4FKy XQ7anFgnLCD6I18PrFEb7g2kYzzwVGxqtvK53h8PNYh7swGxyr2eHxBHlkc6OC3E eZa20aqhgVENVC/5PSmR/jpoR1CJta52aNhu3lJy+Ym1aIy/fdQVog4TZ44osyHG VAOV4FEP0Ucw+tKAXzYlRDnCpMCsR/O8iycwgaJa2dhXPn156zY29MNxXdELMWo0 IUpBXG+KNm9NJty1HOZVoagUFI2pglXxnvYoh66sudBX3g27lXTIWTFjVoX5MyjY duxBo6leRzY7OrK8A2j/73OrgudBU94kLQF7iig3vEYx3EYwl8yIzB6yEP5TNzYf pX38rgBrSi3klsxg9ZVWXIIGz0demLCDO43rHnom6Uglq+zTFl6qePJ8XWwwPxMb bETeMWMAG08HQJoMDoYW =+g4T -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1416895 Title: /etc/dnsmasq.conf does not contain an ending newline character To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1416895/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1416895] Re: /etc/dnsmasq.conf does not contain an ending newline character
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, this is fixed upstream. I'll add (LP: #1416895) to the changelog. Cheers, Simon. On 01/02/15 21:04, Thomas Hood wrote: Confirmed that the bug affects 2.72-2. $ cat /etc/dnsmasq.conf | tail -n 2 # Include all files in a directory which end in .conf #conf-dir=/etc/dnsmasq.d/*.conf$ od -t c /etc/dnsmasq.conf | tail -n 2 0062620 / * . c o n f 0062627 $ ** Changed in: dnsmasq (Ubuntu) Status: New = Confirmed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUz+wdAAoJEBXN2mrhkTWi/gwP/1QL4kncy+NHv4u9XUu7C3Nf ilfwOPmZquxXL6Xe2SyoLcM6O5cMPamfMRNvp6upVozZqvn3buBSflXn5I5lgl6j J3/fmHwOl2uUg+GT7kM+6lca8SrFVaWuyOVLsCzlH1PVIuucrVoQmCGjMxo/3dy2 PB6fvMve21vGYYXs39rsmhoPFIOB+Xz10cbDeeyF4GIwFB15s3dPaL/9yy4y8x9O TUNivrrUVBAKqTFjx9rWx8Xi/h98sy2WJ0dZWnWCJuA0Vy01lnzwMK6WRDaZ4FKy XQ7anFgnLCD6I18PrFEb7g2kYzzwVGxqtvK53h8PNYh7swGxyr2eHxBHlkc6OC3E eZa20aqhgVENVC/5PSmR/jpoR1CJta52aNhu3lJy+Ym1aIy/fdQVog4TZ44osyHG VAOV4FEP0Ucw+tKAXzYlRDnCpMCsR/O8iycwgaJa2dhXPn156zY29MNxXdELMWo0 IUpBXG+KNm9NJty1HOZVoagUFI2pglXxnvYoh66sudBX3g27lXTIWTFjVoX5MyjY duxBo6leRzY7OrK8A2j/73OrgudBU94kLQF7iig3vEYx3EYwl8yIzB6yEP5TNzYf pX38rgBrSi3klsxg9ZVWXIIGz0demLCDO43rHnom6Uglq+zTFl6qePJ8XWwwPxMb bETeMWMAG08HQJoMDoYW =+g4T -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1416895 Title: /etc/dnsmasq.conf does not contain an ending newline character To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1416895/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[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 Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1327477
Title:
dnsmasq not using all DHCPv6 provided nameservers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1327477/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1327477
Title:
dnsmasq not using all DHCPv6 provided nameservers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1327477/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1314697] Re: DNS resolution no longer works; dnsmasq uses 100% CPU
On 08/05/14 22:18, James Hunt wrote: A bit of debugging shows that the culprit is blockdata_expand() which is being called via blockdata_init(). The issue seems to be that blockdata_expand() is passed a parameter of zero. That function then mallocs zero bytes (successfully seemingly), the proceeds to overwrite data before the returned address resulting the the 2 fds being set to zero. blockdata_expand() is passed zero since daemon-cachesize (aka dnsmasq_daemon-cachesize) is zero. This is confirmed by looking at syslog which shows: May 8 21:56:54 utopic dnsmasq[10812]: started, version 2.70 cache disabled Excellent. Many thanks for doing that. I've pushed the fix to the git repo and a test release, 2.71test2. I'm minded to make a 2.71 release (which has this and a few other bugfixes) in the next couple of days. BTW - the problem is recreatable for me every time simply by spinning up a utopic kvm instance. I'm on the end of a dodgy 3G connection that won't support a netinstall or image download in reasonable time/cost. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: DNS resolution no longer works; dnsmasq uses 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1314697] Re: DNS resolution no longer works; dnsmasq uses 100% CPU
On 08/05/14 22:18, James Hunt wrote: A bit of debugging shows that the culprit is blockdata_expand() which is being called via blockdata_init(). The issue seems to be that blockdata_expand() is passed a parameter of zero. That function then mallocs zero bytes (successfully seemingly), the proceeds to overwrite data before the returned address resulting the the 2 fds being set to zero. blockdata_expand() is passed zero since daemon-cachesize (aka dnsmasq_daemon-cachesize) is zero. This is confirmed by looking at syslog which shows: May 8 21:56:54 utopic dnsmasq[10812]: started, version 2.70 cache disabled Excellent. Many thanks for doing that. I've pushed the fix to the git repo and a test release, 2.71test2. I'm minded to make a 2.71 release (which has this and a few other bugfixes) in the next couple of days. BTW - the problem is recreatable for me every time simply by spinning up a utopic kvm instance. I'm on the end of a dodgy 3G connection that won't support a netinstall or image download in reasonable time/cost. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: DNS resolution no longer works; dnsmasq uses 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1314697] Re: DNS resolution no longer works; dnsmasq uses 100% CPU
Annoyingly, I still can't reproduce this on the systems I have available. On a system where the problem occurs, can it be reproduced when dnsmasq is started standalone with the same command-line parameters? The idea situation would be to get the bug to show up in a dnsmasq instance running under gdb. The strace gives lots of valuable information: during inialisation in network.c, create_bound_listeners() calls create_listeners() once. The creates a UDP socket and a TCP socket each bound to 127.0.1.1:53, with file-descriptors 4 and 5. Those file descriptors are stored in a struct listener object which will be the only one in a chain pointed to by daemon-listeners (or dnsmasq_daemon-listeners, in gdb). The file descriptors are stored in the -fd and -tcpfd fields of the struct. By the time dnsmasq gets to the select loop in dnsmasq.c, those two fields have somehow been zeroed - that's enough to exactly match what's in the strace. dnsmasq selects for read events on fd 0 instead of fd 4 and fd 5 and when select says that reading is OK, is makes the syscalls is would make for fd 4 (recvfrom) and fd 5 (accept) but to fd 0 instead. If someone can reproduce this in gdb I suggest doing the following. 1) Set a breakpoint in create_bound_listeners() and trace through until dnsmasq_daemon-listeners-fd and dnsmasq_daemon-listeners-tcpfd have the correct values (4 and 5) 2) Set watchpoints on those two expressions, and then continue execution. Gdb should then tell us where those locations are being overwritten. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: DNS resolution no longer works; dnsmasq uses 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1314697] Re: DNS resolution no longer works; dnsmasq uses 100% CPU
Annoyingly, I still can't reproduce this on the systems I have available. On a system where the problem occurs, can it be reproduced when dnsmasq is started standalone with the same command-line parameters? The idea situation would be to get the bug to show up in a dnsmasq instance running under gdb. The strace gives lots of valuable information: during inialisation in network.c, create_bound_listeners() calls create_listeners() once. The creates a UDP socket and a TCP socket each bound to 127.0.1.1:53, with file-descriptors 4 and 5. Those file descriptors are stored in a struct listener object which will be the only one in a chain pointed to by daemon-listeners (or dnsmasq_daemon-listeners, in gdb). The file descriptors are stored in the -fd and -tcpfd fields of the struct. By the time dnsmasq gets to the select loop in dnsmasq.c, those two fields have somehow been zeroed - that's enough to exactly match what's in the strace. dnsmasq selects for read events on fd 0 instead of fd 4 and fd 5 and when select says that reading is OK, is makes the syscalls is would make for fd 4 (recvfrom) and fd 5 (accept) but to fd 0 instead. If someone can reproduce this in gdb I suggest doing the following. 1) Set a breakpoint in create_bound_listeners() and trace through until dnsmasq_daemon-listeners-fd and dnsmasq_daemon-listeners-tcpfd have the correct values (4 and 5) 2) Set watchpoints on those two expressions, and then continue execution. Gdb should then tell us where those locations are being overwritten. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: DNS resolution no longer works; dnsmasq uses 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1314697] Re: Upon upgrade, DNS resolution no longer works
On 02/05/14 12:00, Adam Smith wrote: LSOF output below. I tried to put a strace in init.d but failed miserably lsof | grep dnsmasq dnsmasq 1430 dnsmasq cwd unknown /proc/1430/cwd (readlink: Permission denied) dnsmasq 1430 dnsmasq rtd unknown /proc/1430/root (readlink: Permission denied) dnsmasq 1430 dnsmasq txt unknown /proc/1430/exe (readlink: Permission denied) dnsmasq 1430 dnsmasq NOFD /proc/1430/fd (opendir: Permission denied) dnsmasq 2066 nobody cwd unknown /proc/2066/cwd (readlink: Permission denied) dnsmasq 2066 nobody rtd unknown /proc/2066/root (readlink: Permission denied) dnsmasq 2066 nobody txt unknown /proc/2066/exe (readlink: Permission denied) dnsmasq 2066 nobody NOFD /proc/2066/fd (opendir: Permission denied) dnsmasq 3176 libvirt-dnsmasq cwd unknown /proc/3176/cwd (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq rtd unknown /proc/3176/root (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq txt unknown /proc/3176/exe (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq NOFD /proc/3176/fd (opendir: Permission denied) It looks like that was done as an ordinary user. Please could you repeat as root sudo lsof | grep dnsmasq. I note that there's two instances of dnsmasq here, one started by libvirt (?) and one, I guess, started by network-manager. I wonder if some interaction between the two is what's causing the problem. Which one is the which is spinning? Can you disable the libvirt stuff and see if that makes a difference? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: Upon upgrade, DNS resolution no longer works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1314697] Re: Upon upgrade, DNS resolution no longer works
On 02/05/14 12:00, Adam Smith wrote: LSOF output below. I tried to put a strace in init.d but failed miserably lsof | grep dnsmasq dnsmasq 1430 dnsmasq cwd unknown /proc/1430/cwd (readlink: Permission denied) dnsmasq 1430 dnsmasq rtd unknown /proc/1430/root (readlink: Permission denied) dnsmasq 1430 dnsmasq txt unknown /proc/1430/exe (readlink: Permission denied) dnsmasq 1430 dnsmasq NOFD /proc/1430/fd (opendir: Permission denied) dnsmasq 2066 nobody cwd unknown /proc/2066/cwd (readlink: Permission denied) dnsmasq 2066 nobody rtd unknown /proc/2066/root (readlink: Permission denied) dnsmasq 2066 nobody txt unknown /proc/2066/exe (readlink: Permission denied) dnsmasq 2066 nobody NOFD /proc/2066/fd (opendir: Permission denied) dnsmasq 3176 libvirt-dnsmasq cwd unknown /proc/3176/cwd (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq rtd unknown /proc/3176/root (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq txt unknown /proc/3176/exe (readlink: Permission denied) dnsmasq 3176 libvirt-dnsmasq NOFD /proc/3176/fd (opendir: Permission denied) It looks like that was done as an ordinary user. Please could you repeat as root sudo lsof | grep dnsmasq. I note that there's two instances of dnsmasq here, one started by libvirt (?) and one, I guess, started by network-manager. I wonder if some interaction between the two is what's causing the problem. Which one is the which is spinning? Can you disable the libvirt stuff and see if that makes a difference? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: Upon upgrade, DNS resolution no longer works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1314697] Re: Upon upgrade, DNS resolution no longer works
On 01/05/14 07:45, Colin King wrote: I'm seeing this too, strace show it spinning on: select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) So we're getting ENOTSOCK on fd 0, which is /dev/null : It would be really useful to get an strace of dnsmasq from startup to when it's in this state, since I've no yet been able to reproduce this. Also the output of lsof | grep dnsmasq The bug looks superficially like an earlier one which was triggered by starting dnsmasq without stdout/stdin/stderr (ie fd 0,1,2). Sockets would be opened which used these fds, and subsequently the connect std* to /dev/null code would trash them. However that doesn't explain why both the UDP and TCP listening sockets seem to be zero here. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: Upon upgrade, DNS resolution no longer works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1314697] Re: Upon upgrade, DNS resolution no longer works
On 01/05/14 07:45, Colin King wrote: I'm seeing this too, strace show it spinning on: select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7fffdb2aa6d0, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) So we're getting ENOTSOCK on fd 0, which is /dev/null : It would be really useful to get an strace of dnsmasq from startup to when it's in this state, since I've no yet been able to reproduce this. Also the output of lsof | grep dnsmasq The bug looks superficially like an earlier one which was triggered by starting dnsmasq without stdout/stdin/stderr (ie fd 0,1,2). Sockets would be opened which used these fds, and subsequently the connect std* to /dev/null code would trash them. However that doesn't explain why both the UDP and TCP listening sockets seem to be zero here. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: Upon upgrade, DNS resolution no longer works To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1313393] [NEW] dnsmasq lockup at 100% cpu
This is useful, thanks. A couple of questions: 1) Is this easily reproducible? 2) Could you tell me exactly what command-line flags dnsmasq is being started with? Cheers, Simon. On 27/04/14 18:02, Dave Gilbert wrote: Public bug reported: I hit a case where dnsmasq was running at 100% cpu and not responding to requests. This is a freshly installed and updated trusty VM which has just been dist-upgraded to utopic. At boot/login it seemed OK, but then I bought up firefox and it couldn't get to it's home page, top showed dnsmasq eating cpu. strace'ing dnsmasq showed it doing: select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7ba98110, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) constantly. fd 8 is a pipe (not sure where to - back to another thread?) This is the dnsmasq kicked off by a default network manager setup; not changed any networking settings. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: dnsmasq-base 2.70-1 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Sun Apr 27 17:58:21 2014 InstallationDate: Installed on 2014-04-27 (0 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Daily amd64 (20140412) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1313393] Re: dnsmasq lockup at 100% cpu
On 27/04/14 18:53, Dave Gilbert wrote: Hi Simon, 1) Apparently so - I just rebooted the vm to see if I could repeat it, and it was already stuck at 100% and non-responsive. (and blueskaj who confirmed it was seeing the same problem on irc) 2) /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d (typed so typos are probably mine) sudo killing the dnsmasq and then reenabling the network interface on nm gets it working again. That's great, thanks. I can't reproduce this, but I have a few hunches as to what the problem may be. If I supply you with modified code are you in a position to compile and test it? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1313393] Re: dnsmasq lockup at 100% cpu
On 27/04/14 18:53, Dave Gilbert wrote: Hi Simon, 1) Apparently so - I just rebooted the vm to see if I could repeat it, and it was already stuck at 100% and non-responsive. (and blueskaj who confirmed it was seeing the same problem on irc) 2) /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d (typed so typos are probably mine) sudo killing the dnsmasq and then reenabling the network interface on nm gets it working again. Further to my previous, another useful option would be to replace the dnsmasq binary with a wrapper which runs is under strace and routes the strace output to a file. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1313393] [NEW] dnsmasq lockup at 100% cpu
This is useful, thanks. A couple of questions: 1) Is this easily reproducible? 2) Could you tell me exactly what command-line flags dnsmasq is being started with? Cheers, Simon. On 27/04/14 18:02, Dave Gilbert wrote: Public bug reported: I hit a case where dnsmasq was running at 100% cpu and not responding to requests. This is a freshly installed and updated trusty VM which has just been dist-upgraded to utopic. At boot/login it seemed OK, but then I bought up firefox and it couldn't get to it's home page, top showed dnsmasq eating cpu. strace'ing dnsmasq showed it doing: select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) recvmsg(0, 0x7ba98110, 0) = -1 ENOTSOCK (Socket operation on non-socket) accept(0, 0, NULL) = -1 ENOTSOCK (Socket operation on non-socket) select(8, [0 3 6 7], [], [6], NULL) = 1 (in [0]) constantly. fd 8 is a pipe (not sure where to - back to another thread?) This is the dnsmasq kicked off by a default network manager setup; not changed any networking settings. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: dnsmasq-base 2.70-1 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Sun Apr 27 17:58:21 2014 InstallationDate: Installed on 2014-04-27 (0 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Daily amd64 (20140412) SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1313393] Re: dnsmasq lockup at 100% cpu
On 27/04/14 18:53, Dave Gilbert wrote: Hi Simon, 1) Apparently so - I just rebooted the vm to see if I could repeat it, and it was already stuck at 100% and non-responsive. (and blueskaj who confirmed it was seeing the same problem on irc) 2) /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d (typed so typos are probably mine) sudo killing the dnsmasq and then reenabling the network interface on nm gets it working again. Further to my previous, another useful option would be to replace the dnsmasq binary with a wrapper which runs is under strace and routes the strace output to a file. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1313393] Re: dnsmasq lockup at 100% cpu
On 27/04/14 18:53, Dave Gilbert wrote: Hi Simon, 1) Apparently so - I just rebooted the vm to see if I could repeat it, and it was already stuck at 100% and non-responsive. (and blueskaj who confirmed it was seeing the same problem on irc) 2) /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d (typed so typos are probably mine) sudo killing the dnsmasq and then reenabling the network interface on nm gets it working again. That's great, thanks. I can't reproduce this, but I have a few hunches as to what the problem may be. If I supply you with modified code are you in a position to compile and test it? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1313393 Title: dnsmasq lockup at 100% cpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1313393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1291369] [NEW] dnsmasq can't send OFFERS missing capabilities but doesn't check
On 12/03/14 13:24, fish wrote: Public bug reported: Hi, I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq without arguments and it failed with: dnsmasq: setting capabilities failed: Operation not permitted Guess this is expected because the container has limited privileges. The odd thing is, if I start it with --no-daemon it starts just fine, it receives the DISCOVERs and says it's sending the OFFERS. The log shows: dnsmasq-dhcp: DHCPDISCOVER(eth1) a4:ba:db:0a:3f:ef dnsmasq-dhcp: DHCPOFFER(eth1) 192.168.101.183 a4:ba:db:0a:3f:ef But according to tcpdump it's trying to send this as unicast which isn't possible (I only see arp requests to resolve 192.168.101.183). This is a strace when answering the request: https://gist.github.com/discordianfish/687f4cb5756c9cf3d841 No idea whether this is just a obscure bug or dnsmasq trying to be smart. So guess in the end it needs just better error handling/checks for capabilities. ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New From the dnsmasq man page: -d, --no-daemon Debug mode: don't fork to the background, don't write a pid file, don't change user id, generate a complete cache dump on receipt on SIGUSR1, log to stderr as well as syslog, don't fork new processes to handle TCP queries. Note that this option is for use in debugging only, to stop dnsmasq daemonising in production, use -k. Note last sentence. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1291369 Title: dnsmasq can't send OFFERS missing capabilities but doesn't check To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1291369/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1291369] [NEW] dnsmasq can't send OFFERS missing capabilities but doesn't check
On 12/03/14 13:24, fish wrote: Public bug reported: Hi, I'm running dnsmasq in a (docker) container. If I tried to start dnsmasq without arguments and it failed with: dnsmasq: setting capabilities failed: Operation not permitted Guess this is expected because the container has limited privileges. The odd thing is, if I start it with --no-daemon it starts just fine, it receives the DISCOVERs and says it's sending the OFFERS. The log shows: dnsmasq-dhcp: DHCPDISCOVER(eth1) a4:ba:db:0a:3f:ef dnsmasq-dhcp: DHCPOFFER(eth1) 192.168.101.183 a4:ba:db:0a:3f:ef But according to tcpdump it's trying to send this as unicast which isn't possible (I only see arp requests to resolve 192.168.101.183). This is a strace when answering the request: https://gist.github.com/discordianfish/687f4cb5756c9cf3d841 No idea whether this is just a obscure bug or dnsmasq trying to be smart. So guess in the end it needs just better error handling/checks for capabilities. ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New From the dnsmasq man page: -d, --no-daemon Debug mode: don't fork to the background, don't write a pid file, don't change user id, generate a complete cache dump on receipt on SIGUSR1, log to stderr as well as syslog, don't fork new processes to handle TCP queries. Note that this option is for use in debugging only, to stop dnsmasq daemonising in production, use -k. Note last sentence. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1291369 Title: dnsmasq can't send OFFERS missing capabilities but doesn't check To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1291369/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1247803] Re: dnsmasq temporarily breaks DNS resolution when starting for the first time
On 09/11/13 19:07, Philip Potter wrote: I agree that the postinst is a better place than the init script to run resolvconf -u. I'm not sure that it should be conditional on IGNORE_RESOLVCONF though - given that the update script will be run next time anything touches resolvconf, what's to be gained by not running it in the postinst? And why stop there? Why not also make it conditional on ENABLED=0? I've created a branch with an unconditional resolvconf -u in the postinst. I'm new to launchpad and bazaar so I'm not sure what the next step is -- do I propose a merge? Do I attach a patch to this ticket? Once this has gone though Ubunutu processes, please send my a diff and I'll propogate it to the Debian package. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1247803 Title: dnsmasq temporarily breaks DNS resolution when starting for the first time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1247803/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1247803] Re: dnsmasq temporarily breaks DNS resolution when starting for the first time
On 09/11/13 19:07, Philip Potter wrote: I agree that the postinst is a better place than the init script to run resolvconf -u. I'm not sure that it should be conditional on IGNORE_RESOLVCONF though - given that the update script will be run next time anything touches resolvconf, what's to be gained by not running it in the postinst? And why stop there? Why not also make it conditional on ENABLED=0? I've created a branch with an unconditional resolvconf -u in the postinst. I'm new to launchpad and bazaar so I'm not sure what the next step is -- do I propose a merge? Do I attach a patch to this ticket? Once this has gone though Ubunutu processes, please send my a diff and I'll propogate it to the Debian package. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1247803 Title: dnsmasq temporarily breaks DNS resolution when starting for the first time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1247803/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1231893] [NEW] dnsmasq sometimes lose primary dns (saucy)
On 27/09/13 10:37, Franck wrote: Public bug reported: Since I upgraded to Saucy, my local dnsmasq instance seems to lose its primary dns server and fallback to secondary dns. Since the primary dns is a dnsmasq instance that knows of local servers, and the secondary one is external, my local dnsmasq instance fails to resolv local server names. This does not happen on startup, it happens after some time. Restarting solves the issue. It does not happen on Raring... not sure where to look for to resolve this issue... Dnsmasq doesn't consider the DNS servers to be primary and secondary. They're both equivalent, and which ever answers fastest will be used. Every so often, the race is re-run, with a query sent to all servers, and the one which answers first becoming the new preferred server. It's possible to change this behaviour to something more like what you're expecting with the strict-order dnsmasq config flag. It's possible that was set in Raring and is no longer in Saucy, or you might just have been lucky before. Leaving it to the Ubuntu devs to answer that. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1231893 Title: dnsmasq sometimes lose primary dns (saucy) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1231893/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1231893] [NEW] dnsmasq sometimes lose primary dns (saucy)
On 27/09/13 10:37, Franck wrote: Public bug reported: Since I upgraded to Saucy, my local dnsmasq instance seems to lose its primary dns server and fallback to secondary dns. Since the primary dns is a dnsmasq instance that knows of local servers, and the secondary one is external, my local dnsmasq instance fails to resolv local server names. This does not happen on startup, it happens after some time. Restarting solves the issue. It does not happen on Raring... not sure where to look for to resolve this issue... Dnsmasq doesn't consider the DNS servers to be primary and secondary. They're both equivalent, and which ever answers fastest will be used. Every so often, the race is re-run, with a query sent to all servers, and the one which answers first becoming the new preferred server. It's possible to change this behaviour to something more like what you're expecting with the strict-order dnsmasq config flag. It's possible that was set in Raring and is no longer in Saucy, or you might just have been lucky before. Leaving it to the Ubuntu devs to answer that. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1231893 Title: dnsmasq sometimes lose primary dns (saucy) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1231893/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1203430] Re: dnsmasq doesn't listen on a given 127.* listen-address if bind-dynamic, interface and except-interface options are given
Fixed in developement version. thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09 Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1203430 Title: dnsmasq doesn't listen on a given 127.* listen-address if bind- dynamic, interface and except-interface options are given To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1203430/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1203430] Re: dnsmasq doesn't listen on a given 127.* listen-address if bind-dynamic, interface and except-interface options are given
Fixed in developement version. thttp://hekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=edf0bde0c6837b010560c40e6b74d2f67b64da09 Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1203430 Title: dnsmasq doesn't listen on a given 127.* listen-address if bind- dynamic, interface and except-interface options are given To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1203430/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
On 24/07/13 20:33, Thomas Hood wrote: Hi Simon, I think we've established that the submitter is having a problem with dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would be interesting to know if clear-on-reload fixes the submitter's problem. (He already said that no-negcache fixes it.) That clear-on-reload is ignored in the D-Bus case sounds like a distinct issue. Agreed, I'll fix that now. What about Stéphane's suggestion that dnsmasq treats failure to find a name in /etc/hosts as a NXDOMAIN? No name in /etc/hosts and no upstream servers - NXDOMAIN reply, but no state changes: the same query repeated after installing an upstream server would result in a query to the upstream server. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
On 24/07/13 20:33, Thomas Hood wrote: Hi Simon, I think we've established that the submitter is having a problem with dnsmasq server, not with NetworkManager-controlled dnsmasq. So it would be interesting to know if clear-on-reload fixes the submitter's problem. (He already said that no-negcache fixes it.) That clear-on-reload is ignored in the D-Bus case sounds like a distinct issue. Agreed, I'll fix that now. What about Stéphane's suggestion that dnsmasq treats failure to find a name in /etc/hosts as a NXDOMAIN? No name in /etc/hosts and no upstream servers - NXDOMAIN reply, but no state changes: the same query repeated after installing an upstream server would result in a query to the upstream server. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
On 08/07/13 15:02, Thomas Hood wrote: What do you think, Simon? ** Changed in: dnsmasq (Ubuntu) Status: Incomplete = New I'm confused: dnsmasq won't cache a negative answer if it has no upstream servers. To cache a negative answer it has to _receive_ a negative answer (and the negative answer has to have certain information, notably an SOA record to determine the TTL for the negative answer. Whatever is going on, it's more complex. Maybe the problem is that dnsmasq gets a negative answer from some upstream server, and then gets a new upstream server which has the correct information? The solution then is --clear-on-reload but I think NM sets that? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
Whatever is going on, it's more complex. Maybe the problem is that dnsmasq gets a negative answer from some upstream server, and then gets a new upstream server which has the correct information? The solution then is --clear-on-reload but I think NM sets that? but --clear-on-reload doesn't appear to do anything when the upstream nameservers are set via DBus, maybe that's the underlying problem. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
On 08/07/13 15:02, Thomas Hood wrote: What do you think, Simon? ** Changed in: dnsmasq (Ubuntu) Status: Incomplete = New I'm confused: dnsmasq won't cache a negative answer if it has no upstream servers. To cache a negative answer it has to _receive_ a negative answer (and the negative answer has to have certain information, notably an SOA record to determine the TTL for the negative answer. Whatever is going on, it's more complex. Maybe the problem is that dnsmasq gets a negative answer from some upstream server, and then gets a new upstream server which has the correct information? The solution then is --clear-on-reload but I think NM sets that? Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1172467] Re: Dnsmasq caches negative results if it starts before the network is up
Whatever is going on, it's more complex. Maybe the problem is that dnsmasq gets a negative answer from some upstream server, and then gets a new upstream server which has the correct information? The solution then is --clear-on-reload but I think NM sets that? but --clear-on-reload doesn't appear to do anything when the upstream nameservers are set via DBus, maybe that's the underlying problem. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1172467 Title: Dnsmasq caches negative results if it starts before the network is up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1172467/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1126488] [NEW] libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 18:00, Steve Langasek wrote: Public bug reported: On a raring system, the dnsmasq instance spawned by libvirt is not forwarding DNS requests to the upstream resolver. dnsmasq is run as: /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Steve, what version of dnsmasq is exhibiting the bug? Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1126488] Re: libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 18:52, Steve Langasek wrote: On Fri, Feb 15, 2013 at 06:35:40PM -, Simon Kelley wrote: On 15/02/13 18:00, Steve Langasek wrote: Public bug reported: On a raring system, the dnsmasq instance spawned by libvirt is not forwarding DNS requests to the upstream resolver. dnsmasq is run as: /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Steve, what version of dnsmasq is exhibiting the bug? The raring version, 2.65-1. I've just installed a test package from https://launchpad.net/~mdeslaur/+archive/testing per Seth Arnold's suggestion on IRC, which appears to resolve the issue. According to Seth, that implies this is probably linked to https://bugzilla.redhat.com/show_bug.cgi?id=894486. ** Bug watch added: Red Hat Bugzilla #894486 https://bugzilla.redhat.com/show_bug.cgi?id=894486 That's possible, but the fix for RedHat involves subtracting from the set of queries which get answered, not adding to it, so that doesn't quite fit the description. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1126488] Re: libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 19:52, Marc Deslauriers wrote: I was waiting for 2.66 to come out. Simon, is a 2.66 release planned soon? Probably not soon. There are no current showstopper issues, but there's a lot of new code over 2.65, so it will need a reasonably long release-candidate period to get it tested. I'd like to understand what the problem is with 2.65, since I'm not aware of this problem and I don't understand how 2.66 has fixed it. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1126488] [NEW] libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 18:00, Steve Langasek wrote: Public bug reported: On a raring system, the dnsmasq instance spawned by libvirt is not forwarding DNS requests to the upstream resolver. dnsmasq is run as: /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Steve, what version of dnsmasq is exhibiting the bug? Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1126488] Re: libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 18:52, Steve Langasek wrote: On Fri, Feb 15, 2013 at 06:35:40PM -, Simon Kelley wrote: On 15/02/13 18:00, Steve Langasek wrote: Public bug reported: On a raring system, the dnsmasq instance spawned by libvirt is not forwarding DNS requests to the upstream resolver. dnsmasq is run as: /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf Steve, what version of dnsmasq is exhibiting the bug? The raring version, 2.65-1. I've just installed a test package from https://launchpad.net/~mdeslaur/+archive/testing per Seth Arnold's suggestion on IRC, which appears to resolve the issue. According to Seth, that implies this is probably linked to https://bugzilla.redhat.com/show_bug.cgi?id=894486. ** Bug watch added: Red Hat Bugzilla #894486 https://bugzilla.redhat.com/show_bug.cgi?id=894486 That's possible, but the fix for RedHat involves subtracting from the set of queries which get answered, not adding to it, so that doesn't quite fit the description. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1126488] Re: libvirt instance of dnsmasq in raring fails to forward DNS requests
On 15/02/13 19:52, Marc Deslauriers wrote: I was waiting for 2.66 to come out. Simon, is a 2.66 release planned soon? Probably not soon. There are no current showstopper issues, but there's a lot of new code over 2.65, so it will need a reasonably long release-candidate period to get it tested. I'd like to understand what the problem is with 2.65, since I'm not aware of this problem and I don't understand how 2.66 has fixed it. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1126488 Title: libvirt instance of dnsmasq in raring fails to forward DNS requests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1126488/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1072899] [NEW] vpn dns server addresses - host lookups fail if first server is not reachable
On 29/10/12 21:50, Glenn Coombs wrote: The nm-dns-dnsmasq.conf file only shows information relating to the 1st server - it seems to have totally ignored the 2nd server: $ cat /var/run/nm-dns-dnsmasq.conf server=/kl.imgtec.org/192.168.15.221 server=/79.168.192.in-addr.arpa/192.168.15.221 server=/200.9.192.in-addr.arpa/192.168.15.221 server=/5.168.192.in-addr.arpa/192.168.15.221 server=/6.168.192.in-addr.arpa/192.168.15.221 server=/7.168.192.in-addr.arpa/192.168.15.221 server=/14.168.192.in-addr.arpa/192.168.15.221 server=/15.168.192.in-addr.arpa/192.168.15.221 This would seem to indicate a network-manager problem, rather than one with dnsmasq. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1072899 Title: vpn dns server addresses - host lookups fail if first server is not reachable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1072899/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1072899] [NEW] vpn dns server addresses - host lookups fail if first server is not reachable
On 29/10/12 21:50, Glenn Coombs wrote: The nm-dns-dnsmasq.conf file only shows information relating to the 1st server - it seems to have totally ignored the 2nd server: $ cat /var/run/nm-dns-dnsmasq.conf server=/kl.imgtec.org/192.168.15.221 server=/79.168.192.in-addr.arpa/192.168.15.221 server=/200.9.192.in-addr.arpa/192.168.15.221 server=/5.168.192.in-addr.arpa/192.168.15.221 server=/6.168.192.in-addr.arpa/192.168.15.221 server=/7.168.192.in-addr.arpa/192.168.15.221 server=/14.168.192.in-addr.arpa/192.168.15.221 server=/15.168.192.in-addr.arpa/192.168.15.221 This would seem to indicate a network-manager problem, rather than one with dnsmasq. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1072899 Title: vpn dns server addresses - host lookups fail if first server is not reachable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1072899/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1027808] Re: dnsmasq doesn't start at system startup
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote: Any news about this? There's actually multiple issues here; one of them being that loopback probably isn't ready yet, which is something we fixed in NetworkManager (which had the same issue) by depending on it through upstart before starting the network-manager job. Then, we now ship configuration in /etc/dnsmasq.d/network-manager which explicitly mentions bind-interfaces and except-interface=lo; which would clash with your configuration. Your best bet is to disable NetworkManager's instance of dnsmasq used for dnsmasq caching (and remove /etc/dnsmasq.d/network-manager) or to disable the system-wide instance. My guess is that adding bind-interfaces in /etc/dnsmasq.d/network-manager is what's causing the system dnsmasq to fail if the lo interface is not up when it starts. Moving to dnsmasq 2.63 and substituting bind-dynamic for bind-interfaces should solve that problem, backporting bind-dynamic to earlier releases is not for the faint-hearted... Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1027808 Title: dnsmasq doesn't start at system startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1027808/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1027808] Re: dnsmasq doesn't start at system startup
On 17/08/12 19:26, Mathieu Trudel-Lapierre wrote: Any news about this? There's actually multiple issues here; one of them being that loopback probably isn't ready yet, which is something we fixed in NetworkManager (which had the same issue) by depending on it through upstart before starting the network-manager job. Then, we now ship configuration in /etc/dnsmasq.d/network-manager which explicitly mentions bind-interfaces and except-interface=lo; which would clash with your configuration. Your best bet is to disable NetworkManager's instance of dnsmasq used for dnsmasq caching (and remove /etc/dnsmasq.d/network-manager) or to disable the system-wide instance. My guess is that adding bind-interfaces in /etc/dnsmasq.d/network-manager is what's causing the system dnsmasq to fail if the lo interface is not up when it starts. Moving to dnsmasq 2.63 and substituting bind-dynamic for bind-interfaces should solve that problem, backporting bind-dynamic to earlier releases is not for the faint-hearted... Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1027808 Title: dnsmasq doesn't start at system startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1027808/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1029977] Re: dnsmasq-base should ship the dnsmasq dbus configuration file
On 27/07/12 16:10, Launchpad Bug Tracker wrote: This bug was fixed in the package dnsmasq - 2.62-3ubuntu1 --- dnsmasq (2.62-3ubuntu1) quantal; urgency=low * debian/rules: install the dnsmasq dbus configuration in dnsmasq-base, since users of the standalone binary might want to use DBus (ie. NetworkManager). (LP: #1029977) * debian/control: dnsmasq-base Breaks/Replaces dnsmasq ( 2.62-3ubuntu1) due to the file move. * debian/dnsmasq.conffiles, debian/dnsmasq-base.conffiles: make sure the dbus configuration file is properly listed as such. -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com Tue, 24 Jul 2012 08:57:45 -0400 ** Changed in: dnsmasq (Ubuntu) Status: In Progress = Fix Released Fix taken for Debian 2.63-1 release. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1029977 Title: dnsmasq-base should ship the dnsmasq dbus configuration file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1029977/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1029977] Re: dnsmasq-base should ship the dnsmasq dbus configuration file
On 27/07/12 16:10, Launchpad Bug Tracker wrote: This bug was fixed in the package dnsmasq - 2.62-3ubuntu1 --- dnsmasq (2.62-3ubuntu1) quantal; urgency=low * debian/rules: install the dnsmasq dbus configuration in dnsmasq-base, since users of the standalone binary might want to use DBus (ie. NetworkManager). (LP: #1029977) * debian/control: dnsmasq-base Breaks/Replaces dnsmasq ( 2.62-3ubuntu1) due to the file move. * debian/dnsmasq.conffiles, debian/dnsmasq-base.conffiles: make sure the dbus configuration file is properly listed as such. -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com Tue, 24 Jul 2012 08:57:45 -0400 ** Changed in: dnsmasq (Ubuntu) Status: In Progress = Fix Released Fix taken for Debian 2.63-1 release. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1029977 Title: dnsmasq-base should ship the dnsmasq dbus configuration file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1029977/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/991308 Title: DNS Querying fails if any DNS server is unreachable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/991308/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/991308 Title: DNS Querying fails if any DNS server is unreachable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/991308/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
On 19/06/12 10:10, Chris Halse Rogers wrote: Additionally, I'd like to know what the likely impact of adding bind- interfaces to dnsmasq is on users. What (if anything) will break on users' systems? Three things change. 1) Dnsmasq loses the ability to provide service on dynamically created interface. If an interface doesn't exist when dnsmasq starts, dnsmasq will not be listening on that interface when it comes up. Similarly if an interface changes address. 2) --interface=non-existent interface becomes a fatal error. 3) The semantics of -interface changes. Without --bind-interfaces, --interface filters on packet arrival interface. With --bind-interface, --interface=iface becomes equivalent to --listen-address=address(es) of iface. So, on a multi-homed host, with --interface=eth0, a request sent to the address of eth0 which arrives from eth1 will be answered with --bind-interfaces, but not answered without it. HTH Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other
On 19/06/12 10:10, Chris Halse Rogers wrote: Additionally, I'd like to know what the likely impact of adding bind- interfaces to dnsmasq is on users. What (if anything) will break on users' systems? Three things change. 1) Dnsmasq loses the ability to provide service on dynamically created interface. If an interface doesn't exist when dnsmasq starts, dnsmasq will not be listening on that interface when it comes up. Similarly if an interface changes address. 2) --interface=non-existent interface becomes a fatal error. 3) The semantics of -interface changes. Without --bind-interfaces, --interface filters on packet arrival interface. With --bind-interface, --interface=iface becomes equivalent to --listen-address=address(es) of iface. So, on a multi-homed host, with --interface=eth0, a request sent to the address of eth0 which arrives from eth1 will be answered with --bind-interfaces, but not answered without it. HTH Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/231060 Title: packages dnsmasq and libvirt-bin conflict with each other To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/231060/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 928524] Re: lxcbr0 fails to come up when dnsmasq is installed
On 18/06/12 18:11, Thomas Hood wrote: Hi Stéphane, Changing the default of dnsmasq to bind-interfaces wouldn't have been a very good solution because some people run dnsmasq without installing those other packages and rely upon the unbound mode. The implemented solution is better because the cases of dnsmasq being forced into bind- interfaces mode will be fewer. I guess the only risk of breakage is in cases like the following. Someone is using dnsmasq and requires unbound mode, has installed lxc but disabled it. She upgrades (getting a new lxc in the process) and finds that dnsmasq no longer works as expected. I'm certainly not saying that this is a showstopper, just that risk of malheur isn't nonexistent. I'm wondering about adding a _third_ mode, which is has a desirable mixture of the properties of the current two (--bind-interfaces and NOT --bind-interfaces). Essentially, dnsmasq would bind the addresses of individual interfaces rather than the wildcard address, making it less of a bully for other dnsmasq instances or DNS servers, but it would use netlink to track the creation of new interfaces or the addition of new addresses to existing interfaces, and automatically bind them as required. This mode is inherently Linux-specific, since it needs netlink to work. You could either just use it as the default, or as a less problematic alternative to --bind-interfaces to be dropped into the system dnsmasq by networkmanager. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/928524 Title: lxcbr0 fails to come up when dnsmasq is installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/928524/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 928524] Re: lxcbr0 fails to come up when dnsmasq is installed
On 18/06/12 18:11, Thomas Hood wrote: Hi Stéphane, Changing the default of dnsmasq to bind-interfaces wouldn't have been a very good solution because some people run dnsmasq without installing those other packages and rely upon the unbound mode. The implemented solution is better because the cases of dnsmasq being forced into bind- interfaces mode will be fewer. I guess the only risk of breakage is in cases like the following. Someone is using dnsmasq and requires unbound mode, has installed lxc but disabled it. She upgrades (getting a new lxc in the process) and finds that dnsmasq no longer works as expected. I'm certainly not saying that this is a showstopper, just that risk of malheur isn't nonexistent. I'm wondering about adding a _third_ mode, which is has a desirable mixture of the properties of the current two (--bind-interfaces and NOT --bind-interfaces). Essentially, dnsmasq would bind the addresses of individual interfaces rather than the wildcard address, making it less of a bully for other dnsmasq instances or DNS servers, but it would use netlink to track the creation of new interfaces or the addition of new addresses to existing interfaces, and automatically bind them as required. This mode is inherently Linux-specific, since it needs netlink to work. You could either just use it as the default, or as a less problematic alternative to --bind-interfaces to be dropped into the system dnsmasq by networkmanager. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/928524 Title: lxcbr0 fails to come up when dnsmasq is installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/928524/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1013529] Re: dnsmasq 2.61 cause problems with dhcp in single-bound VLAN interfaces
On 15/06/12 14:54, Christian Parpart wrote: Hey, thanks, and now I also found this one: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898 which is exactly what I was talking about (interesting that I didn't find earlier). However, the last commenter says he's pulling it into precise next days, but this is about 2 weeks ago. :-( No, that was me, and I said I'd release 2.62 (upstream and Debian packages, which I'm responsible for), and I did, on the 4th June. Simon. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1013529 Title: dnsmasq 2.61 cause problems with dhcp in single-bound VLAN interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1013529/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1013529] Re: dnsmasq 2.61 cause problems with dhcp in single-bound VLAN interfaces
On 15/06/12 14:54, Christian Parpart wrote: Hey, thanks, and now I also found this one: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898 which is exactly what I was talking about (interesting that I didn't find earlier). However, the last commenter says he's pulling it into precise next days, but this is about 2 weeks ago. :-( No, that was me, and I said I'd release 2.62 (upstream and Debian packages, which I'm responsible for), and I did, on the 4th June. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1013529 Title: dnsmasq 2.61 cause problems with dhcp in single-bound VLAN interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1013529/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [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 Ubuntu Server Team, which is subscribed to dnsmasq 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
