(Sent on behalf of jima, the former owner)
The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features.
It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership.
Hello Stephen,
On 08/22/2011 01:49 PM, Stephen Gallagher wrote:
(Sent on behalf of jima, the former owner)
The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features.
It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership.
I took.
On Mon, Aug 22, 2011 at 03:33:58PM -0400, Douglas Landgraf wrote:
Hello Stephen,
On 08/22/2011 01:49 PM, Stephen Gallagher wrote:
(Sent on behalf of jima, the former owner)
The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features.
It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership.
I took.
Thanks, I certainly watch the package, but I'm happy to delegate this :-)
Daniel
On Mon, 22 Aug 2011, Stephen Gallagher wrote:
(Sent on behalf of jima, the former owner)
The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features.
It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership.
If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on.
Paul
On 08/22/2011 06:35 PM, Paul Wouters wrote:
If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on.
Are you talking about dnsmasq or the way that libvirt uses dnsmasq?
The interfaces on which dnsmasq listens are configurable with the 'interface' and 'listen-address' parameters in /etc/dnsmasq.conf.
When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers.
On 08/24/2011 12:24 PM, Ian Pilcher wrote:
When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers.
At least for a NAT network, it does bind tightly, e.g. I see: --bind-interfaces --except-interface lo --listen-address 192.168.122.1
Josh
On Wed, 24 Aug 2011, Ian Pilcher wrote:
On 08/22/2011 06:35 PM, Paul Wouters wrote:
If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on.
Are you talking about dnsmasq or the way that libvirt uses dnsmasq?
I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly:
1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) 2) "service dnsmasq stop" fails because it is not started as a regular service
When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers.
Here the issue is:
3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it)
The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple "yum install unbound|bind" by stealing port 53. Especially on my laptop with libvirtd....
Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free.
Paul
2011/8/25 Paul Wouters paul@xelerance.com:
Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free.
Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53?
In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces.
- Thomas
[1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces.
On Thu, 25 Aug 2011, Thomas Moschny wrote:
2011/8/25 Paul Wouters paul@xelerance.com:
Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free.
Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53?
In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces.
- Thomas
[1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces.
I'll double check with f16 alpha on some iron and if it is still a problem, get back and file a bug to formalise talking about this.
Paul
On Thu, Aug 25, 2011 at 04:37:26PM +0200, Thomas Moschny wrote:
2011/8/25 Paul Wouters paul@xelerance.com:
Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free.
Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53?
libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is configured to only bind to the IP addresses directly associated with the bridge of the virtual network.
# netstat -a -n -p | grep dnsmasq tcp 0 0 192.168.123.1:53 0.0.0.0:* LISTEN 14230/dnsmasq tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN 14208/dnsmasq tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 14007/dnsmasq udp 0 0 192.168.123.1:53 0.0.0.0:* 14230/dnsmasq udp 0 0 192.168.124.1:53 0.0.0.0:* 14208/dnsmasq udp 0 0 192.168.122.1:53 0.0.0.0:* 14007/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 14230/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 14208/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 14007/dnsmasq
# ip addr | grep 192 inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr2 inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr1
The wildcard bind on the UDP port number 67 there is not a problem because dnsmasq will only reply to requests coming in on the interface that it is configured to use.
In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces.
Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones.
[1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces.
For interoperability with libvirt, any dnsmasq instance *must* use the --bind-interfaces argumement, in combination with either '--interface=XXX' or '--listen-address=XX.XX.XX.XX'
Regards, Daniel
On Thu, 25 Aug 2011, Daniel P. Berrange wrote:
libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is
In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces.
Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones.
[1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces.
unbound and bind both only grab 127.0.0.1:53 and ::1:53 on their default installs.
So it looks like this problem has been solved or went away.
Thanks for the answers everyone!
Paul
On Thu, 2011-08-25 at 10:24 -0400, Paul Wouters wrote:
On Wed, 24 Aug 2011, Ian Pilcher wrote:
On 08/22/2011 06:35 PM, Paul Wouters wrote:
If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on.
Are you talking about dnsmasq or the way that libvirt uses dnsmasq?
I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly:
- Prevents other DNS resolvers from listening (eg DNSSEC aware ones)
- "service dnsmasq stop" fails because it is not started as a regular service
When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers.
Here the issue is:
- I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it)
On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver.
On Thu, 25 Aug 2011, Tomas Mraz wrote:
- I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it)
On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver.
Okay, good to know. Though I'd guess most people (esp on laptops) would bridge their VMs to the local ethX/wlanX to provide connectivity. If the NATed setup, those VM's could go out but would not be reachable by a local IP.
Paul
On 25/08/11 15:24, Paul Wouters wrote:
Here the issue is:
- I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it)
The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple "yum install unbound|bind" by stealing port 53. Especially on my laptop with libvirtd....
I think you've got something odd going on.... I'm using a bridged setup with libvirt and although I do have a dnsmasq running it is for the private network defined in libvirt (which I'm not using) and it is only listing on that private network's address.
So when I list networks I just have the default one:
virsh # net-list Name State Autostart ----------------------------------------- default active yes
and it is defined over a private address range:
virsh # net-dumpxml default <network> <name>default</name> <uuid>6229892b-486a-4c48-961a-20298d585e47</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0' /> <mac address='52:54:00:37:0B:C2'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> </dhcp> </ip> </network>
and that is what lsof shows dnsmasq as listening on:
dnsmasq 2229 nobody 6u IPv4 23692 0t0 TCP 192.168.122.1:domain (LISTEN)
Though like I say, I don't actually use that as I have br0 setup as a bridge to my ethernet card and use bridged networking with that instead.
Tom