Replies: 4 comments
-
Hi, pete. I hope you are doing well. Status field answers that question: Are we using that domain actively? Let me give some examples. Let's say we have project X. We bought a domain for that project, x.com. We use that domain actively so we mark the status field as "active". On the other hand, we bought domains x.org and x.net. We don't use these domains actively, we just want anyone else doesn't buy these domains. In this case, we mark the status field as "passive". Let's say we have some parked domains. In this case, we mark these domains as passive. In my company, we have some parked domains and domains not used. We mark these domains as passive. I hope my answer is clear enough. Have a nice day :) |
Beta Was this translation helpful? Give feedback.
-
Hi Süleyman, thanks, very well especially now that at the end of the year the workload slowly starts to ebb down. I hope you're fine, too, and the heavy storms in Istanbul haven't affected you too much. I get your point with the "Status" field, that makes sense. In fact, it's pretty exactly when my suggestion for its usage ist: Flag a domain as "inactive" when it isn't actually used but reserved, in preparation or for whatever other reason not to be used as a data source. It is just the term "Passive" that is confusing. For that purpose it would make sense to build on the status field in a way that makes it more useful. I see two possible ways to proceed:
(I would rather avoid "Passive" as it is a bit confusing as to what it means)
After your clarification I think the first option makes more sense as it will give you finer-grained control over what status a domain within your environment can have. As for the automatic PTR generation for records in non-active zones, there are two options as well:
The former solution has the advantage of being able to reserve IP addresses without making them active immediately (but with conflict checking etc. in place), the second one would find conflicts only when a formerly inactive zone eventually gets activated but make it possible to prepare a replacement of a currently active zone without caring about duplicate IP addresses. Both variants have their merits, but intuitively I would tend to the first one, because you'd be able to find conflicts earlier in the process, and the second behaviour can still be created by setting all records to "Disable PTR" while the zone is being prepared, then switching that flag off after the old zone is removed. What do you think? Cheers, Pete. |
Beta Was this translation helpful? Give feedback.
-
Hi Pete Sorry for the late response. As you said, the first option makes more sense. And maybe we can add "parked" as an option. Is this OK for you? And for PTR. I am not a master at PTR stuff. Whichever you choose, that's OK for me. Have a nice day. |
Beta Was this translation helpful? Give feedback.
-
Hi Süleyman, sure, "parked" makes sense as well - the main advantage of having multiple states is the option to add anything that helps organising stuff, after all. So I'll have a go at redesigning that part and adding the functionality to create reverse records for inactive zones, but mark them as "inactive" to see how it works out. And afterwards (hoping that the year-end rallye is finally over) I'll have a look at views ... A nice day to you, too, Pete. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
while I was working on getting a bit of documentation (see PR #106) on Netbox DNS in place, I stumbled across an issue that I had been ignoring for a while.
Zones have (and always had, it's nothing that was added recently) a "status" field that is required and can have the values "Active" or "Passive". I must admit that when I tried to document it I had no idea what the status of a zone might signify. In DNS there is no such property of a zone (unless I'm missing something, which is definitely possible) by itself, only perhaps its status on a given name server - the name server can either have the primary zone data, or it might be a secondary and receive the zone via AXFR/IXFR. But in any case it's nothing specific to the zone.
One idea what to do with the field is to slightly change the values to "Enabled" and "Disabled". That would make much sense for zones that are not in production yet in the way that disabled zones would not be used by a provisioning system that uses Netbox DNS data, and - more importantly - they would not create PTR records in the reverse zones, which is not a good idea at all if the zone is not actively used yet.
I would add a new "Enabled" (or rather "Disabled", as "Enabled" should be the default) field, but I thought I'd first ask if you have any ideas or plans what else to do with the "Status" field.
Cheers,
Pete.
Beta Was this translation helpful? Give feedback.
All reactions