Denote registrar information for second level domains

[enpaul]

Is your feature request related to a problem? Please describe.
I'd like a way to note the registrar that a domain is registered through. My company has a large number of domains parked for marketing/brand protection purposes, all of which are manged by the IT department. I'd like a way to note in the zone object for a SLD (ex example.com) which registrar it's registered through and potentially registrant information (i.e. what gets returned with a WHOIS lookup).

Describe the solution you'd like
I'm not sure the best way to implement this as I am not a DNS administrator by profession so I'm not certain what validation or data structure would be.

Describe alternatives you've considered
Add a custom field for Content Type Netbox DNS > Zone called "Registrar" with a list of valid values like "Godaddy", "Route 53", "CrazyDomains", "Gandi", etc. This is probably not the best solution.

[peteeckel]

TBH, I don't see what problem you are trying to solve.

Regarding having registrar information for zones in NetBox, a custom field would seem like the perfect solution to me. What are you missing with that solution?

I am struggling to think of any task in managing DNS data that could be automated or validated with the registrar information, at least without having some additional code that, for instance, accesses a registrar's APIs or the whois database, which is IMHO beyond the scope of NetBox.

Do you have a use case for registrar information that you can share?

[enpaul]

Thanks for the response! This workflow is very much still a work in progress, so the idea is very much not fully flushed out or thought through.

I'm working on getting Netbox setup as both an Ansible inventory and a Terraform data source, including for the management of DNS records, domains, and domain settings. What I'd like to be able to do is configure Netbox with the registrar and registrant information so that Terraform can then a) know which registrar to find the domain in and b) enforce registrant information. The way I'd imagine this working is creating a new "domain registrant" object type (with info like name, email, address) and a "registrar" object type, then allowing these records to be assigned to one or more zones. This way, if (for example) our technical marketing manager changes we can update the contact email on the registrant record and all the assigned zones automatically assume the new registrant info (to then be enforced by ansible/terraform/etc).

Is that a valid use case? As I said I'm not a DNS administrator by profession or training so I may be misunderstanding and/or over complicating things unnecessarily.

[peteeckel]

Hi @enpaul, thanks for the clarification! After giving it some more thought yesterday I was already suspecting the direction in which this is going.

Putting it that way an extension of the data model absolutely makes sense, and there is indeed no satisfactory solution using custom fields only. So let's put some more concrete ideas together.

As I see it, we need to add at least two models to NetBox DNS:

• Contact
• Registrar

Contact is used for the Owner, Tech-C and Admin-C information for a zone, while Registrar is used for the registrar information. All fields are of course optional.

Zone then needs to be extended by five fields:

• Registrar
• Registry Domain ID
• Owner
• Tech Contact
• Admin Contact

Registrar should have (at least) the following fields:

• Name
• Address
• IANA ID
• URL
• WHOIS Server
• Abuse Contact Email
• Abuse Contact Phone

Contact should have (at least) the following fields:

• Name/Handle
• Address
• Email
• Phone

Does that make sense to you? Actually I'm not sure I thought of everything, but I think it would be a start - what do you think?

[peteeckel]

Hi @enpaul, I hope you can make use of this first approach to assessing your problem. I mainly added models for Registrars and Contacts, and I created some fields on Zone objects that map generic whois information and the IANA documentation.

It would be great if you could provide some feedback, as I basically had only a clean table to go with. I run it in my NetBox instance as well so I get a feeling for its usability, but your use cases are almost certainly not exactly the same as mine and so your input would be valuable.

[enpaul]

Hi @peteeckel thanks so much for getting this put together, and so quickly! Everything looks great to me, the one thought I had was whether it'd be better to replace the Netbox DNS > Contact object with the builtin Tenancy > Contact? Or at least have some way to link them together (eg have a field on Netbox DNS > Contact that points to a Tenancy > Contact object). While the plugin's Contact object includes a lot more broken out fields compared to the builtin Contact object, I'm not sure that necessarily adds a lot of value.

What are your thoughts on that?

[peteeckel]

Hi @enpaul, thanks for your feedback!

I first thought of using the tenancy contact object as well, but refrained from it for a number of reasons. First, I didn't want to rely on the structure of the core Contact object type, as the ICANN document is pretty specific in what information you need for WHOIS (e.g. separate fields for street, city, state/province etc.) while the tenancy contact only has a generic "address" field.

Then, a Zone object can have a tenant as well as registration information, and getting that too mixed up was also something I wanted to avoid. Moreover, a tenancy contact is something completely different from a registration contact - they can be the same person or someone completely different. Getting that linked too closely would create more restrictions than necessary.

That said, if in your specific case tenancy contacts in fact are linked to DNS registration contact there's nothing that keeps you from doing this with a custom field (and maybe some script pushing information from one to the other). It's just not the general case ...

And one more thing that came to my attention later in the process while I was implementing: A DNS registration contact's name is not the primary key. That's the contact ID, or 'handle' with some registrars. The name is, in fact, optional (unlike with the tenancy contact).

[enpaul]

That makes good sense to me! Thank you for clarifying!

I think the last thing I'd look at would be potentially adding a "Registration" card to the Zone display page which shows and links back to the registrar and the Owner/Admin/Tech/Billing contact. Does that make sense?

[peteeckel]

Just add some registration information and look at the zone's detail view :-)

(and, by the way, this works vice versa as well).

[enpaul]

🤦 I see it now, thank you!

I may also have just found a bug with the update, though I might just be using the field wrong. Previously the "SOA Responsible" field on the Zone model required an email address, but with the update it now requires a FQDN. Editing a Zone object just now I got a "Not a valid fully qualified DNS host name" error on the "SOA Responsible" record even though I didn't change it's value ([email protected]). Once I updated it to the bare domain (example.com) the validation passed and I could save the record.

Is this change intentional? I took a quick look through the PR diff and I didn't see anything obvious that would've caused this change, but I'm still learning the django/netbox plugin structure so I may have overlooked it.

[peteeckel]

Hi @enpaul, glad you like it!

Actually the SOA Responsible (RNAME) field contains an Email address. It's just the notation that's a bit strange, according to RFC 1035 Section 3.3.13:

RNAME           A <domain-name> which specifies the mailbox of the
                person responsible for this zone.

The name actually must be written as a domain name, i.e. with a dot in place of the @-sign. Strange, but correct.

In your example, the correct entry would actually be domain.example.com.