Is there any way to get the configuration option allowed_admin_ranges to support the use of host names, instead of just IP addresses?
That would allow for those with a dynamically updated IP address but a fixed host name (so to speak) to be whitelisted as well.
Like this, only ip addresses are supported.
You could either try to change the range so large, that you cover the whole range of your providers ip range (perhaps with ipv6, there are less different ranges) but in terms of security you just limit to the range of customers of your ISP.
You could run a cronjob that updates the range settings. Or if you are on Linux, you can probably have a small bash-script that gets your current ip, and connects via SSH to the server and updates the ip.
The basic idea is probably that you can limit access just to computers within your companies network, and if you access from external, you can connect through a VPN. So I am not sure if your use case would justify a feature request. To do something like for mail servers with the sender policy framework where you manage authorized ranges via DNS:
Thank you for the reply. I can’t use a “wide enough range” since this may be a “road warrior” laptop, getting very different IP addresses every time it’s started.
Yes, I realize that I can have a cron job update Nextcloud settings. But, tbh, I really do think this setting should accept a hostname and/or IP addresses.
In this case, you’ll also get a lot of different “hostnames”, because the hostname in this context would be the reverse DNS (PTR) record for the public IP address you’re connecting from, e.g. xx.yy.zz.aa.dynamic.yourisp.tld, which will change as well if the IP changes.
The solution for your use case is to set up a VPN and add the local IP assigned by the VPN server to the client into the allowed_admin_ranges.
No, I will not get “a lot of different hostnames”. I will get “roadwarrior.mydomain.com” every time, because that’s what I have scripted. Every time the “road warrior” starts, it will dynamically update a hostname of mydomain.com (roadwarrior.mydomain.com) to the correct IP address.
So, there’s definitely a case here (IMHO).
You can define a reverse-DNS entry for an IP. But of course you can hava a lot of DNS entries pointing to the same IP.
In your case, you’d need to resolve all the hostnames in the config file ip ranges, get a list of ips, then check if one of these ips corresponds to the current client’s ip.
You can try to create a feature request for that. But it is a very special demand, if I were to implement something DNS-based, I’d rather go for something similar to the Sender Policy Framework. IPs can be used by different users (carrier-grade NAT), it’s a lot of work to implement, still things can go wrong and there is limited benefit of such a feature…
I think the VPN is a much better solution and can be used right now (it does not need any additional implementations in Nextcloud).
Well, it still wouldn’t work, because there’s no way for Nextcloud to know the hostname of the device you’re connecting from, even with a reverse lookup.
The only way this could work is if you set up a PTR record for a specific IP that resolves to roadwarior.yourdomain.com, but then it would still only work from that specific IP, and it would work for all devices connecting from that specific IP. Also, since only the owner of the IP can set up PTR records, there’s no way to change the record dynamically, or in fact you can’t change it at all for dynamic IPs. (See also my next post)
If at all, you would have to run an additional script on the Nextcloud server that determines the current IP address of roadwarior.yourdomain.com via a normal DNS lookup, and then updates the allowed_admin_ranges accordingly.
Afaik, for dynamic IP addresses it’s not possible to get a custom PTR record, and it would not make much sense in the first place, because every time the IP changes, the custom PTR record would have to be changed to point to the new IP address as well.
With a business contract, and fixed IP addresses it’s possible to set your own PTR record with most ISPs, but then you could as well just add the IP to the allowed_admin_ranges 
Right … there seems to be a lot of confusion about what is possible and what is not, and how this could possibly be used.
Let’s just say that I have a use case, and I know how to dynamically modify a zone file, and I have been doing this since 1995; so let’s just end the thread here because all I hear is “It’s not a good idea” and “It’s impossible”, and so on.
It was just a suggestion. I don’t understand the reluctance, because it’s quite easy to implement. You either match an IP address, or you match a hostname.
Thanks for your time.
Because it simply wouldn’t work the way I think you think it would.
The only way it would work is if the Nextcloud first did a (forward) DNS lookup for roadwarior.domain.com for each request, and if the IP from the DNS lookup matches the one in the request, it would need add it to the allow list. This would be a pretty expensive task to do for every request, and would almost certainly impact performance, and all just to save you the effort of setting up a VPN.
If you really want something like this, maybe you could script it yourself, as I mentioned in my previous post (you are already halfway there with your dynamc DNS script). Or maybe you could put a WAF that offers such a feature in front of your Nextcloud and deal with all the hassles that brings, or you could just follow best practices like only exposing admin interfaces locally and using a VPN.
You may be able to use the gethostbyname() hack (it’s not officially supported by some people use it for other config values).
e.g. After upgrade to 29 getting trusted_proxies error - #8 by flotillaropes
@joho68 …which, by the way, also relies on forward DNS requests. There’s no way for a server to know what the hostname of a device is connecting from a given IP, dynamically setting up CNAME or A records pointing to those IP addresses via a script won’t change that. The server would always have to proactively check via forward lookups whether the request from a given IP should be allowed or not, which imho makes this approach extremely inefficient.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.