ipam-coupling - Restrict using an in-use name

[jabbate19]

Hello,

I am interested in using the ipam-coupling feature to allow users to add DNS hostnames to their IP addresses. Currently, I am seeing that someone can use a DNS hostname that is in use by other user, and it will let both A records co-exist.

Is there a feature to restrict this from happening?

[peteeckel]

Actually no - the RFCs are quite unambiguous. Multiple instances of the same name with different versions are completely legal, and so there is no such feature. It would actually restrict the creation of DNS records in a way that would not be generally useful, especially given the fact that your use case is quite unique.

But there is a way out.

NetBox has a feature called 'Custom Validation' that was created for exactly that kind of use case. Essentially you write a piece of Pyhon code that makes sure that there is no other record in the database that has the same zone ID and name. The validate() function needs to check that there is no other Record object with the same zone ID and name, and type RecordTypeChoices.A or RecordTypeChoices.AAAA, depending on whether we look at an IPv4 or and IPv6 address (and potentially your requirements - are identically named records legal if one is IPv6 and the other IPv4?).

That's exactly the kind of use case this NetBox feature was designed for.

[jabbate19]

Got ya. I was aware that is it legal, I was searching if the plug-in or netbox had a feature to allow me to restrain it. Thank you for pointing me to this resource!

[jhofmueller]

I am also interested in a solution and find using custom validators acceptable. However I cannot find the correct mapping between a dns record and my validator. Validation basically works (I use a validator that always fails to see if the mapping works). I asked this question on slack yesterday but got no response so far so I thought I try it here 😎
I return for any suggestions I will publish my validator once I got it working 😎

[peteeckel]

Thanks - see Slack or #248. This actually was a NetBox DNS bug.