mailinabox
mailinabox copied to clipboard
mail-in-a-box
Adding the ability for non admin users to set dns records
It would be useful if you could create non admin users that are able to set dns records on specific domain names or subdomains. The use case here is I have a few devices pinging mailinabox as a ddns. It makes me a little uncomfortable that my admin user password is sitting on all of these devices so if one was compromised, so would my email.
Interesting concept, but likely outside the scope of MiaB ...
So you are proposing something such as a DNS admin which can change just DNS? I really do not know that there would be enough overall demand for such a feature as I imagine that the number of people who use dDns in the first place is relatively small.
On another similar note, it would be very useful for the creation of an admin user which was able to change ONLY mailboxes/aliases on a domain that admin user is assigned to maintain. If this feature were added, what you propose could be a minor tweak ....
Unfortunately, I am strongly against this in a general way. DNS changes are administrative changes and can be used to take over ownership of domain names.
I would be open to a safe mechanism that allowed for a sort of dynamic DNS service, but it would have to be severely constrained to not create any new security issues.
I actually use my box for dynamic DNS, but I found a cheat to avoid storing my admin password on the workstation that is calling the API. Since I already have a password-less SSH key for my Mail-in-a-Box on the workstation, I run:
curl -X PUT --user $(ssh box cat /var/lib/mailinabox/api.key): https://boxhostname/admin/dns/custom/dynamic.boxhostname
I am interested in using ddclient to control the mail-in-a-box hosted dynamic DNS along side the other more mainstream providers in a single place.
This ticket seems like a good place to discuss the trust model and implementation specifics.
I absolutely agree with DNS changes are administrative changes and can be used to take over ownership of domain names in all instances except Dynamic DNS which is a very specific user level feature.
Is there any scope to move on this here?
@JoshData How do you feel about a checkbox or something next to the DNS records that when checked gives you an API key which can be used to update that record only. I was originally thinking of a kind of DNS only user that would be controlled by an admin and regular users would not have access to DNS changes.
Agreed! Awesome idea 👍 That would allow for a very specific subdomain delegation. We could ad a nice warning message telling people what it means to delegate DNS records. It would be cool if it was limited to the record type too. So for instance subdomain-A or subdomain-CNAME.
It would be cool if it was limited to the record type too. So for instance subdomain-A or subdomain-CNAME.
Right.
A good way to start might be to make this a manual process. We can have a separate configuration file that maps qname-rtype pairs to passwords. And the DNS record API endpoints can be adjusted to accept either an admin API key or a password listed in this file.
Is it worth, since we are looking at a new API calls, to follow the format of an existing provider so that we inherit compatibility with various DNS update clients.
For example: https://sourceforge.net/p/ddclient/wiki/protocols/
I am confused... is the updating of a DNS record not an admin task? If a user is not trusted enough to be an admin why would she be trusted to be allowed to change DNS records?
I submitted a PR a while back that allowed an admin to give any user access to any API call. I use this in my fork so that I can create a user that can only update a DNS record and has no email access.
I think I've always said that unrestricted access to DNS is an administrative task but that if it's properly constrained, it could be made to be not an administrative task.
I think I've always said that unrestricted access to DNS is an administrative task but that if it's properly constrained, it could be made to be not an administrative task.
This PR might be a useful starting point for folks wishing to implement this.
Is it worth, since we are looking at a new API calls, to follow the format of an existing provider so that we inherit compatibility with various DNS update clients.
For example: https://sourceforge.net/p/ddclient/wiki/protocols/
Back reference: this has been requested upstream at ddclient using current API scheme
https://github.com/ddclient/ddclient/issues/379