| johnsom | zigo Sorry for the delayed response to your emails, I was on holiday. I have replied to both and happy to talk more about them. | 00:11 |
|---|---|---|
| zigo | johnsom: No worries, and thanks for your answer. | 12:43 |
| zigo | johnsom: If I understand well, the shared-zone thingy would solve the "one user is registering all or a /24 for in-addr.arpa.", but wont solve the "one user is registering a zone for a /32 that doesn't belong to them". | 12:44 |
| zigo | johnsom: Therefore, we'd still need to add such a check. | 12:44 |
| zigo | johnsom: Also, it'd be nice to have the zone + record deleted whenever a floating / public IP is deleted ... | 12:45 |
| zigo | Another thing we thought about, to avoid squatting of zones: check that a zone is really pointing to our ns1/ns2 before allowing to add it. What do you think of adding such a feature? | 12:45 |
| johnsom | zigo Right, you would still have all of in-addr.arpa owned by a service account, thus blocking in projects directly creating child zones. You would then create the classless PTR child zones in the service account and "share" access to the appropriate project. | 21:57 |
| johnsom | zigo As for the delete, I thought the neutron extensions do delete the records on port/float delete. If not, that is probably a neutron bug. Zones is a bit more complicated (outside of the classless PTR child zones, which could potentially easily deleted). | 21:59 |
| johnsom | zigo On the check for proper NS records, I'm not sure I understand how that helps or the scenario. If they are creating the zone in Designate, they should always have the correct NS records based on the pool right? | 22:02 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!