Bug 711276

As an extension of this what I am really after is the ability to setup a PTR record, as required by some of the software I am trying to sandbox. This particularly becomes an issue when you try to virtualize and connect to Directory Services (be they provided by FreeIPA or Active Directory) on the vnet.

Further to the above, I have managed to ascertain that the DNS requirements for directory services (at least FreeIPA and AD) are:

- A resolveable hostname.
- A PTR record.
- A SRV record for ldap, and (usually) kerberos

The lines I use to set this up directly in dnsmasq.conf are of the form:

####

# Set the host/ip mapping.
address=/directory.example.com/192.168.1.2

# Set the PTR record for the above host.
ptr-record=2.1.168.192.in-addr.arpa/directory.example.com

# Set the ldap and kerberos SRV records for the above host.
srv-host=_ldap._tcp.directory.example.com,directory.example.com,389
srv-host=_kerberos._tcp.directory.example.com,directory.example.com,88

####

The two ways that this problem could be approached, as I see it, would be either:

1) Allowing the above records to be set directly via the network xml used by libvirt. If this was done in a generic enough way we could also allow setting of SRV records for other services that use them. Despite being more work/change as far as libvirt is concerned this is probably the main benefit over the option I present below as services other than Directory Services may not be able to provide their own SRV records.

-or-

2) Extend the XML for setting up dhcp in the network xml to allow specification of a DNS server on the vnet to use instead of the host (default 192.168.122.1). In the case where Directory Services are being virtualized this would allow the specification of the machine running them as the DNS server for the vnet, the PTR and SRV records described above could as I understand it be maintained directly in the Directory Services setup with it then handing off lookups it cant find to the gateway (still running dnsmasq in the current configuration) as a secondary DNS server.

The following two commits just pushed upstream may be of some help (just prior to that, support for defining dns TXT records was also added, which could be used as a template for adding SRV and PTR records):

commit 9d4e2845d498edcf46fe339537fe473f24d75f66
Author: Michal Novotny <minovotn>
Date:   Fri Jun 24 12:04:40 2011 +0200

    Network: Add support for DNS hosts definition to the network XML
    
    This commit introduces names definition for the DNS hosts file using
    the following syntax:
    
      <dns>
        <host ip="192.168.1.1">
          <name>alias1</name>
          <name>alias2</name>
        </host>
      </dns>

    Signed-off-by: Michal Novotny <minovotn>
    Signed-off-by: Laine Stump <laine>

commit 91b7924eeeffcbadb9bd89e87ebe7c508f9e4391
Author: Michal Novotny <minovotn>
Date:   Fri Jun 24 12:04:39 2011 +0200

    Network: Add additional hosts internal infrastructure
    
    Signed-off-by: Michal Novotny <minovotn>

(One thing I should point out is that dnsmasq is a DNS relay, so another way to approach the problem would be to define everything you need in an external DNS server, and point /etc/resolv of the host towards that server Anything not satisfied internally to dnsmasq would be passed up to whatever server is configured in /etc/resolv.conf. I don't know if this would get everything you're trying to accomplish though - just a spur of the moment thought).

About these three items you need to add to your dnsmasq config:

> local=/example.com/

Is this strictly necessary? As far as I understand, it just prevents queries that can't be satisfied by dnsmasq itself from leaking out to the upstream DNS server (eg, if dnsmasq doesn't know about waldo.example.com, it will return "not found" rather than passing it up to the DNS server in /etc/resolv.conf)

> domain=example.com

This can already be done - there is a "<domain> element at the top level of a <network> - you just add <domain name='example.com'/>

> expand-hosts

I just sent a patch upstream that will always turn this option on any time a domain name is defined for a network:

  https://www.redhat.com/archives/libvir-list/2011-June/msg01312.html


As far as these two go:

> # Set the host/ip mapping.
> address=/directory.example.com/192.168.1.2
> 
> # Set the PTR record for the above host.
> ptr-record=2.1.168.192.in-addr.arpa/directory.example.com

Wouldn't those both be satisfied by adding a <host> entry to the new <dns> section? As far as I can see, adding a host has the effect of adding both an A and a PTR record.

The SRV record is yet to be solved...

