Force DNS cache persistence?
I've noticed that the DNS cache expires very quickly (less than 60 seconds) for many domains thereby defeating the purpose of caching it in the first place. Is there a way to force entries to last longer? Neounk (talk) 01:30, 31 March 2013 (UTC)
Dnsmasq and Pidgin/Gtalk
Using dnsmasq for dns caching seems to break gtalk on pidgin. Editing /etc/dhcpcd.conf and adding option 'domainneed' '1' solves the issue on my machine.
if others verify the issue and fix, maybe consider for addition to the wiki?
Usage with libvirt
Network-manager think if there is one running libvirt that he run this before. To fix conflicts between other dnsmasq, eg: used in libvirt, you must run it externally.
We do not want change our resolv.conf automaticly.
[main] ... dns=none
We put it manually here.
The interface to bind and bind it even if there is second dnsmasq runned on computer.
This start service if interface is up. This service can start only once before stop which will be initiate by systemd on restart/shutdown.
#!/bin/sh if [ -n "$2" ] && [ "$2" = "up" ]; then # $INTERFACE is up systemctl start NetworkManager-dnsmasq.service fi
[Unit] Description=A lightweight DHCP and caching DNS server After=network.target Documentation=man:dnsmasq(8) [Service] Type=dbus BusName=uk.org.thekelleys.dnsmasq ExecStartPre=/usr/bin/dnsmasq --test ExecStart=/usr/bin/dnsmasq -k --enable-dbus --user=dnsmasq --pid-file --conf-dir=/etc/NetworkManager/dnsmasq.d/ ExecReload=/bin/kill -HUP $MAINPID
00:03, 25 March 2016 3ED
Replace bind-interface w/ bind-dynamic in dnsmasq.conf
I was running into an issue where dnsmasp would try to bind to my device before it was up, and the service would crash. After some research it seems that there is a "bind-dynamic" option that does not require the device to be up (and can simply bind the socket when it is actually connected)
I think this issue is better solved by using bind-dynamic instead of bind-interfaces. network-online.target is not used intentionally. If system is configured to use dnsmasq as DNS resolver of the system, network-online.target may not be active until dnsmasq is ready. It must not wait for network-online.target by default.[bind-dynamic] allows start of dnsmasq even when eth0 is still down. As soon as it is up, it will bind the interface and listen on it. I think this is exactly what is required in this case.
Seems better suited for usage, no?