Hello there, New to this platform, but already love it. I have setup my own Debian 10 master-slave forward/reverse DNS setup with nginx and apache, respectively, setup a domain and several vhosts, all of them using free, valid certs. Everything seems to be working beautifully. Now I'd need to do something maybe rather uncommon. I need to properly resolve domain names to their real IP addresses only for the DNS records already configured on the administration panel; for the rest of the DNS queries my two servers receive, i.e. for domains that are not configured on these machines, I would like to reply always with the same IP address, that points to another machine I already run elsewhere. I understand I can configure wildcard DNS for subdomains, but what can I do for root domains?
I suspect you can't do that from the ISPConfig interface, but should be simple enough by just editing your named.conf
Bummer... thanks for your opinion! Manually editing named.conf... how? And will this break or hinder manageability through the ISPConfig interface?
You need to login to the server and edit that file, probably as root. Eg. I ssh to the server as a normal user (direct root ssh should not be allowed), then run either 'su -' or 'sudo -i' to become root, depending on the system, then open an editor, eg. I would use 'vi /etc/bind/named.conf', though you might use the 'nano' editor if you're new to unix cli (I believe the Perfect Server guides use nano). As for what to put in named.conf, you can find examples searching for 'bind config captive portal' or similar, eg. just checking the first hit it shows example config. No, editing named.conf won't stop the ui from working (unless you make a typo, etc.). ISPConfig does manage named.conf.local though, so don't make your changes there or they'll be gone the next time it is recreated.
Yes, my question was about what to put in the named.conf file, actually. Ok, thanks for pointing me in the right direction!
I have no clue, what that could be good for and it has the potential to break any client which uses your dns server (probably your own server). If you tell us, what you really want to achieve, there is most probably a better solution out there.
I have a list of clients that connect through my network. Everyone's using DNS servers of their choice. I would like to show a fixed page with instructions for some of them, no matter which website they try to visit. To achieve this result I am thinking about putting them in an address list and redirecting their DNS requests to my own server using a rule on my firewall. If I'm not mistaken, narrower DNS zones have precedence over larger ones (not an expert with DNS here), so having set the few zones and records I care about, and catching the rest (zone ".") sounds just fine to me. The only thing that would bother me is the validity of HTTPS certificates, but that may still be acceptable. Of course I'm open to new ideas, so don't be shy
If your needs grow in what your walled garden is doing, you might look into RPZ to see if it fits. Note that dns over http(s) is growing, for better or worse, so a dns intercept approach is increasingly less effective.
RPZ looks interesting! But at the moment it is out of question, I need a free solution for the time being. So I was looking at the named.conf way. I see it includes named.conf.default-zones, and that in turn already includes a "." zone. How do I deal with that? Do I need to edit it, or will putting a new "." zone in named.conf override the default-zones file?
Are all clients connecting in your intranet? Set them up to use your name server, or a name server you control. Then that name server can answer the way you want.
Sure, and thanks for your opinion, my question was rather about how to configure the DNS server to catch all requests. As has already been said, ISPConfig can't do it on its own, so...
Right, I simply meant to point out that feature which you might use for your own config if it fit down the road, but for the simpler setup you intend now it's not needed. Creating another "." zone should produce an error since the zone is already defined. You should either edit named.conf.default-zones to do what you need, or copy the other pieces (all but "." zone) to another local conf file and include that (from named.conf) instead of named.conf.default-zones.
Good! So I'll just comment out the default section and add another one to suit my needs. Thank you so much for your help!!
Back again! Now the system always replies to DNS requests with the same address, unless the requested domain is already included in a zone configured on the same server. On top of this, I'm using Apache2 rewrite rules to redirect to a standard page. My setup is not really identical to the one in the link that Jesse provided, I had to customize it a little bit, but it's still very similar. Turns out the system works rather well, and does exactly what I wanted. I owe you a beer, Jesse! Just a few notes: - sites using https will obviously return a certificate error, and there's nothing we can do about it... right? - I am using Code: RewriteRule ^(.*)$ https://subdomain.domain.tld/ [L] which does the job, but suppose I open https://xx.yy.zz/something/index.php, the address bar will change to read https://subdomain.domain.tld/something/index.php. It would be nicer to keep showing https://xx.yy.zz/something/index.php, despite the content coming out from the rewrite. Unfortunately I couldn't achieve this. Any suggestion?
a) mod_proxy instead of rewrite? b) If this is the only page on that IP, you can use a wildcard domain in Apache to serve the same page for all domains. Will keep domain intact, but fail with certificates c) Redirect could help with certificate, but will change domain.
a) I will have to read how that works, thank you for the tip! b) no, that's a shared IP c) then it's worth leaving things the way they are now, rather than changing In the meantime, any other suggestion is welcome
That's pretty much it, if you want the domain displayed in the browser to remain the same, you'll use a proxy. If you simply want to have another option, you could use an external proxy ahead of the server; that is more complex and there is probably no reason to consider it in your case, just use mod_proxy as suggested.
