[Bug 1826419] Re: dhcp agent configured with mismatching domain and host entries

[Jorge Niedbalski]

I am able to reproduce the bug 1) Forward and reverse resolution is not
honoring the network defined dns-domain. -expressed on my previous
comment without even having designate enabled on my setup.

Deploying this bundle: http://paste.ubuntu.com/p/FZff5NqfvN/ , with the following neutron config options, please
note that a global.neutron. domain has been configured for neutron.

    options:
      dns-domain: global.neutron.
      enable-ml2-dns: true
      enable-ml2-port-security: true
      flat-network-providers: physnet1
      neutron-security-groups: true
      reverse-dns-lookup: true

Then associating a specific domain (local.neutron) to the private
network:

$  neutron net-update --dns-domain local.neutron. private

ubuntu at niedbalski-bastion:~/stsstack-bundles/openstack$ openstack network show private | grep dns_domain
| dns_domain                | local.neutron.                       |

After this step, I launched 3 instances that are associated to this private network.Then if I look into
the --domain attribute of the dnsmasq instance I can see that the configured domain remains as the dns-domain
set for the network.

verifying the --dns-domain option used on the instances network namespace.
root at juju-2e7dc7-1826419-5:/home/ubuntu# ip netns exec qrouter-c5a67f6a-3a15-4dcd-923d-c5c457beddff bash
root at juju-2e7dc7-1826419-5:/home/ubuntu# ps aux|grep dns|grep domain
nobody     491  0.0  0.0  53328  2888 ?        S    17:00   0:00 dnsmasq --no-hosts --no-resolv --except-interface=lo --[...]
87/leases --dhcp-match=set:ipxe,175 --bind-interfaces --interface=ns-75130a43-55 --dhcp-range=set:tag0,192.168.21.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1458 --dhcp-lease-max=256 --conf-file=/etc/neutron/dnsmasq.conf --domain=local.neutron.

However, the dhcp host file generated from the dns-assignments are pointing to the global
domain set in neutron-api. 

root at juju-2e7dc7-1826419-5:/home/ubuntu# more
/var/lib/neutron/dhcp/77902f51-2ac8-4ef1-97d1-962dd745ba87/host

fa:16:3e:d0:80:35,host-192-168-21-1.global.neutron.,192.168.21.1
fa:16:3e:f0:e2:a5,host-192-168-21-2.global.neutron.,192.168.21.2
fa:16:3e:1d:25:6d,cirros-170754-1.global.neutron.,192.168.21.4
fa:16:3e:39:12:a2,cirros-170754-2.global.neutron.,192.168.21.5
fa:16:3e:5b:cd:48,cirros-170754-3.global.neutron.,192.168.21.16

Then if I look at any of the port's dns-assignment they're also pointing to the global.neutron. domain,
not the one defined for the network

ubuntu at niedbalski-bastion:~/stsstack-bundles/openstack$ neutron port-show 75130a43-558e-4b17-90b8-45dc853fbaf7 | grep dns
| dns_assignment        | {"hostname": "host-192-168-21-2", "ip_address": "192.168.21.2", "fqdn": "host-192-168-21-2.global.neutron."} |

This port assignment explains the mismatch in the dnsmasq resolution, because this is used for generating
the hosts file used by dnsmasq. 

In my opinion rather than reverting this patch, the way to fix this is to adjust the https://github.com/openstack/neutron/blob/c21d922abd1208a72fe64d404a8eab93e0c56870/neutron/plugins/ml2/extensions/dns_integration.py#L287
dns_assignment update to use the network provided dns_name instead of the global configuration.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1826419

Title:
  dhcp agent configured with mismatching domain and host entries

Status in neutron:
  In Progress
Status in neutron package in Ubuntu:
  New

Bug description:
  Related bug 1774710 and bug 1580588

  The neutron-dhcp-agent in OpenStack >= Queens makes use of the
  dns_domain value set on a network to configure the '--domain'
  parameter of the dnsmasq instance that supports it;  at the same time,
  neutron makes use of CONF.dns_domain when creating dns_assignments for
  ports - this results in a hosts file for the dnsmasq instance which
  uses CONF.dns_domain and a --domain parameter of network.dns_domain
  which do not match.

  This results in a search path on instances booted attached to the
  network which is inconsistent with the internal DNS entries that
  dnsmasq responds with:

    root at bionic-045546-2:~# host 192.168.21.222
    222.21.168.192.in-addr.arpa domain name pointer bionic-045546-2.jamespage.internal.
    root at bionic-045546-2:~# host bionic-045546-2
    bionic-045546-2.designate.local has address 192.168.21.222

  In the above example:

    CONF.dns_domain = jamespage.internal.
    network.dns_domain = designate.local.

  Based on previous discussion in bug 1580588 I think that the
  dns_domain value for a network was intented for use for external DNS
  integration such as that provided by Designate.

  The changed made under commit:

    https://opendev.org/openstack/neutron/commit/137a6d61053

  appear to break this assumption, producing somewhat inconsistent
  behaviour in the dnsmasq instance for the network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1826419/+subscriptions