ERPNext DNS-Multitenant - disable recursion on the DNS Server

Community German Community
1

Hello,
I installed on a german V-Server Frappe and ERPNext in a multi tenant setup. I used following install routine:

All ERPNext subdomains are with ssl secured via Let’s Encrypt.

All subdomains are registered at my domain provider and the dns a-record is set to the IP of my virtual ubuntu 18.04 cloud server.

With this server running i’ve got an email from our german state department of information security. They said i have an “open dns resolver” running. It is just a hint from them because this can be used for DDoS-Reflection/Amplification-attacks and they advice to convert that “open dns resolver” by disable recursion or limit recursion to trusted clients in the DNS server’s configuration.

How can i solve this problem with my current setup?

Thanks for your advice

2

The advice of the federal office for information security is linked here:

https://www.bsi.bund.de/EN/Topics/IT-Crisis-Management/CERT-Bund/CERT-Reports/HOWTOs/DNS-Open-Resolver/DNS-Open-Resolver_node.html

3

I’m running Linux Ubuntu 18.04.3 LTS on a virtual cloud server based in germany.

4

My ERPNext DNS multitenant installation routine is:

apt update && apt upgrade -y && apt autoremove -y
apt-get install build-essential python3-setuptools python3-pip
wget https://raw.githubusercontent.com/frappe/bench/master/playbooks/install.py
adduser [username]
usermod -aG sudo [username]
python3 install.py --production --python python3 --user [username]
reboot
login [username]
cd frappe-bench
bench update
cd
bench init [bench-name]
cd [bench-name]
bench update
bench get-app erpnext GitHub - frappe/erpnext: Free and Open Source Enterprise Resource Planning (ERP)
bench config dns_multitenant on
bench new-site blank
bench new-site sub1.domain.de
bench new-site sub2.domain.de
bench new-site ….domain.de
bench --site sub1.domain.de install-app erpnext
bench --site sub2.domain.de install-app erpnext
bench --site ….domain.de install-app erpnext
cd bench/sites
rm currentsite.txt
bench setup nginx
sudo service nginx reload
sudo bench setup production [username]
sudo -H bench setup lets-encrypt sub1.domain.de
sudo -H bench setup lets-encrypt sub2.domain.de
sudo -H bench setup lets-encrypt ….domain.de

3 Likes
5

Hi you best refer this to your DNS service provider.

The problem has to do with how they have configured the name space zones of your domain and subdomains, and authoritative (trusted) servers that answer a query for a host lookup.

Presumably the general risk here is possibly a server can be compromised or say a rogue untrusted server added to the set of trusted servers?

1 Like
6

@clarkej

At my domain provider i have only three subdomains. Each domain is via A-Record redirected to my virtual cloud server with a separate site (name of subdomain) of my bench. I have no more subdomains listed at my domain provider. All sites are configured with nginx as multitenant.

I have one more blank bench site, which is directly reachable with the v-server ip. That was the only way to get a multitenant setup workable because i couldn’t set up ssl encrypting for the default site, only the following sites have succesfully ssl encrypting (https). Every time I tried there was the “Sorry! We will be back soon.” notification.

Is maybe this the error? I think that maybe nginx is the reason.

Need some help :slight_smile:

7

My suggestion is limited to this issue here:

How to sort out your multitenant ssl encryption case, is to my mind a distinct separate problem.

8

I had the same experience with our vultr servers. I had to add enable firewall manually, just keeping port 443 and 80 open for incoming.
Rest all closed for incoming.

This had solved the issue I guess. I hope this is the real solution if not then i would be interested to know.

9

Yes, quite likely your cloud provider shares responsibility with your dns provider for name space resolution and query results - so best to find a dns expert to run say nslookup tests to identify which one is the culprit!?

10

This report tool may give you insight into the ‘open recursive’ resolver problem you face https://zonemaster.iis.se

1 Like
11

Hello Curt,

I am in your same exact situation.

I also got a warning today for my recently installed server from the BSI telling me that my server has DNS open-resolver enabled.

I am looking into this.

None of my other servers were on the same situation.

I got a new cloud server a few days ago, and ported my previous v11 installation to it. I am supposing that my previous server was not on the same situation, as I had it for several years and never received the warning, but I can check it.

I am recreating the steps done, because at the moment I don’t know what is producing the dns open-resolver situation. I don’t have Bind9 installed.

I am also in Ubuntu 18.04. By now what I have seen is:

1.- Create server from Ubuntu 18.04 Hetzner image- No problem
2.- After installing ERPNext I check again and now the server is a dns open-server

So I think that definitely this is something related to ERPNext.

I failed to configure the firewall this time and I am sure that this stops the thread, but I wonder why is ERPNext doing this by default and if this might be mitigated to enhance the security by default.

I can do basic things with server, but I am totaly blank with dns related matters.

Thanks and kind regards,

Alb

12

Hi,

On my previous message I forgot to say that I am with v12 now, but until a few days ago I was with v11.

Thanks and kind regards,

Alb

13

Hi,

I found that the open dns resolver is coming from dnsmasq.

I imagine dnsmasq is installed at some point of the EasyInstall ERPNext installation.

I am going to see if I am able to configure dnsmask to only allow local dns queries

Thanks and kind regards,

Alb