(In reply to comment #4)
> (One thing I should point out is that dnsmasq is a DNS relay, so another way to
> approach the problem would be to define everything you need in an external DNS
> server, and point /etc/resolv of the host towards that server Anything not
> satisfied internally to dnsmasq would be passed up to whatever server is
> configured in /etc/resolv.conf. I don't know if this would get everything
> you're trying to accomplish though - just a spur of the moment thought).

In this case what I'm actually attempting to do is run a kerberos ticketing system with LDAP on the virtual network using IPA. IPA can actually provide DNS itself (in which case it would be the IPA servers address that would be added to /etc/resolv.conf) but for the few entries I need using dnsmasq seemed simpler.

> About these three items you need to add to your dnsmasq config:
> 
> > local=/example.com/
> 
> Is this strictly necessary? As far as I understand, it just prevents queries
> that can't be satisfied by dnsmasq itself from leaking out to the upstream DNS
> server (eg, if dnsmasq doesn't know about waldo.example.com, it will return
> "not found" rather than passing it up to the DNS server in /etc/resolv.conf)

Strictly, no, but in my case desirable as I am using a domain on the virtual network for testing which actually exists in the wild. Ideally I don't want queries for hosts which exist in the wild but not on the vnet to get a response - but I still want other hosts in the outside world to resolve correctly.

> > domain=example.com
> 
> This can already be done - there is a "<domain> element at the top level of a
> <network> - you just add <domain name='example.com'/>

Indeed, I had actually noticed this but it is in my config regardless.
 
> > expand-hosts
> 
> I just sent a patch upstream that will always turn this option on any time a
> domain name is defined for a network:
> 
>   https://www.redhat.com/archives/libvir-list/2011-June/msg01312.html

Excellent, thanks.

> As far as these two go:
> 
> > # Set the host/ip mapping.
> > address=/directory.example.com/192.168.1.2
> > 
> > # Set the PTR record for the above host.
> > ptr-record=2.1.168.192.in-addr.arpa/directory.example.com
> 
> Wouldn't those both be satisfied by adding a <host> entry to the new <dns>
> section? As far as I can see, adding a host has the effect of adding both an A
> and a PTR record.
>
> The SRV record is yet to be solved...

The SRV record is unfortunately the most important part of what I'm trying to achieve. Obviously there are many different types of SRV, not just the _ldap and _kerberos ones I am using, so you wouldn't want to pigeon hole this change such that it only fixes it for this case.

> 
> The SRV record is unfortunately the most important part of what I'm trying to
> achieve. Obviously there are many different types of SRV, not just the _ldap
> and _kerberos ones I am using, so you wouldn't want to pigeon hole this change
> such that it only fixes it for this case.

For the dnsmasq you can provide the service, protocol, domain and optionally target, port, priority and weight

According to the dnsmasq man page:

       -W, --srv-host=<_service>.<_prot>.[<domain>],[<target>[,<port>[,<priority>[,<weight>]]]]
              Return a SRV DNS record. See RFC2782 for details. If not supplied, the domain defaults to that given by --domain.  The default for the target domain is empty, and  the
              default  for  port is one and the defaults for weight and priority are zero. Be careful if transposing data from BIND zone files: the port, weight and priority numbers
              are in a different order. More than one SRV record for a given service/domain is allowed, all that match are returned.

Is that what you're looking for or why exactly do you want in the SRV record? My understanding of the RFC 2782 [1] is that you can put any service name you want in here - please see the fictional example on the link.

Why exactly do you want SRV record in here?

Michal

[1] http://tools.ietf.org/html/rfc2782

The SRV configuration I wish to specify is in the description of this bug. The provided dnsmasq.conf lines provide the SRV records for LDAP and Kerberos. This allows me to use FreeIPA running on a virtual machine to provide kerberos and LDAP support for the rest of the VMs on the virtual network.

Currently, as far as I can see, although dnsmasq supports SRV records, this functionality is not exposed through the network XML.

An admin could want SRV records for any number of valid reasons. The real question is why the SRV records should be supplied by dnsmasq rather than by the server that dnsmasq defers to when it can't resolve a request itself. dnsmasq is, after all, not the authoritative end of the line for requests - if it doesn't know the answer, it will pass on the request to the DNS server listed in the host's /etc/resolv.conf. So in theory, libvirt's dnsmasq could remain in place, and the SRV records could be served by a separate DNS server, located via /etc/resolv.conf on the host (and the guests would be none the wiser).

I can see two potential reasons you might want to do everything with the dnsmasq instance run by libvirt - 1) ease/simplicity of configuration, 2) it may be desireable for some reason to have the guests' network completely isolated from the rest of the network.

