Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] - Manipulating DNS Records without the RecordsIDs #70

Open
axos88 opened this issue Jan 20, 2020 · 4 comments
Open

[Feature] - Manipulating DNS Records without the RecordsIDs #70

axos88 opened this issue Jan 20, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@axos88
Copy link

axos88 commented Jan 20, 2020

Finding the record IDs is unnecessary complexity. The same arguments for create should be able to be used for update.

Describe the solution you'd like

Two solutions:

  1. Create should have a flag for --upsert. If a record with that domain, name, and type alredy exists, overwrite the data and ttl fields. If there are multiple matches it should probably be an error (unless an --allow-multiple flag is set?)

  2. Update/delete should not require a recordID. Supplying --name --type should act as filters. If there is only one matching record, it should update/delete the data and ttl. If there are more same case as above

If the record is unique (e.g. zero or only one matching record):

  • update should of the data field and ttl should be performed

Additional context
The API will feel more natural and easier to script.

@axos88 axos88 added the enhancement New feature or request label Jan 20, 2020
@ddymko
Copy link
Contributor

ddymko commented Jan 20, 2020

Hey @axos88

We want to keep all of the available crude actions as their own CLI command.

As for removing the recordIDs those are the unique identifiers for the API call. If we were to change to this we would then add more API calls to validate that a domain that was passed in exists to your user or even the --name or --type. We want to keep the API calls back and forth to a minimum given that V1 of the API has a rate limit of 3r/s. This is something that we are currently working on improving.

@axos88
Copy link
Author

axos88 commented Jan 21, 2020

I mean that's fine, sure, I understand wanting to keep a low-level interface which is basically just a facade in front of the API endpoints.

But I don't think there is anything holding you back from adding new, more advanced operations.
During the setup of my system if I want to update the DNS data for a particular record, with or without the cli abstracting it away, I need to make those calls anyways. Without built-in support, it's just more complicated for me to do, but not having support for these seemingly (well at least for me & my use-case) ubiquitous operations doesn't change the fact that I will be making those API requests anyways.

As a user I don't really care (nor should I) about how the API is laid out. I want a simple, and - best case scenario - efficient way to express and do what I want. And when you - as a user - think about DNS, you most certainly say I want to update the DNS record from foo.example.com to point to 1.2.3.4, rather than Let me take a look at the RecordID for foo.example.com. Okkkay. Now I want to update the DNS record with ID a135bd to point to 1.2.3.4

@axos88
Copy link
Author

axos88 commented Jan 21, 2020

So maybe instead of modifying the current operations the better course of action would be to add an "update++" operation :)

@ddymko
Copy link
Contributor

ddymko commented Jan 21, 2020

@axos88

Definitely the better approach would be to create a new command in the CLI 👍

I may not have time to get to making this enhancement anytime soon. So if you or anyone else wants to make this enhancement please feel free!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants