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] [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 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 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
[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 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 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 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 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] 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 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] [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 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 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 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 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 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 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 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 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 -0000, 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] [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 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. > > 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 > 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 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
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 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
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 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 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 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-LapierreTue, 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 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 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= becomes a fatal error. 3) The semantics of -interface changes. Without --bind-interfaces, --interface filters on packet arrival interface. With --bind-interface, --interface= becomes equivalent to --listen-address=. So, on a multi-homed host, with --interface=, 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 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 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 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 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 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 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 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. > Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address= where is not on an interface, will listen on port 69 of 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 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 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
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 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 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 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 11/06/12 20:41, Thomas Hood wrote: > Aha, I had tried this and it didn't work... in version 2.57. But I see > that quantal already has 2.62. > >> Another instance of dnsmasq will run without interfering with that, > providing only that --bind-interfaces is set. > > Just to make sure I understand correctly: Do you mean here that --bind- > interfaces has to be set on both instances of dnsmasq? Or will one > instance (the NM-controlled one) with --bind-interfaces coexist nicely > with another (the standalone dnsmasq) which doesn't use that option and > listens on 0.0.0.0? It has to be set in both instances of dnsmasq. dnsmasq started as a system daemon reads config from /etc/dnsmasq.d/* so dropping a file there containing "bind-interfaces" and doing the relevant restart in postinst should make this automatic in most cases. > > NM already runs dnsmasq with --bind-interfaces and --listen-address > (specifically, --listen-address=127.0.0.1) so we would only be changing > the address. > > Mathieu mentioned earlier the possibility of using 127.0.1.1 which > happens to be the address assigned (in /etc/hosts) to the system > hostname on some (but not all) systems. Is there any advantage to using > 127.0.1.1 as opposed to another 127.* address? > I don't think so: they're all equivalent. Simon. -- You received this bug notification because you are a member of 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 11/06/12 19:57, Thomas Hood wrote: > But, second, there is a problem connecting the resolver to the NM- > controlled dnsmasq such that the latter stays out of the way of the > general local nameserver which currently wants to listen on the IPv4 > wildcard address. Using address ::1 for nm-dnsmasq is a quick hack > which might work without further ado > > But even if it works it clearly isn't a permanent solution. More > satisfactory would be to use an another port than 53 for the special > purpose of connecting the resolver with nm-dnsmasq. > Another option is to use another address in 127.0.0.0/8, any will work. You'll need dnsmasq 2.61 or later for this to be a viable option. You could have the nm-dnsmasq run with --bind-interfaces --listen-address=127.0.100.1 and put 127.0.100.1 in /etc/resolv.conf. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Simon. -- You received this bug notification because you are a member of 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 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode
On 31/05/12 14:57, Scott Moser wrote: > this looks like something we should pull in. > Since Ubuntu has unmodified debian package, and debian maintainer is upstream > maintainer, we should probably let the quantal package get synced from > debian. Then, we can patch the 12.04 Ubuntu version in an SRU. > > @Simon, > If you're reading this, do you have plans for a 2.6.2 release and > subsequent 2.6.2-1 upload soon? I do. There are a few nasty bugs in 2.61 in the new DHCPv6 and router advertisement code, I plan to release 2.62 to address these in the next few days. 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/1006898 Title: [SRU] dnsmasq fails at leasing issues when using vlan mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
On 31/05/12 08:47, Thomas Hood wrote: > In addition to devising an algorithm for dnsmasq to detect all and only > NNNs, the implementation of which will no doubt take a while, we should > consider implementing a quick fix too, along the lines suggested by > Sergio in #19. NM could be changed to do the following. > > "If the nameserver address list to be fed to dnsmasq contains one or > more local addresses followed by one or more non-local addresses then > run dnsmasq with the --strict-order option." > > I must confess that I am not sure what exactly should fall under "local > addresses" here. In IPv4 I presume that these would be the familiar > ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, but what about IPv6? I think you're right for IPv4. For IPv6, I'm tempted to treat it as a tabula rasa and explicitly not support NNNs. the rationale being that NNN support is to work around historical bad practice and such bad practice is not supported in the brave new world of IPv6. If that won't fly, then the IPv6 equivalent would be link-local (fe80::/64), site-local (fec0::/10) and ULAs (block fc00::/7), I think. > Nevertheless, I think we can safely proceed with this fix without being > sure that we have exactly the right definition of local address since > dnsmasq works no worse than libc in strict-order mode. > > ** Also affects: dnsmasq (Ubuntu) >Importance: Undecided >Status: New > > ** Also affects: resolvconf (Ubuntu) >Importance: Undecided >Status: New > -- You received this bug notification because you are a member of 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
[Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
> Simon, your suggestion (call it "#18") differs from the suggestion in #17 in > two ways. First, #18 sends the first-received reply back > to the client without waiting for the results of comparison with other > results whereas #17 does wait. Second, #18 switches to > strict-order mode when *any* difference is found, whereas #17 proposed only > looking for a particular pattern, that being: a > NODATA/NXDOMAIN is received from a nameserver that is not listed first and an > earlier-listed nameserver does return an address > within the standard libc > timeout period. In #17's defence... in #17 the client only has to wait for a > reply in the case of a > NODATA/NXDOMAIN from a non-first nameserver; the client does get the desired > address from the earlier-listed nameserver if > there is one --- even the first time; and dnsmasq only drops into > strict-order mode under the circumstances when it is necessary for > it to do > so such that clients get needed addresses. There is no point, for example, in > dropping into strict-order mode if it's the first > nameserver returning > NXDOMAIN and a later-listed nameserver returning an address! > What do you think about the possibility of implementing such ideas? I think that both are implementable. I worry that #17 will make (real) NXDOMAIN/NODATA replies much slower, since there at least two round-trips, and possibly a timeout, if a server never replies. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
Thomas in #17 A heuristic for this is difficult, because you have to prove a negative. If we can assume the first nameserver has local addresses, we can never return a reply from any other nameserver until we have the reply from the first one, in case the first one has different data. Once we see different data from different nameservers, we can go to --strict-order mode, but the opposite is not true: the same answer for a particular query doesn't guarantee that the answers to future queries will always agree. There's no way to be sure that the nameservers are equivalent based on the history of returned queries. Unless we can assume that, we always need to wait for the first nameserver to reply (or a timeout) and have to stay in --strict-order mode forever. There is one possibility, which is to assume that nameservers are equivalent, but switch to --strict-order mode if conflicting replies are seen. When a query is forwarded to all available servers, and the first reply sent back to the original requestor, keep the record of the reply (at least, a bit indicating NODATA/NXDOMAIN or a valid reply. If another reply comes in later from another nameserver which conflicts, then switch to --strict-order mode. This will not get the first queries right, but it will be triggered eventually (and it might be triggered, swicthing mode forever, by random server glitches) For a single-host cache, --strict-order might be the simplest fix.. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
> To be frank, when changing the default system resolver, expected > behavior should be the default. It's all well and good saying that > non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that > might be true - but that's a value judgement that shouldn't have a place > in this scenario, since users haven't made the choice to enable dnsmasq, > and so shouldn't have to be aware of the caveats (ie - "My DNS worked > fine before upgrade"). It's a delicate trade-off, made all the more ironic by the fact that without dnsmasq, a second DNS server is practically useless (because you have to wait for the time-out on the first for each and every query). The easiest solution is just to delete the second nameserver. All I can say is that dnsmasq provides both modes, and the default is what it is for the reasons I outlined. If Ubuntu as a distro wants to flip the default, they can. My personal opinion is that it would be a mistake, but that's just my opinion. Question: does networkmanager's GUI expose the option to divert particular domains to a special nameserver? That's an alternative correct way to achieve layering local names over the global DNS. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1003842] Re: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
>Simon Kelley might have written dnsmaskq with the assumption that all DNS servers upstream have the same view about the >namespace. However, this is not how RFC sees it nor how it is set up in a majority of installations. Can you provide an authoritative reference for that? As far as I can see, the "internal" DNS server can provide one of five different answers to a query (there are other possible answers, including delagations, but these are the five possible ones to a stub resolver which sets the RD bit in th query) 1) A valid answer 2) A NODATA answer asserting that the domain exists, but the domain has no information for the type (A, , MX..) queried. 3) A NXDOMAIN anser asserting that the domain does not exist. 4) No answer. 5) An error return code. 1) and 4) and 5) are not a probem, the next step is obvious. the argument is what to do in 2) and 3), we can either accept the valid reply that comes from DNS server or we can try again witha another one. Dnsmasq does the former, and that, I assert, is the correct thing to do. I believe it's what the libc resolver does too. Given the above, the only way to use an "internal" DNS server which knows about local records is to make sure it's always queried first: we can't sensibly send the query to the "external" server and then to the internal server when the external one says "don't know" since THERE IS NO VALID DON'T KNOW ANSWER. My comment about random failures due to UDP packet loss applies here, but if you want dnsmasq to work this way, there's a flag, --strict-order, which will do it. Assume --strict-order. Since we've decide that the only time we're going to use a second nameserver is when the first one doesn't reply, this affects the timeliness of anwers, if you always send to the one nameserver first, the only circumstance you can use an answer from the second server if after the first one times out. The second server isn't very useful if using it makes all DNS queries take 2-3 seconds. One the other hand, if you arrange that all the servers are equivalent, you can keep a note of which ones are up, or even send the query to all the servers, use the first reply, and discard the rest. Dnsmasq uses both these techniques to improve resilience. If you have very flaky servers, you can even tell it to send every query to all the available servers. Executive summary: non-equivalent servers are bad, but --strict-order will make things work, for the same value of "work" as the libc resolver). Non-equivalent servers are bad, so don't encourage their use by making --strict-order the default. HTH Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 998712] Re: dnsmasq integration into name resolution broken
On 17/05/12 10:19, Wolf Rogner wrote: > I recreated the situation by restarting the network manager. > > resolv.conf contains link to 127.0.0.1 > /run/nm-dns-dnsmasq.conf contained my name server already. > > However, even dig does not resolv correctly. Here are the results (my > network is 10.x.x.x actually) > > wolf@mbp:~$ ping s4 > ping: unknown host s4 > wolf@mbp:~$ dig s4 > > ; <<>> DiG 9.8.1-P1 <<>> s4 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27930 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;s4. IN A > > ;; Query time: 3 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu May 17 11:07:39 2012 > ;; MSG SIZE rcvd: 20 > > wolf@mbp:~$ dig @10.1.0.4 s4 > > ; <<>> DiG 9.8.1-P1 <<>> @10.1.0.4 s4 > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34081 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;s4. IN A > > ;; AUTHORITY SECTION: > . 10800 IN SOA a.root-servers.net. > nstld.verisign-grs.com. 2012051700 1800 900 604800 86400 > > ;; Query time: 21 msec > ;; SERVER: 10.1.0.4#53(10.1.0.4) > ;; WHEN: Thu May 17 11:07:50 2012 > ;; MSG SIZE rcvd: 95 > > wolf@mbp:~$ dig @10.1.0.4 s4.rsb.intern > > ; <<>> DiG 9.8.1-P1 <<>> @10.1.0.4 s4.rsb.intern > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35717 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;s4.rsb.intern. IN A > > ;; ANSWER SECTION: > s4.rsb.intern.34000 IN A 10.1.0.4 > > ;; AUTHORITY SECTION: > rsb.intern. 34000 IN NS s4.rsb.intern. > > ;; Query time: 3 msec > ;; SERVER: 10.1.0.4#53(10.1.0.4) > ;; WHEN: Thu May 17 11:08:03 2012 > ;; MSG SIZE rcvd: 61 > > wolf@mbp:~$ less /run/nm-dns-dnsmasq.conf > wolf@mbp:~$ dig s4 > > ; <<>> DiG 9.8.1-P1 <<>> s4 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18553 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;s4. IN A > > ;; AUTHORITY SECTION: > . 10725 IN SOA a.root-servers.net. > nstld.verisign-grs.com. 2012051700 1800 900 604800 86400 > > ;; Query time: 14 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu May 17 11:09:05 2012 > ;; MSG SIZE rcvd: 95 > > wolf@mbp:~$ ping s4 > PING s4.rsb.intern (10.1.0.4) 56(84) bytes of data. > ^X^C64 bytes from 10.1.0.4: icmp_req=1 ttl=64 time=0.792 ms > > --- s4.rsb.intern ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 0.792/0.792/0.792/0.000 ms > wolf@mbp:~$ > The difference between the working and non-working examples is that the non-working ones are looking up s4. and the working ones are looking up s4.rsb.intern. getting from "ssh s4" to a DNS lookup of the A record s4.rsb.intern, is the responsibilty of the C library resolver, which is configured by /etc/resolv.conf. There are a few parameters in there that can affect things, look for domain, search and options ndots. Are there differences in these parameters between the working and non-working states? Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/998712 Title: dnsmasq integration into name resolution broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/998712/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 998712] [NEW] dnsmasq integration into name resolution broken
On 13/05/12 11:00, Wolf Rogner wrote: > Public bug reported: > > dnsmasq does not resolve DNS names correcty. > > Applications like Thunderbird or tools like ssh rely on working name > resolution. However, if there never was a working name resolution, > dnsmasq never gets to know about the DNS names. > > Setup: > > private network: 192.168.0.x/24 > domain mydomain.intern > server: 192.168.0.1 hostname s1 > dhcp (.100 - .200) and bind running, postfix and dovecot running > client: 192.168.0.100 (dhclient) > > /etc/resolv.conf > ... > nameserver 127.0.0.1 > search mydomain.intern > > /var/run/nm-dns-dnsmasq.conf > server=192.168.0.1 > > Open Thunderbird -> Thunderbird fails to open s1 > ssh admin@s1 -> ssh: Could not resolve hostname s1: Name or service not known > > Adding > nameserver 192.168.0.1 > to /etc/resolv.conf > > resolves the issue immediately > > calling sudo resolvconf -u > > creates the lookup problem immediately again Please could you add the output from dig s1 run when DNS is broken to this bug report, also dig @192.168.0.1 s1 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/998712 Title: dnsmasq integration into name resolution broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/998712/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 925511] Re: lxc init script should fail when it ... failed
On 08/02/12 08:33, Ritesh Raj Sarraf wrote: > On Wednesday 08 February 2012 03:54 AM, Serge Hallyn wrote: >> @Ritesh, >> >> Unfortunately I don't know that that many people would read the README :) >> It is worth adding though, thanks for the suggestion. >> >> In addition, I will add an LXC section to the ubuntu server guide soon, >> and this should be mentioned there. >> >> I'm also marking this (and the equivalent libvirt) bugs as affecting >> dnsmasq. Perhaps we can do something to its default configuration to be >> less belligerant. Maybe even just an explicit >> '--except-interface=virbr0,lxcbr0', though hard-coding that seems a bit >> ugly. > > Serge, > > IMO the better option would be to just ship a binder in /etc/dnsmasq.d/ > > dnsmasq is a personal dns caching service. I doubt if anyone is using it > as a bind replacement. > > By shipping a dnsmasq sub conf file (and making it bind to loopback > only), you eliminate the need to track the list of virtual bridges. > Then, you also don't need to spawn off your own dnsmasq proc from the > lxc init script. > There is special provision in dnsmasq to do exactly this, but it's never made it into libvirt upstream. Please feel free to push there! from "man dnsmasq" NOTES section: -- dhcp-range may have an interface name supplied as "interface:". The semantics if this are as follows: For DHCP, if any other dhcp-range exists _without_ an interface name, then the interface name is ignored and and dnsmasq behaves as if the interface parts did not exist, otherwise DHCP is only provided to interfaces mentioned in dhcp-range declarations. For DNS, if there are no --interface or --listen-address flags, behaviour is unchanged by the interface part. If either of these flags are present, the interfaces mentioned in dhcp-ranges are added to the set which get DNS service. Similarly, enable-tftp may take an interface name, which enables TFTP only for a particular interface, ignoring --interface or --listen-address flags. In addition --tftp-secure and --tftp-unique-root and --tftp-no-blocksize are ignored for requests from such interfaces. (A --tftp-root directive giving a root path and an interface should be provided too.) These rules may seem odd at first sight, but they allow a single line of the form "dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" to be added to dnsmasq configuration which then supplies DHCP and DNS services to that interface, without affecting what services are supplied to other interfaces and irrespective of the existance or lack of "interface=" lines elsewhere in the dnsmasq configuration. "enable-tftp=virt0" and "tftp-root=,virt0" do the same job for TFTP. The idea is that such a line can be added automatically by libvirt or equivalent systems, without disturbing any manual configuration. --- 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/925511 Title: lxc init script should fail when it ... failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/925511/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 876458] Re: dnsmasq started before all interfaces are up
An addition to my last reply: If a DHCP request is received via in interface which doesn't have an IP address, there will be a log message, but the request will be otherwise ignored. 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/876458 Title: dnsmasq started before all interfaces are up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/876458/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 876458] Re: dnsmasq started before all interfaces are up
On 02/01/12 09:44, Thomas Schweikle wrote: >> That's exactly what happens without --bind-interface, interfaces which >> are configured in dnsmasq but don't exist at startup generate a warning >> only, and start to work when they are created. > > This seems to be correct. > >> Packets from interfaces which are not configured are ignored. > > This isn't correct at all. Assume configuration: > > auto vm0 > iface vm0 inet dhcp > bridge_fd 3 > bridge_hello 2 > bridge_maxage 12 > bridge_stp off > bridge_ports eth0 > > auto vm1 > iface vm1 inet static > address 172.18.1.1 > netmask 255.255.255.0 > bridge_fd 3 > bridge_hello 2 > bridge_maxage 12 > bridge_stp off > pre-up brctl addbr $IFACE > post-down brctl delbr $IFACE > > auto vm8 > iface vm1 inet static > address 172.18.8.1 > netmask 255.255.255.0 > bridge_fd 3 > bridge_hello 2 > bridge_maxage 12 > bridge_stp off > pre-up brctl addbr $IFACE > post-down brctl delbr $IFACE > > and in /etc/dnsmasq.conf: > localise-queries > domain-needed > expand-hosts > no-negcache > filterwin2k > cache-size=150 > > dhcp-authoritative > dhcp-fqdn > dhcp-leasefile=/var/lib/misc/dnsmasq.leases > > dhcp-boot=boot/grub/i386-pc/core.0 > dhcp-no-override > tftp-root=/srv/tftpboot > enable-tftp > > listen-address=127.0.0.1 > resolv-file=/etc/resolv.dhcp > > domain=fritz.box > > #== Interface vm1 > listen-address=172.18.1.1 > domain=fritz.box,172.18.1.0/24 > dhcp-range=172-18-1,172.18.1.129,172.18.1.200,255.255.255.0,30m > dhcp-option=net:172-18-1,28,172.18.1.255 # > option broadcast address > dhcp-option=net:172-18-1,3,172.18.1.1 # > option default route > dhcp-option=net:172-18-1,option:domain-search,fritz.box# > option domain search (RFC-3397) > dhcp-option=net:172-18-1,42,172.18.1.1 # > option ntp-servers > dhcp-option=net:172-18-1,6,172.18.1.1 # > option domain name servers > dhcp-option=net:172-18-1,15,fritz.box # > option domain name > dhcp-option=net:172-18-1,40,fritz.box # > option nis domain > dhcp-option=net:172-18-1,23,50 # > option ttl > dhcp-option=net:172-18-1,19,0 # > option ip-forwarding off > dhcp-option=net:172-18-1,44,0.0.0.0# set > netbios-over-TCP/IP nameserver(s) aka WINS server(s) > dhcp-option=net:172-18-1,45,0.0.0.0# > netbios datagram distribution server > dhcp-option=net:172-18-1,46,8 # > netbios node type > > dhcp-option=net:172-18-1,vendor:PXEClient,1,0.0.0.0 > dhcp-option=net:172-18-1,vendor:MSFT,2,1i # > Microsoft: tell client to release the lease > > #== Interface vm8 > listen-address=172.18.8.1 > domain=fritz.box,172.18.8.0/24 > dhcp-range=172-18-8,172.18.8.129,172.18.8.200,255.255.255.0,30m > dhcp-option=net:172-18-8,28,172.18.8.255# > option broadcast address > dhcp-option=net:172-18-8,3,172.18.8.1 # > option default route > dhcp-option=net:172-18-8,option:domain-search,fritz.box # > option domain search (RFC-3397) > dhcp-option=net:172-18-8,42,172.18.8.1 # > option ntp-servers > dhcp-option=net:172-18-8,6,172.18.8.1 # > option domain name servers > dhcp-option=net:172-18-8,15,fritz.box # > option domain name > dhcp-option=net:172-18-8,40,fritz.box # > option nis domain > dhcp-option=net:172-18-8,23,50 # > option ttl > dhcp-option=net:172-18-8,19,0 # > option ip-forwarding off > dhcp-option=net:172-18-8,44,0.0.0.0 # > set netbios-over-TCP/IP nameserver(s) aka WINS server(s) > dhcp-option=net:172-18-8,45,0.0.0.0 # > netbios datagram distribution server > dhcp-option=net:172-18-8,46,8 # > netbios node type > > dhcp-option=net:172-18-8,vendor:PXEClient,1,0.0.0.0 > dhcp-option=net:172-18-8,vendor:MSFT,2,1i # > Microsoft: tell client to release the lease > > > dhcp-queries are answered on interfaces connected to all bridges! As soon, as > I turn on dnsmasq systems connected via ethernet receive addresses from my > dnsmasq dhcp server I'd suppose only being seen from virtual bridges inside > the host. If I turn on "bind-interfaces" all is OK again. > OK, some of this behaviour, I think I understand, some not. The first thing to say, is that it's much better
Re: [Bug 876458] Re: dnsmasq started before all interfaces are up
On 20/12/11 20:55, Thomas Schweikle wrote: > H. If this is the reason, how to force dnsmasq not to respond on > some interfaces, while listening on all others, with different > configurations per interface? > > Wouldn't it be better to configure dnsmasq even for interfaces not there > at startup, and if these interfaces come up take them, if configs match? > Avoiding unconfigured interfaces? > That's exactly what happens without --bind-interface, interfaces which are configured in dnsmasq but don't exist at startup generate a warning only, and start to work when they are created. Packets from interfaces which are not configured are ignored. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/876458 Title: dnsmasq started before all interfaces are up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/876458/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 876458] Re: dnsmasq started before all interfaces are up
On 08/12/11 12:57, Thomas Schweikle wrote: > Yes, that's right, but there are interfaces not started from > /etc/network/interfaces or Network Manager: > * VMware Workstation / Player installs interfaces starting VMware daemons > * VirtualBox installs interfaces > * KVM may install an additional bridge > * some VPN software installs tun/tap interfaces or virtual interfaces up on > an existing interface > > As far as I could find: > * VMware is started after dnsmasq, leading to a situation dhcp via dnsmasq > works, but DNS doesn't > * VirtualBox creates interfaces and bridges on the fly --- sometimes dhcp > works, sometimes it doesn't; DNS did not work always > * KVM interfaces are started concurently with dnsmasq, because kvm is started > after "network" is up. Sometimes you'll get full functionality, sometimes you > do not. If KVM starts its own dnsmasq both daemons challenge with each other > about whom answers dhcp --- sometimes the VM is assigned the one address, > sometimes the other. DNS may work or may not. > * VPN: sometimes dnsmasq binds dhcp to VPN, sometimes it doesn't. Either way: > it leads into trouble. > > To make dnsmasq work with dhcp, dns (and, if configured tftp) you'll > have to restart the daemon each time a new interface it shall bind to is > started. > Dnsmasq will cope fine with dynamically-created interfaces, as long as "bind-interfaces" is NOT set in the configuration. Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/876458 Title: dnsmasq started before all interfaces are up To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/876458/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 781557] [NEW] multiple search domains not honoured
Launchpad Bug Tracker wrote: > You have been subscribed to a public bug: > > Binary package hint: resolvconf > > in /etc/resolvconf/resolv.conf.d/base I have > > search domain1.local domain2.local > > When trying to connect to a host in domain2.local using only the > hostname, only the first domain is searched by my local dnscache > (dnsmasq): > > lieven@T500:~$ ping host2 > ping: unknown host host2 > > while dnsmasq only gets the query for domain1.local > > May 12 09:33:38 T500 dnsmasq[4302]: query[A] host2.domain1.local from > 127.0.0.1 > May 12 09:33:38 T500 dnsmasq[4302]: forwarded host2.domain1.local to > 192.168.5.254 > May 12 09:33:43 T500 dnsmasq[4302]: query[A] host2.domain1.local from > 127.0.0.1 > May 12 09:33:43 T500 dnsmasq[4302]: forwarded host2.domain1.local to > 192.168.5.254 > > my /etc/resolv.conf (linked to /etc/resolvconf/run/resolv.conf) contains > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN > nameserver 127.0.0.1 > search domain1.local domain2.local dhcp.supplied.domain.net > Sorry to bounce responsibilty again, but this isn't a dnsmasq problem, the search-domain function is implemented by the libc resolver code, which should generate separate DNS queries for host2.domain1.local, host2.domain2.local, etc. Dnsmasq's only role in this is to forward those queries. Since from the log, the host2.domain2.local aren't getting to dnsmasq, the problem must lie elsewhere. 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/781557 Title: multiple search domains not honoured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/781557/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 691329] [NEW] dnsmasq init file has incorrect DNSMASQ_INTERFACE reference
To Ubuntu triagers: This is a real bug, but it only affects code which provides compatibility with very old (pre-Ubuntu) Debian installations which might have interface configuration in /etc/default/dnsmasq. The accepted place for such configuration has always been /etc/dnsmasq.conf during the entire life of Ubuntu, so this is very unlikely to bite on any Ubuntu installation. I'll fix it in the next 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/691329 Title: dnsmasq init file has incorrect DNSMASQ_INTERFACE reference -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 674645] [NEW] occasional crashes: glibc detected double free or corruption
On 12/11/10 19:09, Dave Walker wrote: > Public bug reported: > > Binary package hint: dnsmasq > > *** glibc detected *** /usr/sbin/dnsmasq: double free or corruption > (top): 0x08ab60b8 *** > > (As initially reported: http://lists.thekelleys.org.uk/pipermail > /dnsmasq-discuss/2010q3/004369.html) > This was fixed in Debian with 2.55-2. That will be added to Ubuntu automatically, yes? Simon. -- occasional crashes: glibc detected double free or corruption https://bugs.launchpad.net/bugs/674645 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 526386] Re: dnsmasq exits using --interface if the interface does not exist yet
Emmet Hikory wrote: > Actually, I filed this bug more as a result of the comments in the > libvirt code, which indicate that at least one user of dnsmasq found it > unable to accomplish an operation that seemed to make sense based on the > documentation with a particular corner-case configuration. > > I consider it wishlist at best, and perhaps won'tfix. Addressing > this is completely unnecessary to either allow libvirt and dnsmasq to > interoperate or to permit users to use ad-hoc interfaces. It's also not > necessarily the best way to address the case where someone wants to do > both things at once (there being several other ways to do that well). > It only exists to document either a decision that dnsmasq specifically > doesn't support using --interface and --bind-interface in combination > with an ad-hoc interface *or* that when used in this combination there > is a potential for a race condition. > > Although this issue was initially raised in bug #231060, it's > irrelevant to my current plan to address that bug, but since I won't be > addressing this race condition in the resolution of that bug, I wanted > to separate this out. > You're right that this is beyond the scope of the Ubuntu bugs. I've opened negotiations with upstream libvirt development, that's clearly the right path to take here. If it can be arranged that --bind-interfaces is no longer needed, all of the problems fall out. Cheers, Simon. -- dnsmasq exits using --interface if the interface does not exist yet https://bugs.launchpad.net/bugs/526386 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 526386] Re: dnsmasq exits using --interface if the interface does not exist yet
Something else that's required: we need to stop a libvirt-started dnsmasq from picking up configuration left around by a removed system dnsmasq, so the start-dnsmasq pseudo-code in libvirt becomes. echo dhcp-range=interface:virt0, >/etc/dnsmasq.d/libvirtf if system dnsmasq is not installed or enabled> dnsmasq --interface=virt0\ --bind-interfaces --conf-file=/etc/dnsmasq.d/libvirt else /etc/init.d/dnsmasq restart Simon. -- dnsmasq exits using --interface if the interface does not exist yet https://bugs.launchpad.net/bugs/526386 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 526386] Re: dnsmasq exits using --interface if the interface does not exist yet
Emmet Hikory wrote: >>From a brief look at the code, it appears that the relevant section is > in src/dnsmasq.c : 169-189. In this mode, if unable to access an > interface because it doesn't exist, dnsmasq should poll the interface > for a configurable timeout to see if it becomes available before > quitting. As there may be multiple interfaces, implementing this as a > push-to-back-of-queue delay until there is only one interface polling > will ensure that the majority of intentionally specified interfaces come > up as quickly as if all interfaces existed. > [This covers 231060 too, they're basically the same problem.] Such code would be possible, but shouldn't be necessary. Going back to the original bug report, there are two problems, the first is the race-condition in libvirt, which could be fixed (I assume) by a delay between the synchronous creation of the virtual interface and the starting of dnsmasq. The second problem is, paraphrasing, "we have problems with network interfaces which are created ad-hoc, come and go, and change IP address over time." It's for precisely this use case that I carefully coded the standard (ie not --bind-interfaces") network mode in dnsmasq, many years ago. Without bind-interfaces, dnsmasq works exactly as you wish in these circumstances. Many people have been using it with ad-hoc interfaces and don't have any problems. This is a non-problem, _except_ that lib-virt insists on running a private instance of dnsmasq, and therefore needs the --bind-interfaces command. Adding polling hackery to get something like the sane behaviour which is available _by_default_ does seem like a bad idea, if there are other alternatives. Can we try and enumerate exactly what services libvirt wants from dnsmasq on the virtual network? I think it should be possible to express that as some configuration fragments that libvirt can drop into /etc/dnsmasq.d and have a high confidence of not affecting any other existing configuration on a "system" dnsmasq, or accidentally providing services to non-virtual networks unless they are explicitly configured. That way, libvirt can start up a dnsmasq instance a "system" dnsmasq is not running, but defer to the system dnsmasq if it is. The trick here would be for libvirt to start dnsmasq as if dnsmasq --interface=virt0 --bind-interfaces else /etc/init.d/dnsmasq restart That would inhibit the usual dnsmasq behaviour of offering service on every interface unless configured otherwise. The --bind-interfaces means that it will work even if the system is running eg BIND on port 53 of other interfaces. By putting these on the command line, they won't be seen when a system dnsmasq is installed. The rest of the configuration could be dropped in /etc/dnsmasq.d and suitably tagged so that it only applied to requests from virt0 (or whatever it's called). That way they will be picked up by a system dnsmasq and suitable service supplied to the virtual network by a system dnsmasq. Note the pid-file of the libvirt dnsmasq should be the same as a system one, so that installing a system dnsmasq will stop the libvirt dnsmasq before starting the system one. For removing dnsmasq on a system which has libvirt installed, some code in post-rm of the dnsmasq package can poke libvirt to restart its private instance. The only problem I can see with this so far goes like this. Consider a "system" dnsmasq install, that just does the default, ie it provides a DNS service, but no DHCP service. Now install libvirt, which configures DHCP for virt0 with dhcp-range= That actually enables DHCP on every interface (no command-line --interface flag, here, it's a system instance.) DHCP requests on other interfaces will fail, because there won't be a suitable dhcp-range, but there will be log messages to that effect, and general unpleasantness, there's also the remote possibility that the libvirt address range could overlap with a real interface and then DHCP service would be provided on a real interface. To fix this, lets add to dhcp-range dhcp-range=interface:virt0, The semantics of this is to _only_ provide and DHCP service on virt0 _unless_ there's another dhcp-range line without an interface; part, when the original sematics rule. How does that sound? Simon. -- dnsmasq exits using --interface if the interface does not exist yet https://bugs.launchpad.net/bugs/526386 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- 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
Thierry Carrez wrote: > @Simon: what are the options from a dnsmasq perspective ? > Some background: dnsmasq can run in two modes. Default mode: dnsmasq binds the wildcard address and does network magic to determine which interface request packets actually come from, so that the results can be send back with the correct source address. This has the advantage that network interfaces can come and go and change IP address and dnsmasq will keep working. It's possible to restrict dnsmasq to only reply to requests on some interfaces; requests from other interfaces will be read by dnsmasq and then silently dropped. Telling dnsmasq to use an interface which doesn't exist but might in the future will result in a logged warning, but dnsmasq will still start and when the interface comes up it will work. Bind-interfaces mode: This is the traditional way to do UDP servers. At startup dnsmasq enumerates all the extant interfaces and then opens a socket for each one, listening on the interfaces's IP address. Interfaces may be skipped if excluded by the --interface and --except-interface flags, and any interface specified in --interface which doesn't exist at start-up will generate a fatal error. In almost all cases, default mode is better: --bind-interfaces is only there to cope with old platforms which don't support enough socket options to do default mode. The only time when --bind-interfaces works better is when it's desirable to run more than one instance of dnsmasq. This is not possible in default mode, but it does work in bind-interfaces mode, providing than _all_ instances are in bind-interfaces mode, and that they listen on a disjoint set of interfaces. This is what the libvirt package attempts to do, as I understand it: it starts its own dnsmasq in --bind-interfaces mode listening on a virtual interface and it forces any "system" dnsmasq into --bind-interfaces mode and away from the the virtual interface by dropping a configuration fragment into /etc/dnsmasq.d This method brings the disadvantages of --bind-interfaces to the private libvirt dnsmasq instance (the race condition at start-up) and to the "system" dnsmasq (which will no longer cope with changes to network interfaces.) Options. 1) Keep doing what you're doing, work around the race condition and accept that installing libvirt will limit the functionality of a system dnsmasq by forcing it into --bind-interfaces mode. 2) Arrange that if libvirt and a "system" dnsmasq co-exist, libvirt uses the system dnsmasq, rather than starting its own. It should be possible to drop some configuration to make the system dnsmasq do what is needed for libvirt. There's a problem here if libvirt is installed alone and using a private dnsmasq, and then subsequently a system dnsmasq is installed. 3) Make some changes to dnsmasq to improve the situation when two instances are running. This may be possible, but I don't have many clues what could be done. 4) Look at some sort of partitioning in the kernel so that the virtual interface is in some sort of separate partition with effectively two network stacks. A sort of chroot for networking. I don't know if this exists in the Linux container stuff, or could be done. It's not really my area. HTH Simon. -- packages dnsmasq and libvirt-bin conflict with each other https://bugs.launchpad.net/bugs/231060 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 428318] Re: unable to mount an ext2 partition by label or uuid, unbootable system
Worryingly, I've just encountered this whilst doing a dist-upgrade from 9.04 to 9.10. The 9.04 installation was a complete re-partition and install on an Acer Aspire one, so it's possible that the remains of the toy Linux distro it came with caused the confusion; also possible is that the problem is that the root filesystem is ext2. Whatever, an Acer Aspire one installed with 9.04 over the toy Linux and then upgraded to 9.10 is probably a pretty common trajectory. I've recovered the system by specifying the root filesystem as /dev/sda1 and I'm not proposing to do anything further. If I can provide any more diagnostics, please shout. Simon. -- unable to mount an ext2 partition by label or uuid, unbootable system https://bugs.launchpad.net/bugs/428318 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 461725] Re: rc-sysinit job might start before loopback is up
More context from the dnsmasq side of things: http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2009q4/003369.html Missing from the public archive is the result of adding "ip addr show" to the dnsmasq startup script, it looks like this: 1: lo: mtu 16436 qdisc noop state DOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth2: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:1f:c6:85:29:28 brd ff:ff:ff:ff:ff:ff 3: wmaster0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ieee802.11 00:24:01:12:87:8d brd ff:ff:ff:ff:ff:ff 4: wlan1: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:24:01:12:87:8d brd ff:ff:ff:ff:ff:ff Simon. -- rc-sysinit job might start before loopback is up https://bugs.launchpad.net/bugs/461725 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 327703] Re: DHCP Request Cycle can get caught in infinite loop
Thierry Carrez wrote: > Simon: > Good news. Do you plan to push that release to Debian soon ? > It went last night, so should be in unstable very soon, if not already. Cheers, Simon. -- DHCP Request Cycle can get caught in infinite loop https://bugs.launchpad.net/bugs/327703 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 327703] Re: DHCP Request Cycle can get caught in infinite loop
2.48 release is now available and includes the fix for this bug. Cheers, Simon. -- DHCP Request Cycle can get caught in infinite loop https://bugs.launchpad.net/bugs/327703 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 380566] [NEW] netboot tarball needs a symlink to facilitate multi-arch installation
Public bug reported: Binary package hint: debian-installer The netboot.tar.gz tarball has symlinks at the top level from pxelinux.0 to ubuntu-installer/$ARCH/pxelinux.0 and pxelinux.cfg to ubuntu-installer/$ARCH/pxelinux.cfg This causes a problem is more than one arch netboot is installed, or if the Debian netboot tarball is installed, since the symlinks trample on each other. The simplest way to avoid this when setting up a multi-arch/distro boot server is to ignore the top-level symlinks, and set the bootfile name in the DHCP/PXE config to include the directory, so instead of using a filename pxelinux.0, use the filename ubuntu-installer/$ARCH/pxelinux.0 PXE ROMs are bright enough to spot and use the prefixed directory, so they continue to download files from there; pxelinux.cfg is found, no problem. The problem occurs with all of the boot screens, etc, whose paths inside pxelinux.cfg already include the ubuntu-installer/$ARCH/ prefix. The PXE ROM adds the path again, and tries to tftp eg. ubuntu-installer/$ARCH/ubuntu-installer/$ARCH/boot-screens/splash.png The simplest way to fix this, is to add a symlink in the netboot tarball from ubuntu-installer/$ARCH/ubuntu-installer to ../../ubuntu-installer. This is completely backwards compatible, it doesn't affect the majority who continue to rely on the top-level symlinks and a simple DHCP filenname config, but it does allow more complex configurations to work without manually making the link. ProblemType: Bug Architecture: i386 Dependencies: DistroRelease: Ubuntu 9.04 Package: debian-installer None [modified: /var/lib/dpkg/info/debian-installer.list] ProcEnviron: LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: debian-installer Tags: ubuntu-unr Uname: Linux 2.6.28-11-generic i686 UnreportableReason: This is not a genuine Ubuntu package ** Affects: debian-installer (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 ubuntu-unr -- netboot tarball needs a symlink to facilitate multi-arch installation https://bugs.launchpad.net/bugs/380566 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 242869] Re: dnsmasq's dhcp blocked to clients by firestarter
A useful bit of information here: ISC dhcpd uses raw sockets to grab incoming packets before they pass through the IP stack and IP tables, it therefore doesn't suffer from problems caused by broken firewall rules. Dnsmasq uses standard IP sockets so that all incoming packets are filtered by iptables. It is therefore not the case that having dhcpd work with firestarter means that the problem is solved and firestarter just has to do the same for dnsmasq as for dhcpd. WIth dhpcd the problem is moot, but with dnsmasq firestarter really has to get it right. >From the dnsmasq FAQ: Q: I'm using dnsmasq on a machine with the Firestarter firewall, and DHCP doesn't work. What's the problem? A: This a variant on the iptables problem. Explicit details on how to proceed can be found at http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html Cheers, SImon. -- dnsmasq's dhcp blocked to clients by firestarter https://bugs.launchpad.net/bugs/242869 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 307328] Re: dnsmasq should ONLY bind the virtual interface, not hog the whole system
Because a DHCP server has to cope with "strange" packets from unconfigured and half-configured clients, it's not possible always to bind the DHCP listening socket to an IP address. However, when --bind- interfaces is set, dnsmasq does set the SO_REUSEADDRESS flag on the socket, so that it is possible to run another instance of dnsmasq listening on another interface. For this to work ALL instances of dnsmasq have to have --bind-interfaces set, which may be the problem here. Cheers, Simon. -- dnsmasq should ONLY bind the virtual interface, not hog the whole system https://bugs.launchpad.net/bugs/307328 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 327703] Re: DHCP Request Cycle can get caught in infinite loop
I think I've deduced what is happening here. The combination of the dhcp-host line and the /etc/hosts entry generates the equivalent of dhcp-host=name,192.168.X.X When you run Ubuntu, the DHCP requests send the name, so dnsmasq find and uses this line, and all is good. When the machine was rebooted with the install disk, the name is not sent. At DISCOVER time, the 192.168.X.X address gets offered, because that machine (based on MAC address) already has a lease on the that address. At REQUEST time, the address is disallowed, becasue it's been set as a static address for another machine (remember, no name to match the dhcp-host line.) This hasn't been seen often, because most people nail down static addresses using the MAC address. Given that, this should be fairly easy to fix: I believe that http://www.thekelleys.org.uk/dnsmasq/test- releases/dnsmasq-2.48test6.tar.gz will do the trick. Cheers, Simon. -- DHCP Request Cycle can get caught in infinite loop https://bugs.launchpad.net/bugs/327703 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 327703] Re: DHCP Request Cycle can get caught in infinite loop
Simon Kelley here: I'm the principal author of dnsmasq.
I have a couple of questions for FactTech:
1) Was the text message in the DHCPNAK log entry the same as the initial
reporter's ("address reserved")?
2) Is there any other dhcp-host line in the dnsmasq configuration which might
apply to the host in question?
If you can reproduce the bug easily, I'd really like to see the result
of turning on "log-dhcp" in dnsmasq.conf
Cheers,
Simon.
--
DHCP Request Cycle can get caught in infinite loop
https://bugs.launchpad.net/bugs/327703
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