Are there other reasons?

(Note that I think it would be good for libvirt's DNS service to allow configuring *all* the common DNS record types. I'm just curious about what makes the alternate solutions undesirable).

From my point of view having to run a separate DNS server for 2 records when one is already being run by libvirt is overkill. We do not have any control over upstream DNS and we prefer to have DNS specific to the virtual network anyway so that we can use whatever FQDNs suit (primarily this is for documentation of the software being tested - we don't want 'real' addresses to be used for security reasons).

As a result the workarounds are either to provide the required DNS records from the host or run a DNS server on one of the virtual machines and modify the host's resolver chain to point to it. To me, given that there is already a DNS server running on the host, it seemed like a no brainer to put the records here.

Given that libvirt exposes very, very, little of the functionality of dnsmasq (or any DNS server for that matter) to achieve this I kill the instance of dnsmasq started by libvirt on boot and start an instance configured to include all of the parameters libvirt would use + the ones to provide the records I need which aren't currently supported. I wouldn't use this in a production configuration or one where I was frequently adding and removing virtual networks, but for our purposes it does the job.

From my point of view I had already solved my problem when I discussed this with Laine on IRC. This bug has been raised so that libvirt can expose a more useful subset of the functionality of dnsmasq through the network configuration. Whether you do or don't choose to do this doesn't phase me either way, I just think it's useful functionality.

In summary, yes - there are workarounds, but when the alternative just adding some extra options to the network configuration which would be sent to the existing dnsmasq instance they don't look so great.

Laine, Stephen,
you are right that adding the option to support all the DNS records supported by dnsmasq could be a great thing resulting into no need for workaround. Although the workaround to kill the dnsmasq process and spawn a new one with the additional parameters added works for you, Stephen, I find this workaround really ugly since you're killing the process under the libvirt's control (since it's spawned by libvirt) and it would be much better if we implement the support for those DNS records directly into the libvirt network XML configuration file. Some time ago, I've been talking about this with somebody however the guy told me that it would be an overengineering and it's not necessary if I recall correctly.

Michal

I think you may be remembering this post:

http://www.redhat.com/archives/libvir-list/2011-March/msg01382.html

Where Paolo questions the usefulness of supporting *all* DNS record types. He seems very much in agreement that more DNS/dhcp-related things should be configurable in libvirt, though.

Aside from that, there was some discussion that any new configuration added should be agnostic about the backend implementation (it should be something useful if a DHCP/DNS server other than dnsmasq is used), but otherwise I think everyone is in general agreement that adding support for more DNS record types is a "good thing"(tm) (although some are more important than others).

Since your patches to support extra hosts effectively takes care of both A and PTR records (there might be some reason you would want to define one without the other, but it's probably not very common), I think the most important next target is the SRV record, followed by CNAME, I suppose (and that is following at a distant 2nd!)

There was this:

commit 973af2362cbf5348134b7ee90dbd34481182b9ac
Author: Michal Novotny <minovotn>
Date:   Mon Jan 2 15:23:54 2012 +0100

    Implement DNS SRV record into the bridge driver

so not sure if there's anything else to handle here?

We've also added a localOnly attribute:

commit 298fa4858ced29e2c42681635a5a8dcd6da0b231
Author: Josh Stone <jistone>
Date:   Wed Dec 3 16:01:33 2014 -0800

    network: Let domains be restricted to local DNS
    
    This adds a new "localOnly" attribute on the domain element of the
    network xml.  With this set to "yes", DNS requests under that domain
    will only be resolved by libvirt's dnsmasq, never forwarded upstream.
    

I had also mentioned adding support for CNAME records in there, but didn't catch whether that was requested by someone else, or if I was just rattling off a list of DNS record types and noticed that one missing. At any rate, it is possible to specify multiple hostnames for a single IP address with the <host> subelement of <dns>, which is nearly the same thing as a CNAME.