Give control to 3rd party

I want to give a 3rd party control over DNS-records but I do not want him to be able to change the login
e-mail address or password. Is that possible?

Cheers, Chris

Hi Chris,

thanks for posting and welcome to deSEC!

@peter is currently working on this. You can track the status at https://github.com/desec-io/desec-stack/issues/347

We’re interested in your precise usage scenario! Would you be willing to share it here or at GitHub?

Thanks,
Nils

Hi Nils,

What I want:

  • possibility to have multiple users sign in with different rights.
  • which rights: assign the right to create/modify groups of DNS-records like MX- or TXT-records and the right to modify an existing record for example:

I don’t want certain users to have the right to create/change any MX-records.
I don’t want certain users to have the right to change an existing record like www.domain.de

Sorry for the late reply,

Chris

Hi Chris,

Thank you for the feedback. Can you please clarify the next two points (which seem to be a contradiction to me):

  • “assign the right to create/modify groups of DNS-records like MX- or TXT-records and the right to modify an existing record”
  • “I don’t want certain users to have the right to create/change any MX-records”

Stay secure,
Peter

Hi Peter,

it was late last night when i wrote that…

I want to set the following rights for a person:

Allow to view “X-type”-records but not allowed to create/change/delete “X-type”-records.
Allow to create “X-type”-records and change/delete records created by the same person
Allow to create “X-type”-records and change any record created by whomever (full allow)

hope this makes it a bit clearer.

Have a nice day,

Chris

Hi Chris,

To clarify, the notion of “users” is not the best one here, as all records of a domain are owned by the same user (the deSEC account owner). A user can create API tokens, and those may have different permissions. So, let’s focus on how these permissions could be implemented.

Your proposal requires that we keep track of which token was used when creating a certain DNS record. Apart from the necessary book-keeping logistics, this comes with a bunch of complications that may not be immediate obvious, but they are security relevant. For example, someone who can create SVCB records (we will start supporting them this winter) will effectively be able to override A/AAAA records. For many, this would be rather unexpected, and we’d like to reduce the potential for this type of accidental misconfiguration. So, I’m leaning towards not going down this route … not to mention other complications, such as what should be done when a token that owns a record is removed. Should the record also be removed, and why (not)?

Frankly, I also did not understand yet what the use case for this is. Why do you need this, and what other approaches did you rule out, and why?

Cheers,
Peter

use case is obvious:

a firm owns a domain and some employee shall manage some limited aspects of the dns records.

one way to achieve this is to use cloudns.net for some subdomain maybe. they do this sort of delegation.