Comment 4 for bug 1501206

I can confirm Jeremy's understanding. The tenant in question has opted not to use private (RFC1918) IPv4 addressing or SNAT. Instead, he has a range of public IPv4 addresses which us routed from the upstream network to his router's address in the external gateway network. This allows the tenant to configure his subnets using prefixes from this public range. That said, the use case for enabling DHCP service (and by extension DNS service) on his subnets remains the same as for any other tenant.

I would also like to note that for IPv6, the method described above is the only possible way do it. There is no SNAT for IPv6; using private IPv6 address space on a subnet will thus only ensure that instances on that subnet cannot communicate with the world outside of OpenStack *at all*.

So I would agree with Salvatore's last comment - you cannot assume that the external network will ensure that services running in network namespaces (such as dnsmasq) is not reachable from the global Internet. Those services, or their containing namespaces, must themselves ensure that they do not inadvertently offer their services to external non-OpenStack clients.

Finally, I can confirm that there is no firewall or packet filter in the network outside of OpenStack. The expectation is that the tenants will maintain their own firewall rules using security groups (or maybe FWaaS) - but these do not apply to the qdchp network namespace. Also, it is not really a workable solution for an operator to simply drop all inbound DNS traffic (dst port 53/udp) before it reaches OpenStack, as this would also interfere with other completely legitimate use cases (e.g., another tenant running a non-recursing authoritative DNS server on one of his instances).