That does, indeed, appear to be a solution to the problem.  Albeit, not an
ideal solution.  I really hope that this will be resolved in Neutron

On Wed, Jan 10, 2018 at 5:00 PM, Jonathan Mills <> wrote:

> Thanks, Flint WALRUS.  I will certainly try that.
> On Wed, Jan 10, 2018 at 4:57 PM, Flint WALRUS <>
> wrote:
>> As you’re using a L2 network topology and until all of your project use a
>> different network you can do:
>> domain=domain1,
>> domain=domain2,
>> Within the dnsmasq-neutron.conf file.
>> Of course, restart the neutron-server service once done.
>> Le mer. 10 janv. 2018 à 22:40, Jonathan Mills <> a
>> écrit :
>>> Dear Operators,
>>> I have a mix of Mitaka and Pike clusters, all for private clouds, and
>>> with multiple tenants.  I am very interested in having the ability to have
>>> per-network (really, per-tenant) dns_domain.  You would think that this
>>> works, based on the documentation here:
>>> ta/networking-guide/config-dns-int.html
>>> And yes, I have read and re-read that document many times, and carefully
>>> followed its instructions.  I have the 'dns' extension_driver enabled in
>>> ML2.  I have set an alternate value from 'openstacklocal' in neutron.conf.
>>> I am using the neutron dnsmasq processes as my real DNS servers in my VMs
>>> for tenant internal name resolution. (Instance short-name resolution does
>>> work, it's just that the FQDN of every VM is wrong.)  I have created
>>> per-network dns_domain entries in my neutron database.  Nevertheless, it
>>> does not work.  In every tenant, every VM has a dns suffix equal to
>>> whatever I have set for 'dns_domain' in neutron.conf (the global default).
>>> Scouring the web for clues, I've come across this, which seems to describe
>>> my problem:
>>> Notice that the importance is 'wishlist'.  Wishlist?  I find it
>>> surprising that it is a mere wish to have DNS work as expected.  I'm
>>> curious so I'm asking the community, is this really not working for
>>> anyone?  And if it is not working for anyone else either, is it really not
>>> a big deal?  It seems to me this would pose a rather large problem for any
>>> number of use cases.  In my immediate situation, I am deploying VMs onto a
>>> provider network that has a pre-existing Puppet infrastructure, and all the
>>> FQDNs are wrong, which means the generation of Puppet SSL certificates on
>>> these VMs is problematic.
>>> Any feedback would be much appreciated!
>>> Cheers,
>>> Jonathan Mills
>>> NASA Center for Climate Simulation (NCCS)
>>> Goddard Space Flight Center, Greenbelt, MD
>>> _______________________________________________
>>> OpenStack-operators mailing list
OpenStack-operators mailing list

Reply via email to