Bug 1532856

I have same requirement with David. but now I found a workaround. 

1. config libvirt network forward dns to host ip , assumed host have eth0 192.168.60.236 

  <dns>
    <forwarder addr='192.168.60.236'/>
  </dns>

2. boot up dnsmasq service on host's eth0 interface , because the dnsmasq is full functional, you can config a dns wildcard as:

address=/*.cloudapps.example.com/{vm's IP}

+1

Jason's workaround is useful, but troublesome on a laptop getting new host IPs from wifi all the time. I could probably get a little more creative and create a dummy interface just to host the dnsmasq wildcard.

We should simply be able in the network XML file to:

<dns>
  <host ip='10.11.12.203'>
    <hostname>*</hostname>
  </host>
</dns>

or something like that, IMO.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This feature is still not available on my Fedora 29 system (libvirt-daemon-4.7.0-1.fc29.x86_64). I too am using wifi and getting different IPs so prefer not to use a workaround that requires setting the IP. My current workaround is to just set up the network and dnsmasq outside of libvirt.

In my dnsmasq configuration, I then use a cname similar to this:

cname=*.cloudapps.example.com,master.example.com

This RFE is exactly what is missing to make openshift cluster installation working out of box on top of libvirt.

My expectation is something like following snippet to do a trick.
```
<dns>
  <host ip='192.168.126.11'>
    <hostname>*.apps.clustername.clusterdomain</hostname>
  </host>
</dns>
```

+1 to get this RFE implemented

+1 to get this RFE implemented

I sent patches upstream that enable setting raw dnsmasq options in the <network> XML, which should enable this in the absence of proper XML support. If it's accepted I'll update this bug with an XML example

+1 to get this RFE implemented.  Similar to others who have posted before, my workaround thus far has been to turn off libvirt and use dnsmasq standalone for wildcard DNS.

The next libvirt release 5.6.0 should be out within the next couple weeks and will allow passing options directly to dnsmasq. So you will be able to do something like:

      <network xmlns:dnsmasq='http://libvirt.org/schemas/network/dnsmasq/1.0'>
        ...
        <dnsmasq:options>
          <dnsmasq:option value="cname=BLAH"/>
        </dnsmasq:options>
      </network>

Replacing BLAH with whatever cname value you need. These are dnsmasq config file options so they shouldn't be preceded with a '-'

This bug will remain open though to track officially exposing this option in the XML. But there's no timetable on that

According to https://libvirt.org/formatnetwork.html#network-namespaces the feature announced has been implemented and is present in version 9.0.0 / Fedora 38.

And indeed, adding the following lines to the network XML:

```
<network xmlns:dnsmasq='http://libvirt.org/schemas/network/dnsmasq/1.0' connections='1'>
[...]
  <dnsmasq:options>
    <dnsmasq:option value='cname=api.myocp.example.com,ocp.example.com'/>
    <dnsmasq:option value='cname=api-int.myocp.example.com,ocp.example.com'/>
    <dnsmasq:option value='cname=*.apps.myocp.example.com,ocp.example.com'/>
  </dnsmasq:options>
```

Adds the following lines to `/var/lib/libvirt/dnsmasq/default.conf`:

```
cname=api.myocp.example.com,ocp.example.com
cname=api-int.myocp.example.com,ocp.example.com
cname=*.apps.myocp.example.com,ocp.example.com
```

The first two CNAMEs also do work, but the 3rd one doesn't act like a wildcard, it only responds to the "asterisk" but doesn't do any wildcarding

```
$ getent hosts *.apps.myocp.example.com
192.168.122.123 ocp.example.com
$ getent hosts xyz.apps.myocp.example.com
<no answer>
```

But the 1st link seems to hint at the fact that it should work, but perhaps I'm missing something.

OK, so I think I got it this time and the ticket can probably be closed:

Adding the following lines to the net-XML makes the wildcard CNAME work:

```
    <dnsmasq:option value='auth-server=example.com,'/>
    <dnsmasq:option value='auth-zone=example.com,192.168.122.0/24'/>
```

From my limited understanding, this makes the dnsmasq authoritative for the zone and allows for the wildcard to work as expected.

An alternative might have been to add `address=/.apps.myocp.ewl.example.com/192.168.122.123` (without wildcard CNAME) but it would have required to know the VM's IP address in advance.