| frickler | nicolasbock: wow, that's some pretty ancient stuff in your local.conf. note that if you include the neutron devstack plugin, you can simple enable_service q-dns instead of doing all that manual configuration | 05:19 |
|---|---|---|
| frickler | also OVN had many issues with DNS handling, some have recently been solved, but you need to check how far those fixes have been backported. some issues are still open, too | 05:20 |
| frickler | and in general I still think that their idea of spoofing DNS responses is a bad thing to do | 05:20 |
| nicolasbock | I found https://bugs.launchpad.net/neutron/+bug/1951872 for example frickler | 12:42 |
| nicolasbock | Is that one of those issues you were thinking of? | 12:42 |
| frickler | that is one of the things that got fixed, yes. https://bugs.launchpad.net/neutron/+bug/1902950 is still open | 12:44 |
| nicolasbock | The fact that OVN hijacks DNS had me confused for a while frickler | 12:51 |
| nicolasbock | It would be nice if it wasn't so stealthy about it | 12:51 |
| frickler | at least every provider will have to attach a large warning sign for their customers: DNS answers may not be coming from the source they appear to be coming from | 12:55 |
| frickler | and I didn't even create bugs yet for what happens when you use TCP for DNS or some additional options in your query | 12:56 |
| nicolasbock | Oh great, there is that :/ | 12:59 |
| johnsom | Yeah, I think there is still no way to integrate outside resolution with OVN. I think it's either routed out or answered from the OVN DB. Unlike OVS where you could configure local resolvers. | 15:59 |
| *** tweining_ is now known as tweining | 16:01 | |
| opendevreview | Merged openstack/designate master: Fix Redis connection over TLS https://review.opendev.org/c/openstack/designate/+/856313 | 16:10 |
| opendevreview | Michael Johnson proposed openstack/designate stable/yoga: Fix Redis connection over TLS https://review.opendev.org/c/openstack/designate/+/857486 | 16:11 |
| opendevreview | Michael Johnson proposed openstack/designate stable/xena: Fix Redis connection over TLS https://review.opendev.org/c/openstack/designate/+/857487 | 16:11 |
| opendevreview | Michael Johnson proposed openstack/designate stable/wallaby: Fix Redis connection over TLS https://review.opendev.org/c/openstack/designate/+/857488 | 16:11 |
| nicolasbock | Maybe what I am trying to solve is https://bugzilla.redhat.com/show_bug.cgi?id=2036034 johnsom | 17:01 |
| nicolasbock | The issue is that when I do a reverse lookup inside a VM I get the `dns_domain` of `neutron.conf` | 17:02 |
| nicolasbock | And not the domain I set on my network | 17:02 |
| nicolasbock | Which is presumably because the VM gets the generic dns domain via DHCP | 17:02 |
| johnsom | OVN will only do name resolution from it's database, it doesn't support using resolvers like OVS did. | 17:04 |
| nicolasbock | This is not working properly even with OVS though if I am not mistaken | 17:04 |
| johnsom | What I am talking about is Case 2 here: https://docs.openstack.org/neutron/yoga/admin/config-dns-res.html#case-2-dhcp-agents-forward-dns-queries-from-instances | 17:06 |
| johnsom | It's not implemented in OVN, but does work for the other ML2s | 17:06 |
| nicolasbock | Ah ok | 17:06 |
| johnsom | Maybe a different issue to the one you are seeing | 17:06 |
| nicolasbock | Maybe I misunderstand the documentation. Let me explain what I did | 17:08 |
| nicolasbock | 1. create network with --dns-domain | 17:08 |
| nicolasbock | 2. create zone | 17:08 |
| johnsom | If you are doing a reverse "dig -x" from inside the guest, it should be using the resolvers configured in the guest. OVN does try to hijack the outgoing requests as Jens mentioned, and will respond with information it has in the OVN DB. | 17:08 |
| nicolasbock | create server on network | 17:08 |
| nicolasbock | The port that's created for the sever will have the wrong dns_assignment | 17:09 |
| nicolasbock | the fqdn uses the generic dns domain | 17:10 |
| nicolasbock | Not the one from the network | 17:10 |
| nicolasbock | Did I misunderstand case 3(c)? | 17:11 |
| nicolasbock | Expecting that the domain used here is the one from the network? | 17:11 |
| johnsom | Ok, yeah, the typical neutron ignored the external DNS setup. There are these three restrictions: | 17:11 |
| johnsom | The network may not have attribute router:external set to True. | 17:11 |
| johnsom | The network type can be FLAT, VLAN, GRE, VXLAN or GENEVE. | 17:11 |
| johnsom | For network types VLAN, GRE, VXLAN or GENEVE, the segmentation ID must be outside the ranges assigned to project networks. | 17:11 |
| johnsom | That last one is the one that gets most people | 17:12 |
| nicolasbock | Check and check | 17:12 |
| nicolasbock | I do get correct recordsets | 17:12 |
| nicolasbock | PTR and A | 17:12 |
| nicolasbock | So the Designate part is fine | 17:12 |
| johnsom | All three of those have to be met, plus the zone existing for the project ID | 17:12 |
| johnsom | Oh, you get records in Designate but the dns_assignment field is different???? | 17:13 |
| johnsom | That would be a new one for me. | 17:13 |
| nicolasbock | The recordsets look correct | 17:13 |
| nicolasbock | They have the correct domain | 17:13 |
| nicolasbock | But the port doesn't | 17:13 |
| nicolasbock | The port does not have a dns domain set | 17:13 |
| nicolasbock | But its fqdn is using the wrong domain | 17:13 |
| nicolasbock | The VM thinks it's in the generic dns domain | 17:14 |
| johnsom | So, network is example.org. dns_domain, port has dns_name test and dns_domain empty. You get test.example.org. in the Designate recordset, but dns_assignment on the port is different? | 17:15 |
| nicolasbock | Correct | 17:16 |
| nicolasbock | That's using Ussuri | 17:16 |
| nicolasbock | I am still ironing out my devstack setup so I can test this in master | 17:16 |
| johnsom | So, that sounds like a neutron bug to me | 17:16 |
| nicolasbock | Ah | 17:16 |
| nicolasbock | Neutron creates the port and its dns assignment right? | 17:16 |
| johnsom | Also, the guest VM hostname/domain, that comes in via cloud-init from nova | 17:16 |
| nicolasbock | Ok | 17:17 |
| johnsom | Nova has many issues around hostnames. If you don't put a fqdn in the "hostname" field (and the version of nova let's you), it only passed the short name to the VM, it doesn't pass a domain. | 17:17 |
| nicolasbock | Wow, that'sounds terribly fragile | 17:18 |
| johnsom | In recent versions they broke the hostname field worse, to not allow FQDNs anymore, which.... is bad for many reasons | 17:18 |
| nicolasbock | Yes, I can see that | 17:18 |
| johnsom | Just to give you more of the picture, this cloud-init section is helpful: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname | 17:29 |
| nicolasbock | Thanks | 17:32 |
| *** kleini_ is now known as kleini | 19:30 | |
| opendevreview | Michael Johnson proposed openstack/designate stable/yoga: Remove lower-constraint job from stable/victoria https://review.opendev.org/c/openstack/designate/+/857768 | 21:10 |
| opendevreview | Michael Johnson proposed openstack/designate stable/yoga: Remove lower-constraint job from stable/yoga https://review.opendev.org/c/openstack/designate/+/857768 | 21:10 |
| opendevreview | Michael Johnson proposed openstack/designate stable/yoga: Check zone_id in notification_handler to avoid UUID format issue. https://review.opendev.org/c/openstack/designate/+/857069 | 21:11 |
| opendevreview | Michael Johnson proposed openstack/designate stable/xena: Check zone_id in notification_handler to avoid UUID format issue. https://review.opendev.org/c/openstack/designate/+/857489 | 21:11 |
| opendevreview | Michael Johnson proposed openstack/designate stable/wallaby: Check zone_id in notification_handler to avoid UUID format issue. https://review.opendev.org/c/openstack/designate/+/857770 | 21:11 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!